Ho letto che il principio di sostituzione di Liskov è violato se:
Le condizioni sono rafforzate o
Le postcondizioni sono indebolite
Ma non riesco ancora a capire in che modo questi due punti violerebbero il principio di sostituzione di Liskov. Qualcuno può spiegare con un esempio. In particolare, in che modo una qualsiasi delle condizioni sopra descritte può causare una situazione in cui un oggetto di sottoclasse non può essere sostituito da un oggetto superclasse?
Supponi che la tua baseclass funzioni con un membro int. Ora il tuo sottotipo richiede che int sia positivo. Questo è un pre-condizioni rafforzate, e ora qualsiasi codice che ha funzionato perfettamente bene prima con gli inti negativi è rotto.
Allo stesso modo, si assuma lo stesso scenario, ma la classe base utilizzata per garantire che il membro sia positivo dopo essere stato chiamato. Quindi il sottotipo cambia il comportamento per consentire valori negativi. Il codice che funziona sull'oggetto (e presuppone che la post-condizione sia positiva int) è ora interrotto poiché la post-condizione non viene confermata.
Questi sono ovviamente degli esempi banali, ma il concetto è valido. Stuff come lasciare una connessione file / database aperta è un esempio di una post-condizione facilitata che porta a problemi.
Invariante - Modello di SelfDrivingVehicle che rimane invariato in tutti i sottotipi, ad esempio Ordine in cui esegue i comportamenti sottoposti a override per raggiungere la destinazione.
Consente di assumere un altro metodo qui
-List<SelfDrivingVehicle> vehicles
+Add(SelfDrivingVehicle vehicle)
vehicles.add(vehicle)
Precondition - SelfDriveVehicle Il Tipo Base non ha veicoli in esso (qui il contesto è Aggiungi) e il suo in Precondition Indebolito che non può essere alterato da nessuno dei suoi sottotipi modificando i veicoli di proprietà e rafforzandolo esplicitamente. Qualsiasi sottotipo può solo richiamare Aggiungi.
Postcondition - Una volta aggiunto viene chiamato il tipo base in Postcondition rafforzato che non può essere indebolito dai sottotipi modificando il valore dei veicoli.
Lo stato del tipo di base ritorna al suo stato originale una volta che viene richiamato il comportamento di aggiunta.
Questo esempio è praticamente battuto fino alla morte, ma considera la possibilità di Square / Rectangle o Circle / Ellipse. Supponiamo di avere un rettangolo di classe base che definisce un oggetto con lunghezza e larghezza. Se hai una classe Square che eredita la classe Rectangle, dovrebbe avere una regola nel suo setter / getter che richiederebbe che qualsiasi modifica alla lunghezza o alla larghezza alterasse la sua controparte. Questi requisiti dimensionali rafforzano le pre-condizioni perché a un rettangolo sostituito da un quadrato mancano questi requisiti dimensionali. Supponendo di invertire l'ereditarietà in modo che un rettangolo erediti un quadrato, si indebolirebbero le condizioni del post attenuando i requisiti dimensionali per consentire al rettangolo di comportarsi in modo indipendente.
Tuttavia, se dovessi rimuovere la capacità di modifica dimensionale, il principio di sostituzione vale perché se né un Rettangolo né un Quadrato possono cambiare le dimensioni, allora hanno condizioni pre e post uguali indipendentemente dall'ereditarietà. Entrambi hanno una lunghezza, entrambi hanno una larghezza e nessuno dei due può modificare quei valori.
ref: Wikipedia - http://en.wikipedia.org/wiki/Liskov_substitution_principle
Leggi altre domande sui tag object-oriented inheritance abstraction liskov-substitution