Это нарушение принципа подстановки Лискова?

Скажем, у нас есть список сущностей задач и 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статус «Запущено», а если нет, то если это была базовая Задача. Но это бизнес-требования. Это должно потерпеть неудачу. Можно ли считать это нарушением принципа подстановки Лискова ?

Да, это нарушение LSP. Принцип замещения Лискова требует, чтобы

• Предпосылки не могут быть усилены в подтипе.
• Постусловия не могут быть ослаблены в подтипе.
• Инварианты супертипа должны быть сохранены в подтипе.
• Ограничение истории («правило истории»). Объекты считаются изменяемыми только через их методы (инкапсуляция). Поскольку подтипы могут вводить методы, которых нет в супертипе, введение этих методов может разрешить изменения состояния в подтипе, которые не допускаются в супертипе. Ограничение истории запрещает это.

Ваш пример нарушает первое требование, усиливая предварительное условие для вызова 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исключение возникает только при закрытии, программа должна быть заменена на acommodate для этого, должна ProjectTaskиспользоваться вместо Task. Так что это нарушение.

Но если вы измените, Taskуказав в своей подписи, что оно может вызвать исключение при закрытии, вы не нарушите этот принцип.

Нарушение LSP требует трех сторон. Тип T, Подтип S и программа P, которая использует T, но получает экземпляр S.

Ваш вопрос предоставил T (Task) и 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 должно уточнить документированное поведение T.
• Если S является подтипом (или равен) T, поведение кода S должно уточнять документированное поведение T.
• Если S является подтипом (или равен) T, поведение S по умолчанию должно уточнить документированное поведение T.
• Фактическое поведение кода для класса должно улучшить его документированное поведение по умолчанию.

Это не нарушение принципа подстановки Лискова.

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

Пусть д (х) является свойством доказуемо об объектах х типа Т . Пусть 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, кажется, что он использует исключения для управления потоком программы (я должен предположить, что вы где-то ловите это тривиальное исключение и делаете некоторый пользовательский поток, а не позволяете ему аварийно завершить работу приложения).

Похоже, что это хорошее место для реализации шаблона State для TaskState и позволяющего объектам состояния управлять допустимыми переходами.

Здесь я упускаю важную вещь, связанную с LSP и проектированием по контракту - в предварительных условиях именно вызывающий абонент должен убедиться, что предварительные условия выполнены. В теории DbC вызываемый код не должен проверять предварительное условие. В контракте должно быть указано, когда задача может быть закрыта (например, CanClose возвращает True), а затем вызывающий код должен убедиться, что предварительное условие выполнено, прежде чем вызывать метод Close ().

Да, это явное нарушение LSP.

Некоторые люди утверждают, что в базовом классе указание на то, что подклассы могут генерировать исключения, сделало бы это приемлемым, но я не думаю, что это правда. Независимо от того, что вы документируете в базовом классе или на какой уровень абстракции вы перемещаете код, предварительные условия все равно будут усилены в подклассе, поскольку вы добавляете в него часть «Не удается закрыть запущенную задачу проекта». Это не то, что вы можете решить с помощью обходного пути, вам нужна другая модель, которая не нарушает LSP (или нам нужно ослабить ограничение «предварительные условия не могут быть усилены»).

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