คำถามติดแท็ก class-design

ฉันกำลังคิดเกี่ยวกับส่วนต่อประสานกับชั้นเรียนที่ฉันกำลังเขียน คลาสนี้มีสไตล์สำหรับตัวละครตัวอย่างเช่นตัวละครเป็นตัวหนาตัวเอียงขีดเส้นใต้และอื่น ๆ ฉันได้ถกเถียงกับตัวเองเป็นเวลาสองวันว่าฉันควรใช้ getters / setters หรือชื่อโลจิคัลสำหรับวิธีที่เปลี่ยนค่าเป็น สไตล์เหล่านี้ ในขณะที่ฉันมักจะชอบชื่อแบบลอจิคัลมันหมายถึงการเขียนรหัสที่ไม่มีประสิทธิภาพและไม่เป็นแบบลอจิคัล ให้ฉันยกตัวอย่างให้คุณ ฉันมีชั้นเรียนCharacterStylesที่มีตัวแปรสมาชิกbold, italic, underline(และอื่น ๆ บางอย่าง แต่ฉันจะปล่อยให้พวกเขาออกไปให้มันง่าย) วิธีที่ง่ายที่สุดที่จะช่วยให้ส่วนอื่น ๆ ของโปรแกรมที่จะเข้าถึงตัวแปรเหล่านี้จะเขียนวิธีการ getter / หมาเพื่อให้คุณสามารถทำและstyles.setBold(true)styles.setItalic(false) แต่ฉันไม่ชอบสิ่งนี้ ไม่เพียงเพราะผู้คนจำนวนมากพูดว่าผู้ได้รับ / setters ทำลายการห่อหุ้ม (มันเลวร้ายจริงๆเหรอ?) แต่ส่วนใหญ่เป็นเพราะมันไม่สมเหตุสมผล ฉันคาดหวังที่จะจัดสไตล์ตัวละครผ่านวิธีการหนึ่งstyles.format("bold", true)หรือบางอย่างเช่นนั้น แต่ไม่ผ่านวิธีเหล่านี้ทั้งหมด แม้ว่าจะมีปัญหาหนึ่งข้อ เนื่องจากคุณไม่สามารถเข้าถึงตัวแปรสมาชิกวัตถุโดยเนื้อหาของสตริงใน C ++ ฉันจะต้องเขียนคอนเทนเนอร์ if-statement / switch ขนาดใหญ่สำหรับสไตล์ทั้งหมดหรือฉันจะต้องเก็บสไตล์ไว้ในอาเรย์แบบเชื่อมโยง ( แผนที่). ฉันไม่สามารถเข้าใจได้ว่าวิธีที่ดีที่สุดคืออะไร ช่วงเวลาหนึ่งฉันคิดว่าฉันควรเขียนตัวรับสัญญาณ / ผู้ตั้งค่าและช่วงเวลาถัดไปที่ฉันเอนตัวไปทางอื่น คำถามของฉันคือคุณจะทำอย่างไร แล้วทำไมคุณถึงทำอย่างนั้น?

12 c++  object-oriented  class-design 

