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

Deep dynamics

Ad un incontro con xp ug di Milano ho parlato per un'oretta di quanto mi ricordavo di "Deep Dynamics of agile teams".

Gli argomenti sono stati:

identità individuale

"mainstream flow, cambiamenti/turbolenze", metafora del fiume, e degli affluenti,
conversazioni difficili,
B.A.T.N.A.: best alternative to negotiation agreement,

intento e impatto di un messaggio

"yes, and..." vs. "yes, but...",

gestire la polarizzazione tra due tesi contrapposte, (*)
conflitto, soluzioni win win. (cooperazione rispetto a compromesso o resa/vittoria)

ribaltare una "accusa" ("tu sei X". "Se per X intendi .... allora si' d'accordo con te")
"temperatura" come stato: confort, un-confort, panic

learning culture vs blaming culture

mindset preconvenzionale, convenzionale, postconvenzionale.
social rank, legitimate rank, personal rank.

Mi è stato chiesto qualche riferimento bibliografico, e sono rimasto spiazzato.
Mi sono ricordato di “Project Retrospectives” di Norman Kerth, ma in realtà era faceva parte dei testi consigliati in un altro corso di Joseph, quello di Scrum. Forse alla fine una bibliografia non ci fu data. Si tratta in effetti di un mix di argomenti mutuati dalla psicologia applicati alle interazioni interne ad un team.

"Difficult Conversations"

Ho pensato a quali libri io avrei considerato vagamente correlati all'argomento, e mi sono venuti in mente:
"Calcoli Morali - Lazlo Mero "
"Nexus. Perché la natura, la società, l'economia, la comunicazione funzionano allo stesso modo - Buchanan Mark"
"Creatività e pensiero laterale -E. De Bono"


Avrei anche aggiunto, ma un po' più, alla lontana
"Verso un'ecologia della mente. G. Bateson"
"La società della mente - Marvin Minsky"