วิธีที่ดีที่สุดในการเริ่มต้นการอ้างอิงของเด็กถึงผู้ปกครองคืออะไร


35

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

ฉันจะไม่ตรวจสอบว่ารหัสด้านล่างรวบรวมดังนั้นโปรดลองดูความตั้งใจของฉันถ้ารหัสไม่ถูกต้อง syntactically

โปรดทราบว่าตัวสร้างคลาสลูกของฉันบางคนใช้พารามิเตอร์ (นอกเหนือจากแม่) แม้ว่าฉันจะไม่แสดงใด ๆ

  1. ผู้เรียกมีหน้าที่ตั้งค่าพาเรนต์และเพิ่มในพาเรนต์เดียวกัน

    class Child {
      public Child(Parent parent) {Parent=parent;}
      public Parent Parent {get; private set;}
    }
    class Parent {
      // singleton child
      public Child Child {get; set;}
      //children
      private List<Child> _children = new List<Child>();
      public List<Child> Children { get {return _children;} }
    }
    

    ข้อเสีย:การตั้งค่าพาเรนต์เป็นกระบวนการสองขั้นตอนสำหรับผู้ใช้บริการ

    var child = new Child(parent);
    parent.Children.Add(child);
    

    ข้อเสีย:เกิดข้อผิดพลาดได้ง่าย ผู้เรียกสามารถเพิ่มชายด์ลงในพาเรนต์ต่างจากที่ใช้เพื่อเริ่มต้นเด็ก

    var child = new Child(parent1);
    parent2.Children.Add(child);
    
  2. ผู้ปกครองตรวจสอบว่าผู้โทรเพิ่มลูกกับผู้ปกครองที่มีการเริ่มต้น

    class Child {
      public Child(Parent parent) {Parent = parent;}
      public Parent Parent {get; private set;}
    }
    class Parent {
      // singleton child
      private Child _child;
      public Child Child {
        get {return _child;}
        set {
          if (value.Parent != this) throw new Exception();
          _child=value;
        }
      }
      //children
      private List<Child> _children = new List<Child>();
      public ReadOnlyCollection<Child> Children { get {return _children;} }
      public void AddChild(Child child) {
        if (child.Parent != this) throw new Exception();
        _children.Add(child);
      }
    }
    

    ข้อเสีย:ผู้โทรยังคงมีกระบวนการสองขั้นตอนสำหรับการตั้งค่าพาเรนต์

    ข้อเสีย: การตรวจสอบรันไทม์ - ลดประสิทธิภาพและเพิ่มรหัสให้กับทุก ๆ การเพิ่ม / setter

  3. ผู้ปกครองตั้งค่าการอ้างอิงผู้ปกครองของเด็ก (กับตัวเอง) เมื่อมีการเพิ่ม / กำหนดเด็กให้กับผู้ปกครอง Parent Setter เป็นภายใน

    class Child {
      public Parent Parent {get; internal set;}
    }
    class Parent {
      // singleton child
      private Child _child;
      public Child Child {
        get {return _child;}
        set {
          value.Parent = this;
          _child = value;
        }
      }
      //children
      private List<Child> _children = new List<Child>();
      public ReadOnlyCollection<Child> Children { get {return _children;} }
      public void AddChild(Child child) {
        child.Parent = this;
        _children.Add(child);
      }
    }
    

    ข้อเสีย:เด็กถูกสร้างขึ้นโดยไม่มีการอ้างอิงผู้ปกครอง บางครั้งการเริ่มต้น / การตรวจสอบความต้องการผู้ปกครองซึ่งหมายความว่าการเริ่มต้น / การตรวจสอบความถูกต้องจะต้องดำเนินการในผู้ปกครองของเด็ก รหัสอาจซับซ้อน มันจะง่ายขึ้นมากที่จะใช้เด็กถ้ามันมักจะมีการอ้างอิงผู้ปกครอง

  4. พาเรนต์ตีแผ่วิธีการเพิ่มจากโรงงานเพื่อให้เด็กมีการอ้างอิงพาเรนต์เสมอ เด็ก ctor อยู่ภายใน แม่ Setter เป็นส่วนตัว

    class Child {
      internal Child(Parent parent, init-params) {Parent = parent;}
      public Parent Parent {get; private set;}
    }
    class Parent {
      // singleton child
      public Child Child {get; private set;}
      public void CreateChild(init-params) {
          var child = new Child(this, init-params);
          Child = value;
      }
      //children
      private List<Child> _children = new List<Child>();
      public ReadOnlyCollection<Child> Children { get {return _children;} }
      public Child AddChild(init-params) {
        var child = new Child(this, init-params);
        _children.Add(child);
        return child;
      }
    }
    

    ข้อเสีย:new Child(){prop = value}ไม่สามารถใช้ไวยากรณ์การเริ่มต้นเช่น แทนที่จะต้องทำ:

    var c = parent.AddChild(); 
    c.prop = value;
    

    ข้อเสีย:ต้องทำซ้ำพารามิเตอร์ของตัวสร้างลูกในวิธีการเพิ่มจากโรงงาน

    ข้อเสีย:ไม่สามารถใช้ setter คุณสมบัติสำหรับชายน์เดี่ยว ดูเหมือนง่อยที่ฉันต้องการวิธีการตั้งค่า แต่ให้เข้าถึงการอ่านผ่านตัวรับทรัพย์สิน มันลำเอียง

  5. เด็กเพิ่มตัวเองให้กับผู้ปกครองที่อ้างอิงในตัวสร้างของมัน เด็ก ctor เป็นสาธารณะ ไม่มีการเพิ่มการเข้าถึงแบบสาธารณะจากพาเรนต์

    //singleton
    class Child{
      public Child(ParentWithChild parent) {
        Parent = parent;
        Parent.Child = this;
      }
      public ParentWithChild Parent {get; private set;}
    }
    class ParentWithChild {
      public Child Child {get; internal set;}
    }
    
    //children
    class Child {
      public Child(ParentWithChildren parent) {
        Parent = parent;
        Parent._children.Add(this);
      }
      public ParentWithChildren Parent {get; private set;}
    }
    class ParentWithChildren {
      internal List<Child> _children = new List<Child>();
      public ReadOnlyCollection<Child> Children { get {return _children;} }
    }
    

    ข้อเสีย:ไวยากรณ์การโทรไม่ได้ยอดเยี่ยม โดยปกติหนึ่งเรียกaddวิธีการในผู้ปกครองแทนเพียงแค่การสร้างวัตถุเช่นนี้

    var parent = new ParentWithChildren();
    new Child(parent); //adds child to parent
    new Child(parent);
    new Child(parent);
    

    และตั้งค่าคุณสมบัติแทนที่จะสร้างวัตถุเช่นนี้:

    var parent = new ParentWithChild();
    new Child(parent); // sets parent.Child
    

