ობიექტზე ორიენტირებული პროგრამირების მემკვიდრეობის გამოყენება რომელ სიტუაციებში სასარგებლოა და რომელ სიტუაციებში უნდა უარყოს?

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

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

მემკვიდრეობიდან უარის თქმა საჭიროა, თუ:

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

// როდესაც მემკვიდრეობა სასარგებლოა
open class Animal {
    open fun makeSound() {
        println("საერთო ცხოველის ხმა")
    }
}

class Dog : Animal() { // Dog IS-A Animal
    override fun makeSound() {
        println("ვუוף")
    }
}

class Cat : Animal() { // Cat IS-A Animal
    override fun makeSound() {
        println("მიო")
    }
}

// როდესაც კომპოზიცია მერყეობს მემკვიდრეობაზე "has-a" ურთიერთობაში
class Engine {
    fun start() { println("ძრავი დაიწყო") }
}

// მანქანისთვის Engine-ის მემკვიდრეობა არ არის საჭირო
// class Car : Engine() // ცუდი დიზაინი, Car არ არის Engine

class Car {
    private val engine = Engine() // Car HAS-A Engine
    fun drive() {
        engine.start()
        println("მანქანა მოძრაობს")
    }
}