brevi note sul principio Open Closed e quello di sostituibilità

Open closed: open to extensions, closed to modifications.
Se una parte di un sistema non necessita di modifiche, ma semplicemente di nuove aggiunte a fronte di possibili evoluzioni del sistema stesso, allora si sta rispettando il principio open closed.
In realtà non esiste un "open closed" per tutte le stagioni, ovvero valido per ogni possibile evoluzione. Ci sarà sempre qualche evoluzione che richieda un cambiamento.

Più pragmaticamente c'è il concetto di "chiusura strategica" che vorrebbe dire poter rispettare questo principio rispetto a quelle evoluzioni che più verosimilmente si verificheranno (o quelle che ci interessano di più).

Principio di sostituzione di Liskov:
se il comportamento di tutti (*) i programmi che usano una certa classe rimarrà invariato sostituendo a quella classe una sua sottoclasse, allora nel design classe->sottoclasse viene rispettato il principio di sostituzione di Liskov.
Quindi se una certa sottoclasse farà altre cose, oltre a quelle che fa la classe base, oppure farà le stesse cose della classe base ma in modo diverso, allora non occorrerà fare modifiche a tutti i metodi che usano la classe base affinche' si prevengano comportamenti "strani".

In questo senso il principio di sostituzione di Liskov può essere considerato un caso particolare del principio Open Closed, perché la classe base è "chiusa" rispetto a modifiche dovute alla creazione di sue sottoclassi.

In Eiffell la questione viene affrontata attraverso il design by contract.
Nel t.d.d. una tecnica semplice e' quella di applicare alle sottoclassi gli stessi test che vengono applicati alle classi base.

Entrambi questi principi direi che discendono dal più astratto principio del "least astonishment" "http://en.wikipedia.org/wiki/Principle_of_least_astonishment".

(*) nota. Non proprio tutti i programmi, altrimenti dall'esistenza di programmi che hanno un comportamento che dipende esplicitamente da un controllo di appartenenza di classe su un oggetto (if (myInstance.getClass()) { ... }, si dedurrebbe che l'insieme delle sottoclassi che rispettano il principio sarebbe vuoto.

Riferimento principale: http://butunclebob. com/ArticleS. UncleBob. PrinciplesOfOod