È una violazione del principio di sostituzione di Liskov?

Supponiamo di avere un elenco di entità Task e un ProjectTasksottotipo. Le attività possono essere chiuse in qualsiasi momento, tranne ProjectTasksche non possono essere chiuse una volta che hanno lo stato Avviato. L'interfaccia utente dovrebbe garantire che l'opzione per chiudere un avvio ProjectTasknon sia mai disponibile, ma nel dominio sono presenti alcune garanzie:

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

Ora quando si chiama Close()un'attività, è possibile che la chiamata fallisca se è ProjectTaskcon lo stato avviato, quando non sarebbe se fosse un'attività base. Ma questi sono i requisiti aziendali. Dovrebbe fallire. Questo può essere considerato una violazione del principio di sostituzione di Liskov ?

Sì, è una violazione dell'LSP. Liskov principio di sostituzione richiede che

• Le condizioni preliminari non possono essere rafforzate in un sottotipo.
• Le postcondizioni non possono essere indebolite in un sottotipo.
• Gli invarianti del supertipo devono essere conservati in un sottotipo.
• Vincolo storico (la "regola della storia"). Gli oggetti sono considerati modificabili solo attraverso i loro metodi (incapsulamento). Poiché i sottotipi possono introdurre metodi che non sono presenti nel supertipo, l'introduzione di questi metodi può consentire cambiamenti di stato nel sottotipo che non sono ammessi nel supertipo. Il vincolo storico lo proibisce.

Il tuo esempio rompe il primo requisito rafforzando una precondizione per chiamare il Close()metodo.

Puoi risolverlo portando la pre-condizione rafforzata al livello più alto della gerarchia ereditaria:

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

Stabilendo che una chiamata di Close()è valida solo nello stato in cui i CanClose()ritorni truesi applicano le condizioni preliminari al Task, nonché al ProjectTask, fissando la violazione 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();
    }
}

Sì. Questo viola LSP.

Il mio suggerimento è di aggiungere CanClosemetodo / proprietà all'attività di base, in modo che qualsiasi attività possa dire se l'attività in questo stato può essere chiusa. Può anche fornire un motivo per cui. E rimuovi il virtuale da Close.

Sulla base del mio commento:

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

Il principio di sostituzione di Liskov afferma che una classe base dovrebbe essere sostituibile con una qualsiasi delle sue sottoclassi senza alterare nessuna delle proprietà desiderabili del programma. Dal momento che ProjectTasksolleva un'eccezione solo quando chiuso, un programma dovrebbe essere modificato per adattarsi a tale, dovrebbe ProjectTaskessere utilizzato in sostituzione di Task. Quindi è una violazione.

Ma se modifichi Taskdichiarando che potrebbe sollevare un'eccezione quando chiuso, non violeresti il ​​principio.

Una violazione di LSP richiede tre parti. Il tipo T, il sottotipo S e il programma P che utilizza T ma riceve un'istanza di S.

La tua domanda ha fornito T (Task) e S (ProjectTask), ma non P. Quindi la tua domanda è incompleta e la risposta è qualificata: se esiste una P che non si aspetta un'eccezione, per quella P hai un LSP violazione. Se ogni P prevede un'eccezione, non vi è alcuna violazione LSP.

Tuttavia, è fare un SRP violazione. Il fatto che lo stato di un'attività possa essere modificato e la politica secondo cui determinati compiti in determinati stati non dovrebbero essere cambiati in altri stati, sono due responsabilità molto diverse.

• Responsabilità 1: rappresentare un'attività.
• Responsabilità 2: implementare le politiche che cambiano lo stato delle attività.

Queste due responsabilità cambiano per ragioni diverse e quindi dovrebbero essere in classi separate. Le attività dovrebbero gestire il fatto di essere un'attività e i dati associati a un'attività. TaskStatePolicy dovrebbe gestire il modo in cui le attività passano da uno stato all'altro in una determinata applicazione.

Ciò può o meno costituire una violazione dell'LSP.

Sul serio. Ascoltami.

Se segui l'LSP, gli oggetti di tipo ProjectTaskdevono comportarsi come dovrebbero comportarsi gli oggetti di tipo Task.

