[java] member access modifier vraag.

[Alarmnummer]

Ik ben op dit moment wat aan het gochelen met mijn objecten en ben tegen het volgende probleem aangelopen. Stel dat ik een class fruit heb, en die heeft een int member gewicht. Deze maak ik protected. Als ik nu een nieuwe class Peer ga maken die extend van Fruit dan heeft hij ook geschikking over gewicht. Maar er is nu geen sprake meer van encapsulation. Je zou het kunnen oplossen met getters en setters (die wel protected zijn) en dan gewicht private maken. Maar is er ook en style guide voor dit soort zaken?

PS: ik heb al een aantal styleguides doorgelezen maar daar staat bitter weinig hierover in.

[tomato]

Wat heb je er aan om gewicht private te maken en dan protected getters en setters te gebruiken? Ga je in je class Peer dan weer public getters en setters maken die de super getters en setters gebruiken

[Alarmnummer]

Op dinsdag 29 januari 2002 13:11 schreef tomato het volgende:
Wat heb je er aan om gewicht private te maken en dan protected getters en setters te gebruiken? Ga je in je class Peer dan weer public getters en setters maken die de super getters en setters gebruiken

Misschien was mijn fruit voorbeeld wat slecht gekozen

even een beter voorbeeld bedenken

[ps] het gaat erom dat je door protected member access encapsulation verliest.

[ps2] buiten de classes om is er geen behoefte aan gewicht. Het is puur voor intern gebruik.

[Alarmnummer]

En ik zoek niet zozeer naar een adhoc oplossing want die is niet zo lastig. Ik zoek eigelijk een styleguide voor member access.

Een voorbeeld bedenken is knap lastig

[tomato]

Volgens mij zou je gewicht gewoon een protected int moeten maken. Afgeleide classes van Fruit zoals Peer hebben dan gewoon toegang tot gewicht net als de base class Fruit dat heeft. Volgens mij is hier niets mis mee.
Het lijkt me zelfs problemen geven wanneer je dit soort dingen private houdt en protected methods ervoor gaat maken. Van data encapsulation is imho zeker nog wel sprake, er is geen toegang tot gewicht buiten de class. Als gewicht ook niet toegankelijk zou moeten zijn in afgeleide classes had je net natuurlijk sowieso niet als protected aangeboden.

[Alarmnummer]

dat had ik zelf ook al bedacht maar het kan dus na verloop van tijd voorkomen dat je gewicht wel moet afschermen of dat je er bv een listener aan wilt plakken. Ipv 1 centrale plek waar je de bewerking doet (fruit) doe je het op meerdere plaatsen, appel peer etc etc.

Het is dus wel encapsulation in de zin dat objecten die niet afstammen van fruit er niet bijkunnen. Maar het is geen encapsulation binnen de fruit classes (zijn kinderen) zelf.

Ik heb eens een paar guide lines gezien en een van deze was dat je iedere member private moest maken en alleen protected mocht gebruiken in combinatie met final.

[tomato]

Ik heb nog even gekeken wat erover gezegd wordt in ons Java boekje:

Use of the Keyword Protected

[..] [heel verhaal, yada yada yada bla bla bla] [..]

For methods (and data) there are four types of access. In increasing constraint, they are public, protected, "default", and private:

• public - methods declared public are always visible. This is an ideal keyword for use in describing interfaces.
• protected - class methods declared as protected are visible to any class declared in the same package, as well as any extension to the class whether or not it is in the same package.
• "defaul" or "friendly" - class methods declared without any keyword are visible to any class declared in the same package, as well s any extension to the class whithin the same package.
• private - class methods are not visible outside of the class.

For our purposes it seems best to commit to one level of protection for the implementation: protected. What follows is an informal defense for that decision.

First, the use of public provides no control over the acces of methods and fields. [..] Make it public and they will use it. Even if you don't want them to.

