La 'Legge di Demeter' è applicabile alle firme del metodo pubblico / API?

Question

La 'Legge di Demeter' è applicabile alle firme del metodo pubblico / API?

#1 da (3 voti)
#2 da (0 voti)

10

Dato che le modifiche all'API / firma del metodo pubblico dovrebbero essere minime per evitare di infrangere quei codici client che usano questi metodi, mi chiedevo se Law of Demeter è meno applicabile a questi.

Un semplice esempio:

class Account() {
   double balance;
   public void debit(Transaction t) {
      balance -= t.getAmount();
   }
}

Si noti che il metodo di addebito supera l'oggetto Transaction anziché solo il doppio (la "Legge di Demeter", come ho capito, direbbe semplicemente di passare le informazioni richieste, in questo caso solo l'importo, non l'oggetto Transaction ...). La ragione di questo, è perché il metodo in futuro potrebbe richiedere alcune altre proprietà di transazione oltre all'importo. Da quanto ho capito, ciò impedirà di rompere la firma del metodo aggiungendo un nuovo parametro in futuro.

Questo rende quindi una scelta sensata? O mi sto perdendo qualcosa?

design api-design

posta Carlos Jaime C. De Leon 12.03.2012 - 09:11

fonte

2 risposte

Leggi altre domande sui tag design api-design

Scadenza cache casuale Progettare un'architettura robusta per più tipi di esportazione?

score 3 · Answer 1

Ma questo non infrange la Legge di Demeter.

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

O itself

M's parameters

any objects created/instantiated within M

O's direct component objects

a global variable, accessible by O, in the scope of M

Wikipedia: Legge di Demetra

La transazione è un argomento del metodo di debito, quindi chiamare t.getAmount () va bene.

Modifica: interpretato male, stai dicendo che il LoD ti farebbe passare l'importo della transazione, non un oggetto Transaction. Se è così, allora sì, penso che sia un buon posto per romperlo, sapendo che in futuro avrai bisogno di più dall'oggetto Transaction. Inoltre, incapsulare le primitive negli oggetti a livello di dominio è un'altra buona pratica di programmazione.

Modifica 2: dopo aver letto potrebbe averne bisogno di più in futuro, si potrebbe anche vedere questo come una placcatura d'oro non necessaria. Fornire un metodo che richiede un doppio ora (o meglio una classe di denaro) è sufficiente. Se hai bisogno di un argomento di transazione in un secondo momento, non è disastroso fornire una seconda firma per prendere una Transazione, ma continuare a supportare la firma originale. Non è che tu stia implementando due metodi, uno chiamerebbe l'altro.

score 0 · Answer 2

Se hai in programma di espandere la classe Account in futuro, direi che questa è una situazione in cui rendere l'oggetto Transaction più generico sarebbe una buona flessione delle regole della legge.

Ad esempio:

public class Amount {

    public void process( Transaction t ) {
        ....
    }
}

public abstract class Transaction {

    public String getType();

}

Penso di allontanarmi dalla domanda originale, ma il mio punto è che mentre si è preoccupati che si sta allontanando dalla legge di Demeter, i vantaggi di farlo superano quelli negativi.