Il problema con il tuo codice è che non hai documentato come Taskdovrebbero comportarsi gli oggetti di tipo . Hai un codice scritto, ma nessun contratto. Aggiungerò un contratto per Task.Close. A seconda del contratto che aggiungo, il codice per ProjectTask.Closeo non segue o meno l'LSP.

Dato il seguente contratto per Task.Close, il codice per ProjectTask.Close non segue l'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;
     }

Dato il seguente contratto per Task.Close, il codice per ProjectTask.Close non seguire la 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;
     }

I metodi che possono essere sovrascritti devono essere documentati in due modi:

• Il "Comportamento" documenta ciò su cui può fare affidamento un client che conosce l'oggetto destinatario a Task, ma non sa di quale classe è un'istanza diretta. Indica anche ai progettisti di sottoclassi quali sostituzioni sono ragionevoli e quali non sono ragionevoli.

• Il "Comportamento predefinito" documenta ciò su cui può fare affidamento un client che sa che l'oggetto destinatario è un'istanza diretta di Task(ovvero ciò che si ottiene se si utilizza new Task(). Indica inoltre ai progettisti di sottoclassi quale comportamento verrà ereditato se non lo fanno sovrascrivere il metodo.

Ora dovrebbero tenere le seguenti relazioni:

• Se S è un sottotipo di T, il comportamento documentato di S dovrebbe perfezionare il comportamento documentato di T.
• Se S è un sottotipo di (o uguale a) T, il comportamento del codice S dovrebbe perfezionare il comportamento documentato di T.
• Se S è un sottotipo di (o uguale a) T, il comportamento predefinito di S dovrebbe perfezionare il comportamento documentato di T.
• Il comportamento effettivo del codice per una classe dovrebbe perfezionare il comportamento predefinito documentato.

Non è una violazione del principio di sostituzione di Liskov.

Il principio di sostituzione di Liskov afferma:

Let q (x) sia una proprietà dimostrabile sugli oggetti x di tipo T . Diamo S essere un sottotipo di T . Il tipo S viola il principio di sostituzione di Liskov se esiste un oggetto y di tipo S , tale che q (y) non è provabile.

Il motivo, per cui l'implementazione del sottotipo non costituisce una violazione del Principio di sostituzione di Liskov, è piuttosto semplice: nulla può essere dimostrato su ciò che Task::Close()effettivamente fa. Certo, ProjectTask::Close()genera un'eccezione quando Status == Status.Started, ma così potrebbe Status = Status.Closedin Task::Close().

Sì, è una violazione.

Suggerirei di avere la tua gerarchia al contrario. Se non tutto Taskè richiudibile, allora close()non appartiene Task. Forse vuoi un'interfaccia CloseableTaskche tutti i non- ProjectTaskspossono implementare.

Oltre ad essere un problema LSP, sembra che stia usando le eccezioni per controllare il flusso del programma (devo presumere che tu catturi questa banale eccezione da qualche parte e fai un flusso personalizzato piuttosto che lasciarlo andare in crash la tua app).

Sembra che questo sia un buon posto per implementare il modello di stato per TaskState e lasciare che gli oggetti di stato gestiscano le transizioni valide.

Mi manca qui una cosa importante relativa a LSP e Design by Contract - in precondizioni, è il chiamante la cui responsabilità è assicurarsi che le condizioni siano soddisfatte. Il codice chiamato, nella teoria DbC, non dovrebbe verificare il presupposto. Il contratto deve specificare quando un'attività può essere chiusa (ad es. CanClose restituisce True) e quindi il codice chiamante deve garantire il rispetto delle condizioni preliminari, prima di chiamare Close ().

Sì, è una chiara violazione di LSP.

Alcune persone sostengono che rendere esplicito nella classe base che le sottoclassi possano generare eccezioni lo renderebbe accettabile, ma non credo sia vero. Indipendentemente da ciò che documenti nella classe di base o in quale livello di astrazione sposti il ​​codice, le condizioni preliminari verranno comunque rafforzate nella sottoclasse, perché si aggiunge la parte "Impossibile chiudere un'attività di progetto avviata". Questo non è qualcosa che puoi risolvere con una soluzione alternativa, hai bisogno di un modello diverso, che non viola LSP (o dobbiamo allentare il vincolo "le condizioni preliminari non possono essere rafforzate").

Puoi provare il motivo del decoratore se vuoi evitare la violazione LSP in questo caso. Potrebbe funzionare, non lo so.