პროგრამირებაში მემკვიდრეობა როდის არის სასარგებლო და როდის შეიძლება იყოს არასასურველი?

მემკვიდრეობა შეიძლება იყოს სასარგებლო:

• კოდის გადამეორებითი გამოყენება: საერთო მეთოდები და ველები განსაზღვრულია ძირითადი კლასში და მემკვიდრეობით გადაეცემა ქვესინფებს.
• პოლიმორფიზმი: ქვესინფების ობიექტები შეიძლება განიხილებოდეს როგორც ძირითადი კლასის ობიექტები, რაც საშუალებას აძლევს გამოიყენოს საერთო ინტერფეისი სხვადასხვა რეალიზაციისთვის.
• ტიპების ჰიეარარქიების შექმნა: ურთიერთობების მოდელირება "არის-და" შორის ობიექტების.

მემკვიდრეობა შეიძლება იყოს არასასურველი ან პრობლემური შემდეგ შემთხვევებში:

• მჭიდრო კავშირი (tight coupling): ძირითადი კლასში ცვლილებები შეიძლება გავლენა იქონიოს ყველა ქვესინფზე, რაც გამარტივებს შენარჩუნებას და რეფაქტორირებას.
• დიამანტის პრობლემა (diamond problem): მრავალმემკვიდრეობით ენებში, როდესაც ორი კლასი მემკვიდრეობს საერთო ძირითადი კლასიდან, და მესამე კლასი ამ ორი კლასი მემკვიდრეობს, იჩენს თავს გაურკვევლობა მეთოდების გამოძახებისას. (არ გამოიყენება პირდაპირ Java/Kotlin-ში, მაგრამ კონცეპტუალური პრობლემა პოლიმორფული ჰიეარარქიებში).
• LSP (Liskov-ის ჩანაცვლების პრინციპის) დარღვევა: ქვესინფს არ შეუძლია გამოიყენოს როგორც ძირითადი კლასი, ისე შეცვალოს პროგრამის სისწორე. ხშირად მიუთითებს მემკვიდრეობის არასწორ გამოყენებაზე.
• ძირითადი კლასის გაფართოება (bloat): ძირითადი კლასი ძალიან რთული ხდება და შეიცავს ფუნქციებს, რომლებიც საჭიროა მხოლოდ გარკვეული ქვესინფებისთვის.
• ძირითადი კლასის მყიფეობა: მცირე ცვლილებები ძირითადი კლასში შეიძლება გაურკვევლად დააზიანოს ქვესინფების ქცევა.

ალტერნატიული მიდგომები, როგორიცაა კომპოზიცია ("აქვს-" ურთიერთობები) და ინტერფეისები, ხშირად უკეთესია მემკვიდრეობასთან შედარებით, რათა მიაღწიოს მოქნილობას და სუსტი კავშირს.