Hoe zou u toegang Object eigenschappen vanuit een object methode?

stemmen
81

Wat is de puristische of correct manier om toegang te krijgen tot eigenschappen van een object vanuit een object methode die is niet een getter / setter methode?

Ik weet dat van buiten het object moet u een getter / setter te gebruiken, maar van binnen uit zou je gewoon doen:

Java:

String property = this.property;

PHP:

$property = $this->property;

of zou u doen:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Vergeef me als mijn Java is een beetje uit, het is al een jaar geleden dat ik in Java geprogrammeerd ...

BEWERK:

Het lijkt erop dat mensen gaan ervan Ik heb het over een eigen of beschermde variabelen / alleen eigenschappen. Toen ik OO leerde werd mij geleerd om getters / setters gebruiken voor ieder afzonderlijk object, zelfs als het publiek was (en eigenlijk kreeg ik te horen nooit een variabele / onroerend goed openbaar te maken). Dus, kan ik worden wegrijden uit een verkeerde veronderstelling uit de slag te gaan. Het lijkt erop dat mensen de beantwoording van deze vraag misschien zeggen dat je publiek eigenschappen en dat deze niet getters en setters nodig zou moeten hebben, wat in strijd is wat ik werd onderwezen, en wat ik het over had, hoewel misschien dat moet worden besproken goed. Dat is waarschijnlijk een goed onderwerp voor een andere vraag maar ...

De vraag is gesteld op 01/08/2008 om 17:10
bron van user
In andere talen...                            


18 antwoorden

stemmen
58

Dit heeft godsdienstoorlog potentieel, maar het lijkt me dat als je gebruik maakt van een getter / setter, moet u het gebruiken ook intern - gebruik van beide zal leiden tot onderhoud problemen op de weg (bijvoorbeeld iemand voegt code om een setter die nodig elke keer dat eigenschap is ingesteld en de eigenschap wordt intern set w / o die setter wordt genoemd) draaien.

antwoordde op 01/08/2008 om 17:13
bron van user

stemmen
18

Het hangt af van hoe het onroerend goed wordt gebruikt. Stel bijvoorbeeld dat u een student object dat een naam eigenschap heeft. Je kon je Get methode gebruiken om de naam te trekken uit de database, als het nog niet is opgehaald. Op deze manier bent onnodige oproepen naar de database.

Laten we nu eens zeggen dat je een eigen integer teller in uw object, dat het aantal keren dat de naam is uitgeroepen telt. Misschien wilt u de Get methode niet gebruiken van binnen het object, omdat het een ongeldige telling zou produceren.

antwoordde op 01/08/2008 om 17:19
bron van user

stemmen
12

Ben ik gewoon overboord gaan hier?

Misschien;)

Een andere benadering zou zijn om een ​​private / beschermd methode te gebruiken om daadwerkelijk doen het krijgen van (caching / db / etc), en een openbare wrapper voor zorgen dat de telling verhoogt:

PHP:

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

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

en vanuit het object zelf:

PHP:

$name = $this->_getName();

Op deze manier kunt u nog steeds dat het eerste argument voor iets anders (zoals het verzenden van een vlag voor het al dan niet om gegevens in de cache hier misschien gebruikt).

antwoordde op 01/08/2008 om 17:43
bron van user

stemmen
5

Nou, het lijkt met de standaard uitvoering C # 3.0 eigenschappen, het besluit wordt genomen voor u; Je moet de eigenschap in te stellen met behulp van de (eventueel privé) onroerend setter.

Persoonlijk alleen de private-lid uitgelopen toen niet te doen zou veroorzaken het object vallen in een minder dan wenselijk toestand, bijvoorbeeld bij initialisatie of bij cache / afterloading betrokken.

antwoordde op 01/08/2008 om 17:56
bron van user

stemmen
4

Zoals vermeld in een aantal van de reacties: Soms moet je, soms moet je niet. Het grote deel over private variabelen is dat je in staat om alle plaatsen waar ze worden gebruikt wanneer u iets te veranderen te zien zijn. Als uw getter / setter iets wat je nodig hebt doet, gebruik het. Als het maakt niet uit u beslist.

Het tegenovergestelde geval zou kunnen worden gemaakt dat als je de getter / setter gebruiken en iemand verandert de getter / setter moeten ze alle plaatsen van de getter en setter wordt intern gebruikt om te zien of het iets verknoeit analyseren.

antwoordde op 01/08/2008 om 18:01
bron van user

