Liskov'un yerine geçme ilkesi

Liskov’un yerine geçme ilkesi (İngilizce: Liskov Substitution Principle, kısaca LSP), nesne yönelimli programlamada bir yazılım bileşeninde kullanılan bir alt sınıfın, üst sınıfın yerine geçerek sistemin doğru çalışmasını sürdürebilmesi gerektiğini ifade eden bir yazılım tasarım ilkesidir. İlk kez Barbara Liskov tarafından 1987 yılında tanımlanmıştır. Bu ilke, SOLID ilkeleri adıyla bilinen beş temel yazılım mühendisliği ilkesinden biridir.^[1][2]

Tarihçe

Liskov’un yerine geçme ilkesi, bilgisayar bilimci Barbara Liskov ve Jeannette Wing tarafından 1987 yılında A Behavioral Notion of Subtyping başlıklı bilimsel bildiride tanıtılmıştır.^[3] Bu bildiride, alt türlerin, üst türlerin tüm davranışsal beklentilerini karşılaması gerektiği öne sürülmüş ve bu kavram, nesne yönelimli sistemlerde alt sınıfların doğru şekilde kalıtım yoluyla kullanılabilmesi için bir temel oluşturmuştur.

Bu ilke, yazılım mühendisliği dünyasında yaygınlık kazanarak, Robert C. Martin’in öncülüğünde geliştirilen SOLID ilkeleri arasında yerini almıştır.^[1]

Tanım ve özellikler

Liskov’un yerine geçme ilkesi, genellikle şu şekilde özetlenir:

"Bir programın, bir sınıfın nesneleri yerine bu sınıfın alt sınıflarının nesneleri kullanıldığında, programın doğruluğu bozulmadan çalışmaya devam etmesi gerekir."^[3]

Özellikleri

• Alt sınıf, üst sınıfın tüm davranışsal beklentilerini karşılamalıdır.
• Alt sınıf, üst sınıfın arayüzünü genişletebilir, ancak değiştiremez.
• Alt sınıflar, üst sınıftan devralınan fonksiyonların ön koşullarını daraltmamalı, sonuçlarını ise genişletmemelidir.^[4]

Örnek: Dikdörtgen–Kare Problemi

LSP’ye klasik bir ihlal örneği, “dikdörtgen–kare problemi” olarak bilinir. Kare, geometrik olarak dikdörtgenin özel bir hâli olsa da yazılım dünyasında bu ilişki kalıtımla ifade edildiğinde istenmeyen durumlar ortaya çıkabilir:

class Dikdortgen {
    protected double genislik;
    protected double yukseklik;

    public void setGenislik(double g) { this.genislik = g; }
    public void setYukseklik(double y) { this.yukseklik = y; }
    public double alanHesapla() { return genislik * yukseklik; }
}

class Kare extends Dikdortgen {
    @Override
    public void setGenislik(double g) {
        super.setGenislik(g);
        super.setYukseklik(g);
    }

    @Override
    public void setYukseklik(double y) {
        super.setGenislik(y);
        super.setYukseklik(y);
    }
}

Bu örnekte, kullanıcılar `setGenislik()` ve `setYukseklik()` yöntemlerinin birbirinden bağımsız olduğunu varsayar. Ancak `Kare` sınıfı bu varsayımı bozar, dolayısıyla LSP ihlali gerçekleşmiş olur.

Yazılım tasarımına etkileri

LSP, nesne yönelimli programlamada kalıtım hiyerarşisinin doğru kurulmasını sağlar. İlkenin uygulanması şu faydaları getirir:

• Kodun yeniden kullanılabilirliğini artırır.
• Alt sınıfların üst sınıfların yerine kullanılabilir olmasını garanti eder.
• Bakımı kolay ve genişletilebilir yazılım sistemleri oluşturulmasına katkı sağlar.^[5]

Tartışmalar ve eleştiriler

LSP, yazılım mühendisliğinde önemli bir yer edinmiş olsa da bazı durumlarda katı yorumlanmasının tasarımı zorlaştırabileceği ileri sürülmüştür.^[6] Özellikle davranışsal açıdan karmaşık soyutlamalarda, alt sınıfların tüm üst sınıf beklentilerini karşılaması zor olabilir. Bu nedenle modern yazılım tasarım yaklaşımlarında kalıtım yerine bileşen kullanımı (composition) ya da arayüz temelli tasarım önerilmektedir.