...

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


14
แนวปฏิบัติที่ดีที่สุดคือเด็กไม่ควรรู้เกี่ยวกับพ่อแม่
Telastyn


2
@Telastyn ฉันอดไม่ได้ที่จะอ่านว่าเป็นลิ้นในแก้มและมันก็เฮฮา เลือดที่ตายแล้วยังแม่นยำอย่างสมบูรณ์ Steven คำที่ต้องพิจารณาคือ "acyclic" เนื่องจากมีวรรณกรรมมากมายอยู่ที่นั่นทำไมคุณควรสร้างกราฟ acyclic ถ้าเป็นไปได้
จิมมี่ฮอฟฟา

10
@Telastyn คุณควรลองใช้ความคิดเห็นนั้นใน parenting.stackexchange
Fabio Marcolini

2
อืมมม ไม่ทราบวิธีย้ายโพสต์ (ไม่เห็นตัวควบคุมธง) ฉันโพสต์ใหม่ไปยังโปรแกรมเมอร์เนื่องจากมีคนบอกฉันว่ามันอยู่ในนั้น
Steven Broshar

คำตอบ:


18

ฉันจะอยู่ห่างจากสถานการณ์ใด ๆ ที่จำเป็นต้องให้เด็กรู้เกี่ยวกับผู้ปกครอง

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

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

หวังว่าจะช่วย!