stemmen
41

Persoonlijk heb ik het gevoel dat het belangrijk is om consistent te blijven. Als u getters en setters hebben, gebruik ze. De enige keer dat ik zou een veld rechtstreeks is wanneer de accessor heeft veel overhead. Het kan voelen als u uw code onnodig zijn opgeblazen gevoel, maar het kan zeker bespaart een heleboel hoofdpijn in de toekomst. Het klassieke voorbeeld:

Later, kunt u de wens om de wijze waarop het veld werkt veranderen. Misschien moet worden berekend on-the-fly of misschien wilt u een ander type te gebruiken voor de externe opslag. Als u direct toegang tot eigenschappen, kan een verandering als dat een heleboel code te breken in een deining FOOP.

antwoordde op 01/08/2008 om 19:23
bron van user

stemmen
6

Ik kan verkeerd zijn, want ik ben autodidact, maar ik heb nooit gebruiker publieke woningen in mijn Java-klassen, ze zijn altijd privé of beschermd, zodat buiten code moet openen door getters / setters. Het is beter voor onderhoud / wijziging doeleinden. En voor binnen klasse code ... Als getter methode is triviaal ik gebruik maken van de goederen die in rechtstreeks, maar ik gebruik altijd de setter methoden want ik kon gemakkelijk code toe te voegen aan gebeurtenissen ontslaan als ik wil.

antwoordde op 06/08/2008 om 15:43
bron van user

stemmen
6

ik heb gevonden met behulp van setters / getters maakte mijn code gemakkelijker te lezen. Ik hou ook van de controle die het geeft wanneer andere klassen van de methoden te gebruiken en als ik de data te veranderen het onroerend goed op te slaan.

antwoordde op 18/08/2008 om 18:37
bron van user

stemmen
6

Private velden met openbare of beschermde eigenschappen. Toegang tot de waarden moeten gaan door de eigenschappen en worden gekopieerd naar een lokale variabele als ze meer dan eens zullen worden gebruikt in een werkwijze. Indien en alleen als u de rest van uw aanvraag zo totaal getweaked, wiegde uit, en anders geoptimaliseerd naar de plaats waar de toegang tot de waarden door te gaan door middel van hun assosciated eigenschappen is uitgegroeid tot een knelpunt (En dat zal nooit gebeuren, ik garandeer) moet u zelfs beginnen te overwegen iets anders te laten zijn dan de eigenschappen rechtstreeks raken hun steun variabelen.

.NET ontwikkelaars kunnen automatische eigenschappen gebruiken om dit af te dwingen, omdat je de steun variabelen tijdens de ontwerpfase niet eens kan zien.

antwoordde op 18/08/2008 om 18:43
bron van user

stemmen
7

Als door "puristische" bedoel je "de meeste inkapseling", dan typisch verklaar ik al mijn velden als privé en gebruik vervolgens this.field van binnen de klasse zelf, maar alle andere klassen, met inbegrip van subklassen, toegang Zo staat het gebruik van de getters.

antwoordde op 22/08/2008 om 12:15
bron van user

stemmen
6

Als ik de woning niet zal wijzigen zal ik gebruik maken van een get_property()openbare methode tenzij het een speciale gelegenheid, zoals een MySQLi object in een ander object in dat geval zal ik gewoon publiek het pand en verwijzen naar het als $obj->object_property.

Binnen het object is het altijd $ this-> onroerend goed voor mij.

antwoordde op 22/08/2008 om 12:34
bron van user

stemmen
5

Ik hou van het antwoord van cmcculloh , maar het lijkt erop dat de meest correcte is het antwoord door Greg Hurlman . Gebruik getter / setters de hele tijd als je begonnen met hen uit de getgo en / of worden gebruikt voor het werken met hen.

Even terzijde, ik persoonlijk vind dat het gebruik van getter / setters maakt de code gemakkelijker te lezen en om later op te debuggen.

antwoordde op 15/09/2008 om 10:46
bron van user

stemmen
25

Ik ben vrij verbaasd over hoe unaniem het sentiment is dat gettersen setters zijn prima en goed. Ik stel voor de opruiende artikel van Allen Holub " getters en setters zijn Kwaad ". Toegegeven, de titel is voor shock waarde, maar de auteur maakt goede punten.

In wezen, als u gettersen settersvoor elke particuliere veld, bent u het maken van die gebieden zo goed als publiek. Je zou heel hard ingedrukt om het type van een privé-veld te veranderen zonder rimpel effecten voor elke klasse die dat vraagt getter.

