Ieri sera nel tornare a casa ho iniziato a ricordare quanto è cambiato il mio modo di modellare gli oggetti nel corso degli anni... credo di dire che la vera rivoluzione è legata al fatto che maturando ho iniziato a dare più importanza al caso d'uso e alla facile estendibilità/utilizzo invece di puntare al modello astratto perfetto.
I primi di esperimenti di OOP e in particolare i primi esperimenti di modellazione di oggetti per descrivere i dati e/o il dominio applicativo tendevano a disegnare/definire oggetti che fossero quanto più simile alla vita reale invece che all'uso che se doveva fare nel contesto applicativo. Il mio pensiero era: prima descrivo la realtà e poi la adatto ai miei casi. Ma questo richiede troppo effort. Rischiavo di cercare la complicazione la dove la questione poteva essere davvero più semplice. E' da questa esperienza/considerazione che poi mi sono trovato la metafora della pallina che rimbalza. "La pallina che rimbalza la posso descrivere mettendo in gioco forza di gravità e il peso, posso se voglio introdurre gli attriti oppure posso introdurre atomi e meccanica atomica". Sono tutti modelli corretti ma sono modi diversi di vedere la stessa cosa; occorre scegliere quello meglio e con meno effort ci aiuata ad arrivare al nostro scopo. Mi ripeto la metafora ogni volta che mi sembra che si stia complicando il disegno... chiedendomi "si ma è davvero necessario/richiesto quanto sto facendo?"
Altra pretesa che avevo era quella di implementare/disegnare una sorta perfetta SDK che chiunque non avrebbe potuto/dovuto sbagliare ad usare gli oggetti... riducendo gli errori di utilizzo e pensando in questo modo di aiutare il consumer. Era per questo mia cura creare regole ferree; regole che complicavano l'utilizzo anche a me - che le avevo fatte - e che richiedevano sempre più "eccezioni di utilizzo" e quindi comportavano refactoring continui (troppo continui)... e quindi aumento dell'effort. Mi però sono reso conto che lo sforzo che facevo non era necessario perchè... non è proponibile cercare morbosamente e con malizia tutte le possibile combinazione per cui una combinazione di oggetti sbombi. Quando si approccia all'uso di una libreria è cura del programmatore chiederne le specifiche di utilizzo e comunque credo se un oggetto è usato male deve risultate nella fase di testing e per fortuna oggi ci sono programmi per lo unit-test e il code-coverage che aiutano/facilitano questo.
Beh sbagliano si impara e nel mio percorso di crescita OOP ho imparato a focalizzare l'attenzione su problemi più concreti (i casi d'uso) invece di perdermi in idee di modelli tanto belli quanto limitanti e stringenti.
posted @ venerdì 7 aprile 2006 13:34