Law Of Demeter

Di recente ho seguito un thread intitolato “The Law of Demeter and Testability” sulla lista xp americana.

A partire dal primo post di Jay Flowers (niente di travolgente), il discorso si e’ poi spostato sulla legge di demeter di per se’, il cui ‘peso’ personalmente non ho mai capito fino in fondo. Ne’ tantomeno mi sembra che se ne parli molto, al contrario magari di altri principi piu’ noti come OCP, DIP, LSP, SRP, eccetera.

Alcuni messaggi di questo thread mi hanno fatto capire meglio questo ‘principio’ (chiamarla legge fa un po’ ridere) e a vederlo in un’ottica diversa.

Vi sottopongo gli spunti piu’ interessanti, sperando possano esservi di stimolo quanto lo sono stati per me

Michael Feathers:

It’s a great article, but the thing to remember about LoD is that it is not iron-clad. There are cases where you’re better off not having demetered code. The classic example is the Excel Object model. You get the workbook from the application and the worksheet from the workbook, and drill down through ranges to cells. It works because the model is very stable.

In general, when the structure of data has meaning, LoD gets in the way; when you care more about behavior (and usually you can), LoD is the way to go.

Ron Jeffries:

Yes … the observation about structure is a good one. If you think of what you’d have to do, otherwise, with the Excel model, you’d have to make each call to Excel, parameterized with workbook name, worksheet name, maybe range, then cell. Pulling the innards out amounts to an addressing prefix, or stepping down through a hierarchy.

Mostly, though, I’d say LoD is the way to bet.

E infine Brad Appleton:

I actually took a class from Dr. Lieberherr on the full Demeter method (of which LoD is one small part). Having had the benefit of that, I think I have a lot of additional insight into the above.

The issue with the LoD is that, the way it is usually stated, the assumption is any/every class in an O-O program should be exhibiting functional behavior and hiding the details of what it contains, and how it contain them.

There are classes whose job is to encapsulate functional behavior/services, and there are classes whose job is to encapsulate structural behavior/services. That is to say that for some classes, the “secret” they need to “hide” isnt the fact that they contain some kinds of objects, but the details of HOW they contain those objects.
Simple examples of these would be data-structures, lists, collections, iterators, dictionaries, data-stores, etc. Accessing the interfaces of the objects contained by such encapsulated structures actually doesnt violate the principle behind the LoD. But because of the way LoD is stated in such an oversimplified manner, those things appear to be violations when they really arent.

When a method-call returns a subobject of its containing object, then consider that invocation to be a violation of LOD *only* *if* the containing object is supposed to encapsulate behavior concerning its subobjects. If the object really only needs to encapsulate structural details about HOW it contains that object (rather than WHAT it contains), then it’s not really a violation of LoD.

So it’s less about whather or not the caller cares about the behavior or structure of the data, it more about whather the callee cares about (should be encapsulating) the behavior or the structure of what it contains.

Il mio feedback sull’Agile Day 2006 – Milano 01.12.06

Venerdi’ primo dicembre ho partecipato al secondo Agile Day, organizzato a Milano al Centro congressi MilanoFiori.

Innanzitutto devo ringraziare Marco Abis e tutti coloro che hanno contribuito (anche economicamente) alla sua realizzazione.

Di seguito qualche mia considerazione sulla giornata:

Interessante la presentazione del gruppo corse Ferrari (Nicola Canalini e Luca), anche se meno d’impatto di quella dell’anno scorso.
Di quello che hanno detto mi hanno colpito alcune cose:

  • la grande attenzione che pongono nello standup meeting, dove mi sembra di capire che ognuno dice qualcosa. Addirittura ognuno se lo prepara il giorno prima (che e’ piu’ o meno quello che facciamo nel nostro team quando compiliamo il journal sul wiki a fine giornata). Ognuno arriva allo standup con una carta con i propri feedback, che ruotano attorno a poche domande:
    1. cosa ha fatto ieri
    2. cosa fara’ oggi
    3. di cosa ha bisogno
    4. problemi incontrati
    5. comunicazioni generali
  • un forte accenno alla leggibilita’ del codice (e noi come siamo messi a riguardo, eh?)
  • per gestire l’alto numero di progetti (circa 100!) e la loro complessita’, stabiliscono degli standard a cui tutti si attengono, tipo: c’e’ un solo modo di accedere alle basi dati, e chi deve accedere ad una base dati deve seguirlo. In tal modo diventa piu’ facile e veloce ‘entrare’ in un progetto o capire cosa non va.
  • uno sforzo per il miglioramento continuo e per l’auto-organizzazione
  • una delle metriche che adottano e monitorano costantemente e’ il numero di test scritti nell’arco di tempo (ogni giorno, ad ogni iterazione), sia come team che a livello ‘individuale’. Il delta dei test scritti dal team viene pubblicato quotidianamente su un monitor visibile a tutti.

La presentazione di Davide e Giuliano ha avuto luci ed ombre: bella e frizzante la presentazione con le slide, un po’ debole il video, sia per problemi tecnici (non si vedeva/sentiva bene), sia perche’ forse piu’ che una sessione di pair remoto dava l’impressione di essere una sessione di TDD.

Non sempre ho trovato interessanti alcuni temi delle track (mi e’ capitato di non essere interessato a nessuna track che si stava svolgendo in quel momento).

Il pubblico era vasto ma generalmente non sembrava da molto addentro all’xp e al mondo agile, per cui spesso le track tecniche per forza di cose si ‘appiattivano’ sul livello dei meno esperti. Per carita’, questo va benissimo, diffondere l’xp e i principi agili e’ una cosa molto importante e positiva, ma penso che il formato dell’open-space poco si presti a questa cosa, mentre e’ piu’ adatto a favorire lo scambio di esperienze tra persone piu’ o meno addentro agli argomenti trattati (io me lo immagino come un BOF).

Come alcuni hanno detto lo stanzone dove si teneva la riunione e la sua acustica hanno disturbato non poco lo svolgimento delle track: solo le persone nelle immediate vicinanze della persona che parlava lo riuscivano a sentire, le altre no.
Avrei poi preferito che le track fossero organizzate in modo che sembrassero meno delle presentazioni da uno a molti e piu’ una discussione tra tutti: magari mettersi tutti attorno ad un tavolo avrebbe semplificato, magari no. Non so.

Io ho ‘tenuto’ due track: una sui test (“Scrivere Test che incoraggiano il cambiamento”) con Enrico Mangano e una sui Mock Objects. In tutti e due i casi siamo andati a volte fuori tema, soprattutto con la prima sui test. Sui mock objects sono soddisfatto a meta’: alcune persone erano interessate, ma una buona meta’ non sapeva cosa fossero i mock o comunque non li avava mai utilizzati. Avrei preferito tornare a casa con qualcosa di nuovo sui mock e sul loro uso, ma niente da fare. Pazienza

In generale sono tornato a casa con pochi veri spunti di riflessione, giusto quelli che ho detto di ferrari e Cirillo sul ROI, qualcosa sulle metriche e basta.

PS: Gabriele Lana ha fatto qualche foto della giornata…