Hvordan vil du få tilgang Objektegenskaper innenfra et objekt metode?

stemmer
84

Hva er purist eller riktig måte å få tilgang til et objekt innenfra et objekt metode som ikke er en getter / setter metoden?

Jeg vet at fra utsiden av objektet bør du bruke en getter / setter, men innenfra vil du bare gjøre:

Java:

String property = this.property;

PHP:

$property = $this->property;

eller ville du gjøre:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Tilgi meg hvis min Java er litt utenfor, det har vært et år siden jeg programmert i Java ...

REDIGERE:

Det synes folk antar jeg snakker om private eller beskyttet variabler / eneste egenskapene. Da jeg lærte OO lærte jeg å bruke getters / settere for hver enkelt eiendom, selv om det var offentlig (og faktisk ble jeg fortalt aldri å gjøre noen variable / eiendom public). Så jeg kan starte ut fra en falsk forutsetning fra får gå. Det ser ut til at folk svarer på dette spørsmålet er kanskje å si at du bør ha offentlige eiendommer og at de ikke trenger kundeskaffere og settere, som går mot det jeg lærte, og hva jeg snakket om, men kanskje det må diskuteres som vi vil. Det er sannsynligvis et godt emne for et annet spørsmål om ...

Publisert på 01/08/2008 klokken 16:10
kilden bruker
På andre språk...                            


18 svar

stemmer
59

Dette har religiøs krig potensial, men det virker for meg at hvis du bruker en getter / setter, bør du bruke det internt så vel - å bruke både vil føre til vedlikehold problemer nedover veien (f.eks noen legger kode til en setter som trenger å kjøre hver gang at eiendommen ligger, og eiendommen blir satt internt w / o som setter bli kalt).

Svarte 01/08/2008 kl. 16:13
kilden bruker

stemmer
42

Personlig føler jeg at det er viktig å være konsekvent. Hvis du har kundeskaffere og settere, bruke dem. Den eneste gangen jeg ville få tilgang til et felt direkte er når tilbehør har mye overhead. Det kan føles som om du oppblåsthet koden unødvendig, men det kan sikkert spare en hel masse hodepine i fremtiden. Det klassiske eksempelet:

Senere på, kan du ønsker å endre måten dette feltet fungerer. Kanskje bør det beregnes on-the-fly, eller kanskje du ønsker å bruke en annen type for kompet butikken. Hvis du har tilgang eiendommer direkte, kan en endring som det bryte en forferdelig mye kode i en dønning foop.

Svarte 01/08/2008 kl. 18:23
kilden bruker

stemmer
25

Jeg er ganske overrasket over hvor enstemmig følelse er at gettersog settere er fine og gode. Jeg foreslår at brann artikkel av Allen Holub " Getters Og settere er onde ". Riktignok er tittelen for sjokk verdi, men forfatteren gjør gyldige poeng.

Egentlig, hvis du har gettersog settersfor hver og private felt, er du gjøre disse feltene så godt som publikum. Du vil bli veldig hardt presset til å endre type privat feltet uten ringvirkninger for hver klasse som kaller det getter.

Dessuten, fra et strengt OO synspunkt, bør gjenstandene være reagere på meldinger (metoder) som svarer til deres (forhåpentligvis) enkelt ansvar. De aller fleste getters, og settersikke gir mening for sine bestanddeler objekter; Pen.dispenseInkOnto(Surface)gjør mer fornuftig for meg enn Pen.getColor().

Kundeskaffere og settere også oppfordre brukere av klassen for å be objektet for noen data, utføre en beregning, og deretter sette en annen verdi i objektet, bedre kjent som prosedyreorientert programmering. Du ville være bedre tjent å bare fortelle objektet til å gjøre hva du skulle i første omgang; også kjent som Information Expert idiom.

Kundeskaffere og settere, men er nødvendige onder på grensen av lag - UI, utholdenhet, og så videre. Begrenset tilgang til klassens innvendige, for eksempel C ++ 's venn søkeord, Java pakken beskyttet tilgang, .NET interne tilgang, og Friend Class Pattern kan hjelpe deg å redusere synligheten av gettersog settere til bare de som trenger dem.

