Come si applica la Legge di Demetra ai sistemi orientati agli oggetti in materia di accoppiamento e coesione? [chiuso]


15

In che modo la Legge di Demetra si applica ai sistemi orientati agli oggetti con accoppiamento e coesione?

Stavo leggendo un libro "Sviluppo software e pratica professionale" e mi sono imbattuto nel capitolo su LoD, ed ero curioso di sapere come applicare questo principio nei sistemi orientati agli oggetti.


Una volta ho ereditato un progetto che aveva un alto livello di accoppiamento (topologia a stella). Ho ripulito le cose usando un 'modello mediatore' per limitare l'accoppiamento tra oggetti e lasciare invece che il mediatore parlasse con ciascun oggetto. Sebbene sia ancora coinvolto l'accoppiamento, limita il numero di individui accoppiati. Alcuni potrebbero voler esplorare ancora di più se ritengono di avere un problema di accoppiamento elevato con il loro design.
Jeach

Risposte:


9

Secondo Emerson Macedo la Legge di Demetra afferma quanto segue:

  • Ogni unità dovrebbe avere 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 immediati.

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

  • Non essere strettamente accoppiati tra loro. Solo quelli più vicini lo sono.
  • Ognuno dovrebbe parlare solo con i suoi collaboratori e non con i collaboratori del collaboratore
  • Parla solo con l'oggetto collaboratore immediato

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

Inoltre, da quello che posso vedere, la Legge di Demetra non corrisponde direttamente al principio dell'alta coesione in quanto afferma solo che gli oggetti stessi dovrebbero sapere quali dati possiedono. Un oggetto con bassa coesione ha membri di dati che non utilizza frequentemente nei propri metodi. Si tratta più del contenuto di un oggetto piuttosto che delle sue relazioni e degli oggetti che collaborano.


8

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 la chiamata non può cambiare nulla del proprio metodo / prop. senza interrompere il chiamante .

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

contemplando l'accoppiamento

  • Facendo riferimento anche a un singolo prop., Il metodo accoppia due oggetti.
  • Ovviamente l'accoppiamento è necessario per la creazione di software.
  • Data la natura del "passo di blocco" dell'accoppiamento, vogliamo sia limitarlo che isolarlo. Questo obiettivo va semplicemente d'accordo con gli sviluppatori software generici. i principi.
  • Meno oggetti con cui dobbiamo parlare, minore è l'accoppiamento.
  • Se devo fare, diciamo, 20 chiamate di metodi diversi, l'accoppiamento è inferiore se tutte e 20 le chiamate sono rivolte a una classe / oggetto, viceversa quegli stessi metodi si estendono su più classi / oggetti.

La maggior parte delle Conoscenze provoca un accoppiamento folle

Qui abbiamo un Employeeche ha un Personche 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 che devo chiamare: myEmployee.me.home.street. Questo è l'opposto di 180 gradi del principio della minima conoscenza. Devo sapere riguardo la struttura interna, la struttura composita, del Employee, Persone Addressle classi.

Questo design di classe difettoso mi costringe a conoscere tutte quelle classi e quindi myEmployee.me.home.streetmi abbina (l'oggetto chiamante) a non meno di 3 classi - per ottenere una sola proprietà!

La minima conoscenza salva la giornata

Se parlo solo la Employeeclasse che sto applicando il principio della conoscenza almeno di per sé, e così facendo abbiamo automaticamente limito giunto solo a quella classe, e allo stesso tempo isolato accoppiamento a quella di classe.

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

così

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

Mi permette di chiamare: myEmployee.street-

  1. "Lo so" solo Employee
  2. Sono accoppiato solo a Employee, non importa quanto complessa sia la sua struttura.

Minima conoscenza fino in fondo

Abbiamo disaccoppiato myEmployee da Persone Address, idealmente, dovremmo continuare ad applicare la minima conoscenza aggiungendo proprietà pass through in modo tale da Employeeparlare solo Persone Personsolo parlareAddress


1

Studio ( V. Basili, L. Briand e WL Melo. Una convalida delle metriche di progettazione orientate agli oggetti come indicatori di qualità ) ha dimostrato che le classi con set di risposta più grandi hanno la tendenza a creare più errori rispetto alle classi con set di risposta più piccolo perché più set di risposta 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ò chiamare solo un metodo di se stesso, qualsiasi parametro passato al metodo, metodo di qualsiasi oggetto creato e metodo di qualsiasi oggetto direttamente trattenuto. Poiché il set di risposta è più piccolo, ci sono meno possibilità di un elevato accoppiamento. Poiché il modulo / metodo utilizza solo riferimenti immediatamente disponibili, esiste una maggiore coesione.


1
Lo studio ( Anquetil, N. e Laval, J. Legacy Software Ristrutturazione: analisi di un caso concreto ) ha anche dimostrato che ridurre l'accoppiamento e aumentare la coesione non sempre porta a una migliore qualità. Affidarsi al risultato di un singolo piccolo studio considerato dannoso.

0

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

Ciò consente un basso accoppiamento poiché riduce notevolmente il numero di dipendenze di un modulo; la coesione, sebbene di concezione diversa dall'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 nel fare cose specializzate per il modulo dipendente (contrariamente agli oggetti divini) che si traduce direttamente in un sistema più coerente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.