Getters and Setters sono cattivi design OO?

Getter e setter sono cattivi

Leggendo brevemente l’articolo di cui sopra, trovo che i getter ei setter sono un cattivo design di OO e dovrebbero essere evitati mentre vanno contro Encapsulation e Data Hiding. Poiché questo è il caso, come può essere evitato durante la creazione di oggetti e in che modo un object del modello può tenerne conto.

Nei casi in cui è richiesto un getter o setter quali altre alternative possono essere utilizzate?

Grazie.

Getters o setter da soli non sono male design OO.

Ciò che è male è la pratica di codifica che include un getter E un setter per OGNI singolo membro automaticamente, se questo getter / setter è necessario o meno (abbinato a rendere pubblici i membri che non dovrebbero essere pubblici) – perché questo espone fondamentalmente l’implementazione della class al mondo esterno violare l’occultamento / l’astrazione delle informazioni. A volte questo viene fatto automaticamente da IDE, il che significa che tale pratica è molto più diffusa di quanto si spera.

Hai perso il punto. Il bit valido e valido di quell’articolo è:

Non chiedere le informazioni necessarie per svolgere il lavoro; chiedi all’object che ha le informazioni per fare il lavoro per te.

La proliferazione getter e setter in stile Java sono sintomi di ignorare questo consiglio.

Credo nell’includere i setter nell’API solo se fanno realmente parte delle specifiche di class (ossia il suo contratto con il chiamante).

Qualsiasi altro membro dei dati relativo alla rappresentazione interna dovrebbe essere nascosto, e vedo almeno 2 ragioni principali per questo:

1) Se la rappresentazione interna è esposta, le modifiche alla progettazione sono più problematiche in futuro e richiedono anche modifiche API.

2) Esporre i membri dei dati con setter / getter senza alcuna caucanvas consente ai chiamanti di rovinare molto facilmente l’invariante di class. Gli oggetti con stato incoerente possono causare bug che sono molto difficili da analizzare.

Sfortunatamente ci sono alcuni framework che incoraggiano (a volte richiedono) l’aggiunta di setter / getter per tutto.

Getter e setter non sono male da soli. Ciò che è male è la pratica di rendere qualsiasi campo privato e fornire getter / setter per tutti loro, qualunque cosa accada.

Sì, getter e setter è un anti-pattern in OOP: http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html . In poche parole, non si adattano al paradigma orientato agli oggetti perché incoraggiano a trattare un object come una struttura di dati. Quale è un malinteso importante.

Il modo in cui l’ho letto, l’autore sostiene che mettere ciecamente getter e setter nei campi non è meglio che rendere pubblico il campo.

Credo che l’autore sostenga che i getter ei setter dovrebbero essere posti scarsamente, e con cura, perché l’idea di OO è che gli oggetti dovrebbero limitare la loro esposizione solo a ciò che è necessario.

Andrò un po ‘oltre e dico che solo i tipi di valore dovrebbero avere getter. Ogni tipo di valore dovrebbe essere immutabile e avere un costruttore che è mutabile e ha setter.

Se il tuo tipo di valore ha setter, devono restituire una nuova istanza dopo aver copiato gli altri valori.

Url.setAnchor (…)

Restituirebbe un nuovo Url copiando la porta host ecc ma sovrascrivendo l’ancora.

Le classi del tipo di servizio non hanno bisogno di setter (impostarli in ctor) e sicuramente i getter dei caratteri necessari. Il tuo Mailer dovrebbe prendere le cose statiche host / port / etc in esso. Se desidero inviare un messaggio e-mail, quindi, cellula è send (), non c’è alcun motivo per cui il mio codice dovrebbe aver bisogno di sapere o volere o richiedere l’host e altri valori di configurazione. Detto questo, avrebbe senso creare una class MailServer come il seguente // valore tipo MsilServer {String host int port Nome stringa Strung password // all come ruth getter} // factory Mailer create (MailServer)

Vi suggerisco di leggere attentamente l’intero articolo poiché presenta argomenti e alternative ben congegnati. La domanda in sé è troppo aperta e le risposte che otterrete saranno solo più opinioni.

Getter e setter sono solo metodi. Cosa fanno? Cambiano un campo in una proprietà, e questa è una distinzione importante.

Un campo è un po ‘di dati, di stato, nell’object. Una proprietà è una caratteristica osservabile esternamente, parte del contratto dell’object. Spruzzare le viscere di un object dappertutto, sia direttamente che tramite getter / setter, è sempre una ctriggers idea. Design scadente. Ma sollevandolo fino al punto di dire che getter e setter sono sempre cattivi? Questo è solo un programmatore povero senza un senso del buon gusto che sostiene che una vaga regola empirica (che in realtà non capiscono) è una legge in ghisa.

Personalmente, tendo a cercare di mantenere le proprietà come cose che non cambiano inaspettatamente sotto i piedi dei clienti. (I clienti della class sono.) Le uniche proprietà che cambierò dynamicmente sono quelle che non possono scrivere, e anche allora proverò ad evitarlo. Sento che le proprietà sono in molti modi valori che controllano il comportamento dell’istanza che sono impostati dal client, non cose arbitrarie sotto il controllo della class. (Questo è il campo normale per …)

Dall’articolo:

Quando è accettabile un accessorio? Innanzitutto, come discusso in precedenza, va bene che un metodo restituisca un object in termini di un’interfaccia che l’object implementa perché quell’interfaccia ti isola dalle modifiche alla class di implementazione. Questo tipo di metodo (che restituisce un riferimento all’interfaccia) non è realmente un “getter” nel senso di un metodo che fornisce solo l’accesso a un campo. Se si modifica l’implementazione interna del provider, è sufficiente modificare la definizione dell’object restituito per adattarla alle modifiche. Proteggi ancora il codice esterno che usa l’object attraverso la sua interfaccia.

In altre parole, utilizzare le interfacce per entrambi i metodi getter e setter quando sono necessari in questo modo è ansible mantenere l’incapsulamento. In generale, è buona norma specificare un’interfaccia per un tipo di ritorno o un parametro formale.

Ci sono altri articoli che dicono che sono un buon design. Ma la risposta è questa: getXXX e setXXX sono buoni o cattivi in ​​base all’utilizzo. questi mathod rendono molte cose più facili. Quindi, se alcuni articoli dicono che è un cattivo design, penso; sta solo cercando di essere troppo duro con l’idea.

Uno dei più grandi usi di questi metodi è in molti framework e usato come meccanismo di riflessione.

Quindi non evitare completamente l’uso di questi, piuttosto … usalo con giudizio.

grazie Ayusman

Getters and Setters sono cattivi design OO?

Solo se usato senza pensare.

Se devi creare un object valore per trasportare i dati, stanno bene.

Se stai creando un object più importante, allora non dovrebbero esserci. Dai un’occhiata all’interfaccia ArrayList * per esempio. Non vedi Object[] getElementData() perché ciò interromperà l’incapsulamento (qualcuno potrebbe temperare l’array sottostante).

* Mi riferisco all’interfaccia pubblica della class (i metodi esposti dalla definizione della class)

I getter / setter sono perfettamente appropriati, nelle giuste condizioni. Tuttavia, la massa Get / Set è sbagliata.

Tuttavia, sono un po ‘confuso. Hai taggato Java, ma il materiale non è particolarmente specifico di Java (solo gli esempi). Vale la pena notare che in C ++ (meglio fatto in 0x) molti di questi problemi non esistono. Se volevi cambiare la tua interfaccia da long ad int, quindi tra decltype, templates e auto questo è facilmente realizzabile, ed è per questo che tali costrutti rock. Typedef funziona bene anche