Svarte 19/09/2008 kl. 00:13
kilden bruker

stemmer
19

Det avhenger av hvordan eiendommen blir brukt. For eksempel si at du har en student objekt som har et navn eiendom. Du kan bruke din Get metode for å trekke navnet fra databasen, hvis det ikke har blitt hentet allerede. På denne måten reduserer unødvendige samtaler til databasen.

Nå la oss si du har en privat heltall telleren i objektet som teller hvor mange ganger navnet har blitt kalt. Det kan være lurt å ikke bruke GET-metoden fra innsiden av objektet, fordi det ville produsere en ugyldig teller.

Svarte 01/08/2008 kl. 16:19
kilden bruker

stemmer
13

PHP tilbyr en myriade av måter å håndtere dette, inkludert magiske metoder __getog __set, men jeg foretrekker eksplisitte kundeskaffere og settere. Her er hvorfor:

  1. Validering kan plasseres i settere (og getter for den saks skyld)
  2. IntelliSense fungerer med eksplisitte metoder
  3. Ingen tvil om en eiendom er skrivebeskyttet, skrive eller bare lese-skrive
  4. Hente virtuelle eiendommer (dvs. beregnet verdi) ser det samme som vanlige eiendommer
  5. Du kan enkelt sette et objekt eiendom som er aldri definert hvor som helst, som deretter går udokumentert
Svarte 24/09/2008 kl. 17:24
kilden bruker

stemmer
13

Er jeg bare gå over her?

Kanskje;)

En annen tilnærming ville være å utnytte en privat / beskyttet metode for å faktisk gjøre å få (caching / db / etc), og en offentlig wrapper for det som øker count:

PHP:

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

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

og deretter innenfra selve objektet:

PHP:

$name = $this->_getName();

På denne måten kan du fortsatt bruke det første argumentet for noe annet (som å sende et flagg for om det skal brukes bufrede data her kanskje).

Svarte 01/08/2008 kl. 16:43
kilden bruker

stemmer
11

Jeg må være mangler poenget her, hvorfor ville du bruke en getter inne i et objekt for å få tilgang til en eiendom som objekt?

Tar dette til sin konklusjon getter bør kalle en getter, som skal kalle en getter.

Så jeg vil si inne i et objekt metode tilgang til en eiendom direkte, spesielt ettersom ringer en annen metode i det objektet (som vil bare få tilgang til eiendommen direkte likevel deretter returnere det) er bare en meningsløs, bortkastet trening (eller har jeg misforstått spørsmålet ).

Svarte 04/06/2011 kl. 15:42
kilden bruker

stemmer
7

Jeg vil si det er bedre å bruke tilgangsmetoder selv i objektet. Her er de punktene som kommer til meg en gang:

1) Det bør gjøres i interesse av å opprettholde konsistens med aksesser gjort utenfor objektet.

2) I noen tilfeller kan disse tilgangsmetoder være å gjøre mer enn bare å få tilgang på marken; de kunne gjøre noen ytterligere behandling (sin sjeldne skjønt). Hvis dette er tilfelle, ved å gå til feltet direkte du ville gått glipp av at ytterligere behandling og programmet kan gå galt hvis dette behandling er alltid gjøres i løpet av disse tilganger

Svarte 20/01/2010 kl. 08:32
kilden bruker

stemmer
7

Purist OO måten er å unngå begge og følge lov av Demeter ved hjelp av tips Ikke spør tilnærming.

I stedet for å få verdien av objektet eiendom, som tett par de to klassen, bruker objektet som parameter f.eks

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

Hvor eiendommen var opprinnelig type, for eksempel int, bruker tilgangsmetode, navn det for problem domene ikke programmerings domene.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Disse vil tillate deg å opprettholde innkapsling og eventuelle etter forhold eller avhengige invarianter. Du kan også bruke den setter metoden for å opprettholde noen forutsetninger eller avhengige invarianter, men ikke falle i fellen med å navngi dem settere, gå tilbake til Hollywood Prinsipp for navngiving når du bruker uttrykk.

Svarte 24/09/2008 kl. 17:04
kilden bruker

stemmer
7

