การออกแบบสำหรับการสืบทอดสามารถทำให้มีค่าใช้จ่ายเพิ่มเติมได้อย่างไร [ปิด]

ดังนั้นฉันต้องการสืบทอดจากsealed classในcsharpและถูกไฟไหม้ ไม่มีทางที่จะเปิดผนึกจนกว่าคุณจะเข้าถึงแหล่งข้อมูลได้

ฉันคิดว่า "ทำไมsealedถึงมีอยู่จริง" 4 เดือนที่แล้ว ฉันไม่สามารถเข้าใจได้แม้จะอ่านสิ่งต่าง ๆ มากมายเช่น:

• ความปรารถนาของ Jon Skeet " คลาสถูกปิดผนึกโดยค่าเริ่มต้นใน. NET "
• ชอบการแต่งมากกว่าการสืบทอด?
• "คุณไม่ควรปิดคลาสทั้งหมด (... )"
• คุณจะล้อเลียนคลาสที่ปิดสนิทได้อย่างไร

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

• ทำไมชั้นเรียนควรเป็นอย่างอื่นนอกจาก "นามธรรม" หรือ "ขั้นสุดท้าย / ปิดผนึก"
• ในการเขียนโปรแกรมกว่า 15 ปีครั้งแรกที่ฉันได้ยินเกี่ยวกับSOLIDจากคำตอบของคำถามที่เชื่อมโยงแล้วและเห็นได้ชัดว่าฉันไม่ได้อ่านมาตลอด 4 เดือนที่ผ่านมา

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

คำถามเดิมกว้างเกินไปและอัตนัย มันเป็นพื้นถาม:

1. ในชื่อเก่า: เหตุผลหนึ่งที่ดีในการใช้ตราประทับ
2. ในร่างกาย: วิธีการปรับเปลี่ยนคลาสที่ปิดผนึกอย่างถูกต้อง? ลืมเกี่ยวกับมรดก ใช้องค์ประกอบ?

แต่ตอนนี้ความเข้าใจ (ซึ่งฉันไม่ได้เมื่อวานนี้) ที่ทุกคนsealedไม่สามารถป้องกันการสืบทอดและเราสามารถและควรใช้องค์ประกอบมากกว่าการสืบทอดฉันรู้ว่าสิ่งที่ฉันต้องการคือตัวอย่างที่ใช้งานได้จริง

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

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

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

สมมติว่านักพัฒนาขยายคลาส core. Net (เนื่องจากไม่มีการปิดผนึก) และทำให้มันทำงานได้อย่างสมบูรณ์ Yay สำหรับนักพัฒนา ผู้พัฒนาส่งมอบผลิตภัณฑ์ให้กับลูกค้า แอพของนักพัฒนาใช้งานได้ดี ลูกค้ามีความสุข ชีวิตเป็นสิ่งที่ดี.

ตอนนี้ Microsoft เปิดตัวระบบปฏิบัติการใหม่ซึ่งรวมถึงการแก้ไขข้อบกพร่องในระดับแกนหลัก. Net นี้โดยเฉพาะ ลูกค้าต้องการติดตามเวลาและเลือกที่จะติดตั้งระบบปฏิบัติการใหม่ ในทันทีที่แอปพลิเคชันที่ลูกค้าชื่นชอบใช้งานไม่ได้อีกต่อไปเพราะมันไม่ได้คำนึงถึงข้อผิดพลาดที่ได้รับการแก้ไขในระดับแกนกลาง. Net

ใครจะเป็นผู้ตำหนิ?

ผู้ที่คุ้นเคยกับประวัติศาสตร์ของ Microsoft ทราบว่าระบบปฏิบัติการใหม่ของ Microsoft จะได้รับการตำหนิและไม่ใช่ซอฟต์แวร์แอปพลิเคชันที่ใช้ไลบรารี windows ในทางที่ผิด ดังนั้นจึงกลายเป็นหน้าที่ของ Microsoft ในการแก้ไขปัญหาแทน บริษัท แอปพลิเคชันที่สร้างปัญหา นี่คือหนึ่งในเหตุผลที่รหัส Windows กลายเป็นป่อง จากสิ่งที่ฉันได้อ่านรหัสระบบปฏิบัติการ Windows จะเกลื่อนไปด้วย if-then เฉพาะเจาะจงเพื่อตรวจสอบว่ามีการใช้งานแอปพลิเคชันและรุ่นที่เฉพาะเจาะจงหรือไม่และหากเป็นเช่นนั้นให้ดำเนินการพิเศษบางอย่างเพื่อให้โปรแกรมทำงานได้ นั่นเป็นเงินจำนวนมากที่ Microsoft ใช้เพื่อแก้ไขความไม่สามารถของ บริษัท อื่น

การใช้sealedไม่ได้เป็นการกำจัดภาพจำลองทั้งหมดอย่างสมบูรณ์ แต่สามารถช่วยได้

sealedใช้เพื่อระบุว่าผู้เขียนของคลาสไม่ได้ออกแบบมาให้สืบทอด ไม่มีอะไรน้อยไม่มีอะไรเพิ่มเติม

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

ลองจินตนาการถึงกรณีที่ชั้นมาจากCustomBoeing787 Airlinerสิ่งนี้CustomBoeing787จะแทนที่วิธีการป้องกันบางอย่างจากAirlinerแต่ไม่ใช่ทั้งหมด หากนักพัฒนามีเวลาเพียงพอและคุ้มค่าเขาสามารถทดสอบหน่วยเพื่อให้แน่ใจว่าทุกอย่างทำงานได้ตามที่คาดไว้แม้ในบริบทที่มีการเรียกวิธีที่ไม่ overriden (ตัวอย่างเช่น setters ที่มีการป้องกันซึ่งเปลี่ยนสถานะของวัตถุ) หากผู้พัฒนารายเดียวกัน (1) ไม่มีเวลา (2) ไม่ต้องการใช้เจ้านายหรือลูกค้าเพิ่มเติมหลายร้อยหรือหลายพันดอลลาร์หรือ (3) ไม่ต้องการเขียนรหัสเพิ่มเติมเขาไม่ ต้องการตอนนี้ (YAGNI) จากนั้นเขาสามารถ:

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

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

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

