DISABILITARE ADBLOCK

ADBlock sta bloccando alcuni contenuti del sito

ADBlock errore
risultati trovati: 

DOMANDA

Che cos'è il "purista" o "corretto" modo di accedere alle proprietà di un oggetto all'interno di un metodo oggetto che non è un metodo getter / setter?

So che dall'esterno dell'oggetto dovresti usare un getter / setter, ma dall'interno faresti semplicemente:

Java:

String property = this.property;

PHP:

$property = $this->property;

o lo faresti:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Perdonami se il mio Java è un po 'fuori, è passato un anno da quando ho programmato in Java ...

Modifica

Sembra che le persone stiano assumendo che sto parlando solo di variabili / proprietà private o protette. Quando ho appreso OO, mi è stato insegnato a usare getter / setter per ogni singola proprietà anche se era pubblico (e in realtà mi è stato detto di non rendere mai pubblica alcuna variabile / proprietà). Quindi, potrei iniziare da una falsa ipotesi sin dall'inizio. Sembra che le persone che rispondono a questa domanda stiano forse dicendo che dovresti avere proprietà pubbliche e che quelle non hanno bisogno di getter e setter, il che va contro ciò che mi è stato insegnato e ciò di cui stavo parlando, anche se forse questo deve essere discusso come bene. Questo è probabilmente un buon argomento per una domanda diversa però ...

SOLUZIONE

Questo ha un potenziale di guerra religiosa, ma mi sembra che se stai usando un getter / setter, dovresti usarlo anche internamente - l'uso di entrambi porterà a problemi di manutenzione lungo la strada (ad esempio qualcuno aggiunge codice a un setter che deve essere eseguito ogni volta che viene impostata la proprietà e la proprietà viene impostata internamente senza quel setter chiamato).

Se ti va lasciaci una tua opinione

L'articolo ti è stato utile ed è tradotto correttamente?

ALTRI SUGGERIMENTI

Personalmente, penso che sia importante rimanere coerenti. Se hai getter e setter, usali. L'unica volta in cui accedevo direttamente a un campo è quando l'accessor ha molte spese generali. Potrebbe sembrare che stai gonfiando inutilmente il tuo codice, ma può sicuramente salvare un sacco di mal di testa in futuro. L'esempio classico:

In seguito, potresti voler cambiare il modo in cui quel campo funziona. Forse dovrebbe essere calcolato al volo o forse si desidera utilizzare un tipo diverso per il negozio di supporto. Se stai accedendo direttamente alle proprietà, una modifica del genere può interrompere un sacco di codice in un colpo solo.

Sono abbastanza sorpreso da quanto sia unanime il sentimento che getters e i setter stanno bene e bene. Suggerisco l'articolo incendiario di Allen Holub " Getters And Setters Are Evil " ;. Concesso, il titolo è per il valore di shock, ma l'autore fa punti validi.

In sostanza, se hai getter e setter per ogni campo privato, stai rendendo quei campi buoni come pubblici. Sarebbe molto difficile cambiare il tipo di campo privato senza effetti a catena in ogni classe che chiama quel getter .

Inoltre, da un punto di vista strettamente OO, gli oggetti dovrebbero rispondere ai messaggi (metodi) che corrispondono alla loro (si spera) unica responsabilità. La stragrande maggioranza dei getter e setter non ha senso per i loro oggetti costitutivi; Pen.dispenseInkOnto (Surface) per me ha più senso di Pen.getColor () .

Getter e setter incoraggiano anche gli utenti della classe a chiedere all'oggetto alcuni dati, eseguire un calcolo e quindi impostare un altro valore nell'oggetto, meglio noto come programmazione procedurale. Saresti meglio servito semplicemente a dire all'oggetto di fare quello che stavi per fare in primo luogo; noto anche come esperto di informazioni .

Getter e setter, tuttavia, sono mali necessari al limite dei livelli: UI, persistenza e così via. Accesso limitato agli interni di una classe, come la parola chiave friend di C ++, l'accesso protetto del pacchetto Java, l'accesso interno .NET e Modello di classe di amici può aiutarti a ridurre la visibilità di getters e dei setter solo a coloro che ne hanno bisogno.

Dipende da come viene utilizzata la proprietà. Ad esempio, supponiamo di avere un oggetto studente con una proprietà name. È possibile utilizzare il metodo Get per estrarre il nome dal database, se non è già stato recuperato. In questo modo si riducono le chiamate non necessarie al database.

Ora supponiamo che tu abbia un contatore intero privato nel tuo oggetto che conta il numero di volte che il nome è stato chiamato. È possibile che non si desideri utilizzare il metodo Get dall'interno perché produrrebbe un conteggio non valido.

PHP offre una miriade di modi per gestirlo, inclusi i metodi magici __get e __set , ma preferisco i getter e setter espliciti. Ecco perché:

  1. La convalida può essere inserita in setter (e getter per quella materia)
  2. Intellisense funziona con metodi espliciti
  3. Non c'è dubbio se una proprietà è di sola lettura, sola scrittura o lettura-scrittura
  4. Il recupero delle proprietà virtuali (ovvero i valori calcolati) è uguale alle proprietà normali
  5. Puoi facilmente impostare una proprietà dell'oggetto che in realtà non è mai definita da nessuna parte, che quindi non è documentata

  

Sto esagerando qui?

Forse;)

Un altro approccio sarebbe quello di utilizzare un metodo privato / protetto per eseguire effettivamente il get (memorizzazione nella cache / db / ecc.) e un wrapper pubblico che aumenti il ??conteggio:

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

e quindi dall'interno dell'oggetto stesso:

