มีเหตุผล "ของจริง" ที่ไม่ชอบการสืบทอดหลายครั้งหรือไม่

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

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

เพียงตระหนักถึงปัญหานี้ 90% ของการต่อสู้ นอกจากนี้ฉันคิดว่าฉันได้ยินบางสิ่งบางอย่างเมื่อหลายปีก่อนเกี่ยวกับวัตถุประสงค์ทั่วไปที่เกี่ยวข้องกับอัลกอริทึม "ซองจดหมาย" หรืออะไรทำนองนั้น (เสียงกริ่งดังขึ้นทุกคนหรือไม่)

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

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

ตัวอย่าง

รถขยาย WheeledVehicle, KIASpectra ขยายรถยนต์และอิเล็กทรอนิกส์ KIASpectra มีวิทยุ เหตุใด KIASpectra จึงไม่มี Electronic

1. เพราะมันเป็นอิเล็กทรอนิกส์ การสืบทอดกับการจัดองค์ประกอบควรเป็นความสัมพันธ์แบบ is-a กับความสัมพันธ์แบบ a-a

2. เพราะมันเป็นอิเล็กทรอนิกส์ มีสายไฟแผงวงจรสวิตช์ ฯลฯ ทั้งหมดขึ้นและลงสิ่งนั้น

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

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

private void runOrDont()
{
    if (this.battery)
    {
        if (this.battery.working && this.switchedOn)
        {
            this.run();
            return;
        }
    }
    this.dontRun();
}

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

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

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

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

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

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

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

มีกรณีทดสอบเดียวที่แตกถ้าคุณแทนการใช้งานของสแควร์สำหรับสี่เหลี่ยมนี้

var rectangle = new Square();
rectangle.length= 5;
rectangle.width= 6;
Assert.AreEqual(30, rectangle.GetArea()); 
//Square returns 36 because setting the width clobbers the length

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

ข้อผิดพลาดที่ฉันพูดถึงกับ Pegasus ใน MI และความสัมพันธ์แบบสี่เหลี่ยมผืนผ้า / สี่เหลี่ยมนั้นเป็นผลมาจากการออกแบบที่ไม่มีประสบการณ์สำหรับชั้นเรียน โดยทั่วไปการหลีกเลี่ยงการสืบทอดหลาย ๆ แบบเป็นวิธีที่จะช่วยให้นักพัฒนามือใหม่เริ่มหลีกเลี่ยงการยิงตัวเองด้วยการเดินเท้า เช่นเดียวกับหลักการออกแบบทั้งหมดการมีระเบียบวินัยและการฝึกอบรมขึ้นอยู่กับพวกเขาช่วยให้คุณสามารถค้นพบเมื่อมันตกลงที่จะทำลายพวกเขาในเวลา ดูรูปแบบการได้รับทักษะของเดรย์ฟัสที่ระดับผู้เชี่ยวชาญความรู้ที่แท้จริงของคุณจะอยู่เหนือความเชื่อมั่นสูงสุด / หลักการ คุณสามารถ "รู้สึก" เมื่อกฎใช้ไม่ได้

และฉันก็เห็นด้วยว่าฉันค่อนข้างโกงกับตัวอย่าง "โลกแห่งความจริง" ว่าทำไม MI ถึงถูกขมวดคิ้ว

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

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

การหลีกเลี่ยง MI ช่วยให้คุณก้าวเท้าเลี่ยงอันตรายนี้โดยสิ้นเชิง และอาจทำให้คุณแตกคุณลักษณะทั่วไปที่สามารถใช้ซ้ำได้ของวิดเจ็ต UI ของคุณเพื่อให้สามารถใช้งานได้ตามต้องการ ตัวอย่างที่ยอดเยี่ยมของสิ่งนี้คือWPF Attached Propertyซึ่งอนุญาตให้องค์ประกอบเฟรมเวิร์กใน WPF จัดเตรียมคุณสมบัติที่อิลิเมนต์เฟรมเวิร์กอื่นสามารถใช้ได้โดยไม่ต้องสืบทอดจากอิลิเมนต์พาเรนต์เฟรม

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

นักพัฒนาใช้แนวคิดนี้เพิ่มเติมและใช้คุณสมบัติที่แนบมาเป็นวิธีในการทำพฤติกรรมขององค์ประกอบ (ตัวอย่างนี่คือโพสต์ของฉันในการสร้างGridView ที่เรียงลำดับได้โดยใช้คุณสมบัติที่แนบมาซึ่งเขียนก่อน WPF รวม DataGrid) วิธีการดังกล่าวได้รับการยอมรับว่าเป็นรูปแบบการออกแบบ XAML ที่เรียกว่าพฤติกรรมที่แนบมา

หวังว่านี่จะให้ข้อมูลเชิงลึกมากขึ้นเกี่ยวกับสาเหตุที่ทำให้หลายมรดกสืบทอดโดยทั่วไป

มีบางอย่างที่ฉันไม่เห็นใช่ไหม

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

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

