Usa quello che ti serve

Usa quello che ti serve e non quello che detta qualche moda.

In questo caso la moda è il "disaccoppiamento". Cosa c'è di male nel disaccpoppiamento? Non c'è nulla di male nel disaccoppiamento in se, l'abuso di disaccoppiamento invece è più un male che un bene.

Perché? Semplicemente perché cominci a (far) perdere di vista la struttura della tua architettura a chi collabora con te, oltre ad introdurre un overhead che possiamo trascurare - più che altro perché se ne fanno spesso di peggiori...

E quando si perde di vista la struttura dell'architettura è un vero inferno andare a creare nuovo codice, se non è chiaro chi-usa-cosa non riesci nemmeno a pensarlo il nuovo codice. 

Pensate un attimo ad un utente che seleziona un certo numero di componenti da un elenco generale e li pone in un elenco di componenti selezionati. Poi comincia a comporre dei documenti prelevando componenti da questo secondo elenco. E siccome errare è umano, l'utente può tornare a cambiare in ogni momento l'elenco dei componenti selezionati - magari non può togliere un componente che ha già usato.

Una architettura sensata prevede un elenco generale, con i dati in un certo formato, magari più di un formato non proprio omogeneo in una serie di sub-elenchi generali. Poi la collezione di componenti selezionati, in cui i dati vengono portati nel formato utile alle ulteriori elaborazioni appena entrano nella collezione. In un MVC o MVP avremmo quindi un nuovo model con una nuova struttura. E quindi la funzione di composizione dei documenti.

Quando si cambia il contenuto della collezione degli elementi selezionati si fa solo quello, si toglie ciò che va (e si può togliere), si mette ciò che va aggiunto.

Oppure possiamo avere un'architettura disaccoppiata come questa:

• Dall'elenco si passa ad una collezione temporanea in cui i dati sono ancora nei formati non omogenei
• Dalla collezione temporanea grazie ad un meccanismo ad eventi (niente chiamata diretta) si inviano i dati in formati non omogenei ad una seconda collezione dove i dati vengono rielaborati e resi omogenei.
• A qesto punto posso creare i documenti con i miei componenti

Se si deve modificare l'elenco dei compoenti selezionati, 

• I dati dei compoenti devono tornare nel formato non omogeneo per essere ricaricati nella collezione temporanea. 
• Quando l'utente ha modificato la lista temporanea questa torna -sempre col meccanismo ad eventi - alla collezione da usare che deve operare una sincronizzazione tra i dati

Non solo ci si complica la vita con lavoro extra, è come dover modificare il progetto un motore a scoppio in cui il pistone non è collegato all'albero motore tramite una biella rigida, ma manda un messaggio ad un leveraggio complesso che alla fine fa girare l'albero motore. Provate a presentare un idea del genere ad un ingegnere meccanico e poi ditemi come siete tornati indietro. Non mi assumo responsabilità sulla vostra salute se lo fate...

Insomma, perché complicarsi la vita per avere cose che più che ragionevolmente non si useranno? Ma non si dovevano tenere le cose semplici (Keep It Simple Stupid! -KISS)?