Come si applica la legge di Demeter ai sistemi orientati agli oggetti per quanto riguarda l'accoppiamento e la coesione? [chiuso]

Secondo Emerson Macedo il Law of Demeter afferma quanto segue:

• Ogni unità dovrebbe avere solo una conoscenza limitata delle altre unità: solo le unità "strettamente" correlate all'unità corrente.
• Ogni unità dovrebbe parlare solo con i suoi amici; non parlare con estranei.
• Parla solo con i tuoi amici più stretti.

Questo corrisponde direttamente al principio di basso accoppiamento come si suppone che le unità (o gli oggetti), come sopra:

• Non essere strettamente accoppiati l'uno all'altro. Solo i più vicini sono.
• Ognuno dovrebbe parlare solo con i suoi collaboratori e non con i collaboratori del collaboratore
• Parla solo con oggetti collaborativi immediati

Una delle forme di accoppiamento più basse è il passaggio di messaggi, ovvero i dati sono condivisi tra oggetti tramite chiamate di metodo con parametri.

Inoltre, da quello che vedo, la Legge di Demetra non corrisponde direttamente al principio di alta coesione come solo afferma che gli oggetti stessi dovrebbero sapere quali dati possiedono essi stessi. Un oggetto con bassa coesione ha membri di dati che non utilizza frequentemente nei propri metodi. Si tratta più del contenuto di un oggetto che delle sue relazioni e oggetti collaborativi.

Accoppiamento, semplificato

Quando un oggetto chiama un metodo, una proprietà, ecc. di un altro oggetto, diciamo che gli oggetti sono accoppiati. Lo chiamiamo accoppiamento perché ora callee non può cambiare qualsiasi del proprio metodo / oggetto. w.out rompendo il chiamante .

Quindi, più l'accoppiamento - metodi, oggetti di scena. - più difficile è modificare il codice callee senza rompere tutto il codice che lo utilizza.

contemplando l'accoppiamento

• Facendo riferimento anche a un singolo puntello., il metodo accoppia due oggetti.
• Ovviamente l'accoppiamento è necessario per la creazione di software.
• Data la natura di "blocco del passo" dell'accoppiamento, vogliamo sia limitarlo che isolarlo. Questo obiettivo si accompagna semplicemente allo sviluppo di software generici. principi.
• Meno oggetti dobbiamo parlare, più basso è l'accoppiamento.
• Se devo fare, diciamo, 20 diverse chiamate di metodo, l'accoppiamento è più basso se tutte e 20 le chiamate sono relative a una classe / oggetto, viceversa quegli stessi metodi si diffondono su più classi / oggetti.

La maggior parte delle Conoscenze causa un accoppiamento pazzo

Qui abbiamo un Employee che ha un Person che ha un 'Indirizzo'

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Per ottenere la strada devo chiamare: myEmployee.me.home.street . Questo è di 180 gradi opposto al principio della conoscenza minima. Devo sapere sugli interni, la struttura composita, delle classi Employee , Person e Address .

Questo design di classe difettoso mi obbliga a sapere su tutte quelle classi e quindi myEmployee.me.home.street mi accoppia (l'oggetto chiamante) a non meno di 3 classi - per ottenere solo una singola proprietà!

Minima conoscenza salva il giorno

Se parlo solo con la classe Employee sto applicando di per sé il minimo principio di conoscenza, e così facendo accoppiamo automaticamente limit solo a quella classe, e allo stesso tempo isolare accoppiando a quella classe.

Aggiungendo tutte le proprietà necessarie nella classe Employee , risolviamo l'accoppiamento.

così

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Mi consente di chiamare: myEmployee.street -

1. I "so" solo Employee
2. Sono abbinato solo a Employee - non importa quanto sia complessa la sua struttura.

Least Knowledge in fondo

Abbiamo disgiunto myEmployee da Person e Address , e idealmente dovremmo continuare ad applicare la minima conoscenza aggiungendo passare attraverso proprietà in modo che Employee parli solo a Person e Person parla solo con Address

Study ( V. Basili, L. Briand e WL Melo Una convalida delle metriche progettuali orientate agli oggetti come indicatori di qualità ) ha dimostrato che le classi con più insiemi di risposte tendono a creare più errori rispetto alle classi con una risposta più piccola poiché un maggior numero di risposte significa la possibilità di un accoppiamento più elevato.

Il valore di Law of Demeter è che riduce la risposta impostata per definizione. Il metodo di un oggetto può solo chiamare un metodo di se stesso, qualsiasi parametro che è stato passato al metodo, metodo di qualsiasi oggetto che ha creato e metodo di qualsiasi oggetto direttamente detenuto. Poiché il set di risposta è più piccolo, ci sono meno possibilità di un accoppiamento elevato. Dal momento che il modulo / metodo utilizza solo riferimenti immediati disponibili, esiste una maggiore coesione.

È piuttosto semplice; dire A dipende da B e B dipende da C. Senza la Legge di Demetra puoi usare sia B che C in A ma aderendo a questa legge, A dipende solo da B, non può dipendere da C.

Ciò consente l'accoppiamento basso poiché riduce notevolmente il numero di dipendenze di un modulo; la coesione, benché diversa dal concetto di accoppiamento, si ottiene allo stesso modo. Avendo meno dipendenze su un modulo, queste diventano più specifiche per quel modulo e quindi aumentano la coesione. Anche il numero totale di moduli aumenterà e diventeranno più specializzati per fare cose specializzate per il modulo dipendente (contrariamente agli oggetti di dio) che si traducono direttamente in un sistema più coerente.