Hvis av "purist" du mener "mest innkapsling", så jeg vanligvis fortelle om alle mine felt som privat og deretter bruke this.field innenfra klassen selv, men alle andre klasser, inkludert underklasser, tilgang eksempel tilstand ved hjelp av getters.

Svarte 22/08/2008 kl. 11:15
kilden bruker

stemmer
6

Det kommer an på. Det er mer en stil problem enn noe annet, og det er ingen vanskelig regelen.

Svarte 01/10/2008 kl. 10:51
kilden bruker

stemmer
6

Hvis jeg ikke vil redigere egenskapen jeg kommer til å bruke en get_property()offentlig metode med mindre det er en spesiell anledning som en MySQLi objekt inne i et annet objekt i så fall vil jeg bare offentlig eiendom og refererer til det som $obj->object_property.

Inne i objektet det er alltid $ dette-> eiendom for meg.

Svarte 22/08/2008 kl. 11:34
kilden bruker

stemmer
6

Private felt med offentlige eller beskyttede egenskaper. Tilgang til verdiene bør gå gjennom eiendommene, og kopieres til en lokal variabel hvis de skal brukes mer enn én gang i en metode. Hvis og bare hvis du har resten av søknaden din så helt forskjøvet, rystet ut, og ellers optimalisert til der tilgang til verdiene ved å gå gjennom sine postbokskonto egenskaper har blitt en flaskehals (Og det vil aldri skje, jeg garantere) bør du begynner å vurdere å la noe annet enn egenskapene berøre sine backing variabler direkte.

NET utviklere kan bruke automatiske egenskaper for å håndheve denne siden du ikke kan selv se backing variabler på design tid.

Svarte 18/08/2008 kl. 17:43
kilden bruker

stemmer
6

Jeg har funnet ved hjelp settere / getters gjort min kode lettere å lese. Jeg liker også kontrollen det gir når andre klasser bruker metodene og hvis jeg endre dataene eiendommen vil lagre.

Svarte 18/08/2008 kl. 17:37
kilden bruker

stemmer
6

Jeg kan være galt fordi jeg er autodidakt, men jeg aldri bruker offentlige eiendommer i mine Java-klasser, de er alltid privat eller beskyttet, slik at utenfor koden må få tilgang til ved å kundeskaffere / settere. Det er bedre for vedlikehold / modifikasjons formål. Og for innvendig klassekoden ... Hvis getter metoden er trivielt jeg bruke eiendommen direkte, men jeg bruker alltid setter-metoder, fordi jeg lett kan legge til kode til brann hendelser hvis jeg ønsker det.

Svarte 06/08/2008 kl. 14:43
kilden bruker

stemmer
6

Vel, det virker med C # 3.0 eiendommenes standard implementering, beslutningen er tatt for deg; Du må sette eiendommen med (muligens privat) eiendom setter.

Jeg personlig bare bruke den private medlem-bak når ikke dette ville føre til at gjenstanden faller i en mindre enn ønskelig tilstand, slik som når det initialiseres eller når caching / lat lasting er involvert.

Svarte 01/08/2008 kl. 16:56
kilden bruker

stemmer
5

Jeg liker svaret ved cmcculloh , men det virker som den mest korrekte svaret ved Greg Hurlman . Bruk getter / settere hele tiden hvis du begynte å bruke dem fra getgo og / eller er vant til å jobbe med dem.

Som en side, jeg personlig synes at det å bruke getter / settere gjør koden lettere å lese og å feilsøke senere.

Svarte 15/09/2008 kl. 09:46
kilden bruker

stemmer
5

Som nevnt i noen av kommentarene: Noen ganger bør du, noen ganger du ikke burde. Den store delen om private variabler er at du er i stand til å se alle de stedene de brukes når du endrer noe. Hvis getter / setter gjør noe du trenger, kan du bruke den. Hvis det spiller ingen rolle du bestemmer deg.

Motsatt fall kunne gjøres at hvis du bruker getter / setter og noen forandrer getter / setter de har til å analysere alle steder det getter og setter brukes internt for å se om det søl noe opp.

Svarte 01/08/2008 kl. 17:01
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more