คำถามติดแท็ก inheritance

จาก: http://www.artima.com/lejava/articles/designprinciples4.html Erich Gamma: ฉันยังคงคิดว่ามันเป็นความจริงแม้หลังจากผ่านไปสิบปี การสืบทอดเป็นวิธีที่ยอดเยี่ยมในการเปลี่ยนพฤติกรรม แต่เรารู้ว่ามันเปราะบางเนื่องจากคลาสย่อยสามารถตั้งสมมติฐานเกี่ยวกับบริบทที่มีการเรียกเมธอดแทนที่ได้ง่าย มีการเชื่อมต่ออย่างแน่นหนาระหว่างคลาสฐานและคลาสย่อยเนื่องจากบริบทโดยปริยายซึ่งโค้ดคลาสย่อยที่ฉันเสียบเข้าจะถูกเรียก องค์ประกอบมีคุณสมบัติที่ดีกว่า การมีเพศสัมพันธ์จะลดลงเพียงแค่มีสิ่งเล็ก ๆ ที่คุณเสียบเข้าไปกับสิ่งที่ใหญ่กว่าและวัตถุที่ใหญ่กว่าก็เรียกวัตถุที่เล็กกว่ากลับมา จากมุมมองของ API ที่กำหนดว่าวิธีการใด ๆ ที่สามารถแทนที่ได้คือความมุ่งมั่นที่แข็งแกร่งกว่าการกำหนดวิธีการที่สามารถเรียกได้ ฉันไม่เข้าใจสิ่งที่เขาหมายถึง ใครช่วยอธิบายหน่อยได้ไหม

36 object-oriented  api  inheritance  composition 