ในกรณีนี้คุณมี 3 สถานการณ์:

1. A ไม่รู้อะไรเลยเกี่ยวกับ B - เยี่ยมมากคุณสามารถรวมชั้นเรียนเข้าด้วยกันเพราะคุณโชคดี
2. A รู้เกี่ยวกับ B - ทำไม A ถึงไม่ได้รับมรดกจาก B?
3. A และ B รู้เกี่ยวกับกันและกัน - ทำไมคุณไม่ทำชั้นเดียว? ประโยชน์ที่ได้รับจากการทำสิ่งเหล่านี้ควบคู่กัน แต่สามารถทดแทนได้บางส่วน?

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

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

เหตุผลเดียวที่ทำไมมันไม่ได้รับอนุญาตเพราะมันทำให้คนยิงตัวเองได้ง่าย

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

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

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

แก้ไข

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

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

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

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

คำตอบอื่น ๆ ที่นี่ดูเหมือนจะเป็นทฤษฎี ดังนั้นนี่คือตัวอย่างของ Python ที่เป็นรูปธรรมทำให้เรียบง่ายลงซึ่งฉันได้ทุบหัวทิ่มเข้าไปซึ่งต้องใช้การรีแฟคเตอร์จำนวนพอใช้:

class Foo(object):
   def zeta(self):
      print "foozeta"

class Bar(object):
   def zeta(self):
      print "barzeta"

   def barstuff(self):
      print "barstuff"
      self.zeta()

class Bang(Foo, Bar):
   def stuff(self):
      self.zeta()
      print "---"
      self.barstuff()

z = Bang()
z.stuff()

Barถูกเขียนขึ้นโดยสมมติว่ามีการใช้งานของตัวเองzeta()ซึ่งโดยทั่วไปเป็นข้อสันนิษฐานที่ค่อนข้างดี คลาสย่อยควรแทนที่มันตามความเหมาะสมเพื่อที่จะทำสิ่งที่ถูกต้อง น่าเสียดายที่ชื่อเหล่านี้เหมือนกันโดยบังเอิญ - พวกเขาทำสิ่งที่แตกต่างกัน แต่Barตอนนี้กำลังเรียกFooใช้งาน:

foozeta
---
barstuff
foozeta

มันค่อนข้างน่าผิดหวังเมื่อไม่มีข้อผิดพลาดเกิดขึ้นแอปพลิเคชันเริ่มทำงานผิดพลาดเล็กน้อยและการเปลี่ยนรหัสที่ทำให้เกิด (การสร้างBar.zeta) ดูเหมือนจะไม่เกิดปัญหา

ฉันจะยืนยันว่าไม่มีปัญหาจริงใด ๆ กับ MI ในภาษาที่เหมาะสม กุญแจสำคัญคือการอนุญาตให้โครงสร้างเพชร แต่ต้องการให้ประเภทย่อยให้แทนที่ของตัวเองแทนการรวบรวมรวบรวมหนึ่งในการใช้งานขึ้นอยู่กับกฎบางอย่าง

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

type Sequence[+A] {
  String toString() {
    return "[" + ... + "]";
  }
}

type Set[+A] {
  String toString() {
    return "{" + ... + "}";
  }
}

type OrderedSet[+A] extends Sequence[A], Set[A] {
  String toString() {
    // This is Guava's syntax for statically invoking instance methods
    return Set.toString(this);
  }
}

หากเราไม่ได้ให้OrderedSetตัวเองtoStringเราจะได้รับข้อผิดพลาดในการรวบรวม ไม่แปลกใจ.

ฉันพบว่า MI มีประโยชน์อย่างยิ่งกับคอลเล็กชัน ตัวอย่างเช่นฉันต้องการใช้RandomlyEnumerableSequenceประเภทเพื่อหลีกเลี่ยงการประกาศgetEnumeratorสำหรับอาร์เรย์ deques และอื่น ๆ :

type Enumerable[+A] {
  Source[A] getEnumerator();
}

type Sequence[+A] extends Enumerable[A] {
  A get(Int index);
}

type RandomlyEnumerableSequence[+A] extends Sequence[A] {
  Source[A] getEnumerator() {
    ...
  }
}

type DynamicArray[A] extends MutableStack[A],
                             RandomlyEnumerableSequence[A] {
  // No need to define getEnumerator.
}

หากเราไม่มี MI เราสามารถเขียนRandomAccessEnumeratorคอลเล็กชั่นหลายอย่างให้ใช้ แต่ต้องเขียนgetEnumeratorวิธีสั้น ๆ ที่ยังคงเพิ่มแผ่นความร้อน

ในทำนองเดียวกัน, มิชิแกนจะเป็นประโยชน์สำหรับการสืบทอดการใช้งานมาตรฐานequals, hashCodeและtoStringสำหรับคอลเลกชัน

การสืบทอดนั้นไม่สำคัญหรือไม่สำคัญ หากวัตถุสองชนิดที่แตกต่างกันจะถูกทดแทนนั่นคือสิ่งที่สำคัญแม้ว่าพวกเขาจะไม่ได้รับการเชื่อมโยงโดยการสืบทอด

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

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

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

