Stack extending LinkedList. Una violazione del principio di sostituzione di Liskov?

Question

Stack extending LinkedList. Una violazione del principio di sostituzione di Liskov?

#1 da (31 voti)
#2 da (1 voti)

13

Esiste una classe LinkedList con funzioni come add_first (), add_last (), add_after (), remove_first (), remove_last () e remove ()

Ora c'è una classe Stack che fornisce funzionalità come push (), pop (), peek () o top (), e per implementare questi metodi estende i metodi della classe LinkedList. Si tratta di una violazione del principio di sostituzione di Liskov?

Ad esempio, considera il caso add_after () per aggiungere un nodo all'ennesimo posto di un elenco collegato. Questo può essere fatto nella classe base ma non nella classe Stack. Le post-condizioni sono indebolite qui o modifichi il metodo add_after () per aggiungerlo all'inizio dello stack?

Inoltre, se non è una violazione, è questo cattivo design? E come implementeresti la funzionalità Stack usando la classe LinkedList?

object-oriented design object-oriented-design solid liskov-substitution

posta jxvmiranda 13.12.2017 - 13:17

fonte

2 risposte

Leggi altre domande sui tag object-oriented design object-oriented-design solid liskov-substitution

Come gestire le dipendenze "esterne" in scrum? Le licenze sono importanti se non c'è nessuno intorno a farle valere?

score 31 · Answer 1

Now there is a class Stack that provides functionalities such as push(), pop(), peek() or top(), and to implement these methods it extends the LinkedList class methods. Is this a violation of Liskov Substitution Principle?

No. Va perfettamente bene aggiungere metodi in un sottotipo.

For example, consider the case add_after() to add a node at the nth position of a Linked List. This can be done in the base class but not in the Stack class.

Questa è una violazione dell'LSP. L'LSP dice che le istanze di un sottotipo devono essere sostituibili per le istanze di un supertipo senza modificare le proprietà desiderabili di un programma. Se un sottotipo rimuove un metodo, qualsiasi codice che chiama quel metodo si bloccherà (o otterrà un'eccezione NoMethodError o qualcosa del genere). Chiaramente, "non bloccare" è una proprietà desiderabile.

Are postconditions being weakened here or do you modify the add_after() method to add to the top of the Stack?

La modifica del metodo add_after() in questo modo è una violazione della regola cronologia (la più importante delle regole!) e quindi non aiuta a correggere la violazione dell'LSP.

And how would you implement the Stack functionality using the LinkedList class?

Usando la composizione.

NOTA: tutto ciò che ho scritto sopra only si applica alle lingue che confondono sottotipizzazione e sottoclasse! L'LSP riguarda sottotipizzazione , non la sottoclasse. In un linguaggio che non confonde i due, sarebbe perfettamente accettabile rendere Stack una sottoclasse di LinkedList , purché non si faccia un sottotipo di LinkedList .

score 1 · Answer 2

Dato che Jörg W Mittag aveva già affrontato tutto, ho solo elaborato un po 'sulla seguente parte:

Are postconditions being weakened here or do you modify the add_after() method to add to the top of the Stack?

Fondamentalmente, quando c'è una domanda se una gerarchia viola l'LSP, dipende da quale contratto si pongono. Quindi, quale contratto ha add_after ? Se suona, per quanto pazzesco, come "Aggiungi un nodo nella posizione n-esima o nella parte superiore", che stai bene, la condizione post è soddisfatta, LSP non viene violato. Altrimenti si tratta di una violazione LSP.