Abbiamo parlato di accoppiamento, prima di addentrarci nel discorso coesione un piccolo approfondimento sull’ accoppiamento è doveroso.
Quando è male?
Se abbiamo detto che l’accoppiamento di per se non è ne bene ne male, ma è semplicemente una misura, quali sono i problemi che possono insorgere?
L’accoppiamento diventa un problema evidente quando è una barriera all’evoluzione.
Nella sua forma peggiore è la così detta “big ball of mud” ove tutto è fortemente accoppiato con tutto e l’evoluzione è impossibile.
Ma da perfetto a big ball of mud ci sono un’infinita serie di sfumature, e la barriera al cambiamento può essere un buon modo per misurare il livello di accoppiamento.
Il carrello della spesa
Ripartiamo dall’esempio che abbiamo usato in chiusura nel post precedente:
se abbiamo un’interfaccia “IShoppingCart” che gestisce il carrello di un sistema di e-commerce vogliamo porre molta attenzione a chi la usa perché un uso indiscriminato, con un possibile conseguente forte accoppiamento, può solo portare a conseguenze poco positive in termini di manutenibilità ed evoluzione.
Facciamoci qualche domanda:
- Quale è il ruolo (o se volete quali requisiti deve soddisfare) del carrello della spesa?
- Definito il ruolo ci dovremmo chiedere quali informazioni sono necessarie al carrello per soddisfare il ruolo di cui sopra
- Date le informazioni necessarie ci dobbiamo chiedere di chi è la responsabilità di modificarle
Ecco…se arrivati al punto 3 vi ritrovate con informazioni che stanno nel carrello, ma che sono modificate da attori diversi dal carrello avete la quasi certezza che:
l’identificazione dei service buondary è sbagliata e state creando accoppiamento
tra componenti che non dovrebbero essere accoppiati, ma probabilmente in quel particolare contesto sono solo coesi.
Giusto per darvi un’idea, io non disegnerei un carrello così:
{
CartId,
UserId,
Items: [{
ItemId,
StockItemId
Description,
Price,
Quantity
}]
}
Al prossimo giro parleremo di coesione.