เหตุใดเขตข้อมูลส่วนตัวจึงเป็นประเภทส่วนตัวไม่ใช่เช่นนั้น

ใน C # (และภาษาอื่น ๆ อีกมากมาย) การเข้าใช้ฟิลด์ส่วนตัวของอินสแตนซ์อื่นประเภทเดียวกันนั้นถูกต้องตามกฎหมาย ตัวอย่างเช่น:

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if (anotherFoo.aBool) ...
    }
}

เนื่องจากข้อกำหนดC # (ส่วน 3.5.1, 3.5.2) ระบุว่าการเข้าถึงฟิลด์ส่วนตัวอยู่ในประเภทไม่ใช่อินสแตนซ์ ฉันกำลังคุยเรื่องนี้กับเพื่อนร่วมงานและเรากำลังพยายามหาเหตุผลว่าทำไมมันถึงใช้งานได้ (แทนที่จะ จำกัด การเข้าถึงอินสแตนซ์เดียวกัน)

อาร์กิวเมนต์ที่ดีที่สุดที่เราสามารถหาได้คือการตรวจสอบความเท่าเทียมกันซึ่งคลาสอาจต้องการเข้าถึงฟิลด์ส่วนตัวเพื่อกำหนดความเท่าเทียมกันกับอินสแตนซ์อื่น มีเหตุผลอื่นอีกไหม? หรือเหตุผลทองบางอย่างที่หมายความว่ามันต้องทำงานอย่างนี้หรือบางสิ่งจะเป็นไปไม่ได้อย่างสมบูรณ์?

ผมคิดว่าเหตุผลหนึ่งที่มันทำงานในลักษณะนี้เป็นเพราะการปรับเปลี่ยนการเข้าถึงทำงานที่รวบรวมเวลา ดังนั้นการพิจารณาว่าวัตถุที่กำหนดนั้นเป็นวัตถุปัจจุบันหรือไม่ไม่ใช่เรื่องง่าย ตัวอย่างเช่นพิจารณารหัสนี้:

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

คอมไพเลอร์สามารถคิดได้ว่าotherเป็นจริงthisหรือไม่? ไม่ได้ในทุกกรณี อาจมีคนโต้แย้งว่าสิ่งนี้ไม่ควรรวบรวม แต่นั่นหมายความว่าเรามีเส้นทางรหัสที่สมาชิกอินสแตนซ์ส่วนตัวของอินสแตนซ์ที่ถูกต้องไม่สามารถเข้าถึงได้ซึ่งฉันคิดว่าแย่กว่านั้น

กำหนดให้เฉพาะประเภทระดับมากกว่าวัตถุระดับการมองเห็นเพื่อให้แน่ใจว่าปัญหาคือเวไนยเช่นเดียวกับการทำให้สถานการณ์ที่ดูเหมือนว่ามันควรจะทำงานจริงการทำงาน

