Java Interfaccia Istruzioni per l'uso - sono getter e setter in un'interfaccia male?

Question

Quello che la gente pensa delle migliori linee guida da utilizzare in un'interfaccia? Quello che dovrebbe e non dovrebbe andare in un'interfaccia?

persone

ho sentito dire che, come regola generale, un'interfaccia deve solo definire il comportamento e non lo stato. Questo significa che l'interfaccia non deve contenere getter e setter?

La mia opinione: Forse non è così per setter, ma a volte penso che getter sono validi ad essere messi in un'interfaccia. Questo è semplicemente quello di far rispettare le classi di implementazione per implementare quelle getter e così per indicare che i clienti sono in grado di chiamare i getter per controllare qualcosa, per esempio.

Answer 1

Credo che ci siano due tipi di interfacce dichiarate in generale:

1. descrizione del servizio . Questo potrebbe essere qualcosa di simile CalculationService. Non credo che i metodi getX dovrebbe essere in questo tipo di interfaccia, e sicuramente non setX. Essi chiaramente implicano dettaglio di implementazione, che non è il lavoro di questo tipo di interfaccia.
2. modello di dati - esiste solamente per astrarre l'implementazione di oggetti di dati nel sistema. Questi potrebbero essere utilizzati per aiutare nei test o solo perché alcune persone vecchie come mi ricordano i tempi in cui (per esempio) utilizzando un framework di persistenza si legato ad avere un particolare superclasss (cioè si sceglie di implementare un'interfaccia nel caso in cui si è passati il vostro strato di persistenza). Penso che avere metodi JavaBean in questo tipo di interfaccia è del tutto ragionevole.

Nota: le classi collezioni probabilmente in forma in di tipo 2 #

Answer 2

Non vedo il motivo per cui l'interfaccia non può definire getter e setter. Per esempio, List.size() è effettivamente un getter. L'interfaccia deve definire il comportamento piuttosto che il applicazione anche se - non si può dire come si Maniglia dello Stato, ma si può insistere sul fatto che si può ottenere e impostare esso.

interfacce Collection sono tutti circa lo stato, per esempio -. Ma diverse collezioni in grado di memorizzare quello stato in modi radicalmente diversi

EDIT: I commenti suggeriscono che i getter e setter implicano un campo semplice viene utilizzato per il backup di archiviazione. Sono d'accordo con veemenza questa implicazione. A mio avviso c'è un'implicazione che è "abbastanza a buon mercato" per ottenere / impostare il valore, ma non che è memorizzato come un campo con un'implementazione banale.

---

EDIT: Come notato nei commenti, questo è reso esplicito nella specifica JavaBeans sezione 7.1:

  

Così anche quando un tipo sceneggiatore   in qualcosa come b.Label = foo   v'è ancora una chiamata di metodo in   indirizzare oggetto per impostare la proprietà, e   all'oggetto target è pieno   il controllo programmatico.

     

Quindi proprietà non hanno bisogno di essere solo semplice   campi di dati, che possono effettivamente essere   valori calcolati. Gli aggiornamenti possono avere   vari effetti collaterali programmatiche. Per   esempio, cambiare lo sfondo di un fagiolo   proprietà di colore potrebbe anche causare la   fagiolo per essere ridipinto con il nuovo   colore ".

---

Se la presunta implicazione sono vero, potremmo benissimo esporre proprietà come campi direttamente. Per fortuna che implicazione non : hold. Getter e setter sono perfettamente in diritto di calcolare le cose

Si consideri ad esempio un componente con

getWidth()
getHeight()
getSize()

Credi che ci sia un'implicazione che ci sono tre variabili ci sono? Non sarebbe ragionevole né avere:

private int width;
private int height;

public int getWidth() {
    return width;
}

public int getHeight() {
    return height;
}

public Size getSize() {
    return new Size(width, height); // Assuming an immutable Size type
}

o (preferibilmente IMO):

private Size size;

public int getWidth() {
    return size.getWidth();
}

public int getHeight() {
    return size.getHeight();
}

public Size getSize() {
    return size;
}

Qui sia la proprietà formato o l'altezza / larghezza proprietà sono solo per convenienza - ma non vedo che che li rende non valida in alcun modo

.

Answer 3

Non c'è niente di intrinsecamente malvagio in getter / setter. Tuttavia:

1. tendo a fare i miei oggetti immutabili (in prima istanza) rispetto ai campi che contengono. Perché ? Ho un'istanza di maggior parte delle cose durante la fase di costruzione. Se voglio cambiare qualcosa più tardi poi mi rilasso tali restrizioni. Così i miei interfacce tenderanno a contenere getter, ma non setter (ci sono altri vantaggi - in particolare filettatura).
2. Voglio che i miei oggetti per fare le cose per me , non il contrario. Così, quando uno dei miei oggetti acquisisce una serie di getter, comincio a chiedere se tale oggetto dovrebbe avere più funzionalità in esso, piuttosto che esporre tutti i suoi dati per qualcos'altro con cui lavorare. Vedi questa risposta per maggiori dettagli.

Queste sono tutte le linee guida, note.

Answer 4

Non credo che un fagiolo dovrebbe avere un'interfaccia su di esso, in generale. Un JavaBean è un'interfaccia nel senso più generale. Un interfaccia specifica del contratto esterno di qualcosa di più complesso. contratto esterno di un JavaBean e la sua rappresentazione interna sono identici.

Non vorrei dire che non si dovrebbe avere getter in un'interfaccia, però. Ha senso perfetto per avere un'interfaccia ReadableDataThingie implementata da DataThingieBean.

Answer 5

  persone

ho sentito dire che, come   In generale, un'interfaccia solo deve   definire il comportamento e non lo stato. fa   Questo significa che l'interfaccia non dovrebbe   contenere getter e setter?

Per cominciare, almeno con Java e le dichiarazioni di eccezione esclusi, non si può definire il comportamento completo senza Stato. In Java, le interfacce non definiscono il comportamento. Essi non possono. Ciò che essi definiscono sono i tipi; promesse di attuazione di una serie di funzionalità firme possibilmente con alcuni post-condizioni eccezioni WRT. Ma questo è tutto. Comportamento e stato sono definiti dalle classi di attuazione di tali interfacce.

In secondo luogo, se getter e setter sono definiti in un'interfaccia, non certo definire un comportamento completo (altro che uno è per la lettura e una è per WRT scrivere la proprietà.) Si può avere un comportamento complesso dietro setter e getter, ma possono essere attuate soltanto nelle classi attuali. Non c'è nulla nel linguaggio Java che può permettere di definire liberamente il comportamento nelle interfacce tranne che per il più restrittivo dei casi.

Con questo in considerazione, non c'è nulla di male - sintatticamente e semanticamente -. Con avere setter e getter nelle interfacce

Se l'applicazione è ben modellato e il problema è necessario disporre di un'interfaccia che definisce setter e getter, perché no. Ad esempio, date un'occhiata all'interfaccia ServletResponse.

Ora, se guardiamo a getter e setter dal punto di vista delle classi conformi alle specifiche JavaBeans attuazione, allora non c'è bisogno di definire le interfacce per loro.

Ma se avete le cose che richiedono setter e getter, come un fagiolo potrebbe, e che è necessario anche essere collegato al momento della compilazione di tipo (non a run-time come un fagiolo potrebbero), e per il quale potrebbero esistere più implementazioni , allora sì, questo richiederebbe un'interfaccia che definisce getter e setter.

Speranza che aiuta.

Answer 6

Questo tocca l'intero Getter / Setter sono argomento del male che si rivolge più volte su questo sito e altrove.

Io tendo a favorire non avere funzioni di accesso nell'interfaccia, ma per aggiungere i collaboratori che utilizzano argomenti del costruttore per l'attuazione.

Answer 7

Il fatto che l'attuazione immediata di qualcosa è come un getter non dovrebbe fermarlo essere in un'interfaccia, se ha bisogno di essere.

Answer 8

Per ulteriori approfondimenti:. API pratico design Confessioni di un architetto Java Framework (Jaroslav Tulach 2008, Apress)

Answer 9

Ho usato questo tipo di interfacce, per esempio abbiamo avuto classi con campi BEGINDATE, endDate. Questi campi erano in molte classi e ho avuto uno caso d'uso che ho bisogno di ottenere quei date per oggetti diversi, così ho estratto interfaccia ed era molto felice:)

Answer 10

In pratica se la risposta alla domanda "Ho bisogno di conoscere il valore di [Stato, la proprietà, whateverThignAMaGit] al fine di lavorare con un'istanza di esso?" allora sì ... le funzioni di accesso appartengono nell'interfaccia.

List.size () da John sopra è un esempio perfetto di un getter che deve essere definito in un'interfaccia

Answer 11

Getters sono utilizzati per interrogare lo stato di un oggetto - che si può veramente evitare quando si progetta l'interfaccia. Leggi http://www.pragprog.com/articles/tell-dont-ask