PHP:

$name = $this->_getName();

In questo modo puoi ancora usare quel primo argomento per qualcos'altro (come inviare un flag per usare o meno qui i dati memorizzati nella cache).

Devo mancare il punto qui, perché dovresti usare un getter all'interno di un oggetto per accedere a una proprietà di quell'oggetto?

Portando questo alla sua conclusione, il getter dovrebbe chiamare un getter, che dovrebbe chiamare un getter.

Quindi direi che all'interno di un metodo oggetto accedere direttamente a una proprietà, specialmente visto che chiamare un altro metodo in quell'oggetto (che accederà alla proprietà in ogni caso e poi lo restituirà) è solo un esercizio inutile e dispendioso (o ho frainteso la domanda).

Se di " purista " intendi "maggior parte dell'incapsulamento", quindi in genere dichiaro tutti i miei campi come privati ??e quindi uso this.field dall'interno della classe stessa, ma tutte le altre classi, comprese le sottoclassi, accedono allo stato dell'istanza utilizzando i getter.

Direi che è meglio usare i metodi di accesso anche all'interno dell'oggetto. Ecco i punti che mi vengono subito in mente:

1) Dovrebbe essere fatto nell'interesse di mantenere la coerenza con gli accessi effettuati al di fuori dell'oggetto.

2) In alcuni casi, questi metodi di accesso potrebbero fare di più che accedere semplicemente al campo; potrebbero fare qualche elaborazione aggiuntiva (è raro però). Se questo è il caso, accedendo direttamente al campo perderai quell'ulteriore elaborazione e il tuo programma potrebbe andare storto se questa elaborazione deve sempre essere eseguita durante tali accessi

Il modo OO purista è di evitare entrambi e seguire la Law of Demeter usando il Approccio Tell Don't Ask .

Invece di ottenere il valore della proprietà dell'oggetto, che accoppia strettamente le due classi, usa l'oggetto come parametro es.

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

Dove la proprietà era un tipo nativo, ad es. int, usa un metodo di accesso, chiamalo per dominio problematico e non per dominio di programmazione.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Questi ti permetteranno di mantenere l'incapsulamento e eventuali post-condizioni o invarianti dipendenti. Puoi anche usare il metodo setter per mantenere eventuali pre-condizioni o invarianti dipendenti, tuttavia non cadere nella trappola di nominare loro setter, torna al Principio di Hollywood per nominare quando usi il linguaggio.

ho scoperto che usare setter / getter ha reso il mio codice più facile da leggere. Mi piace anche il controllo che dà quando altre classi usano i metodi e se cambio i dati la proprietà memorizzerà.

Campi privati ??con proprietà pubbliche o protette. L'accesso ai valori deve passare attraverso le proprietà e deve essere copiato in una variabile locale se verranno utilizzati più di una volta in un metodo. Se e SOLO se hai il resto della tua applicazione così completamente ottimizzato, scartato e altrimenti ottimizzato per cui l'accesso ai valori passando attraverso le loro proprietà assosciate è diventato un collo di bottiglia (E che non accadrà mai MAI, ti garantisco) dovresti anche iniziare considerare di lasciare che qualcosa di diverso dalle proprietà tocchi direttamente le loro variabili di supporto.

Gli sviluppatori .NET possono utilizzare le proprietà automatiche per far rispettare questo dato che non è nemmeno possibile vedere le variabili di supporto in fase di progettazione.

Se non modificherò la proprietà userò un metodo pubblico get_property () a meno che non sia un'occasione speciale come un oggetto MySQLi all'interno di un altro oggetto, nel qual caso pubblicherò semplicemente il proprietà e fare riferimento ad essa come $ obj- > object_property .

All'interno dell'oggetto c'è sempre $ this- > proprietà per me.

Dipende. È più un problema di stile che altro, e non esiste una regola rigida.

Posso sbagliarmi perché sono autodidatta, ma non utilizzo MAI proprietà pubbliche nelle mie classi Java, sono sempre private o protette, in modo che il codice esterno debba accedere tramite getter / setter. È migliore per scopi di manutenzione / modifica. E per il codice di classe interna ... Se il metodo getter è banale, uso direttamente la proprietà, ma utilizzo sempre i metodi setter perché, se lo desidero, potrei facilmente aggiungere codice agli eventi di attivazione.

Bene, sembra con l'implementazione predefinita delle proprietà di C # 3.0, la decisione è presa per te; DEVI impostare la proprietà usando il setter proprietà (possibilmente privato).

Uso personalmente il membro privato dietro solo quando non lo farei causerebbe la caduta dell'oggetto in uno stato meno che desiderabile, ad esempio durante l'inizializzazione o quando è coinvolto il caricamento cache / lazy.

Mi piace la risposta di cmcculloh , ma sembra che la più corretta sia la risposta di Greg Hurlman . Usa getter / setter continuamente se hai iniziato a usarli da getgo e / o sei abituato a lavorare con loro.

A parte ciò, trovo personalmente che l'uso di getter / setter semplifica la lettura e il debug del codice in un secondo momento.

Come indicato in alcuni dei commenti: a volte dovresti, a volte non dovresti. La parte migliore delle variabili private è che sei in grado di vedere tutti i luoghi in cui vengono utilizzati quando cambi qualcosa. Se il tuo getter / setter fa qualcosa di cui hai bisogno, usalo. Se non importa, decidi.

Il caso contrario potrebbe essere che se usi il getter / setter e qualcuno cambia il getter / setter, devono analizzare tutti i luoghi in cui getter e setter vengono usati internamente per vedere se rovina qualcosa.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow