[OO] Ook accessors gebruiken binnen de klasse?

[TlighT]

Is het nou altijd beter om private fields via accessors aan te spreken, dus ook binnen de klasse zelf???

Wat ik bedoel, is het hier (<---)

code:

public class Employee
{
    private String name;

    public Employee(String name)
    {
      this.name = name; // <---
    }
    
    public String getName() {return name;}
}

beter om een (private) accessor te gebruiken? Het lijkt een beetje overkill soms en maakt kleine klasses wellicht overbodig ingewikkeld???

[Orphix]

Bedoel je de 'this.' ? Dat is in dit geval wel zo handig ja omdat de naam van je argument hetzelfde is als de member variabele. Ik zou dit vermijden door voor de argumenten andere namen te gebruiken.

Verder begrijp ik je vraag niet helemaal? Bedoel je soms getters/setters?

[Glimi]

Volgens mij bedoel je dat je this.name vervangt door setName( name ); begrijp ik dat goed?

Ik vind eigenlijk door het gebruik van een setter je je klasse er _te_ afhankelijk van maakt. Plus dat het weer een beetje tijd kost

[Verwijderd]

Ik neem aan TlighT een set() methode bedoelt. Ik zou dit niet aanraden voor kleinere objectjes, maar WEL voor grotere objecten, met meer 'state'.

Bijv. 'setName()' dat een Exception gooit als er een illegale String oid wordt meegegeven. In dit geval hoef je die logica maar 1x te implementeren.

[whoami]

Ik denk dat hij bedoelt om

code:

public Employee(String name)
{
  this.name = name;
}

te vervangen door:

code:

public Employee(String name)
{
  this.name = getName();
}

(Al zie ik het nut hiervan nu niet in in dit voorbeeld. Het is toch de bedoeling dat je in uw constructoor het doorgegeven argument asigned aan de member variable? Hoe kan je dan die getName() gaan gebruiken?
Je kan natuurlijk wel een setName() gaan gebruiken zoals Glimmi zegt maar die zie ik nergens in uw code, dus sta mij toe om een beetje verward te zijn. Hieruit kan ik opmaken dat mijn interpretatie van het topic toch niet helemaal juist is).

Ik gebruik zelf nooit getters/en setters binnen m'n class zelf. Waarom zou je?

[TlighT]

Op maandag 11 maart 2002 21:59 schreef Glimi het volgende:
Volgens mij bedoel je dat je this.name vervangt door setName( name ); begrijp ik dat goed?

Dat bedoel ik...

Ik vind eigenlijk door het gebruik van een setter je je klasse er _te_ afhankelijk van maakt. Plus dat het weer een beetje tijd kost

Ik had begrepen dat de meeste huidige compilers dit optimaliseren en er inline code van maken.

[whoami]

Het is toch juist de bedoeling van private members dat ze enkel accessable zijn binnen de class. Dus, waarom zou je botheren om daar nog eens setters/getters of properties rond te schrijven?
Ik zie daar echt het nut niet van in.

[Orphix]

Buiten de constructor je eigen setters/getters gebruiken is juist goed. Waarom zou je voor jezelf niet de implementatie willen verbergen en voor een gebruiker van je class wel?

Een taal als C++ kan veel setters/getters zodanig optimaliseren dat het gebruik ervan performance-gewijs gezien geen probleem vormt.

Stel nou dat je in een getter bv allerlei checks doet en excepties gooit, DAN kan het een beter idee zijn om ervoor te zorgen dat de waarden correct zijn en direct je variabelen aanspreken.

[Orphix]

Op maandag 11 maart 2002 22:06 schreef whoami het volgende:
Het is toch juist de bedoeling van private members dat ze enkel accessable zijn binnen de class. Dus, waarom zou je botheren om daar nog eens setters/getters of properties rond te schrijven?
Ik zie daar echt het nut niet van in.

Nee hoor private members zorgen ervoor dat een gebruiker van je class niet DIRECT de variabele aan kan spreken, dit gaat altijd via een tussen-laag, de functie.
Het voordeel is dat je deze tussen-laag later altijd nog kan veranderen terwijl de interface hetzelfde blijft. Bijvoorbeeld een extra check uitvoeren of iets run-time uitrekenen en dan pas teruggeven.

[whoami]

