Czy jest to naruszenie zasady substytucji Liskowa?

Powiedzmy, że mamy listę encji Zadania i ProjectTaskpodtyp. Zadania można zamknąć w dowolnym momencie, z wyjątkiem tych, ProjectTasksktórych nie można zamknąć, gdy mają status Uruchomione. Interfejs użytkownika powinien upewnić się, że opcja zamknięcia uruchomionego ProjectTasknigdy nie jest dostępna, ale w domenie istnieją pewne zabezpieczenia:

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();
     }
}

Teraz podczas wywoływania Close()Zadania istnieje szansa, że ​​połączenie zakończy się niepowodzeniem, jeśli ma ProjectTaskstatus Rozpoczęty, a nie będzie, jeśli będzie to zadanie podstawowe. Ale to są wymagania biznesowe. To powinno zawieść. Czy można to uznać za naruszenie zasady substytucji Liskowa ?

Tak, jest to naruszenie LSP. Wymaga tego zasada Liskowa

• W podtypie nie można wzmocnić warunków wstępnych.
• Warunki podrzędne nie mogą zostać osłabione w podtypie.
• Niezmienniki nadtypu muszą być zachowane w podtypie.
• Ograniczenie historii („reguła historii”). Obiekty są uważane za modyfikowalne tylko za pomocą ich metod (enkapsulacji). Ponieważ podtypy mogą wprowadzać metody, które nie są obecne w nadtypie, wprowadzenie tych metod może pozwolić na zmiany stanu podtypu, które nie są dopuszczalne w nadtypie. Ograniczenia historyczne tego zabraniają.

Twój przykład łamie pierwszy wymóg, wzmacniając warunek wstępny wywołania Close()metody.

Możesz to naprawić, przenosząc wzmocniony warunek wstępny na najwyższy poziom hierarchii dziedziczenia:

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

Zastrzegając, że wywołanie Close()jest ważne tylko w stanie, gdy CanClose()zwroty true, warunek wstępny stosuje się zarówno do, Taskjak i do ProjectTask, naprawiając naruszenie 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();
    }
}

Tak. Narusza to LSP.

Moją sugestią jest dodanie CanClosemetody / właściwości do zadania podstawowego, aby każde zadanie mogło stwierdzić, czy zadanie w tym stanie można zamknąć. Może również podać powód. I usuń wirtualny z Close.

Na podstawie mojego komentarza:

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);
    }
}

Zasada podstawienia Liskowa stanowi, że klasa podstawowa powinna być wymienna na dowolną z jego podklas bez zmiany jakichkolwiek pożądanych właściwości programu. Ponieważ tylko ProjectTaskpodnosi wyjątek po zamknięciu, program musiałby zostać zmieniony, aby pomieścił to, należy ProjectTaskgo zastąpić Task. To jest naruszenie.

Ale jeśli zmodyfikujesz Taskstwierdzając w swoim podpisie, że może powodować wyjątek po zamknięciu, nie naruszysz zasady.

Naruszenie LSP wymaga trzech stron. Typ T, podtyp S i program P, który używa T, ale otrzymuje instancję S.

Twoje pytanie zawiera T (Zadanie) i S (ProjectTask), ale nie P. Więc twoje pytanie jest niekompletne, a odpowiedź jest kwalifikowana: Jeśli istnieje P, które nie oczekuje wyjątku, to dla tego P masz LSP naruszenie. Jeśli każde P oczekuje wyjątku, oznacza to, że nie ma naruszenia LSP.

Jednak zrobić mają SRP naruszenie. Fakt, że stan zadania można zmienić, oraz polityka , zgodnie z którą niektóre zadania w niektórych stanach nie powinny być zmieniane na inne, to dwie bardzo różne obowiązki.

• Odpowiedzialność 1: Reprezentuj zadanie.
• Odpowiedzialność 2: Wdrożenie zasad zmieniających stan zadań.

Te dwie obowiązki zmieniają się z różnych powodów i dlatego należy je rozdzielić. Zadania powinny obsłużyć fakt bycia zadaniem oraz dane powiązane z zadaniem. TaskStatePolicy powinien obsłużyć sposób przejścia zadań ze stanu do stanu w danej aplikacji.

Może to, ale nie musi, stanowić naruszenie LSP.

Poważnie. Wysłuchaj mnie.

Jeśli podążasz za LSP, obiekty typu ProjectTaskmuszą zachowywać się tak, jak Taskoczekuje się od obiektów typu .

Problem z twoim kodem polega na tym, że nie udokumentowałeś, jak Taskpowinny zachowywać się obiekty typu . Napisałeś kod, ale żadnych umów. Dodam umowę na Task.Close. W zależności od dodanej przeze mnie umowy kod dla ProjectTask.CloseLSP jest zgodny z LSP lub nie.

