La composizione aumenta o diminuisce l'accoppiamento

Stai facendo delle confusioni nei tuoi 3 punti:

1. La sola composizione non è una garanzia di perdita di accoppiamento. La composizione crea una dipendenza da un'interfaccia, quindi di fatto un accoppiamento. Ma più generica è l'interfaccia, perdente l'accoppiamento.

2. La tua offerta è solo uno dei tanti criteri. Si applica se A e B sono classi. Tuttavia se B è un'interfaccia, si applicherebbe la seguente citazione dello stesso articolo di wikipedia (prima frase dopo il proiettile):

   Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module's internal implementation

3. La composizione UML esprime qualcosa di diverso: significa una parte / tutto il rapporto con una proprietà esclusiva indipendentemente dal modo in cui viene implementata questa relazione (sì, nella pratica, è spesso tramite un riferimento, ma non deve essere così). In particolare, UML presume che la morte dell'oggetto proprietario implicherebbe la morte degli elementi di proprietà. Quindi stai confrontando un concetto di implementazione (in 1 e 2 c'è un riferimento, ma nessuna ipotesi sulla proprietà) con una semantica di disegno più astratta (anche se a volte sovrapposta).

Quindi, per semplificare e come regola empirica (e non come leggi inciso nel marmo ), per perde l'accoppiamento :

• preferisci composizione sull'ereditarietà , perché l'ereditarietà è sempre un strong accoppiamento (qualsiasi modifica nella classe genitore potrebbe richiedere un cambiamento in tutte le classi figlie) e inoltre, è definito in fase di compilazione.
• usa segregazione dell'interfaccia per il tipo a cui fai riferimento, per non avere una dipendenza da qualcosa che non dovresti Non c'è bisogno di preoccuparsi.
• inject dependencies , per evitare dipendenze implicite a specifici costruttori di tipi specifici

Misurare l'accoppiamento è difficile.

Le metriche semplicistiche come il numero di riferimenti inter-class sono facili da calcolare, ma in realtà non ti dicono molto che è utile per il codice.

Ci sono più fattori che indicano se l'accoppiamento è cattivo. I più importanti sono:

• la misura in cui la classe che fa riferimento ad un'altra dipende dai dettagli di quella classe
• la misura in cui è probabile che la classe accoppiata possa cambiare
• la misura in cui le classi accoppiate sono indipendenti nello scopo; le classi che potrebbero essere modificate insieme non sono tanto un problema, bensì una classe casuale non correlata.

Si noti che questi sono essenzialmente impossibili da quantificare. Quindi non fidarti mai di una metrica numerica di accoppiamento, perché ignora questi fattori critici.

Si noti che il primo è probabile che sia molto peggio in una classe che eredita da un'altra che usa la composizione, se non altro perché l'ereditarietà fornisce un meccanismo più conveniente, quindi è probabile che venga usato di più. Inoltre fornisce spesso metodi di interazione a un livello più privilegiato (ad esempio tramite membri protetti). Entrambi tendono ad aumentare i cattivi tipi di accoppiamento. Favorire la composizione aiuta quindi ad evitare un cattivo accoppiamento.

Altre tecniche che aiutano a seguire il principio di open closed (dove farlo non porta a disegni mostruosamente cattivi), che tende a ridurre il secondo punto nella mia lista, e seguendo il principio di responsabilità singola che tende a migliorare il terzo .