ในหลาย ๆ ภาษาการสืบทอดของคลาสจะถูกแช่งด้วยการสืบทอดของสัญลักษณ์ เมื่อคุณได้คลาส D จากคลาส B คุณไม่เพียง แต่สร้างความสัมพันธ์ประเภท แต่เนื่องจากคลาสเหล่านี้ยังใช้เป็นเนมสเปซศัพท์คุณจึงต้องจัดการกับการนำเข้าสัญลักษณ์จาก B เนมสเปซไปยัง D เนมสเปซนอกเหนือจาก ความหมายของสิ่งที่เกิดขึ้นกับประเภท B และ D ตัวเอง การสืบทอดหลายครั้งทำให้เกิดปัญหาการปะทะกันของสัญลักษณ์ ถ้าเราสืบทอดจากcard_deckและgraphicทั้งสองนั้นมีdrawวิธีการ"มี" มันหมายความว่าอะไรกับdrawวัตถุที่เกิดขึ้น? ระบบวัตถุที่ไม่มีปัญหานี้เป็นระบบ Common Lisp อาจไม่ได้เกิดขึ้นโดยบังเอิญการสืบทอดหลายครั้งจะถูกใช้ในโปรแกรม LISP

มีการนำไปใช้อย่างไม่ถูกต้องไม่ควรเกลียดสิ่งใด (เช่นการสืบทอดหลายรายการ)

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

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

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

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

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

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

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

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

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

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

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

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

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

• ความสามารถในการมีหลายโมดูลที่คอมไพล์แยกต่างหากรวมคลาสที่สืบทอดจากคลาสของโมดูลอื่นและคอมไพล์โมดูลที่มีคลาสฐานโดยไม่ต้องคอมไพล์ทุกโมดูลที่สืบทอดจากคลาสฐานนั้น

• ความสามารถสำหรับชนิดในการสืบทอดการใช้งานสมาชิกจากคลาสพาเรนต์โดยไม่ต้องมีชนิดที่ได้รับมาเพื่อนำมาใช้ใหม่

• สัจพจน์ที่อินสแตนซ์ของวัตถุใด ๆ อาจเป็น upcast หรือ downcast โดยตรงกับตัวเองหรือประเภทฐานใด ๆ ของมันและ upcasts และ downcasts ดังกล่าวในการรวมกันหรือลำดับใด ๆ มักจะรักษาตัวตน

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

(*) โดยทั่วไปแล้วโดยกำหนดให้ประเภทที่สนับสนุนการสืบทอดหลายรายการถูกประกาศเป็น "ส่วนต่อประสาน" แทนคลาสและไม่อนุญาตให้ส่วนต่อประสานทำทุกอย่างที่ชั้นเรียนปกติสามารถทำได้

ถ้าใครอยากจะอนุญาตให้มีการสืบทอดหลายมรดกโดยทั่วไปสิ่งอื่นจะต้องหลีกทาง ถ้า X และ Y ทั้งคู่สืบทอดจาก B ทั้งคู่จะแทนที่สมาชิก M และ chain เดียวกันกับการใช้งานพื้นฐานและหาก D สืบทอดจาก X และ Y แต่ไม่ได้แทนที่ M แล้วให้ยกตัวอย่าง q ประเภท D สิ่งที่ควร (( B) q) .M () ทำอย่างไร การไม่อนุญาตนักแสดงดังกล่าวจะละเมิดความจริงที่บอกว่าวัตถุใด ๆ ที่สามารถถ่ายทอดไปยังประเภทฐานใด ๆ ได้ แต่พฤติกรรมที่เป็นไปได้ของนักแสดงและการเรียกสมาชิกจะละเมิดความจริงเกี่ยวกับวิธีการผูกมัด เราอาจต้องการให้คลาสนั้นโหลดร่วมกับเวอร์ชันพื้นฐานของคลาสพื้นฐานที่คอมไพล์แล้วเท่านั้น แต่มักจะไม่สะดวก การมีรันไทม์ปฏิเสธที่จะโหลดประเภทใด ๆ ที่บรรพบุรุษสามารถเข้าถึงได้โดยมากกว่าหนึ่งเส้นทางอาจใช้การได้ แต่จะ จำกัด ประโยชน์ของการสืบทอดหลายอย่างมาก การอนุญาตเส้นทางที่ใช้ร่วมกันเฉพาะเมื่อไม่มีความขัดแย้งจะสร้างสถานการณ์ที่ X รุ่นเก่าจะเข้ากันได้กับ Y เก่าหรือใหม่และ Y เก่าจะเข้ากันได้กับ X เก่าหรือใหม่ แต่ X ใหม่และ Y ใหม่จะ สามารถทำงานร่วมกันได้แม้ว่าจะไม่ได้ทำสิ่งใดก็ตามที่คาดหวังว่าจะเป็นการเปลี่ยนแปลงที่ผิดพลาด

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