Biorąc pod uwagę następującą umowę dla Task.Close, kod dla ProjectTask.Close nie jest zgodny z 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;
     }

Biorąc pod uwagę następującą umowę dla Task.Close, kod dla ProjectTask.Close jest zgodny z 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;
     }

Metody, które można zastąpić, należy udokumentować na dwa sposoby:

• „Zachowanie” dokumentuje to, na czym może polegać klient, który wie, że obiekt adresata jest Task, ale nie wie, do której klasy jest bezpośrednią instancją. Informuje także projektantów podklas, które przesłonięcia są uzasadnione, a które nie.

• „Zachowanie domyślne” dokumentuje to, na czym może polegać klient, który wie, że obiekt adresata jest bezpośrednim wystąpieniem Task(tj. Co otrzymujesz, jeśli go użyjesz new Task(). Mówi także projektantom podklas, jakie zachowanie zostanie odziedziczone, jeśli tego nie zrobi przesłonić metodę.

Teraz powinny obowiązywać następujące relacje:

• Jeśli S jest podtypem T, udokumentowane zachowanie S powinno udoskonalić udokumentowane zachowanie T.
• Jeśli S jest podtypem (lub równym) T, zachowanie kodu S powinno udoskonalić udokumentowane zachowanie T.
• Jeśli S jest podtypem (lub równym) T, domyślne zachowanie S powinno udoskonalić udokumentowane zachowanie T.
• Rzeczywiste zachowanie kodu dla klasy powinno udoskonalić jego udokumentowane zachowanie domyślne.

Nie stanowi to naruszenia zasady substytucji Liskowa.

Zasada substytucji Liskowa mówi:

Niech q (x) być właściwością dowodliwe o obiektach x typu T . Niech S jest podtypem T . Typ S narusza zasadę podstawienia Liskowa, jeśli istnieje obiekt y typu S , tak że q (y) nie da się udowodnić.

Powód, dla którego wdrożenie tego podtypu nie jest naruszeniem zasady substytucji Liskowa, jest dość prosty: nic nie można udowodnić na temat tego, co Task::Close()faktycznie robi. Jasne, ProjectTask::Close()zgłasza wyjątek podczas Status == Status.Started, ale tak może Status = Status.Closedsię Task::Close().

Tak, to naruszenie.

Sugerowałbym, abyś miał swoją hierarchię do tyłu. Jeśli nie każdy Taskmożna zamknąć, to close()nie należy do Task. Być może potrzebujesz interfejsu, CloseableTaskktórego wszyscy nie ProjectTasksmogą wdrożyć.

Oprócz tego, że jest to problem LSP, wygląda na to, że używa wyjątków do kontrolowania przepływu programu (muszę założyć, że złapiesz gdzieś ten trywialny wyjątek i wykonasz jakiś niestandardowy przepływ, zamiast pozwolić, aby zawiesił twoją aplikację).

Wydaje się, że jest to dobre miejsce do wdrożenia wzorca stanu dla TaskState i umożliwienia obiektom stanu zarządzania prawidłowymi przejściami.

Brakuje mi tutaj ważnej rzeczy związanej z LSP i projektowaniem na podstawie umowy - w warunkach wstępnych to osoba dzwoniąca jest odpowiedzialna za upewnienie się, że warunki wstępne są spełnione. Kod wywoływany w teorii DbC nie powinien weryfikować warunku wstępnego. Umowa powinna określać, kiedy zadanie może zostać zamknięte (np. CanClose zwraca wartość True), a następnie kod wywołujący powinien zapewnić spełnienie warunku wstępnego przed wywołaniem funkcji Close ().

Tak, jest to wyraźne naruszenie LSP.

Niektórzy twierdzą tutaj, że wyraźne w klasie podstawowej, że podklasy mogą zgłaszać wyjątki, uczyniłoby to akceptowalnym, ale nie sądzę, że to prawda. Bez względu na to, co dokumentujesz w klasie podstawowej lub na jaki poziom abstrakcji przenosisz kod, warunki wstępne będą nadal wzmocnione w podklasie, ponieważ dodasz do niej część „Nie można zamknąć rozpoczętego zadania projektowego”. Nie jest to coś, co można rozwiązać za pomocą obejścia, potrzebujesz innego modelu, który nie narusza LSP (lub musimy poluzować ograniczenie „warunków wstępnych nie można wzmocnić”).

Możesz wypróbować wzór dekoratora, jeśli chcesz uniknąć naruszenia LSP w tym przypadku. To może zadziałać, nie wiem.