6
อยู่ให้ห่างจากสถานการณ์ใด ๆ ที่จำเป็นต้องให้เด็กรู้เกี่ยวกับพ่อแม่ ” - ทำไม? คำตอบของคุณขึ้นอยู่กับสมมติฐานว่ากราฟวัตถุทรงกลมเป็นความคิดที่ไม่ดี แม้ว่าบางครั้งจะเป็นกรณีนี้ (เช่นเมื่อการจัดการหน่วยความจำด้วยการนับซ้ำแบบไร้เดียงสา - ไม่ใช่กรณีใน C #) แต่ก็ไม่ได้เลวร้ายอะไรโดยทั่วไป ยวดรูปแบบการสังเกตการณ์ (ซึ่งมักใช้ในการส่งเหตุการณ์) เกี่ยวข้องกับการสังเกตได้ ( Child) การบำรุงรักษาชุดของผู้สังเกตการณ์ ( Parent) ซึ่งแนะนำการเวียนในทางย้อนกลับ (และแนะนำประเด็นต่าง ๆ ของตนเอง)
amon

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

ฉันเห็นด้วย. เหตุการณ์เป็นวิธีที่ดีที่สุดในการจัดการความสัมพันธ์ระหว่างพ่อแม่และลูกในกรณีนี้ เป็นรูปแบบที่ฉันใช้บ่อยมากและทำให้รหัสนั้นง่ายต่อการบำรุงรักษาแทนที่จะต้องกังวลเกี่ยวกับสิ่งที่ชั้นเรียนเด็กทำกับผู้ปกครองผ่านการอ้างอิง
Eternal21

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

2
@Neil: หากโดเมนรวมถึงวัตถุฟอเรสต์ที่มีการขึ้นต่อกันของข้อมูลแบบวนซ้ำไม่สามารถลดลงได้โมเดลใด ๆ ของโดเมนจะเป็นเช่นนั้น ในหลายกรณีสิ่งนี้จะบ่งบอกว่าป่าจะทำตัวเหมือนวัตถุยักษ์ชิ้นเดียวไม่ว่าจะต้องการหรือไม่ก็ตาม รูปแบบการรวมทำหน้าที่เพื่อรวมความซับซ้อนของฟอเรสต์ลงในวัตถุคลาสเดียวที่เรียกว่า Aggregate Root ขึ้นอยู่กับความซับซ้อนของโดเมนที่ถูกสร้างแบบจำลองรูทรวมนั้นอาจมีขนาดค่อนข้างใหญ่และเทอะทะ แต่ถ้าความซับซ้อนนั้นหลีกเลี่ยงไม่ได้ (เช่นกรณีที่มีบางโดเมน) จะดีกว่า ...
supercat

10

ฉันคิดว่าตัวเลือกของคุณ 3 อาจจะสะอาดที่สุด คุณเขียน.

ข้อเสีย: เด็กถูกสร้างขึ้นโดยไม่มีการอ้างอิงผู้ปกครอง

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

และถ้าคุณคิดว่าเด็ก ๆ ต้องการแอตทริบิวต์เริ่มต้นในตัวสร้างภายใต้สถานการณ์ทั้งหมดด้วยเหตุผลทางเทคนิคให้ใช้บางสิ่งบางอย่างเช่น "วัตถุหลัก null" เป็นค่าเริ่มต้น (แม้ว่าจะมีความเสี่ยงในการปิดบังข้อผิดพลาด)


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

หากกรณีใช้งานเรียกร้องบางสิ่งแม้แต่ครั้งเดียวการออกแบบจะต้องอนุญาตเสมอ จากนั้นการจำกัดความสามารถในสถานการณ์พิเศษนั้นเป็นเรื่องง่าย การเพิ่มความสามารถดังกล่าวในภายหลัง แต่มักจะเป็นไปไม่ได้ ทางออกที่ดีที่สุดคือตัวเลือกที่ 3 อาจมีวัตถุ "ความสัมพันธ์" ที่สามระหว่างผู้ปกครองและเด็กเช่น [ผู้ปกครอง] ---> [ความสัมพันธ์ (ผู้ปกครองเป็นเจ้าของเด็ก)] <--- [เด็ก] สิ่งนี้ยังอนุญาตให้อินสแตนซ์ [ความสัมพันธ์] หลายรายการเช่น [เด็ก] ---> [ความสัมพันธ์ (เด็กเป็นเจ้าของโดยผู้ปกครอง)] <--- [ผู้ปกครอง]
DocSalvager

3

ไม่มีอะไรที่จะป้องกันการรวมตัวกันสูงระหว่างสองคลาสที่ใช้กันโดยทั่วไป (เช่น Order และ LineItem โดยทั่วไปจะอ้างอิงซึ่งกันและกัน) อย่างไรก็ตามในกรณีเหล่านี้ฉันมักจะปฏิบัติตามกฎการออกแบบการขับเคลื่อนด้วยโดเมนและวางรูปแบบพวกเขาเป็นแบบรวมกับผู้ปกครองที่เป็นรากรวม สิ่งนี้บอกเราว่า AR มีหน้าที่รับผิดชอบตลอดอายุการใช้งานของวัตถุทั้งหมดในการรวม

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


1
ฉันจะใช้คำจำกัดความที่รวมตัวกันเล็กน้อยซึ่งจะช่วยให้มีการอ้างอิงภายนอกเป็นส่วนหนึ่งของการรวมอื่นที่ไม่ใช่รากโดยมีเงื่อนไขว่า - จากมุมมองของผู้สังเกตการณ์ภายนอก - พฤติกรรมจะสอดคล้องกัน ด้วยการรวมทุกส่วนของการถือครองเพียงการอ้างอิงถึงรูทและไม่ไปยังส่วนอื่น ๆ ในใจของฉันหลักการที่สำคัญคือแต่ละวัตถุที่ไม่แน่นอนควรจะมีหนึ่งเจ้าของ ; รวมเป็นชุดของวัตถุที่เป็นเจ้าของโดยวัตถุเดียว ("รวมราก") ซึ่งควรรู้การอ้างอิงทั้งหมดที่มีอยู่ในส่วนของมัน
supercat

3

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

var q2N3904 = new TransistorSpec(TransistorType.NPN, 0.691, 40);
var idealResistor4K7 = new IdealResistorSpec(4700.0);
var idealResistor47K = new IdealResistorSpec(47000.0);

var Q1 = Circuit.AddComponent(q2N3904);
var Q2 = Circuit.AddComponent(q2N3904);
var R1 = Circuit.AddComponent(idealResistor4K7);
var R2 = Circuit.AddComponent(idealResistor4K7);
var R3 = Circuit.AddComponent(idealResistor47K);
var R4 = Circuit.AddComponent(idealResistor47K);

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


2

รายการที่ดี ฉันไม่ทราบว่าวิธีใดเป็น "ดีที่สุด" แต่นี่คือวิธีการหนึ่งในการค้นหาวิธีที่แสดงออกที่สุด

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

addChild()บางทีคุณอาจจะได้รับ บางทีคุณอาจจะได้รับสิ่งที่ต้องการaddChildren(List<Child>)หรือaddChildrenNamed(List<String>)หรือloadChildrenFrom(String)หรือหรือnewTwins(String, String)Child.replicate(int)

หากปัญหาของคุณเกี่ยวกับการบังคับให้มีความสัมพันธ์แบบหนึ่งต่อหลายคนบางทีคุณควรจะทำ

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

นี่ไม่ใช่คำตอบ แต่ฉันหวังว่าคุณจะพบในขณะที่อ่านนี้


0

ฉันขอขอบคุณที่มีลิงก์จากเด็กสู่ผู้ปกครองมีข้อเสียตามที่ระบุไว้ข้างต้น

อย่างไรก็ตามสำหรับหลาย ๆ สถานการณ์การแก้ไขปัญหาด้วยเหตุการณ์และกลไก "ตัดการเชื่อมต่อ" อื่น ๆ ยังนำความซับซ้อนและรหัสพิเศษออกมา

ตัวอย่างเช่นการเพิ่มกิจกรรมจาก Child ที่จะได้รับโดยผู้ปกครองจะผูกทั้งสองเข้าด้วยกันแม้ว่าจะอยู่ในรูปแบบการแต่งงานกันแบบหลวม ๆ

บางทีในหลาย ๆ สถานการณ์อาจเป็นที่ชัดเจนสำหรับนักพัฒนาทั้งหมดความหมายของคุณสมบัติ Child.Parent สำหรับระบบส่วนใหญ่ที่ฉันทำงานเกี่ยวกับสิ่งนี้ได้ผลดี กว่าวิศวกรรมอาจใช้เวลานานและ ... ทำให้เกิดความสับสน!

มี Parent.AttachChild () วิธีการที่ทำงานทั้งหมดที่จำเป็นในการผูกเด็กกับแม่ของมัน ทุกคนมีความชัดเจนในสิ่งที่ "หมายถึง" นี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.