Liskov'un yerine geçme ilkesi

Liskov’un yerine geçme ilkesi (, 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.

 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. 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.

 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."

 Ö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.

 Ö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.

 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. Ö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.

 Kaynakça 

Kategori:SOLID ilkeleri
Kategori:Nesne yönelimli programlama
Kategori:Yazılım tasarımı
Kategori:Yazılım mühendisliği
Kategori:1987 tanıtımları