getter e setter: Codice odore, male necessario, o non può vivere senza di loro

Eventuali duplicati:
Allen Holub wrote “You should never use get/set functions”, is he correct?getter e setter: Codice odore, male necessario, o non può vivere senza di loro

C'è un buon, no, un molto buona ragione, per risolvere tutti i problemi legati all'utilizzo di getter e setter per i linguaggi orientati agli oggetti? Cosa c'è che non va usando solo un riferimento diretto a una proprietà o un metodo? Esiste una sorta di "copertura semantica" di cui le persone non vogliono parlare in modo educato? Ero solo troppo stanco e mi sono addormentato quando qualcuno è uscito e ha detto "Tu scriverò quantità copiose di codice per ottenere getter e setter"?

Follow-up dopo un anno:

Sembra essere un evento comune con Java, meno con Python. I'm beginning to wonder if this is more of a cultural phenomena (related to the limitations of the language) rather than "sage advice". Siccome non programma in Java (attualmente per scelta) non posso fare quella valutazione.

Il punteggio di domanda corrente (corrente al momento della stesura 2010-03-22) -1 è completo per il lulz per quanto mi riguarda. È interessante notare che ci sono domande specifiche che sono downvoted, non perché sono "domande cattive", ma piuttosto, perché colpiscono il nervo scoperto di qualcuno .

Quindi andiamo al nocciolo della questione. mi ripeto:

What's wrong with just using a direct reference to a property or method?

Ed ecco il corollario non scritta:

Are we so undisciplined as programmers that we can't keep our hands off of things that are clearly marked "no touchy"?

fonte

2009-06-21 Avery Payne

Non mi sembra un duplicato esatto. L'altra domanda chiede "Dovresti * non * usare getter/setter?" mentre questa domanda chiede "Dovresti * mai * usare getter/setter?" C'è un intero carattere di differenza lì! – Talljoe

D'oh, se questo è un duplicato esatto, allora perché diavolo non è apparso nei suggerimenti quando l'ho postato per la prima volta? –

@Talljoe: Questa è una sottile differenza che mi è sfuggita. Occhio fino! Leggerò attentamente tutte le altre domande nella barra laterale relativa che rispondono a questa domanda per selezionare un sostituto più adatto. Grazie. :) –

Ecco Allen Holub (che è geniale) on the matter. Entra molto più in dettaglio su questo argomento in Holub on Patterns. Alcune cose richiedono getter e setter pubblici come la serializzazione e modelli come lo Data Transfer Object pattern. In generale, ritengo necessario il male poiché la tua domanda diventa complicata quando non le usi.

fonte

2009-06-21 01:58:28

Protection. Alcune proprietà/metodi non dovrebbero essere chiamati senza la classe ... mai. Sono sicuro che tu mantenga l'esclusiva autorità di comunicare a chiunque il tuo numero di previdenza sociale, giusto? Devono chiederti (getter)? Certamente non consiglieresti di consentire alle persone l'accesso diretto a dati/metodi privati nella nostra vita ... perché trattare le tue applicazioni in modo diverso? :)

fonte

2009-06-21 01:52:50 Sampson

Quindi ... se capisco il senso di questo ... getter e setter per i linguaggi OO che non hanno un metodo per nascondere il loro spazio dei nomi? –

Costruiscono un muro di mattoni intorno alla classe, quali diritti specifici di determinati oggetti all'interno. Alcune classi hanno proprietà che non dovrebbero essere gestite da nessuno, mai. Questi sarebbero definiti come privati o protetti, e come tali nessuno potrebbe manipolare i loro valori dall'esterno della classe. Solo fornendo un getter possono effettivamente dire qual è il valore, e solo fornendo un setter possono effettivamente manipolare il valore. Sei il re dei tuoi dati e l'unico accesso che le persone hanno all'interno, è l'accesso che tu concedi loro. – Sampson

Interessante, più per la psicologia di quella spiegazione che per la spiegazione stessa. Sento un'altra domanda in arrivo ... ma a giudicare da quanto funzioni la funzione di ricerca di duplicati funziona (appena chiusa in meno di 30 minuti), dovrò esprimerla con attenzione. In ogni caso, grazie per il chiarimento! –

Un modo in cui ho trovato utile essere in grado di impostare un punto di interruzione sul set (più che il get). Questo probabilmente significa "Sto codificando male", ma almeno posso scoprire esattamente quando cambia.

fonte

2009-06-21 01:55:36

In realtà, posso dirti che è una funzione del tuo debugger. Il tuo debugger (o linguaggio, o il motore che guida il linguaggio se è interpretativo/semi-compilato/p-code) non supporta l'interruzione dello stato di modifica di una proprietà (variabile), e sei quindi costretto ad emulare questo comportamento . Sono stato in lingue diverse che lo fanno e non supportano questa funzione, e anche se è bello avere, non è un punto fermo. Ancora, +1 per (a) comprendendo almeno che è una limitazione (b) trovando un modo per aggirarlo (c) indicandone un uso pratico, anche se non è una risposta diretta. –

Getter e settatori nascondono le informazioni sui dati delle classi dagli utenti delle classi.

In molti casi non sono completamente utilizzati, ma è sempre consigliabile utilizzarli. L'accesso diretto ai dati degli oggetti riduce l'incapsulamento.

Se non si utilizzano getter e setter, quando si cambia idea su un membro dati, si interrompe l'interfaccia delle classi e si deve modificare il resto della base di codice per conformarsi alla modifica. In alcuni casi in cui la tua classe rappresenta parte di un'API pubblica, questo non è nemmeno possibile.Se si avvolgono le proprietà in getter e setter, è possibile apportare tali modifiche e nasconderle dal consumo di codice modificando i metodi getter e setter.

fonte

2009-06-21 01:59:59

Getter e setter sono un aspetto dell'implementazione di Open/Close principle. Se si incapsulano tutte le funzionalità dietro proprietà appropriate, il codice che utilizza le proprietà non si interromperà. Rende anche possibile sostituire completamente quell'oggetto con qualcos'altro in futuro, specialmente se si esegue il codice su un'interfaccia anziché su una classe.

Sono così importanti che C# ha attraversato il problema per rendere semplici getter e setter semplici da scrivere.

Per capire meglio perché alcuni aspetti dell'OOD sono importanti, leggere il libro Emergent Design di Scott Bain.

fonte

2009-06-21 02:09:23 Talljoe

Guarderò nel libro. Nel frattempo, se capisco questo a colpo d'occhio, stai insinuando che io davvero, davvero, non voglio esporre più di quello che è necessario per altri oggetti ... sembra quasi che tutti gli oggetti dovrebbero essere molto strettamente incapsulato e tutto funziona come se ci fossero milioni di piccole chiamate API tra ogni oggetto ... bah, mi sto stancando, dimentico quel commento. –

Sì, lo hai esattamente! Incapsulamento e basso accoppiamento. Ogni oggetto dovrebbe avere la sua (unica) responsabilità e utilizzare interfacce chiare e di piccole dimensioni per comunicare con qualsiasi altro oggetto con cui ha bisogno di parlare. – Peeja

getter e setter: Codice odore, male necessario, o non può vivere senza di loro

risposta

Problemi correlati