The use of the private access control is far too restrictive. Suppose we are interested in constructing two types of lists - a SimpleList and an extension, a ComplexList. The SimpleList has a field, head, that references the first element of the list. Clearly, this field should be declared protected; manipulating the head of the list without going through a method is likely to put the list into an inconsistent state. Now, suppose that the ComplexList manipulates the list in a way that requires manipulating the head of the list in a manner not previously provided. Declaring head to be private makes it impossible for the ComplexList to access the field directly. We might be tempted to provide the access through a method of SimpleList, but we are then forced to restate the argument as it applies to methods. If, then, we are to have an effective extension of types, the private keyword cannot be the preferred method of access control.

If one uses the "default" access control, it is possible for any class inside, but not outside, the package to access the associated field. [..] If the concern is access to implementation information outside the package, the class should be declared final to indicate that extension is not allowed. [..] If extension is allowed, all extensions should have equal access.

What remains, then, is the use of the protected access control. [..] Since all extensions are provided equal access, extensions to the package are welcomed and are likely to occur.

[..]

For most purposes, the protected keyword is suitable. The reader should be aware, however, that its use here is not an adoption of an ideal, but an acceptance of what's available. In short, while Java is not perfect, it is a work in progress and we may reasonably expect improvements in iets access control.

Dat komt een beetje overeen met mijn vorige post dus, al komt dit verhaal me wat kortzichtig over (maar bedenk daarbij dat het hier ook alleen maar om Java voor Wiskundigen gaat ).

Alarmnummer: Ik heb eens een paar guide lines gezien en een van deze was dat je iedere member private moest maken en alleen protected mocht gebruiken in combinatie met final.

Dat is dus niet echt wat hier gezegd wordt

<edit>
De italics heb ik overigens gewoon overgenomen uit de tekst, niets zelf toegevoegd.
</edit>

[.oisyn]

hmmmz ik dacht eigenlijk dat geen access specifier hetzelfde was als protected, maar dat is niet zo volgens bovenstaande tekst... is dat altijd al zo geweest, of is dat een keer veranderd?

[tomato]

OiSyN: hmmmz ik dacht eigenlijk dat geen access specifier hetzelfde was als protected, maar dat is niet zo volgens bovenstaande tekst... is dat altijd al zo geweest, of is dat een keer veranderd?

Wat bedoel je precies? protected _is_ toch een access specifier

Classes kennen maar twee typen access: public en "default"
public classes zijn altijd zichtbaar, "default" classes alleen binnen dezelfde package. Is dat wat je bedoelde?

[Alarmnummer]

Ik zal eerst even laten zien wat ik bedoel.

code:

class Fruit {
   private int gewicht;

   protected int getGewicht(){
     return gewicht;
   }

   protected void setGewicht(int gewicht){
    this.gewicht = gewicht;
   }
}

Door de getter en setter heb je nu wel toegang tot gewicht zoals ook gewenst is. (Nog steeds ervan uitgaan dat alleen Fruit en zijn kinderen gewicht willen weten).

Maar als je nu maximaal gewicht zou willen registeren zou je in veel gevallen problemen krijgen omdat je geen common entrance point hebt. Hier zou het heel eenvoudig gaan:

code:

class Fruit {
   public static int _maxGewicht = 0;

   private int gewicht;

   protected int getGewicht(){
     return gewicht;
   }

   protected void setGewicht(int gewicht){
    this.gewicht = gewicht;

    if(gewicht<_maxGewicht){
        _maxGewicht=gewicht;
    }
   }
}

Dit is dus echte data encapsulation en werken met een protected data member niet.

PS _maxGewicht is wel in strijd met encapsulation maar het gaat even om het idee

[Alarmnummer]

De reden dat een final protected member is toegestaan, is dat deze waarde niet meer kan veranderen en je hier niet iets mee kan doen. Het enigste wat ik kan bedenken is dat je nu niet kan zie hoevaak je die member hebt uitgelezen

Daarom is een final protected member ook niet in strijd met encapsulation.

[.oisyn]

Op dinsdag 29 januari 2002 14:59 schreef tomato het volgende:

[..]

Wat bedoel je precies? protected _is_ toch een access specifier

