Чи зміни в роботі порушують принцип заміни Ліскова?

Скажіть, у мене є:

interface Thing
{
    GetThing();
}

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

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

Це порушення принципу заміни Ліскова?

Це дійсно залежить. Деякі інтерфейси, наприклад, обмежують складність (їх, очевидно, не можна запровадити програмно). Найбільш базовий випадок - "GetThing () дає int- тобто зупиняється", і в цьому випадку відповідь буде "Ні" - обидві версії GetThing () зупиняють і повертають int.

Але багато інтерфейсів передбачають або прямо заявляють гарантії продуктивності, як за складністю, так і за рівний час. Наприклад, у стандарті C ++ незаконно реалізовувати бібліотеку за допомогою виклику, що блокує, за винятком випадків, коли Стандарт це прямо дозволяє.

TL; DR: Ні

Відповідно до "Поведінкового підтипування з використанням інваріантів та обмежень" (формалізація принципу), це стосується насамперед "безпечних" властивостей типу об'єктів. Властивості, які регулюють замінність лише в контексті типової інформації. Тип об'єктів є ортогональним для його виконання. Тому різниця у виконанні не є порушенням принципу заміни Ліскова.

Які гарантії дає інтерфейс? Оскільки GetThingне дає гарантій, то підтипи не повинні його дотримуватися.

Якщо інтерфейс був що - щось на зразок , GetThingInLinearTimeабо якщо базовий тип є віртуальним і реалізація за замовчуванням одна складність, то робить , що алгоритмічна складність гірше буде порушувати LSP.

Продуктивність програмного забезпечення не має нічого спільного з Принципом заміни Ліскова.

Цей принцип пов'язаний із заміною підтипів та поведінковим впливом заміни цього об'єкта лише в термінах OOP.

Вхід і вихід getThing()залишаються однаковими для обох випадків, і повільний і швидкий, ймовірно, приводять об'єкти до одного стану.

Чи має значення те, що конкретно говорить сам Принцип заміщення Ліскова? Якщо підтип порушує сподівання споживача супертипу, це здається поганим, незалежно від того, чи є ЛСП більш обмежувальним.

Отже, на мій погляд, чи всі розумні сподівання споживача абстракції виконані підтипом, здається, хорошим узагальненням LSP.

Однак у прикладі, який ви опублікували, та з інтерфейсами Java загалом, не ясно, що споживач Thingінтерфейсу має будь-які обґрунтовані сподівання на те, чи повинен він бути швидким чи повільним. Якщо javadocs інтерфейсу повинні містити мову про те, які операції, як обіцяють, будуть швидкими, то може виникнути аргумент для проблеми з міркувань продуктивності. Але конвенція Java , безумовно, має для різних реалізацій різні характеристики продуктивності.

Дядько Боб відповів на дуже подібне запитання, де він стверджує, що порушення ЛСП вимагає 3 сторін:

Тип T, підтип S і програма P, яка використовує T, але отримує екземпляр S.

Я б ризикну здогадатися, що це запитання має подібну структуру, як та, на яку він відповів, оскільки в ньому не згадується P, який використовує T, і яку поведінку очікує Р.

Ви можете знайти його відповідь тут . (Вам потрібно буде прокрутити униз і шукати відповідь у користувача на ім’я Роберт Мартін)