Goede oefening bij het benaderen van een veld in een klas

Wanneer u een "lidvariabele"/veld in een klasse moet openen, is het dan een goede gewoonte om er rechtstreeks toegang toe te krijgen of om de getter en de setter te bellen? en waarom?

2
toegevoegd de auteur RCE, de bron

4 antwoord

Ik zie bijna alleen maar voordelen in het privé maken van je velden en alleen toegang bieden via een getter en mogelijk een setter

  • gecontroleerde toegang. Als u alleen leestoegang of alleen schrijftoegang wilt, kunt u dit alleen bereiken met behulp van getters/setters
  • als u PropertyChangeEvents wilt vuren voor bean-eigenschappen, kunt u deze code opnemen in uw setter. Anders zouden alle oproepen die dit veld direct wijzigen, ook een wijzigingsgebeurtenis moeten activeren
  • Ik vind het persoonlijk gemakkelijker om in mijn IDE te ontdekken wie het veld aanpast. De enige directe toegang tot het veld is in de klasse (aangezien het een privéveld is) en alle externe veranderingen gaan door de setter. Dit zorgt voor snellere foutopsporing dan het gebruik van een veldwatchpoint
  • subklassen die iets extra's willen doen wanneer de veldverandering de setter kan overschrijven, super.set kan aanroepen en iets extra's kan doen

Het enige mogelijke nadeel dat ik kan bedenken is dat het een beetje meer code vereist om te schrijven (voor de getters en setters), en een beetje meer code voor toegang tot het veld van buiten de klas. Maar met de huidige IDE's is dit een vrij zwak excuus

Some extra literature: link1, link2

3
toegevoegd

Bel de setter/getter in plaats van direct te gebruiken. Op die manier wordt elke extra vereiste code in de setter/getter uitgevoerd.

3
toegevoegd

Getter/Setter zorgt voor luie instantiatie, wat vaak een manier is om te gaan. Bovendien hebt u op deze manier een gecontroleerde toegang tot uw variabelen (zowel voor uzelf als als onderdeel van een API die u mogelijk wilt vrijgeven); mogelijkheid om de implementatie van initialisatie te verbergen enz. zijn ook erg belangrijk.

De grootste voordelen van S/G zijn naar mijn mening het risico dat iemand het zonder uw controle wijzigt. Een klein voorbeeld .. bedenk dat een getter u ... een kopie van het origineel kan geven in plaats van een origineel.

De voordelen zijn meervoudig, kies een setter/getter voor de voordelen van datakapseling en meer controle wanneer u een keuze krijgt.

2
toegevoegd

Als het een lid van de belklasse is, open het dan direct. Gebruik anders de methode getter/setter.

Waarom? Je zou geen getter/setter-methoden moeten maken, alleen maar zodat de bellende klasse toegang heeft tot zijn eigen leden. Anders moet u de methode voor de getter/setter gebruiken om redenen die door anderen zijn uitgewerkt.

0
toegevoegd