Classes kennen maar twee typen access: public en "default"
public classes zijn altijd zichtbaar, "default" classes alleen binnen dezelfde package. Is dat wat je bedoelde?

wat ik bedoelde is dat ik dacht dat deze 2 statements hetzelfde waren:

code:

int var;
protected int var;

maw, wat ik dacht is dat als je er geen specifier voor staat dat het dan impliciet protected is. Maar als ik jouw verhaaltje lees is dat niet zo: protected members zijn toegankelijk vanuit klassen uit dezelfde package en subklassen, ongeacht of die in dezelfde package staan of niet

geen access-specifier is alleen toegankelijk voor klassen in dezelfde package, en niet vanuit sublkassen in een andere package

het verschil zit m dus in die subklassen

[Alarmnummer]

Op dinsdag 29 januari 2002 15:17 schreef OiSyN het volgende:
...

Jij bent ook al wakker je hebt gelijk.

Ik vind het trouwens wel jammer dat er geen access modifier private protected (heeft wel bestaan) of childrenOnly bestaat. Zodat alleen een object en zijn kinderen erbij kunnen komen en niet objecten uit dezelfde package. Ik heb het trouwens nog nooit voor dat doel misbruikt.

[tomato]

Alarmnummer: Ik vind het trouwens wel jammer dat er geen access modifier private protected (heeft wel bestaan) of childrenOnly bestaat. Zodat alleen een object en zijn kinderen erbij kunnen komen en niet objecten uit dezelfde package. Ik heb het trouwens nog nooit voor dat doel misbruikt.

Laatst had je het hier ook over. Ik kan me eigenlijk wel in je mening vinden, maar ook ik heb deze 'feature' van het protected keyword nooit misbruikt en denk niet dat ik het binnenkort ga doen

[.oisyn]

ja maar nou is mijn vraag nog steeds niet beantwoord (ja okee, is wel niet mijn topic, maar als ik zo brutaal mag zijn...)

is die protected specifier veranderd in de loop der tijd? en dan doel ik op dat van die subklassen buiten de package. Want als ik in mijn onbewuste geheugen graaf (die dingen die ik opvang terwijl ik helemaal niet op zit te letten), zie ik dat een docent ooit eens heeft gezegd dat niets (heeft dat geen naam? "niets" klinkt zo dubbelzinnig) hetzelfde was als protected, en dat het was voor alleen access binnen dezelfde package

in C++ is protected overigens gewoon alleen toegang voor subklassen (komt natuurlijk bij dat je daar geen packages hebt), en dat lijkt me nou het enige nuttige ervan

[Alarmnummer]

Op dinsdag 29 januari 2002 15:31 schreef OiSyN het volgende:
ja maar nou is mijn vraag nog steeds niet beantwoord (ja okee, is wel niet mijn topic, maar als ik zo brutaal mag zijn...)

Jij mag dat

is die protected specifier veranderd in de loop der tijd? en dan doel ik op dat van die subklassen buiten de package. Want als ik in mijn onbewuste geheugen graaf (die dingen die ik opvang terwijl ik helemaal niet op zit te letten), zie ik dat een docent ooit eens heeft gezegd dat niets (heeft dat geen naam? "niets" klinkt zo dubbelzinnig) hetzelfde was als protected,

je bedoelt 'default' access modifier. En hij is niet veranderd voor zover ik weet.

en dat het was voor alleen access binnen dezelfde package

met de default modifier kan iedereen in die package bij de member komen. Dus ook kinderen als ze in dezelde package zitten. Maar ook volledige andere objecten (als deze ook maar in dezelfde package zitten). Bij de protected geld dit ook, maar ook alle kinderen in andere packages kunnen erbij.

in C++ is protected overigens gewoon alleen toegang voor subklassen (komt natuurlijk bij dat je daar geen packages hebt), en dat lijkt me nou het enige nuttige ervan

Die mening deel ik met je. Ik snap ook niet dat ze niet nog een access modifier hebben toegevoegd: ThisAndChildrenOnly ofzo. (private protected staat ergens bij mij in een boek).