Bovendien, vanuit een strikt OO oogpunt dient voorwerpen beantwoordingsoptie (werkwijzen) die overeenkomen met de (hopelijk) enkele verantwoordelijkheid. De overgrote meerderheid van gettersen settersniet zinvol voor de samenstellende objecten; Pen.dispenseInkOnto(Surface)heeft meer zin voor mij dan Pen.getColor().

Getters en setters ook aan te moedigen gebruikers van de klasse om het object te vragen voor een aantal data, het uitvoeren van een berekening, en vervolgens een andere waarde in het object, beter bekend als procedureel programmeren. Je zou beter worden bediend om gewoon het object te vertellen om te doen wat je zou gaan in de eerste plaats; ook wel bekend als de Information Expert idioom.

Getters en setters zijn echter noodzakelijk kwaad op de grens van lagen - UI, persistentie, enzovoort. Beperkte toegang tot interne onderdelen van een klasse, zoals C ++ 's vriend zoekwoord, Java's pakket beschermde toegang, interne toegang NET's, en de Vriend Class Pattern kan u helpen om de zichtbaarheid te verminderen gettersen setters om alleen degenen die ze nodig hebben.

antwoordde op 19/09/2008 om 01:13
bron van user

stemmen
7

De purist OO manier is om zowel te voorkomen en volg de Wet van Demeter met behulp van de Tell Do not Ask aanpak.

In plaats van het krijgen van de waarde van het vastgoed van het object, die strak koppels de twee klasse, gebruikt u het object als een parameter bv

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

Waar het pand was een inheemse soort, bijvoorbeeld int, gebruik maken van een toegang methode, de naam van het voor probleem domein niet de programmering domein.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Deze kunt u inkapseling en alle post-voorwaarden of afhankelijke invarianten te handhaven. U kunt ook de setter methode gebruiken om een ​​pre-voorwaarden of afhankelijke invarianten te behouden, maar niet in de val van het benoemen van hen setters vallen, ga terug naar de Hollywood Principe voor de naamgeving van het gebruik van het idioom.

antwoordde op 24/09/2008 om 18:04
bron van user

stemmen
13

PHP biedt een groot aantal manieren om dit, met inbegrip van magische methodes hanteren __geten __set, maar ik heb liever expliciete getters en setters. Dit is waarom:

  1. Validatie in setters worden geplaatst (en getters wat dat betreft)
  2. Intellisense werkt met expliciete methoden
  3. Geen vraag of een woning alleen lezen, schrijven alleen of read-write
  4. Ophalen virtuele eigenschappen (dat wil zeggen, berekende waarden) ziet er hetzelfde uit als gewone woningen
  5. U kunt eenvoudig een object eigenschap die eigenlijk nooit ergens is gedefinieerd, die vervolgens gaat ongedocumenteerde
antwoordde op 24/09/2008 om 18:24
bron van user

stemmen
6

Het hangt er van af. Het is meer een stijl kwestie dan iets anders, en er is geen harde regel.

antwoordde op 01/10/2008 om 11:51
bron van user

stemmen
7

zou ik het beter zeggen tegen de accessormethoden gebruiken, zelfs binnen het object. Hier zijn de punten die onmiddellijk komen naar mijn mening:

1) Er dient te worden gedaan in het belang van het behoud van samenhang met toegangen die buiten het object.

2) In sommige gevallen zijn deze accessormethoden kon worden meer dan alleen de toegang tot het gebied te doen; ze zouden kunnen doen wat extra processing (zijn zeldzame wel). Als dit het geval is, door de toegang tot het gebied direct je zou het missen erop dat extra verwerking en het programma mis zou kunnen gaan als deze verwerking is altijd om te doen tijdens die toegangen

antwoordde op 20/01/2010 om 09:32
bron van user

stemmen
11

Ik moet missen het punt hier, waarom zou je een getter te gebruiken binnen een object om toegang te krijgen tot een eigenschap van dat object?

Inname van deze ter afsluiting van het getter zou een getter noemen, die een getter moet bellen.

Dus ik zou zeggen dat binnen een methode object toegang tot een woning direct, vooral gezien als het aanroepen van een andere methode in dat object (die gewoon toegang tot de woning direct in ieder geval dan terug) ligt op slechts een zinloze, verspillende oefening (of heb ik de vraag verkeerd begrepen ).

antwoordde op 04/06/2011 om 16:42
bron van user

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