settembre 2010 Blog Posts
Supponete di avere due oggetti uno di tipo A e l'altro di tipo B, dove A chiama un metodo di B e viceversa.
In pratica esiste una dipendenza circolare tra i due oggetti (il discorso si puo' ampliare facilmente ad n oggetti).
Proviamo a visualizzare tale interazione con un communication diagram (ne avevo già parlato in questo
post).
Come vedete dal disegno il refactoring risulta molto semplice da capire. In pratica creiamo un nuovo oggetto di tipo C che chiama
gli oggetti di tipo A e tipo B ed in questo modo abbiamo tolto la referenza circolare.
Non so se esiste già da qualche parte...
Ieri sera ho partecipato alla cena DDD organizzata in Managed Designs, è stata
una piacevole serata in cui abbiamo fatto quattro chiacchiere sulla nostra amata professione.
Si sono toccati molti argomenti non solo il DDD.
C'è un punto emerso tagliando una gustosa cotoletta che mi piacerebbe approfondire qui: l'incertezza intrinseca del nostro mestiere.
Fare previsioni affidabili è una necessità, prima di tutto economica, perchè i budget si devono organizzare prima
e perchè il progetto sia redditizio per chi lo sviluppa.
Una cosa che ci viene naturale come essere umani è quella di cercare di incanalare il progetto in un binario già noto
da cui il...
Ogni tanto, nello sviluppo software, emerge qualche meme come ad esempio: tutte le dipendenze devono essere
disaccoppiate tramite un interface, tutte gli oggetti devono essere creati tramite factory, l'accesso ad un database
deve avvenire tramite un ORM, il TDD genera un buon design ecc.
Cosa hanno in comune tutte le frasi precedenti? Semplice: creano scorciatoie per evitare di pensare.
Sarebbe bello se potessimo scrivere codice seguendo alla lettera un manuale, ma sarebbe anche terribilmente noioso
e probabilmente verremmo sostituiti da qualche tipo di bot.
Prendiamo la prima affermazione: tutte le dipendenze devono essere disaccoppiate tramite un interface
e cerchiamo di capire da dove nasce questa esigenza. Il...