Capitolo 29. Accoppiamento
Questo lavoro è stato tradotto utilizzando l'AI. Siamo lieti di ricevere il tuo feedback e i tuoi commenti: translation-feedback@oreilly.com
Per prepararsi a scrivere il loro classico testo Structured Design, Ed Yourdon e Larry Constantine esaminarono i programmi per capire cosa li rendesse così costosi. Notarono che i programmi costosi avevano tutti una proprietà in comune: la modifica di un elemento richiedeva la modifica di altri elementi. I programmi economici tendevano a richiedere modifiche localizzate.
Hanno soprannominato questa proprietà di infezione del cambiamento "accoppiamento". Due elementi sono accoppiati rispetto a un particolare cambiamento se la modifica di un elemento richiede la modifica dell'altro elemento.
Ad esempio, una funzione chiamante è accoppiata a una funzione chiamata per quanto riguarda le modifiche al nome della funzione chiamata:
caller()
called()
called() // changing this name requires changing the call site(s) too
... // changing the formatting of the body requires no changes to call sites
Il secondo commento sottolinea un'importante sfumatura dell'accoppiamento: non possiamo limitarci a dire che due elementi sono accoppiati. Per dire qualcosa di utile, dobbiamo anche dire accoppiati rispetto a quali cambiamenti. Se due elementi sono accoppiati rispetto a un cambiamento che non avviene mai, allora non sono accoppiati in un modo che dovrebbe preoccuparci. Questo accoppiamento è il masso in cima alla collina che non rotola ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access