Ho visto un certo interesse sul post sull'architettura malleabile proverò a fare qualche esempio su cosa ha funzionato nei progetti su cui ho lavorato o sto lavorando.
L'approccio con cui mi trovo meglio è quello di usare gli oggeti per creare un DSL interno che descriva il comportamento del sistema; questo rende la manutenzione molto più efficace perchè tendenzialmente viene modificata la descrizione del sistema e a nuove feature corrispondono di solito nuovi oggetti.
Proviamo a fare un esempio pratico. Devo realizzare il classico data entry. La prima cosa che viene in mente è quella di creare un nuovo progetto, creare una nuova form, piazzare i controlli, ecc.
La prima cosa che viene in mente solitamente è la meno efficace conviene quindi riflettere un po' di più su come arrivare al risultato.
Il designer è uno strumento molto comodo e potente con uno svantaggio: genera del codice su cui non abbiamo controllo e ne genera parecchio. Proviamo invece a descrivere cosa fa il sistema con il codice:
EditorControl.Label().Text("Cognome").PlaceOn(parent);
updateControl.TextWith(
user => user.Name,
(user, text) => user.Name = text)
.On(EditorControl.TextBox().PlaceOn(parent));
In questo caso abbiamo definito come viene editata la property Name della classe User.
L'implementazione è più semplice di quello che possa sembrare. Ad esempio:
public class EditorControl
{
public static TextEditorControl TextBox()
{
return new TextEditorControl(new TextBox());
}
}
Il layout dei controlli è gestito da un oggetto piuttosto semplice cosi' come lo scambio dei dati.
Con un approccio centralizzato cambiare il TextBox con un altro per tutte le form risulta un'operazione semplicissima.
Per raggiungere questo risultato i test scritti sono quasi esclusivamente acceptance test cioè test end-to-end, uno per ogni singolo scenario di ogni caso d'uso procedendo in maniera incrementale.