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

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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 ).