Misschien word het tijd om java weg te gooien en weer opnieuw te beginnen, Alarva

[edit]Klinkt wel vrij vies, alarva

[.oisyn]

hmmz...

ik zat meer te denken aan ois++

[Alarmnummer]

Ik heb een tijdje zitten zoeken naar Style Guides (die van sun is te matig) ben ik tegen een aantal aangelopen waarvan ik deze wel aardig vind:
http://www.ambysoft.com/javaCodingStandards.pdf

maar om zomaar iemand zijn style over te nemen. Ik gebruik liever een super standaars style. Wie weet hier iets voor?

[Alarmnummer]

Op dinsdag 29 januari 2002 15:52 schreef OiSyN het volgende:
hmmz...

ik zat meer te denken aan ois++

ois++ is alweer de verbeterde versie van ois??

[tomato]

Alarmnummer: ois++ is alweer de verbeterde versie van ois??

* tomato vraagt zich af hoeveel plusjes er nog nodig zijn voor een release

[.oisyn]

Op dinsdag 29 januari 2002 17:48 schreef tomato het volgende:

[..]

* tomato vraagt zich af hoeveel plusjes er nog nodig zijn voor een release

grrr
laten we het dan maar niet over jouw ondertitel gaan hebben

[tomato]

OiSyN: laten we het dan maar niet over jouw ondertitel gaan hebben

He rustig he
_{Maar toch wel beetje *LOL*}

</off-topic>

[tomato]

Alarmnummer: Ik heb een tijdje zitten zoeken naar Style Guides (die van sun is te matig) ben ik tegen een aantal aangelopen waarvan ik deze wel aardig vind:
http://www.ambysoft.com/javaCodingStandards.pdf

Hier wordt dus precies het tegenovergestelde gezegd. Deze meneer wil dat ik nooit een field protected maak, maar altijd access methods schrijf.

Heeft mbravenboer hier misschien nog iets over te zeggen?

[mbravenboer]

Ik vond het topic eerst te lang om door te lezen .

Ik maak variabelen nooit protected of public tenzij ze ook final zijn.

Protected variabelen vind ik onduidelijk en kunnen snel verwarring scheppen met een nieuwe variabele in een lagere klasse als je een specifieker type nodig hebt (komt vrij vaak voor). Liever dus alles private en get/setters gebruiken wat mij betreft.

Package access gebruik ik helemaal nooit. Je ziet regelmatig dat package access hele vervelende gevolgen heeft als je een alternatieve implementatie van iets in de standaard Java API (pas nog tegen gekomen). Heel vervelend dus.

[tomato]

mbravenboer: Ik maak variabelen nooit protected of public tenzij ze ook final zijn.

Je bent het dus duidelijk niet eens met het stukje tekst dat ik plaatste.

Package access gebruik ik ook nooit, ook omdat het me erg verwarrend lijkt te kunnen zijn.

[mbravenboer]

tomato: Je bent het dus duidelijk niet eens met het stukje tekst dat ik plaatste.

Na enig nalezen: : ik vind het niet percee incorrect of fout of wat dan ook, maar ik vind het zelf dus niet prettig werken. Ik gebruik liever protected accessors als je gegevens bekend wilt maken aan sub-classes. Je kunt zo altijd nog je interne opslag-methode aanpassen of iets verplaatsen naar een andere klasse. Ook vind ik het gewoon duidelijker.

Laat ik het over die style-guide die je poste maar helemaal niet hebben . Daar staat een hoop geblaat in wat naar mening helemaal nergens over gaat (althans: niet alle aspecten meeneemt). Work in progress klinkt ook erg stoer (alsof hij er bij hoort ) maar het is helemaal geen work in progress.

[Alarmnummer]

Weet jij een betere style guide staan?

[mbravenboer]

Alarmnummer: Weet jij een betere style guide te staan?

Refactoring: Improving the design of existing code (Martin Fowler) is de beste style-guide die ik ken .

(Dat bedoel ik dus echt heel erg serieus )

Verder gaan de meeste style-guides vooral over layout... dus dat schiet niet zo op.