Oggi, chiacchierando con Mauro durante una riunione di stato avanzamento lavori in bottega, ci siamo soffermati su un suo post sul forum UGIdotNET, in risposta a Raf. Il thread è interessante (nonchè breve :-) ) e merita una lettura; per i più pigri, ecco lo stralcio oggetto della nostra chiacchierata:
Ciao Raffaele,
You wrote :
>>> Buonasera architetti e "metodologisti" (?),
>>
>> non sono ne uno ne l'altro ;-)...
>
> Muratore come me? :-D
Decisamente muratore in prima analisi e artigiano poi... :-D,
preferisco di gran lunga l'approccio "scrivo il codice grezzo e risolvo
il problema contingente alla bene e meglio" così capisco il nodo della
questione, poi comincio a studiarlo e ad analizzarlo per astrarre un
po' di concetti e vado di refactoring, la cosa che faccio moltissimo è
guardarmi in giro per cercare problemi simili e studiare come sono
stati risolti, poi alla fine scopro che ho anche applicatio qualche
pattern, bene mi dico... ;-)
Alla fine ottengo un risultato componentizzato, che rispecchia i
dettami della OOP e che architetturalmente è anche soddisfaciente, ma
la cosa migliore è che ho capito a fondo il prblema e lo padroneggio
In sintesi, Mauro non utilizza i pattern come guida, ma "scopre" di essere incappato in uno di loro strada facendo. Eccoci al punto: per quanto possa capitare di "scegliere" l'adozione di un pattern in modo "up front" (tipicamente architetturale: è il caso, per esempio, di SOA), è decisamente più ricorrente (nonchè auspicabile) che tale scelta avvenga in itinere, come risultato di un refactoring. Ecco quindi che, durante una normale sessione di coding, scatta il "killer istinct": lo sviluppatore/architetto (stiamo praticamente usando due sinonimi, ormai dovremmo saperlo) comprende di essere al cospetto di codice non ottimale (ergo, "sente" i code smell), rifattorizza e, se possibile, "accelera" tendendo ad una soluzione nota come funzionante (refactoring to patterns). In questo modo, Mauro ottiene:
- Un codice maggiormente intelleggibile
- Una risultato: *funzionante*, elegante e più facilmente gestibile
Trattasi di "elucubrazione visionaria" del Saltarello? Non credo: lo stesso Gamma in una vecchia intervista, afferma:
Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?
Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.
Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.
Fine dello sproloquio; torno alla mia sessione di coding: devo rifattorizzare la mia codebase per tendere a Visitor, altrimenti non si va a nanna <g>
Technorati Tags: design pattern, refactoring, refactoring to patterns, software architecture
posted @ martedì 22 gennaio 2008 1.14