เมื่อชั้นเรียนถูกปิดผนึกจะช่วยให้รหัสที่ใช้ประเภทนั้นรู้ว่าพวกเขากำลังทำอะไรอยู่

ตอนนี้ใน C # stringคือsealedคุณไม่สามารถสืบทอดจากมันได้ แต่ให้ลองคิดดูสักวินาทีว่ามันไม่ได้เป็นอย่างนั้น ถ้าคุณทำแล้วมีคนสามารถเขียนชั้นเรียนเช่นนี้:

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

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

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

มีเหตุผลที่ดีที่จะใช้ผนึกหรือไม่?

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

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

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

ฉันไม่ได้ตั้งใจว่าจะเกินไปแต่ถ้าตอนนี้คุณเพิ่งได้ยินเรื่อง SOLID และการทดสอบหน่วยบางทีคุณควรจะออกไปจากหินและเขียนโค้ด สิ่งต่าง ๆ ไม่ชัดเจนและไม่ค่อย "ทำ X" หรือ "ไม่เคยใช้ Y" หรือ "Z ดีที่สุด" มักจะเป็นวิธีที่ถูกต้อง เมื่อคุณเขียนโค้ดคุณจะเห็นกรณีที่sealedอาจดีและกรณีที่ทำให้คุณเสียใจ - เช่นเดียวกับการแลกเปลี่ยนอื่น ๆ

ก่อนอื่นคุณควรอ่านโพสต์ของ Eric Lippert ว่าทำไม Microsoft ถึงผนึกคลาสไว้

http://blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx

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

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

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

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

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

ปัญหาเกี่ยวกับการปิดผนึกใน C # นั้นค่อนข้างสุดท้าย ใน 7 ปีของการพัฒนาเชิงพาณิชย์ C # ที่เดียวที่ฉันเคยเห็นคือใช้ในคลาส Microsoft .NET ซึ่งฉันรู้สึกว่าฉันมีเหตุผลที่ถูกต้องตามกฎหมายที่จะขยายคลาสเฟรมเวิร์กเพื่อใช้พฤติกรรมที่ปรับแล้วและเนื่องจากคลาสถูกปิดผนึก .

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

ดังนั้นโดยสรุปฉันมั่นใจในมุมมองที่ปิดผนึกไม่ได้มีประโยชน์และไม่มีอะไรที่ฉันได้อ่านที่นี่จนถึงตอนนี้ได้เปลี่ยนมุมมองนั้น

ฉันสามารถเห็นได้ว่ามีสามข้อโต้แย้งที่แสดงให้เห็นถึงการปิดผนึกที่วางไว้จนถึงขณะนี้

1. ข้อโต้แย้งที่ 1 คือมันกำจัดแหล่งที่มาของข้อบกพร่องเมื่อผู้คนได้รับมรดกจากชั้นเรียนและจากนั้นได้เพิ่มการเข้าถึง internals ของชั้นเรียนนั้นโดยไม่ต้องเข้าใจภายในอย่างถูกต้อง

2. อาร์กิวเมนต์ 2 คือถ้าคุณขยายคลาส microsoft จากนั้น microsoft จะใช้การแก้ไขข้อบกพร่องในคลาสนั้น แต่ extention ของคุณอาศัยข้อผิดพลาดนั้นรหัสของคุณจะเสียหายตอนนี้ microsoft จะได้รับโทษและผนึกป้องกันไว้

3. อาร์กิวเมนต์ 3 คือในฐานะผู้พัฒนาคลาสฉันเลือกได้ว่าจะให้คุณขยายมันเป็นส่วนหนึ่งของการออกแบบคลาสของฉันหรือไม่

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

ฉันเข้าใจว่าฐานข้อเท็จจริงสำหรับ arg 2 มาจากไหน โดยเฉพาะอย่างยิ่งเมื่อไมโครซอฟท์ทำการตรวจสอบระบบปฏิบัติการเพิ่มเติมเกี่ยวกับการเรียก win32 api เพื่อระบุการโทรที่มีรูปแบบไม่ถูกต้องซึ่งได้ปรับปรุงเสถียรภาพทั่วไปของ Windows XP เมื่อเทียบกับ Windows NT แต่ในระยะเวลาสั้น ๆ Microsoft แก้ไขปัญหานี้โดยการใส่ 'กฎ' เพื่อให้การตรวจสอบเหล่านี้พูดไม่สนใจเมื่อแอป X ละเมิดกฎนี้ซึ่งเป็นข้อบกพร่องที่รู้จัก

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

อาร์กิวเมนต์ 3 เป็นอาร์กิวเมนต์เดียวที่มีเนื้อหาใด ๆ ที่จะปรับตัวเอง แต่มันก็ยังอ่อนแอ มันขัดกับธัญพืชที่นำมาใช้ใหม่

ฉันใช้sealedคีย์เวิร์ดในคลาสที่มีเมธอดแบบสแตติกเท่านั้น

เห็นได้ชัดจากคำถามของฉันฉันไม่มีผู้เชี่ยวชาญที่นี่ แต่ฉันไม่เห็นเหตุผลที่sealedจะมีอยู่

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

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

อาจมีคำหลักstableดังนั้นผู้คนจะรู้ว่าปลอดภัยกว่าที่จะรับมรดกจากมัน