เมื่อใดที่คุณควรใช้คลาสส่วนตัว / ชั้นใน

เพื่อชี้แจงสิ่งที่ฉันถามคือ

public class A{
    private/*or public*/ B b;
}

เมื่อเทียบกับ

public class A{
    private/*or public*/ class B{
        ....
    }
}

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

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

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

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

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

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

ในความคิดของฉันมันเป็นตำรวจที่เป็นธรรมที่จะใช้คลาสที่กำหนดภายในสำหรับคลาสที่ใช้สั้น ๆในคลาสเพื่อให้งานเฉพาะ

ตัวอย่างเช่นหากคุณต้องการผูกรายการข้อมูลที่ประกอบด้วยสองคลาสที่ไม่เกี่ยวข้อง:

public class UiLayer
{
    public BindLists(List<A> as, List<B> bs)
    {
        var list = as.ZipWith(bs, (x, y) => new LayerListItem { AnA = x, AB = y});
        // do stuff with your new list.
    }

    private class LayerListItem
    {
        public A AnA;
        public B AB;
    }
}

หากคลาสภายในของคุณถูกใช้โดยคลาสอื่นคุณควรแยกคลาสนั้น ถ้าคลาสภายในของคุณมีตรรกะใด ๆ คุณควรแยกมันออก

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

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

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

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

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

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

// async_op.h -- someone else's api.
struct callback
{
    virtual ~callback(){}
    virtual void fire() = 0;
};

void do_my_async_op(callback *p);



// caller.cpp -- my api
class caller
{
private :
    struct caller_inner : callback
    {
        caller_inner(caller &self) : self_(self) {}
        void fire() { self_.do_callback(); }
        caller &self_;
    };

    void do_callback()
    {
        // Real callback
    }

    caller_inner inner_;

public :
    caller() : inner_(*this) {}

    void do_op()
    {
        do_my_async_op(&inner_);
    }
};

ในสิ่งนี้ do_my_async_op ต้องการวัตถุชนิดการเรียกกลับที่จะส่งผ่านไป การติดต่อกลับนี้มีลายเซ็นของฟังก์ชันสมาชิกสาธารณะที่ใช้ API

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

ประโยชน์ของสิ่งนี้คือคุณแน่ใจว่าไม่มีใครสามารถเรียกฟังก์ชั่นสมาชิก "fire ()" สาธารณะได้

ตาม Jon Skeet ใน C # in Depth การใช้คลาสที่ซ้อนเป็นวิธีเดียวที่จะใช้singleton safe-threaded ที่ปลอดภัยที่ขี้เกียจอย่างสมบูรณ์(ดูรุ่นที่ห้า) (จนถึง. NET 4)

คลาสส่วนตัวและภายในใช้เพื่อเพิ่มระดับของการห่อหุ้มและซ่อนรายละเอียดการใช้งาน

ใน C ++ นอกเหนือจากคลาสส่วนตัวแนวคิดเดียวกันนี้สามารถทำได้โดยการใช้เนมสเปซที่ไม่ระบุชื่อของคลาส cpp นี้ทำหน้าที่อย่างดีเพื่อซ่อน / แปรรูปรายละเอียดการใช้งาน

มันเป็นความคิดเดียวกันกับคลาสภายในหรือไพรเวต แต่ในระดับที่ยิ่งใหญ่กว่าของการห่อหุ้มเนื่องจากมองไม่เห็นภายนอกหน่วยการรวบรวมไฟล์ ไม่มีสิ่งใดปรากฏในไฟล์ส่วนหัวหรือมองเห็นภายนอกในการประกาศของคลาส