Da quando ci sono stati gli ultimi fantastici CD, non mi sono ancora fermato a studiare: IoC, NSK, Castle Project, Enterprise Library e metto insieme i pezzi, osservando il mio famoso progetto che, il 16 Luglio (in contemporanea con il suo primo compleanno) è stato anche oggetto di una mia piccola (dalle 9:30 alle 15) presentazione...
Oggi mi è venuta una riflessione a galla e volevo condividerla.
Prendendo spunto dal bell'esempio di Mauro durante la sessione INF304 - Estendere Visual Studio: vspackage dalla a alla z, quello dell'infermiera che istanzia il tipo corretto di bisturi e lo passa al medico, mi sono detto: "e se questo modo di programmare (astrazione, IoC, buona suddivisione in componenti agnostici, ecc...) richiedesse davvero una nuova forma mentis?"
E quale?
Beh, per capire quale io mi sono fatto questa pensata: perchè i componenti non devono avere forte accoppiamento? Perchè finchè il progetto è piccolo, può anche andare bene con accoppiamento e poca astrazione (diciamo...) ?
Perchè è come in un team: se lavoro da solo (unico componente, blocco monolitico) tutto va bene ma non è che potrò davvero raggiungere grandi risultati (leggete: enterprise).
Se si è in due tutto sommato l'importante è capirsi anche senza utilizzare contratti (interfacce) o altra formalità, si raggiungeranno buoni risultati.
Ovvio che se uno dei due deve essere sostituito anche l'altro ne soffre (c'è forte accoppiamento) e dovrà adeguarsi.
E se si è in un grande (o importante) team? Come ad esempio un team in ospedale? Un medico deve per forza lavorare con il suo infermiere (o, meglio, infermiera :D)? E se cambia? Deve adeguarsi? O va bene qualsiasi infermiere (ovvero un tizio che implementi quell'interfaccia)?
Ovviamente devono essere tutti agnostici l'un l'altro, come dei componenti con accoppiamento debole, per la buona riuscita del risultato finale.
Io penso che questa sia una branca della OOP, definibile con TOP (Team Oriented Programming).