ฉันกำลังพยายามสร้างโปรแกรมสำหรับจัดการพนักงาน อย่างไรก็ตามฉันไม่สามารถหาวิธีออกแบบEmployeeชั้นเรียนได้ เป้าหมายของฉันคือการสามารถสร้างและจัดการข้อมูลพนักงานในฐานข้อมูลโดยใช้Employeeวัตถุ การใช้งานขั้นพื้นฐานที่ฉันคิดว่าเป็นเรื่องง่าย ๆ นี้: class Employee { // Employee data (let's say, dozens of properties). Employee() {} Create() {} Update() {} Delete() {} } ด้วยการใช้งานนี้ฉันพบปัญหาหลายประการ IDของพนักงานจะได้รับจากฐานข้อมูลดังนั้นหากผมใช้วัตถุสำหรับการอธิบายเป็นพนักงานใหม่จะไม่มีIDการจัดเก็บเลยในขณะที่วัตถุที่เป็นตัวแทนของพนักงานที่มีอยู่จะIDมี ดังนั้นฉันจึงมีคุณสมบัติที่บางครั้งอธิบายวัตถุและบางครั้งก็ไม่ (ซึ่งอาจบ่งบอกว่าเราละเมิดSRPเนื่องจากเราใช้คลาสเดียวกันสำหรับตัวแทนพนักงานใหม่และพนักงานปัจจุบัน ... ) Createวิธีการที่ควรจะสร้างการทำงานของพนักงานในฐานข้อมูลได้ในขณะที่UpdateและDeleteควรจะดำเนินการกับพนักงานที่มีอยู่ (อีกครั้งSRP ... ) วิธีการ 'สร้าง' ควรมีพารามิเตอร์ใด มีพารามิเตอร์หลายสิบสำหรับข้อมูลพนักงานทั้งหมดหรืออาจเป็นEmployeeวัตถุ? ชั้นควรจะไม่เปลี่ยนรูป? จะUpdateทำงานอย่างไร จะใช้คุณสมบัติและอัปเดตฐานข้อมูลหรือไม่ หรืออาจจะใช้วัตถุสองชิ้น - อันเก่าและอันใหม่และอัพเดทฐานข้อมูลด้วยความแตกต่างระหว่างพวกมัน (ฉันคิดว่าคำตอบเกี่ยวข้องกับคำตอบเกี่ยวกับความไม่แน่นอนของชั้นเรียน) อะไรคือความรับผิดชอบของผู้สร้าง? สิ่งที่จะเป็นพารามิเตอร์ที่ใช้? มันจะดึงข้อมูลพนักงานจากฐานข้อมูลโดยใช้idพารามิเตอร์และเติมคุณสมบัติหรือไม่ …

11 object-oriented  class-design  class 

รับคลาส Python ซึ่งจะถูกสร้างอินสแตนซ์เพียงครั้งเดียวคือจะมีเพียงวัตถุเดียวของคลาส ฉันสงสัยในกรณีที่เหมาะสมที่จะสร้างอินสแตนซ์ของคลาสเดียวแทนที่จะทำงานโดยตรงกับคลาสแทน มีคำถามที่คล้ายกันแต่มีจุดเน้นที่แตกต่าง: มันเกี่ยวกับการจัดกลุ่มตัวแปรส่วนกลางและฟังก์ชันในคลาสและ มันไม่ได้เป็นงูหลามที่เฉพาะเจาะจง หลังหมายถึงมันไม่ได้พิจารณาความจริงที่ว่าคลาส (ใน Python) เป็นวัตถุด้วย UPDATE: ใน Python ฉันสามารถทำสิ่งต่อไปนี้กับทั้งคลาสและวัตถุ: class A(object): pass A.some_state_var = True # Then later A.some_state_var = False my_a = A() my_a.some_state_var = True # Then later my_a.some_state_var = False ดังนั้นฉันไม่เห็นวิธีการเลือกระหว่างคลาสและอินสแตนซ์ของคลาสนั้นเกี่ยวกับสถานะ (ใน Python) ฉันสามารถรักษาสถานะด้วยสองอย่างใดอย่างหนึ่ง นอกจากนี้แรงจูงใจในการสร้างคลาส / คลาสอินสแตนซ์ของฉันไม่ได้เกี่ยวกับการบังคับใช้ข้อกำหนดแบบซิงเกิล นอกจากนี้ยังไม่มากนักเกี่ยวกับการสร้างประเภทใหม่ แรงจูงใจคือการจัดกลุ่มรหัสและข้อมูลที่เกี่ยวข้องและมีส่วนต่อประสานกับมัน นี่คือเหตุผลที่ฉันเริ่มต้นแบบเป็นคลาสในแผนภาพคลาส เมื่อพูดถึงการนำไปใช้ฉันเริ่มสงสัยว่าจะยกตัวอย่างชั้นเรียนนี้หรือไม่

11 design  object-oriented  python  object-oriented-design  class-design 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันอยากรู้มากเกี่ยวกับความคิดและแนวปฏิบัติที่ดีที่สุดในอุตสาหกรรมเกี่ยวกับสมาชิกแบบสแตติกหรือคลาสแบบคงที่ทั้งหมด มีข้อเสียหรือไม่หรือมีส่วนร่วมในรูปแบบการต่อต้านใด ๆ ฉันเห็นเอนทิตีเหล่านี้เป็น "คลาส / สมาชิกยูทิลิตี้" ในแง่ที่ว่าพวกเขาไม่ต้องการหรือต้องการอินสแตนซ์ชั้นเรียนเพื่อให้การทำงาน อะไรคือความคิดทั่วไปและแนวปฏิบัติที่ดีที่สุดในอุตสาหกรรมเกี่ยวกับเรื่องนี้ ดูตัวอย่างชั้นเรียนและสมาชิกด้านล่างเพื่อแสดงสิ่งที่ฉันกำลังอ้างอิง // non-static class with static members // public class Class1 { // ... other non-static members ... public static string GetSomeString() { // do something } } // static class // public static …

11 c#  class-design 

ฉันแค่เรียนรู้เกี่ยวกับการฉีดพึ่งพาและติดอยู่กับบางสิ่ง การพึ่งพาการฉีดแนะนำให้ส่งคลาสที่ต้องพึ่งพาผ่านตัวสร้าง แต่ฉันสงสัยว่านี่เป็นสิ่งจำเป็นสำหรับวัตถุข้อมูลหรือไม่ เนื่องจาก Unit-Testability เป็นหนึ่งในประโยชน์หลักของ DI จะเป็น data data ที่เก็บข้อมูลเท่านั้นไม่ใช่โพรซีเดอร์ใด ๆ ที่เคยถูกทดสอบโดยหน่วยทำให้ DI เป็นเลเยอร์ที่ซับซ้อนโดยไม่จำเป็นหรือยังช่วยแสดงการพึ่งพา กับวัตถุข้อมูล? Class DO{ DO(){ DataObject2List = new List<DO2>(); } public string Field1; public string Field2; public List<DO2> DataObject2List; } Class DO2{ public DateTime Date; public double Value; }

11 c#  dependency-injection  class-design 

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

11 c#  sql  class-design 

ใน C ++ โครงการของฉันฉันมีสองชั้นและParticle ContactในParticleระดับที่ฉันมีตัวแปรสมาชิกstd::vector<Contact> contactsที่มีรายชื่อทั้งหมดของParticleวัตถุและสอดคล้องฟังก์ชันสมาชิกและgetContacts() addContact(Contact cont)ดังนั้นใน "Particle.h" ฉันรวม "Contact.h" ในContactชั้นเรียนฉันต้องการเพิ่มรหัสไปยังตัวสร้างContactที่จะเรียกParticle::addContact(Contact cont)เพื่อให้contactsมีการปรับปรุงสำหรับParticleวัตถุทั้งสองระหว่างContactวัตถุที่จะถูกเพิ่ม ดังนั้นฉันจะต้องรวม "Particle.h" ใน "Contact.cpp" คำถามของฉันคือสิ่งนี้เป็นที่ยอมรับ / ฝึกการเขียนโปรแกรมที่ดีหรือไม่และหากไม่มีสิ่งใดจะเป็นวิธีที่ดีกว่าที่จะใช้สิ่งที่ฉันพยายามทำให้สำเร็จ (เพียงแค่อัปเดตรายชื่อผู้ติดต่อสำหรับอนุภาคเฉพาะโดยอัตโนมัติ ถูกสร้าง) คลาสเหล่านี้จะถูกผูกเข้าด้วยกันโดยNetworkคลาสที่จะมี N particles ( std::vector<Particle> particles) และ Nc contact ( std::vector<Contact> contacts) แต่ฉันต้องการที่จะมีฟังก์ชั่นเช่นparticles[0].getContacts()- มันไม่เป็นไรที่จะมีฟังก์ชั่นดังกล่าวในParticleชั้นเรียนในกรณีนี้หรือมีโครงสร้าง "เชื่อมโยง" ที่ดีขึ้นใน C ++ สำหรับวัตถุประสงค์นี้ (ของสองคลาสที่เกี่ยวข้องที่ใช้ในชั้นเรียนอื่น) . ฉันอาจต้องเปลี่ยนมุมมองที่นี่ในวิธีที่ฉันเข้าใกล้นี้ เนื่องจากทั้งสองคลาสเชื่อมต่อกันด้วยNetworkอ็อบเจกต์คลาสเป็นรหัสองค์กร / คลาสทั่วไปที่มีข้อมูลการเชื่อมต่อที่ควบคุมโดยNetworkวัตถุทั้งหมด (ในที่วัตถุ Particle ไม่ควรรับรู้รายชื่อผู้ติดต่อและดังนั้นจึงไม่ควรมีgetContacts()สมาชิก …

10 c++  class-design  class 

ฉันค้นพบอินเทอร์เฟซและฉันเริ่มรักพวกเขา ความสวยงามของอินเทอร์เฟซคือมันเป็นสัญญาและวัตถุใด ๆ ที่ตอบสนองสัญญานั้นสามารถใช้ได้ทุกที่ที่ต้องการอินเตอร์เฟส ปัญหาของอินเทอร์เฟซคือมันไม่สามารถมีการใช้งานเริ่มต้นซึ่งเป็นคุณสมบัติที่เจ็บปวดสำหรับคุณสมบัติทางโลกและกำจัด DRY สิ่งนี้ก็เป็นสิ่งที่ดีเพราะมันทำให้การใช้งานและระบบแยกจากกัน ในทางกลับกันมรดกยังคงรักษาคัปปลิ้งที่แน่นกว่าและมีศักยภาพที่จะทำลายการห่อหุ้ม กรณีที่ 1 (การสืบทอดกับสมาชิกส่วนตัวการห่อหุ้มที่ดีเข้าด้วยกันอย่างแน่นหนา) class Employee { int money_earned; string name; public: void do_work(){money_earned++;}; string get_name(return name;); }; class Nurse : public Employee: { public: void do_work(/*do work. Oops, can't update money_earned. Unaware I have to call superclass' do_work()*/); }; void HireNurse(Nurse *n) …

10 c++  design  interfaces  class-design  inheritance 

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

10 object-oriented  class-design 

แน่นอนคุณทำได้ฉันแค่สงสัยว่ามันมีเหตุผลในการออกแบบในลักษณะนี้ ฉันทำโคลน breakout และกำลังออกแบบคลาส ฉันต้องการใช้การสืบทอดแม้ว่าฉันไม่จำเป็นต้องใช้สิ่งที่ฉันเรียนรู้ใน C ++ ฉันกำลังคิดเกี่ยวกับการออกแบบชั้นเรียนและเกิดขึ้นกับสิ่งนี้: GameObject -> ชั้นฐาน (ประกอบด้วยสมาชิกข้อมูลเช่นชดเชย X และ Y และเวกเตอร์ของ SDL_Surface * a MovableObject: GameObject -> ระดับนามธรรม + ชั้นเรียนมาของ GameObject (วิธีหนึ่งย้ายเป็นโมฆะ () = 0;) NonMovableObject: GameObject -> คลาสที่ว่างเปล่า ... ไม่มีเมธอดหรือสมาชิกข้อมูลอื่นนอกจากตัวสร้างและ destructor (อย่างน้อยตอนนี้หรือไม่) ต่อมาฉันวางแผนที่จะรับคลาสจาก NonMovableObject เช่น Tileset: NonMovableObject ฉันแค่สงสัยว่าคลาสนามธรรม "ว่างเปล่า" หรือแค่คลาสว่างมักใช้ ... ฉันสังเกตว่าวิธีที่ฉันทำเช่นนี้ฉันแค่สร้างคลาส NonMovableObject เพื่อประโยชน์ในการจัดหมวดหมู่ …

10 class-design 

ฉันกำลังอ่านหน้านี้เกี่ยวกับเมื่อ getters / setters เป็นธรรมและ OP ให้ตัวอย่างรหัสต่อไปนี้: class Fridge { int cheese; void set_cheese(int _cheese) { cheese = _cheese; } int get_cheese() { return cheese; } } void go_shopping(Fridge fridge) { fridge.set_cheese(fridge.get_cheese() + 5); } ยอมรับคำตอบรัฐ: โดยวิธีการในตัวอย่างของคุณ, ฉันจะให้ชั้นและวิธีการแทนและ จากนั้นคุณจะยังคงมีการห่อหุ้มFridgeputCheese()takeCheese()get_cheese()set_cheese() การห่อหุ้มนั้นถูกเก็บรักษาไว้อย่างไรโดยการเปลี่ยนชื่อจากรับ / ตั้งค่าเป็นputCheese()/ takeCheese()คุณเห็นได้ชัดว่าได้รับ / ตั้งค่าดังนั้นทำไมไม่ปล่อยไว้เป็นรับ / ตั้งค่า? ในคำตอบเดียวกันมันยังระบุ: มี getters …

9 object-oriented  class-design  encapsulation  setters  getters 

ฉันประสบปัญหากับสิ่งที่ฉันรู้สึกว่าเป็นนามธรรมมากเกินไปในรหัสฐาน (หรืออย่างน้อยก็จัดการกับมัน) เมธอดส่วนใหญ่ในฐานรหัสได้รับการสรุปให้ใช้ในพาเรนต์สูงสุด A ในโค้ดเบส แต่ลูก B ของพาเรนต์นี้มีแอ็ตทริบิวต์ใหม่ที่มีผลต่อตรรกะของบางเมธอดเหล่านั้น ปัญหาคือไม่สามารถตรวจสอบแอตทริบิวต์เหล่านั้นในวิธีการเหล่านั้นได้เนื่องจากอินพุตนั้นถูกส่งไปยัง A และแน่นอนว่า A ไม่มีคุณสมบัตินี้ ถ้าฉันพยายามสร้างวิธีการใหม่เพื่อจัดการ B ที่แตกต่างกันมันจะถูกเรียกใช้สำหรับการทำสำเนารหัส คำแนะนำโดยผู้นำด้านเทคนิคของฉันคือการสร้างวิธีการที่ใช้ร่วมกันซึ่งใช้ในพารามิเตอร์บูลีน แต่ปัญหาของเรื่องนี้คือบางคนมองว่านี่เป็น "การควบคุมการไหลที่ซ่อนอยู่" ซึ่งวิธีการแบ่งปันมีตรรกะที่อาจไม่ชัดเจนสำหรับนักพัฒนาในอนาคต , และวิธีการที่ใช้ร่วมกันนี้จะเพิ่มความซับซ้อน / ซับซ้อนมากขึ้นหากจำเป็นต้องเพิ่มแอตทริบิวต์ในอนาคตแม้ว่าจะถูกแยกย่อยเป็นวิธีที่ใช้ร่วมกันที่มีขนาดเล็กลง สิ่งนี้ยังเพิ่มการแต่งงานลดการทำงานร่วมกันและละเมิดหลักการความรับผิดชอบเดียวซึ่งมีคนในทีมของฉันชี้ให้เห็น โดยพื้นฐานแล้วสิ่งที่เป็นนามธรรมจำนวนมากใน codebase นี้ช่วยลดความซ้ำซ้อนของรหัส แต่มันทำให้การขยาย / เปลี่ยนวิธีที่ยากขึ้นเมื่อพวกเขาถูกทำให้เป็นนามธรรมที่สูงที่สุด ฉันควรทำอย่างไรในสถานการณ์เช่นนี้ ฉันอยู่ที่ศูนย์กลางของการตำหนิแม้ว่าคนอื่น ๆ จะไม่เห็นด้วยกับสิ่งที่พวกเขาคิดว่าดี แต่มันก็ทำให้ฉันเจ็บในที่สุด

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

เราทำการทดสอบหน่วยและการปรับโครงสร้างวัตถุทางธุรกิจของเราอีกมากมายและดูเหมือนว่าฉันมีความคิดเห็นที่แตกต่างกันมากในการออกแบบชั้นเรียนมากกว่าเพื่อนคนอื่น ๆ ตัวอย่างคลาสที่ฉันไม่ใช่แฟนของ: public class Foo { private string field1; private string field2; private string field3; private string field4; private string field5; public Foo() { } public Foo(string in1, string in2) { field1 = in1; field2 = in2; } public Foo(string in1, string in2, string in3, string in4) { field1 …

9 c#  object-oriented-design  class-design  class 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันเพิ่งเริ่มเขียนคลาสใหม่และมันเกิดขึ้นกับฉันว่าฉันได้เพิ่มการโต้แย้งวิธีที่ไม่จำเป็นอย่างเคร่งครัด สิ่งนี้กำลังติดตามพฤติกรรมเพื่อหลีกเลี่ยงการมีสถานะในคลาสที่เฉพาะเจาะจงกับการเรียกใช้เมธอดบางตัวแทนที่จะเป็นการกำหนดค่าทั่วไปหรือการพึ่งพาของคลาส การทำเช่นนั้นหมายความว่าวิธีการมากมายที่อาจไม่มีข้อโต้แย้งจบลงด้วยหนึ่งสองหรือสาม ฉันต้องการฟังความคิดเห็นของคุณเกี่ยวกับสิ่งที่คุณคิดเกี่ยวกับการแลกเปลี่ยนนี้และวิธีการตัดสินใจเกี่ยวกับวิธีการที่จะใช้ในสถานการณ์ใด เนื่องจากรหัสมักจะเข้าใจง่ายกว่าภาษาอังกฤษเมื่ออธิบายรหัสฉันจึงสร้างส่วนเล็กน้อยที่มีทั้งสองรูปแบบ: https://gist.github.com/JeroenDeDauw/6525656

9 class-design  complexity  methods  parameters  cohesion 

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

9 object-oriented  inheritance  composition  class-design