Op maandag 11 maart 2002 22:07 schreef Orphix het volgende:
Stel nou dat je in een getter bv allerlei checks doet en excepties gooit, DAN kan het een beter idee zijn om ervoor te zorgen dat de waarden correct zijn en direct je variabelen aanspreken.

Ok, in zo'n geval kan je die setters/getters gaan gebruiken. Maar als die getters niets anders doen dan een gewone assignement zie ik er het nut niet van in.

[Orphix]

Op maandag 11 maart 2002 22:09 schreef whoami het volgende:
Ok, in zo'n geval kan je die setters/getters gaan gebruiken. Maar als die getters niets anders doen dan een gewone assignement zie ik er het nut niet van in.

Het is een kleine moeite om zoiets te maken, en het voordeel is toch wel duidelijk imo. Tuurlijk is een rechtstreekse assignment niet 'nuttig' maar met het oog op de toekomst en hoe je klasse gaat evolueren is het handiger om met getters/setters te werken.

Dit is ook 1 van de redenen dat in .NET (iig met C#) met properties gewerkt kan worden. Dit biedt hetzelfde concept (bekend van bv de VCL) maar dan in de taal ingegoten. Voordeel van deze constructie is weer dat je eerst clienten de variabele direct kan laten aanspreken en indien je het nodig acht kan je alsnog de variabele als property beschouwen en de 'tussenlaag' er in programmeren. (De syntax van een variabele benaderen of een property is namelijk dezelfde)

[mbravenboer]

whoami: Ok, in zo'n geval kan je die setters/getters gaan gebruiken. Maar als die getters niets anders doen dan een gewone assignement zie ik er het nut niet van in.

Er is toch wel een groot voordeel. Het verbergen van variabelen die je om de concrete opslag van de variabele te verbergen en eventueel extra zaken te kunnen doen in get of set methoden. Dat is een voordeel voor de 'buitenwereld', maar het is het ook een voordeel voor jezelf.

Situatie 1:
Stel dat je op de sublieme gedacht komt dat je die variabele eigenlijk in een andere klasse had moeten stoppen, waarbij je in de huidige klasse een referentie naar een instantie van die nieuwe klasse bewaard.

Situatie 2:
Stel dat je bedenkt dat je eigenlijk een scheiding nodig hebt in voor- en achternaam. Je maakt hier dus twee verschillende variabelen van. De naam van de persoon is een samenvoeging van deze variabelen.

In beide gevallen ben je de lul als je direct van de oude variabele gebruik maakt. Je moet elk gebruik van die variabele omzetten naar de nieuwe methode. Als je getter of de setter had gebruikt, is er niets aan de hand: je past de getter of de setter aan aan de nieuwe situatie en je bent klaar...

In veel gevallen kan het dus toch wel erg zinvol zijn. In het algemeen zou ik zeggen: als je geen nadeel ziet, gebruik dan ook intern de getter of de setter.

[whoami]

Hmmm. Ik ga maar even voor de bijl. In die gevallen is een getter/setter idd wel handig.

[Glimi]

Op maandag 11 maart 2002 22:30 schreef whoami het volgende:
Hmmm. Ik ga maar even voor de bijl. In die gevallen is een getter/setter idd wel handig.

* Glimi is ook om. Ik zal morgen kijken of ik het een beetje kan benchen om te kijken of het nou een beetje verschil uitmaakt met een simpele set van één var

[curry684]

Op maandag 11 maart 2002 21:55 schreef Orphix het volgende:
Bedoel je de 'this.' ? Dat is in dit geval wel zo handig ja omdat de naam van je argument hetzelfde is als de member variabele. Ik zou dit vermijden door voor de argumenten andere namen te gebruiken.

Redelijk offtopic, maar hier zie je wel het voordeel van scope-prefixes:

code:

private String m_Name;

public Employee(String p_Name)
{
m_Name = p_Name;
}

[Bananeman]

Op maandag 11 maart 2002 22:22 schreef mbravenboer Ware Woorden

Hier ben ik het helemaal mee eens, en het is de exacte reden waarom ik ook binnen mijn eigen klasse de getters en setters gebruik. Snelheidsverlies kun je voorkomen door ze inline te maken. (ok, de compiler beslist dan nog steeds of ze ge-expand worden of niet, maar dat is even niet relevant. )

Het doel van getters en setters is zeker niet alleen om variabelen toegankelijk te maken, maar ook om bepaalde logica (afleiden van gegevens, bijvoorbeeld) op één plek vast te leggen.