ความเข้าใจในปัจจุบันของฉันเกี่ยวกับการใช้งานมรดกคือควรขยายชั้นเรียนเฉพาะเมื่อมีความสัมพันธ์แบบ IS-A หากคลาสพาเรนต์สามารถมีประเภทลูกที่เฉพาะเจาะจงเพิ่มเติมด้วยฟังก์ชันการทำงานที่แตกต่างกัน แต่จะแบ่งปันองค์ประกอบทั่วไปที่มีนามธรรมในผู้ปกครอง ฉันกำลังถามความเข้าใจนั้นเพราะสิ่งที่อาจารย์ Java ของฉันแนะนำให้เราทำ เขาแนะนำว่าสำหรับJSwingแอปพลิเคชันที่เรากำลังสร้างในชั้นเรียน หนึ่งควรขยายทุกJSwingชั้นเรียน ( JFrame, JButton, JTextBoxฯลฯ ) ในชั้นเรียนที่กำหนดเองแยกต่างหากและระบุ GUI การปรับแต่งที่เกี่ยวข้องในพวกเขา (เช่นขนาดส่วนประกอบฉลากส่วนประกอบ ฯลฯ ) จนถึงตอนนี้ดีมาก แต่เขาก็ยังแนะนำต่อไปว่า JButton ทุกคนควรมีคลาสแบบขยายที่กำหนดเองของตนเองแม้ว่าปัจจัยที่แตกต่างเท่านั้นคือฉลากของพวกเขา สำหรับเช่นหาก GUI มีสองปุ่มโอเคและยกเลิก เขาแนะนำให้ขยายเวลาดังต่อไปนี้: class OkayButton extends JButton{ MainUI mui; public OkayButton(MainUI mui) { setSize(80,60); setText("Okay"); this.mui = mui; mui.add(this); } } class CancelButton extends JButton{ …

35 java  object-oriented  programming-practices  inheritance 

มันจะดีกว่าที่จะใช้List<string>ในคำอธิบายประกอบประเภทหรือStringListที่ไหนStringList class StringList : List<String> { /* no further code!*/ } ฉันวิ่งเข้าไปในหลายของเหล่านี้ในประชด

35 c#  inheritance 

ฉันเพิ่งเริ่มดูการพัฒนา Android สิ่งนี้นำฉันกลับสู่โลกของการพัฒนาซอฟต์แวร์ Java ครั้งสุดท้ายที่ฉันทำงานกับ Java ฉันจะยอมรับว่าฉันไม่เข้าใจ OOP เท่าที่ฉันคิดตอนนี้ หลังจากใช้งาน C # เป็นส่วนใหญ่ในอาชีพของฉันฉันสังเกตเห็นความแตกต่างที่น่าตกใจในการใช้ Java และ C # ในการสืบทอด ใน C # ดูเหมือนว่าสามารถหลีกเลี่ยงการสืบทอดในสถานการณ์ส่วนใหญ่ งานในมือสามารถทำได้โดยใช้คลาสที่เป็นรูปธรรมของ. NET Framework ใน Java จากสิ่งที่ฉันรวบรวมจากตัวอย่างโค้ดดูเหมือนว่า Java framework จะให้ส่วนต่อประสานหรือคลาสนามธรรมที่มีความหมายที่จะนำไปใช้ / ขยายโดยนักพัฒนา ดูเหมือนว่าจะมีความแตกต่างใหญ่เกินไปที่จะทำให้สไตล์ อะไรคือเหตุผลเบื้องหลังสิ่งนี้ ฉันรู้สึกว่าฉันจะไม่เขียนโค้ด Java ที่สะอาดจนกว่าฉันจะเข้าใจสิ่งนี้ นอกจากนี้ยังมีข้อ จำกัด เพียงแค่ Android SDK หรือนี่เป็นแนวทางแบบกว้าง ๆ ของ OOP หรือไม่? หรือใส่ในอีกทางหนึ่ง มันเกี่ยวกับการออกแบบของสองภาษานี้ที่ดูเหมือนว่าจะส่งเสริมให้ใช้มรดกมากกว่าหรือน้อยกว่าอีก? …

34 java  c#  object-oriented  language-design  inheritance 

ฉันรู้อย่างเต็มที่ว่าpylintและเครื่องมือวิเคราะห์แบบคงที่อื่น ๆ ไม่ได้รู้ทั้งหมดและบางครั้งคำแนะนำของพวกเขาจะต้องไม่เชื่อฟัง (ใช้กับคลาสข้อความที่หลากหลายไม่ใช่แค่conventions) ถ้าฉันมีชั้นเรียนเช่น class related_methods(): def a_method(self): self.stack.function(self.my_var) class more_methods(): def b_method(self): self.otherfunc() class implement_methods(related_methods, more_methods): def __init__(self): self.stack = some() self.my_var = other() def otherfunc(self): self.a_method() เห็นได้ชัดว่ามีการวางแผน นี่เป็นตัวอย่างที่ดีกว่าหากคุณต้องการ ฉันเชื่อว่าสไตล์นี้เรียกว่าใช้ "มิกซ์" เช่นเดียวกับเครื่องมืออื่น ๆpylintอัตรารหัสนี้ที่-21.67 / 10ส่วนใหญ่เพราะมันคิดmore_methodsและrelated_methodsไม่ได้มีselfหรือแอตทริบิวต์otherfunc, stack, annd my_varเพราะโดยไม่ต้องใช้รหัสที่มันเห็นได้ชัดว่าไม่สามารถดูrelated_methodsและมีผสมในmore_methodsimplement_methods คอมไพเลอร์และเครื่องมือวิเคราะห์แบบสแตติกไม่สามารถแก้ปัญหาการหยุดนิ่งได้เสมอไปแต่ฉันรู้สึกว่านี่เป็นกรณีที่มองว่าสิ่งที่สืบทอดมาimplement_methodsจะแสดงให้เห็นว่าสิ่งนี้เป็นสิ่งที่ถูกต้องสมบูรณ์และนั่นก็เป็นเรื่องง่ายมาก ทำไมเครื่องมือวิเคราะห์แบบคงที่ปฏิเสธรูปแบบ OOP ที่ถูกต้อง (ฉันคิดว่า) ทั้ง: พวกเขาไม่แม้แต่จะลองตรวจสอบการสืบทอดหรือ มิกซ์อินถูกทำให้หมดกำลังใจใน Python ซึ่งเป็นสำนวนที่อ่านง่าย …

34 object-oriented  python  inheritance  python-3.x  mixins 

Baseฉันได้เรียนฐาน มันมีอยู่สอง subclasses, และSub1 Sub2แต่ละคลาสย่อยมีวิธีเพิ่มเติมบางอย่าง ตัวอย่างเช่นSub1มีSandwich makeASandwich(Ingredients... ingredients)และมีSub2boolean contactAliens(Frequency onFrequency) เนื่องจากวิธีการเหล่านี้ใช้พารามิเตอร์ที่แตกต่างกันและทำสิ่งที่แตกต่างอย่างสิ้นเชิงพวกเขาไม่เข้ากันอย่างสมบูรณ์และฉันไม่สามารถใช้ความหลากหลายในการแก้ปัญหานี้ได้ Baseมอบการทำงานส่วนใหญ่และฉันมีBaseวัตถุจำนวนมาก อย่างไรก็ตามBaseวัตถุทั้งหมดเป็นแบบ a Sub1หรือ a Sub2และบางครั้งฉันจำเป็นต้องรู้ว่ามันคืออะไร ดูเหมือนจะเป็นการดีที่จะทำสิ่งต่อไปนี้: for (Base base : bases) { if (base instanceof Sub1) { ((Sub1) base).makeASandwich(getRandomIngredients()); // ... etc. } else { // must be Sub2 ((Sub2) base).contactAliens(getFrequency()); // ... etc. } } ดังนั้นฉันจึงคิดกลยุทธ์เพื่อหลีกเลี่ยงสิ่งนี้โดยไม่ต้องร่าย Baseตอนนี้มีวิธีการเหล่านี้: …

33 java  inheritance  type-casting 

ฉันสับสนว่าปัญหาจะเกิดขึ้นได้อย่างไรหากคอนสตรัคเตอร์ได้รับมรดกจากคลาสฐาน Cpp Primer Plus กล่าวว่า ก่อสร้างจะแตกต่างจากวิธีการเรียนอื่น ๆ ในการที่พวกเขาสร้างวัตถุใหม่ในขณะที่วิธีการอื่น ๆ จะเรียกโดยวัตถุที่มีอยู่ นี่คือเหตุผลหนึ่งการก่อสร้างยังไม่ได้รับการถ่ายทอด การสืบทอดหมายความว่าวัตถุที่ได้มาสามารถใช้วิธีการระดับฐาน แต่ในกรณีของการก่อสร้างวัตถุที่ไม่มีอยู่จนกว่าหลังจากที่ผู้สร้างได้ทำงานของมัน ฉันเข้าใจว่าตัวสร้างถูกเรียกก่อนการสร้างวัตถุจะเสร็จสมบูรณ์ มันจะนำไปสู่ปัญหาได้อย่างไรถ้าคลาสเด็กสืบทอด ( โดยการสืบทอดฉันหมายความว่าคลาสเด็กสามารถแทนที่เมธอดคลาสพาเรนต์เป็นต้นไม่เพียง แต่เข้าถึงเมธอดคลาสคลาสหลัก ) คอนสตรัคเตอร์หลัก ฉันเข้าใจว่าไม่มีความจำเป็นที่จะต้องเรียกคอนสตรัคเตอร์อย่างชัดเจนจากภายในโค้ด [ไม่ใช่สิ่งที่ฉันรู้ขณะนี้] ยกเว้นขณะสร้างวัตถุ แม้ว่าคุณจะสามารถใช้กลไกบางอย่างในการเรียก const constor ของ parent [ใน cpp, การใช้::หรือการใช้member initialiser list, In java using super] ใน Java มีการบังคับให้เรียกมันในบรรทัดที่ 1 ฉันเข้าใจว่าเพื่อให้แน่ใจว่าวัตถุแม่ถูกสร้างขึ้นก่อนแล้วจึงสร้างการสร้างวัตถุลูก มันสามารถแทนที่มัน แต่ฉันไม่สามารถคิดสถานการณ์ที่ทำให้เกิดปัญหาได้ หากเด็กได้สืบทอดคอนสตรัคเตอร์หลักสิ่งที่สามารถผิดพลาดได้? ดังนั้นนี่คือเพื่อหลีกเลี่ยงการสืบทอดฟังก์ชันที่ไม่จำเป็น หรือมีมากไปไหม

33 c++  inheritance 

ตัวอย่างเช่นฉันเคยเห็นรหัสบางอย่างที่สร้างชิ้นส่วนเช่นนี้: Fragment myFragment=new MyFragment(); ซึ่งประกาศตัวแปรเป็นชิ้นส่วนแทน MyFragment ซึ่ง MyFragment เป็นคลาสย่อยของ Fragment ฉันไม่พอใจรหัสบรรทัดนี้เพราะฉันคิดว่ารหัสนี้ควรเป็น: MyFragment myFragment=new MyFragment(); ข้อไหนเจาะจงกว่ากันจริงหรือ? หรือโดยทั่วไปของคำถามเป็นการใช้งานไม่ถูกต้อง: Parent x=new Child(); แทน Child x=new Child(); หากเราสามารถเปลี่ยนคนที่เคยเป็นคนหลังได้โดยไม่ผิดพลาด

32 object-oriented  coding-style  refactoring  inheritance 

ถ้าชั้นเรียนของฉันimplementsมีอินเตอร์เฟซฉันจะบอกได้ไหมว่าฉันกำลังติดตามมรดกอยู่? ฉันรู้ว่าเมื่อเรียนextendsอีกชั้นหนึ่งแล้วมันเป็นมรดก

31 java  terminology  interfaces  inheritance  definition 

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

30 testing  inheritance 

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

27 design  object-oriented-design  inheritance 

ฉันสงสัยว่าอะไรจะดีไปในแง่ของการออกแบบ OOP ที่ดีทำความสะอาดโค้ดมีความยืดหยุ่นและหลีกเลี่ยงการดมกลิ่นของรหัสในอนาคต สถานการณ์รูปภาพที่คุณมีวัตถุที่คล้ายกันจำนวนมากที่คุณต้องการแสดงเป็นคลาส คลาสเหล่านี้ไม่มีฟังก์ชั่นเฉพาะใด ๆ เพียงแค่คลาสข้อมูลและแตกต่างกันตามชื่อ (และบริบท) ตัวอย่าง: Class A { String name; string description; } Class B { String name; String count; String description; } Class C { String name; String count; String description; String imageUrl; } Class D { String name; String count; } Class E { …

24 object-oriented  inheritance  dry 

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

22 object-oriented  programming-languages  inheritance 

ในอดีตที่ผ่านมาฉันเคยใช้การสืบทอดเพื่อให้สามารถขยายแบบฟอร์ม Windows ในแอปพลิเคชันของฉันได้ ถ้าแบบฟอร์มทั้งหมดของฉันมีตัวควบคุมงานศิลปะและฟังก์ชันการทำงานร่วมกันฉันจะสร้างแบบฟอร์มพื้นฐานที่ใช้ตัวควบคุมและฟังก์ชันการทำงานทั่วไปแล้วอนุญาตให้ตัวควบคุมอื่นสืบทอดจากแบบฟอร์มพื้นฐานนั้น อย่างไรก็ตามฉันพบปัญหาเล็กน้อยเกี่ยวกับการออกแบบ การควบคุมสามารถอยู่ในภาชนะหนึ่งครั้งเท่านั้นดังนั้นการควบคุมแบบคงที่ใด ๆ ที่คุณมีจะยุ่งยาก ตัวอย่างเช่นสมมติว่าคุณมีรูปแบบพื้นฐานที่เรียกว่า BaseForm ซึ่งมี TreeView ซึ่งคุณได้รับการป้องกันและคงที่เพื่อให้อินสแตนซ์อื่น ๆ (ที่ได้รับ) ของคลาสนี้ทั้งหมดสามารถแก้ไขและแสดง TreeView เดียวกันได้ สิ่งนี้จะไม่ทำงานสำหรับหลาย ๆ คลาสที่สืบทอดมาจาก BaseForm เนื่องจาก TreeView นั้นสามารถอยู่ในหนึ่งคอนเทนเนอร์ในแต่ละครั้งเท่านั้น มันน่าจะเป็นในรูปแบบสุดท้ายที่เริ่มต้น แม้ว่าทุกอินสแตนซ์สามารถแก้ไขการควบคุมได้ แต่จะแสดงในเวลาเดียวเท่านั้น แน่นอนว่ามีการแก้ไข แต่พวกมันน่าเกลียด (นี่ดูเหมือนจะเป็นการออกแบบที่แย่มากสำหรับฉันทำไมภาชนะบรรจุหลาย ๆ อันไม่สามารถเก็บพอยน์เตอร์ไปยังวัตถุเดียวกันได้อย่างไรก็ตามมันเป็นอย่างนั้น) สถานะระหว่างฟอร์มนั่นคือปุ่มสถานะข้อความป้ายกำกับ ฯลฯ ฉันต้องใช้ตัวแปรโกลบอลสำหรับและรีเซ็ตสถานะบนโหลด สิ่งนี้ไม่ได้รับการสนับสนุนโดยนักออกแบบของ Visual Studio เป็นอย่างดี มีการออกแบบที่ดีกว่า แต่ยังคงไว้ซึ่งการบำรุงรักษาที่ใช้ง่ายหรือไม่? หรือรูปแบบการสืบทอดยังคงเป็นวิธีที่ดีที่สุด? อัปเดต ฉันเปลี่ยนจากการดู MVC เป็น MVP เป็นรูปแบบการสังเกตการณ์เป็นรูปแบบกิจกรรม นี่คือสิ่งที่ฉันกำลังคิดอยู่ในขณะนี้โปรดวิจารณ์: …

20 c#  .net  object-oriented-design  inheritance  winforms 

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

19 object-oriented  inheritance  abstraction  liskov-substitution