Performanstaki değişiklikler Liskov İkame İlkesini ihlal ediyor mu?

Diyelim ki:

interface Thing
{
    GetThing();
}

class FastThing : Thing 
{
    public int GetThing()
    {
        return 1;
    }
}

class SlowThing : Thing
{
    public int GetThing()
    {
        return GetThingFromDatabase();
    }
}

Bu Liskov İkame İlkesinin ihlali midir?

Bu gerçekten bağlıdır. Bazı arayüzler, örneğin karmaşıklık kısıtlamalarına sahiptir (bunlar açıkça programlı olarak uygulanamaz). En temel durum "GetThing () bir int- yani durur" verir, bu durumda cevap "Hayır" olur - GetThing () 'in her iki sürümü de durur ve bir int döndürür.

Ancak birçok arayüz, karmaşıklık veya düz zamanda performans garantilerini ima etti veya açıkça belirtti. Örneğin, C ++ Standardında, Standard'ın açıkça izin verdiği durumlar dışında kitaplığı engelleme çağrısı ile uygulamak yasa dışıdır.

TL; DR: Hayır

Göre "değişkenleri ve kısıtları kullanarak Davranış alt türlerinin" (prensipte kayıtlılığın) öncelikle bir tür nesneler arasında "güvenli" özellikleri ile ilgilidir. İkame edilebilirliği sadece tip bilgisi bağlamında yöneten özellikler. Bir nesne türü, performansıyla dikeydir. Bu nedenle performanstaki bir fark, Liskov İkame İlkesinin ihlali değildir.

Arayüz hangi garantileri veriyor? Yana GetThingmarkaların hiçbir garanti ardından alt tipleri saygı gerekmez.

Arayüz benzer bir şeyse GetThingInLinearTimeveya taban türü sanal ise ve varsayılan uygulama bir karmaşıklıksa, bu algoritmik karmaşıklığı daha da kötüleştirmek LSP'yi ihlal eder.

Yazılımın performansının Liskov İkame Prensibi ile ilgisi yoktur.

İlke, alt tiplerin ikamesi ve bu nesneyi sadece OOP terimleriyle ikame etmenin davranışsal etkisi ile ilgilidir.

Her getThing()iki durumda da giriş ve çıkış aynı kalır ve hem yavaş hem de hızlı bir şekilde nesneleri aynı duruma getirir.

Liskov İkame Prensibi'nin kendisinin özellikle söylediği önemli mi? Bir alt tip, üst tipin tüketicisinin beklentilerini ihlal ederse, LSP'nin daha kısıtlayıcı olup olmadığına bakılmaksızın kötü bir şey gibi görünüyor.

Benim görüşüme göre, bir soyutlama tüketicisinin tüm makul beklentilerinin alt tip tarafından yerine getirilip getirilmediği LSP'nin iyi bir genellemesi gibi görünmektedir.

Bununla birlikte, genel olarak Java arayüzleri yayınladığınız örnekte, Thingarayüz tüketicisinin hızlı mı yoksa yavaş mı olacağı konusunda makul bir beklentisi olduğu açık değildir . Arayüzün javadokları, hangi işlemlerin hızlı olacağına dair söz verilecek dili içerecekse, performans gerekçesiyle bir sorun için bir argüman olabilir. Ancak Java sözleşmesi kesinlikle çeşitli uygulamaların farklı performans özelliklerine sahip olması içindir.

Bob Amca, LSP ihlalinin 3 taraf gerektirdiğini belirttiği çok benzer bir soruyu yanıtladı:

T'yi kullanan, ancak T'yi kullanan ancak S'nin bir örneği verilen T Tipi, S Tipi ve P programı.

Bu soru, söz etmediğini o, cevap olarak benzer bir yapıya sahip olduğunu bir tahmin yürütebilir P kullanıyor T ve hangi davranış P beklediği.

Cevabını burada bulabilirsiniz . (Bazılarını aşağı kaydırmanız ve Robert Martin adlı kullanıcıdan yanıt aramanız gerekir)