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

Скажімо, у нас є список суб'єктів Завдання та ProjectTaskпідтип. Завдання можуть бути закриті в будь-який час, за винятком випадків, ProjectTasksколи вони не можуть бути закриті, коли вони мають статус Почато. Користувальницький інтерфейс повинен гарантувати, що можливість закрити розпочатий доступ ProjectTaskніколи не доступна, однак у домені є деякі гарантії:

public class Task
{
     public Status Status { get; set; }

     public virtual void Close()
     {
         Status = Status.Closed;
     }
}

public class ProjectTask : Task
{
     public override void Close()
     {
          if (Status == Status.Started) 
              throw new Exception("Cannot close a started Project Task");

          base.Close();
     }
}

Тепер при виклику Close()Завдання є ймовірність, що виклик не вдасться, якщо це статус ProjectTaskіз запущеним статусом, коли він не був би базовим завданням. Але це ділові вимоги. Це повинно провалитися. Чи можна це вважати порушенням принципу заміни Ліскова ?

Так, це порушення ЛСП. Принцип заміщення Ліскова вимагає цього

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

Ваш приклад порушує першу вимогу, посилюючи передумову для виклику Close()методу.

Ви можете виправити це, вивівши посилену попередню умову на найвищий рівень ієрархії спадкування:

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

Зазначаючи, що виклик Close()дійсний лише в тому стані, коли CanClose()повернення trueви вносите, попередня умова застосовується як до, Taskтак і до ProjectTask, виправляючи порушення LSP:

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

Так. Це порушує LSP.

Моя пропозиція - додати CanCloseметод / властивість до базового завдання, тож будь-яке завдання може визначити, чи можна закрити завдання в цьому стані. Це також може навести причину. І видаліть віртуальну з Close.

На основі мого коментаря:

public class Task {
    public Status Status { get; private set; }

    public virtual bool CanClose(out String reason) {
        reason = null;
        return true;
    }
    public void Close() {
        String reason;
        if (!CanClose(out reason))
            throw new Exception(reason);

        Status = Status.Closed;
    }
}

public ProjectTask : Task {
    public override bool CanClose(out String reason) {
        if (Status != Status.Started)
        {
            reason = "Cannot close a started Project Task";
            return false;
        }
        return base.CanClose(out reason);
    }
}

Принцип заміщення Ліскова визначає, що базовий клас повинен бути замінений будь-яким з його підкласів, не змінюючи жодного з бажаних властивостей програми. Оскільки лише ProjectTaskвиняток викликає, коли закривається, програма повинна бути змінена таким чином, щоб вона була доступною для цього, і вона повинна ProjectTaskвикористовуватися для заміни Task. Тож це порушення.

Але якщо ви модифікуєте, Taskвказавши у своєму підписі, що він може створювати виняток, коли він закритий, то ви не порушите цей принцип.

Порушення ЛСП вимагає трьох сторін. Тип T, підтип S і програма P, яка використовує T, але отримує екземпляр S.

У вашому запитанні передбачено T (Завдання) та S (ProjectTask), але не P. Отже, ваше запитання неповне, і відповідь кваліфікована: Якщо існує P, який не очікує винятку, для цього P у вас є LSP порушення. Якщо кожен P очікує на виняток, то порушення LSP немає.

Тим НЕ менше, ви робите мати SRP порушення. Те, що стан завдання може бути змінено, і політика того, що певні завдання в певних штатах не повинні бути змінені в інших штатах, є двома дуже різними обов'язками.

• Відповідальність 1: Представити завдання.
• Відповідальність 2: Реалізуйте політику, яка змінює стан завдань.

Ці дві відповідальності змінюються з різних причин і тому повинні бути в окремих класах. Завдання повинні обробляти факт завдання, а також дані, пов'язані з завданням. TaskStatePolicy повинен обробляти спосіб переходу завдань із стану в стан у заданій програмі.

Це може бути, а може і не бути порушенням LSP.

Серйозно. Вислухай мене.

Якщо ви дотримуєтеся LSP, об'єкти типу ProjectTaskповинні поводитись так, як Taskочікується, що вони поводяться.

Проблема вашого коду полягає в тому, що ви не задокументували поведінку об'єктів типу Task. Ви написали код, але жодних контрактів. Я додам контракт на Task.Close. Залежно від контракту, який я додаю, код для ProjectTask.Closeабо не відповідає LSP.

З огляду на наступний контракт на Task.Close, код для ProjectTask.Close не відповідає LSP:

     // Behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

З огляду на наступний контракт на Task.Close, код для ProjectTask.Close дійсно слідувати LSP:

     // Behaviour: Moves the task to the closed status if possible.
     // If this is not possible, this method throws an Exception
     // and leaves the status unchanged.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Методи, які можуть бути відмінені, повинні бути задокументовані двома способами:

• "Поведінка" документує те, на що може покладатися клієнт, який знає об'єкт одержувача, є Task, але не знає, для якого класу це прямий екземпляр. Він також повідомляє дизайнерам підкласів, які переосмислення є розумними, а які нерозумними.

• "Поведінка за замовчуванням" документує те, на що може покладатися клієнт, який знає, що об'єкт одержувач є прямим екземпляром Task(тобто, що ви отримуєте, якщо використовуєте new Task(). Він також повідомляє дизайнерам підкласів, яка поведінка буде успадкована, якщо вони не будуть перевизначити метод.

Тепер мають відбутися такі відносини:

• Якщо S є підтипом T, документоване поведінка S повинно уточнити задокументовану поведінку Т.
• Якщо S є підтипом (або рівним) T, поведінка коду S повинно уточнити задокументовану поведінку Т.
• Якщо S є підтипом (або рівним) T, поведінка S за замовчуванням S повинна уточнити задокументовану поведінку Т.
• Фактична поведінка коду для класу повинна уточнювати його задокументовану поведінку за замовчуванням.

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

Принцип заміщення Ліскова говорить:

Нехай д (х) є властивістю доказово про об'єкти х типу Т . Нехай S є підтипом T . Тип S порушує Принцип заміщення Ліскова, якщо існує об'єкт y типу S , такий, що q (y) є недоступним.

Причина, чому ваша реалізація підтипу не є порушенням принципу заміни Ліскова, досить проста: нічого не можна довести щодо того, що Task::Close()насправді робить. Звичайно, ProjectTask::Close()кидає виняток коли Status == Status.Started, але так може бути Status = Status.Closedв Task::Close().

Так, це порушення.

Я б запропонував вам мати свою ієрархію назад. Якщо не кожен Taskє закритим, то close()не належить Task. Можливо, вам потрібен інтерфейс, CloseableTaskякий всі не ProjectTasksможуть реалізувати.

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

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

Я пропускаю тут важливу річ, пов’язану з LSP та Design by Contract - за попередніми умовами, це той, хто телефонує, відповідальність за те, щоб переконатися, що передумови виконуються. Викликаний код в теорії DbC не повинен перевіряти передумову. У контракті повинно бути вказано, коли завдання може бути закрите (наприклад, CanClose повертає True), і тоді код виклику повинен забезпечити дотримання умови, перш ніж викликати Close ().

Так, це явне порушення ЛСП.

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

Ви можете спробувати шаблон декоратора, якщо хочете уникнути порушення LSP в цьому випадку. Це може спрацювати, я не знаю.