แก้ไข : ประเด็นของ Danilel Hilgarth ที่การให้เหตุผลนี้ย้อนหลังมีข้อดี นักออกแบบภาษาสามารถสร้างภาษาที่พวกเขาต้องการและผู้เขียนคอมไพเลอร์จะต้องสอดคล้องกับมัน ดังที่กล่าวไปแล้วนักออกแบบภาษามีแรงจูงใจที่จะทำให้นักเขียนคอมไพเลอร์ทำงานได้ง่ายขึ้น (ในกรณีนี้มันง่ายพอที่จะโต้แย้งว่าสมาชิกส่วนตัวสามารถเข้าถึงได้ผ่านทางเท่านั้นthis (ไม่ว่าจะโดยทางตรงหรือทางอ้อม)

อย่างไรก็ตามฉันเชื่อว่าสิ่งนี้ทำให้เกิดความสับสนมากขึ้นกว่าที่ควรจะเป็น ผู้ใช้ส่วนใหญ่ (รวมตัวเอง) จะพบว่ามัน unneccessarily จำกัด ถ้าโค้ดข้างต้นไม่ได้ทำงาน: หลังจากทั้งหมดที่ฉันข้อมูลที่ฉันพยายามที่จะเข้าถึง! ทำไมฉันจึงควรจะต้องไปผ่านthis?

ในระยะสั้นฉันคิดว่าฉันอาจคุยโวเรื่องนี้เพราะ "ยาก" สำหรับคอมไพเลอร์ สิ่งที่ฉันตั้งใจจะทำจริง ๆ ก็คือสถานการณ์ข้างต้นดูเหมือนว่าเป็นสิ่งที่นักออกแบบต้องการที่จะทำงาน

เนื่องจากจุดประสงค์ของการห่อหุ้มที่ใช้ในภาษา C # และภาษาที่คล้ายกัน * คือการลดการพึ่งพาซึ่งกันและกันของรหัสที่ต่างกัน (คลาสใน C # และ Java) ไม่ใช่วัตถุที่แตกต่างกันในหน่วยความจำ

ตัวอย่างเช่นถ้าคุณเขียนโค้ดในคลาสหนึ่งที่ใช้บางฟิลด์ในคลาสอื่นคลาสเหล่านี้จะถูกผนวกเข้าด้วยกันอย่างแน่นหนา อย่างไรก็ตามหากคุณกำลังจัดการกับรหัสที่คุณมีสองวัตถุของคลาสเดียวกันนั้นไม่มีการพึ่งพาพิเศษ คลาสจะขึ้นอยู่กับตัวเองเสมอ

อย่างไรก็ตามทฤษฎีทั้งหมดเกี่ยวกับการห่อหุ้มล้มเหลวทันทีที่มีคนสร้างคุณสมบัติ (หรือรับ / ตั้งค่าคู่ใน Java) และแสดงฟิลด์ทั้งหมดโดยตรงซึ่งทำให้คลาสเป็นคู่เหมือนกับว่าพวกเขากำลังเข้าถึงฟิลด์

_{* สำหรับการอธิบายประเภทของการห่อหุ้มดูคำตอบที่ยอดเยี่ยมของ Abel}

มีการเพิ่มคำตอบบางส่วนในหัวข้อที่น่าสนใจนี้แล้ว แต่ฉันไม่พบเหตุผลที่แท้จริงว่าทำไมพฤติกรรมนี้จึงเป็นแบบนี้ ให้ฉันลองดู:

ย้อนไปเมื่อวันวาน

อยู่ระหว่าง Smalltalk ใน 80 และ Java ในช่วงกลางยุค 90 แนวคิดของการวางแนววัตถุที่ครบกำหนด การซ่อนข้อมูลไม่ใช่แนวคิดดั้งเดิมที่มีให้เฉพาะกับ OO (กล่าวถึงครั้งแรกในปี 1978) ถูกนำมาใช้ใน Smalltalk เนื่องจากข้อมูลทั้งหมด (สาขา) ของชั้นเรียนมีความเป็นส่วนตัวทุกวิธีเป็นแบบสาธารณะ ในระหว่างการพัฒนาใหม่ของ OO ในยุค 90 เบอร์ทรานด์เมเยอร์พยายามทำให้แนวคิดของ OO เป็นรูปเป็นร่างขึ้นในหนังสือสำคัญของเขาObject Oriented Software Construction (OOSC)ซึ่งนับตั้งแต่นั้นมาก็ถือเป็นการอ้างอิงที่ชัดเจนเกี่ยวกับแนวคิดของ OO และการออกแบบภาษา .

ในกรณีของการมองเห็นส่วนตัว

ตามวิธีการของเมเยอร์ควรมีให้สำหรับชุดคลาสที่กำหนด (หน้า 192-193) สิ่งนี้ทำให้เห็นได้ชัดว่ามีการซ่อนตัวของข้อมูลที่ละเอียดสูงมากคุณลักษณะต่อไปนี้มีให้สำหรับ classA และ classB และการสืบทอดทั้งหมด:

feature {classA, classB}
   methodName

ในกรณีที่privateเขากล่าวว่าต่อไปนี้: โดยไม่ต้องประกาศประเภทที่ชัดเจนในระดับของตัวเองคุณไม่สามารถเข้าถึงคุณลักษณะ (เมธอด / ฟิลด์) ในการโทรที่ผ่านการรับรอง คือถ้าxเป็นตัวแปรx.doSomething()ไม่ได้รับอนุญาต แน่นอนว่าการเข้าถึงที่ไม่ได้รับอนุญาตจะทำได้ภายในชั้นเรียนเอง

กล่าวอีกนัยหนึ่ง: เพื่ออนุญาตการเข้าถึงโดยอินสแตนซ์ของคลาสเดียวกันคุณต้องอนุญาตการเข้าถึงเมธอดของคลาสนั้นอย่างชัดเจน บางครั้งเรียกว่าอินสแตนซ์ส่วนตัวกับคลาสส่วนตัว

อินสแตนซ์ส่วนตัวในภาษาการเขียนโปรแกรม

ฉันรู้ว่ามีการใช้งานอย่างน้อยสองภาษาในปัจจุบันที่ใช้การซ่อนข้อมูลอินสแตนซ์ส่วนตัวเมื่อเทียบกับการซ่อนข้อมูลระดับส่วนตัว หนึ่งคือไอเฟลภาษาที่ออกแบบโดยเมเยอร์ซึ่งนำพา OO ไปสู่สุดขั้ว ภาษาอื่นที่เป็นทับทิมซึ่งเป็นภาษาที่ใช้กันทั่วไปในปัจจุบัน ในทับทิมprivateหมายถึง: "ส่วนตัวกับอินสแตนซ์นี้" "ส่วนตัวถึงกรณีนี้"

ตัวเลือกสำหรับการออกแบบภาษา

มีคนแนะนำว่าการอนุญาตให้อินสแตนซ์ส่วนตัวนั้นยากสำหรับคอมไพเลอร์ ฉันไม่คิดอย่างนั้นเพราะมันค่อนข้างง่ายที่จะอนุญาตหรือไม่อนุญาตการโทรไปยังวิธีการที่เหมาะสม หากเป็นวิธีส่วนตัวdoSomething()จะได้รับอนุญาตและx.doSomething()ไม่ได้เป็นผู้ออกแบบภาษาได้กำหนดความสามารถในการเข้าถึงอินสแตนซ์อย่างเดียวอย่างมีประสิทธิภาพสำหรับวิธีการและฟิลด์ส่วนตัว

จากมุมมองทางเทคนิคไม่มีเหตุผลที่จะเลือกทางเดียวหรืออื่น ๆ (โดยเฉพาะเมื่อพิจารณาว่า Eiffel.NET สามารถทำสิ่งนี้กับ IL ได้แม้จะมีหลายมรดก แต่ก็ไม่มีเหตุผลที่จะให้คุณลักษณะนี้)

แน่นอนว่ามันเป็นเรื่องของรสนิยมและตามที่คนอื่นพูดถึงแล้ววิธีการบางอย่างอาจจะยากกว่าในการเขียนโดยไม่ต้องมีการมองเห็นในระดับชั้นของวิธีการและฟิลด์ส่วนตัว

เหตุใด C # อนุญาตให้มีการห่อหุ้มคลาสเท่านั้นและไม่ใช่การห่อหุ้มอินสแตนซ์

หากคุณดูที่เธรดอินเทอร์เน็ตในการห่อหุ้มอินสแตนซ์ (บางครั้งคำที่ใช้เพื่ออ้างถึงความจริงที่ว่าภาษากำหนดตัวดัดแปลงการเข้าถึงในระดับอินสแตนซ์เมื่อเทียบกับระดับคลาส) แนวคิดมักจะขมวดคิ้ว อย่างไรก็ตามการพิจารณาว่าภาษาสมัยใหม่บางภาษาใช้อินสแตนซ์การห่อหุ้มอย่างน้อยสำหรับตัวดัดแปลงการเข้าถึงส่วนตัวทำให้คุณคิดว่ามันสามารถใช้งานได้และเป็นสิ่งที่ใช้ในโลกแห่งการเขียนโปรแกรมสมัยใหม่

อย่างไรก็ตาม C # ดูเป็นเรื่องยากที่สุดในการออกแบบภาษา C ++ และ Java ในขณะที่ Eiffel และ Modula-3 อยู่ในรูปภาพด้วยเมื่อพิจารณาถึงคุณสมบัติหลายอย่างของ Eiffel ที่หายไป (การสืบทอดหลายแบบ) ฉันเชื่อว่าพวกเขาเลือกเส้นทางเดียวกับ Java และ C ++ เมื่อมาถึงตัวปรับการเข้าถึงส่วนตัว

หากคุณต้องการทราบว่าทำไมคุณควรลองจับ Eric Lippert, Krzysztof Cwalina, Anders Hejlsberg หรือใครก็ตามที่ทำงานบนมาตรฐานของ C # แต่น่าเสียดายที่ผมไม่สามารถหาบันทึกที่ชัดเจนในข้อเขียนC # Programming Language

นี่เป็นเพียงความคิดเห็นของฉัน แต่ในทางปฏิบัติฉันคิดว่าหากโปรแกรมเมอร์สามารถเข้าถึงแหล่งที่มาของชั้นเรียนได้คุณสามารถไว้วางใจพวกเขาอย่างสมเหตุสมผลด้วยการเข้าถึงสมาชิกส่วนตัวของชั้นเรียนอินสแตนซ์ ทำไมต้องผูกโปรแกรมเมอร์ไว้ทางด้านซ้ายเมื่อคุณได้มอบกุญแจให้แก่อาณาจักรแล้ว?

เหตุผลก็คือการตรวจสอบความเท่าเทียมกัน, การเปรียบเทียบ, การโคลนนิ่ง, การบรรทุกเกินพิกัด ... มันจะยุ่งยากมากหากจะใช้โอเปอเรเตอร์ + กับตัวเลขที่ซับซ้อน

ก่อนอื่นจะเกิดอะไรขึ้นกับสมาชิกสแตติกส่วนตัว? พวกเขาสามารถเข้าถึงได้โดยวิธีการคงที่? แน่นอนคุณจะไม่ต้องการที่แล้วเพราะคุณจะไม่สามารถเข้าถึงของคุณconsts

สำหรับคำถามที่ชัดเจนของคุณให้พิจารณากรณีของ a StringBuilderซึ่งนำมาใช้เป็นรายการเชื่อมโยงของอินสแตนซ์ของตัวเอง

public class StringBuilder
{
    private string chunk;
    private StringBuilder nextChunk;
}

หากคุณไม่สามารถเข้าถึงสมาชิกส่วนตัวของอินสแตนซ์อื่น ๆ ในชั้นเรียนของคุณคุณต้องดำเนินการToStringดังนี้:

public override string ToString()
{
    return chunk + nextChunk.ToString();
}

สิ่งนี้จะใช้ได้ แต่เป็น O (n ^ 2) - ไม่มีประสิทธิภาพมาก อันที่จริงแล้วนั่นอาจเอาชนะจุดประสงค์ทั้งหมดของการมีStringBuilderชั้นเรียนได้ตั้งแต่แรก หากคุณสามารถเข้าถึงสมาชิกส่วนตัวของอินสแตนซ์อื่นของคลาสของคุณเองคุณสามารถนำไปใช้ToStringโดยการสร้างสตริงที่มีความยาวที่เหมาะสมจากนั้นทำสำเนาที่ไม่ปลอดภัยของแต่ละอันไปยังตำแหน่งที่เหมาะสมในสตริง:

public override string ToString()
{
    string ret = string.FastAllocateString(Length);
    StringBuilder next = this;

    unsafe
    {
        fixed (char *dest = ret)
            while (next != null)
            {
                fixed (char *src = next.chunk)
                    string.wstrcpy(dest, src, next.chunk.Length);
                next = next.nextChunk;
            }
    }
    return ret;
}

การดำเนินการนี้เป็น O (n) ซึ่งทำให้มันเร็วมากและเป็นไปได้ถ้าคุณมีการเข้าถึงสมาชิกส่วนตัวของกรณีอื่น ๆ ของชั้นเรียนของคุณ

สิ่งนี้ถูกต้องตามกฎหมายอย่างสมบูรณ์ในหลายภาษา (C ++ สำหรับหนึ่ง) ตัวดัดแปลงการเข้าถึงมาจากหลักการห่อหุ้มใน OOP แนวคิดคือการ จำกัด การเข้าถึงภายนอกในกรณีนี้คือคลาสภายนอก คลาสที่ซ้อนกันใด ๆ ใน C # สามารถเข้าถึงได้โดยเป็นสมาชิกส่วนตัวของผู้ปกครอง

ขณะนี้เป็นตัวเลือกการออกแบบสำหรับนักออกแบบภาษา ข้อ จำกัด ของการเข้าถึงนี้สามารถทำให้สถานการณ์ทั่วไปที่ซับซ้อนบางอย่างเกิดขึ้นได้โดยไม่ต้องแยกหน่วยงานออกจากกันมากนัก

มีการสนทนาที่คล้ายกันที่นี่

ฉันไม่คิดว่ามีเหตุผลที่เราไม่สามารถเพิ่มความเป็นส่วนตัวอีกระดับซึ่งข้อมูลนั้นเป็นข้อมูลส่วนบุคคลสำหรับแต่ละอินสแตนซ์ ในความเป็นจริงแล้วนั่นอาจทำให้รู้สึกถึงความสมบูรณ์ของภาษา

แต่ในทางปฏิบัติจริงฉันสงสัยว่ามันจะมีประโยชน์จริงๆ ตามที่คุณได้ชี้ให้เห็นแล้วความเป็นส่วนตัวปกติของเรานั้นมีประโยชน์สำหรับสิ่งต่าง ๆ เช่นการตรวจสอบความเท่าเทียมกันรวมถึงการดำเนินการอื่น ๆ ส่วนใหญ่ที่เกี่ยวข้องกับอินสแตนซ์หลายประเภท แม้ว่าฉันจะชอบจุดของคุณเกี่ยวกับการรักษาข้อมูลที่เป็นนามธรรมซึ่งเป็นจุดสำคัญใน OOP

ฉันคิดว่ารอบตัวการให้ความสามารถในการ จำกัด การเข้าถึงในลักษณะนี้อาจเป็นคุณสมบัติที่ดีในการเพิ่มไปยัง OOP มันมีประโยชน์จริงเหรอ? ฉันจะบอกว่าไม่เนื่องจากคลาสควรเชื่อถือรหัสของตัวเองได้ เนื่องจากคลาสนั้นเป็นสิ่งเดียวที่สามารถเข้าถึงสมาชิกส่วนตัวจึงไม่มีเหตุผลที่แท้จริงที่จะต้องการข้อมูลนามธรรมเมื่อจัดการกับอินสแตนซ์ของคลาสอื่น

แน่นอนคุณสามารถเขียนรหัสของคุณได้ตลอดเวลาราวกับว่าเป็นส่วนตัวที่ใช้กับอินสแตนซ์ ใช้get/setวิธีการปกติเพื่อเข้าถึง / เปลี่ยนแปลงข้อมูล นั่นอาจจะทำให้โค้ดสามารถจัดการได้มากขึ้นถ้าคลาสอาจมีการเปลี่ยนแปลงภายใน

คำตอบที่ยอดเยี่ยมที่ได้รับข้างต้น ฉันจะเพิ่มส่วนหนึ่งของปัญหานี้คือความจริงที่ว่าการอนุญาตให้สร้างชั้นเรียนภายในตัวเองนั้นยังได้รับอนุญาตตั้งแต่แรก มันทำมาตั้งแต่ในตรรกะแบบวนซ้ำ "สำหรับ" การวนซ้ำตัวอย่างเช่นเพื่อใช้กลอุบายประเภทนั้นตราบใดที่คุณมีตรรกะในการสิ้นสุดการเรียกซ้ำ แต่การสร้างอินสแตนซ์หรือส่งคลาสเดียวกันภายในตัวเองโดยไม่สร้างลูปดังกล่าวอย่างมีเหตุผลจะสร้างอันตรายของตัวเองแม้ว่าจะเป็นกระบวนทัศน์การเขียนโปรแกรมที่ได้รับการยอมรับอย่างกว้างขวางก็ตาม ตัวอย่างเช่นคลาส C # สามารถยกตัวอย่างสำเนาของตัวเองในคอนสตรัคเตอร์เริ่มต้นได้ แต่ไม่ทำลายกฎใด ๆ หรือสร้างลูปเชิงสาเหตุ ทำไม?

BTW .... ปัญหาเดียวกันนี้ใช้กับสมาชิก "ที่ได้รับการป้องกัน" เช่นกัน :(

ฉันไม่เคยยอมรับกระบวนทัศน์การเขียนโปรแกรมอย่างเต็มที่เพราะมันยังมาพร้อมกับชุดของปัญหาและความเสี่ยงที่โปรแกรมเมอร์ส่วนใหญ่ไม่เข้าใจจนกระทั่งปัญหาเช่นปัญหานี้ลุกขึ้นและทำให้ผู้คนสับสนและท้าทายเหตุผลทั้งหมดในการมีสมาชิกส่วนตัว

แง่มุม "แปลกและแปลกประหลาด" ของ C # นี้ยังเป็นอีกหนึ่งเหตุผลที่การเขียนโปรแกรมที่ดีไม่มีส่วนเกี่ยวข้องกับประสบการณ์และความสามารถ แต่เพียงแค่รู้ถึงเทคนิคและกับดัก ..... เหมือนทำงานในรถ มันเป็นข้อโต้แย้งว่ากฎนั้นตั้งใจที่จะถูกทำลายซึ่งเป็นรูปแบบที่แย่มากสำหรับภาษาคอมพิวเตอร์ใด ๆ

สำหรับฉันแล้วดูเหมือนว่าถ้าข้อมูลเป็นแบบส่วนตัวกับอินสแตนซ์อื่น ๆ ของประเภทเดียวกันมันก็ไม่จำเป็นต้องเป็นประเภทเดียวกันอีกต่อไป ดูเหมือนว่ามันจะไม่ทำงานหรือกระทำเช่นเดียวกับกรณีอื่น ๆ สามารถปรับเปลี่ยนพฤติกรรมได้ง่ายขึ้นอยู่กับข้อมูลภายในส่วนตัวนั้น นั่นจะทำให้เกิดความสับสนในความคิดของฉัน

ฉันพูดอย่างหลวม ๆ โดยส่วนตัวฉันคิดว่าการเขียนคลาสที่ได้จากคลาสพื้นฐานมีฟังก์ชันการทำงานที่คล้ายกับที่คุณอธิบายด้วย 'การมีข้อมูลส่วนตัวต่ออินสแตนซ์' แต่คุณมีคำจำกัดความของคลาสใหม่ตามประเภท 'เฉพาะ'