push of pullen van optionele componenten?

[Jaap de Bergen]

Goedemorgen,

Ik zit een beetje te twijfelen tussen of ik nu moet pushen of pullen
in een bepaalde situatie.

Stel ik heb een pagina met daar op en formulier voor het veranderen
van een organisatie en daar onder een lijst met personen die voor de
organisatie werken.

Nu heb ik de rol "template ontwerper", ik maak dus templates. In m'n
context (hier zitten alle objecten in die ik als template ontwerper
kan gebruiken) zit een organisatie object met alle velden+waarden van
een organisatie. Deze gebruik ik om het formulier voor het veranderen
van een organisatie te vullen.

Nu zijn we aangekomen bij de lijst met personen. Hier zit het
discussie punt. In m'n context zit een object "Lijst" met oa een
functie getPersonenVanOrganisatie(String orgid), deze functie returnt
alle personen die in een bepaalde organisatie werken. Dit is dus
"pullen", je (template ontwerper) vraagt het systeem om data.

Maar je kunt ook pushen, het systeem zet de personen die in een
bepaalde organisatie zit in de context. De template ontwerper kan dan
meteen de personen uit de context halen en in een lijstje zetten.
Klaar is kees. Het systeem pusht dus de personen.

Mij lijkt dat pullen de voorkeur heeft omdat bij pushen het systeem
zich gaat bemoeien met de layout/indeling van de template.

Hoe denken jullie hierover?

mvg,


Jaap

[Jaap de Bergen]

On Mon, 02 Aug 2004 11:16:20 +0200, Jaap de Bergen
<DEBERGEN.COM@REMOVE_THIS_TO_EMAILdomainsbyproxy.co m> wrote:

>Goedemorgen,
>
>Ik zit een beetje te twijfelen tussen of ik nu moet pushen of pullen
>in een bepaalde situatie.
>
>Stel ik heb een pagina met daar op en formulier voor het veranderen
>van een organisatie en daar onder een lijst met personen die voor de
>organisatie werken.
>
>Nu heb ik de rol "template ontwerper", ik maak dus templates. In m'n
>context (hier zitten alle objecten in die ik als template ontwerper
>kan gebruiken) zit een organisatie object met alle velden+waarden van
>een organisatie. Deze gebruik ik om het formulier voor het veranderen
>van een organisatie te vullen.
>
>Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>discussie punt. In m'n context zit een object "Lijst" met oa een
>functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>alle personen die in een bepaalde organisatie werken. Dit is dus
>"pullen", je (template ontwerper) vraagt het systeem om data.
>
>Maar je kunt ook pushen, het systeem zet de personen die in een
>bepaalde organisatie zit in de context. De template ontwerper kan dan
>meteen de personen uit de context halen en in een lijstje zetten.
>Klaar is kees. Het systeem pusht dus de personen.
>
>Mij lijkt dat pullen de voorkeur heeft omdat bij pushen het systeem
>zich gaat bemoeien met de layout/indeling van de template.
>
>Hoe denken jullie hierover?
>

Oops ik heb iets te vlug op de post knop gedrukt. Toevoeging:
lijst met personen is optioneel, het kan ook een lijst met locaties of
een lijst met bijvoorbeeld urls zijn. Wat er in de lijst staat beslist
te template ontwerper.

Mogelijkheden:
1. template ontwerp geeft aan via http request parameter welke lijst
hij wil hebben van het systeem. Systeem leest de parameter uit en
stopt de goede lijst in de context. (pushen)
2. template ontwerper roept een functie aan (van een object die zich
in de context bevind) die de goede lijst terug geeft.



Jaap

[Michiel de Roo]

Jaap de Bergen wrote:
> Goedemorgen,
>
> Ik zit een beetje te twijfelen tussen of ik nu moet pushen of pullen
> in een bepaalde situatie.

Het antwoord op zo'n vraag is niet zomaar te geven, omdat het sterk
afhangt van het design van je totale systeem, de belasting van je
webserver en nog wel wat andere zaken. Ik wil echter wel proberen een zo
goed mogelij antwoord te geven.

>
> Stel ik heb een pagina met daar op en formulier voor het veranderen
> van een organisatie en daar onder een lijst met personen die voor de
> organisatie werken.
>
> Nu heb ik de rol "template ontwerper", ik maak dus templates. In m'n
> context (hier zitten alle objecten in die ik als template ontwerper
> kan gebruiken) zit een organisatie object met alle velden+waarden van
> een organisatie. Deze gebruik ik om het formulier voor het veranderen
> van een organisatie te vullen.
>
> Nu zijn we aangekomen bij de lijst met personen. Hier zit het
> discussie punt. In m'n context zit een object "Lijst" met oa een
> functie getPersonenVanOrganisatie(String orgid), deze functie returnt
> alle personen die in een bepaalde organisatie werken. Dit is dus
> "pullen", je (template ontwerper) vraagt het systeem om data.

Zo zou ik het nooit ontwerpen. Ik zou alleen een object Organisatie in
mijn context zetten, waar op zijn beurt weer een object Lijst in zit met
al die personen. Dit is voor mij een logischere plek om zulke gegevens op
te slaan. Deze lijst heeft bijvoorbeeld een functie load() waarmee de
juiste personen geladen worden.

Een push is in dat geval als het systeem de load() functie automatisch
aanroept, en een pull als de ontwerper eerst in zijn template aan moet
geven dat load() aangeroepen moet worden. Het verschil is gering, een pull
zou ik alleen gebruiken als het niet erg waarshcijnlijk is dat de
ontwerper de data ook echt gaat gebruiken.

>
> Maar je kunt ook pushen, het systeem zet de personen die in een
> bepaalde organisatie zit in de context. De template ontwerper kan dan
> meteen de personen uit de context halen en in een lijstje zetten.
> Klaar is kees. Het systeem pusht dus de personen.
>
> Mij lijkt dat pullen de voorkeur heeft omdat bij pushen het systeem
> zich gaat bemoeien met de layout/indeling van de template.

Niet met de layout, het syteem bepaalt alleen welke data er beschikbaar
is. Waar en of de ontwerper die data gebruikt is aan de ontwerper.

>
> Hoe denken jullie hierover?
>
> mvg,
>
>
> Jaap

[Michiel de Roo]

Jaap de Bergen wrote:
> On Mon, 02 Aug 2004 11:16:20 +0200, Jaap de Bergen
> <DEBERGEN.COM@REMOVE_THIS_TO_EMAILdomainsbyproxy.co m> wrote:
>
>
>>Goedemorgen,
>>
>>Ik zit een beetje te twijfelen tussen of ik nu moet pushen of pullen
>>in een bepaalde situatie.
>>
>>Stel ik heb een pagina met daar op en formulier voor het veranderen
>>van een organisatie en daar onder een lijst met personen die voor de
>>organisatie werken.
>>
>>Nu heb ik de rol "template ontwerper", ik maak dus templates. In m'n
>>context (hier zitten alle objecten in die ik als template ontwerper
>>kan gebruiken) zit een organisatie object met alle velden+waarden van
>>een organisatie. Deze gebruik ik om het formulier voor het veranderen
>>van een organisatie te vullen.
>>
>>Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>>discussie punt. In m'n context zit een object "Lijst" met oa een
>>functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>>alle personen die in een bepaalde organisatie werken. Dit is dus
>>"pullen", je (template ontwerper) vraagt het systeem om data.
>>
>>Maar je kunt ook pushen, het systeem zet de personen die in een
>>bepaalde organisatie zit in de context. De template ontwerper kan dan
>>meteen de personen uit de context halen en in een lijstje zetten.
>>Klaar is kees. Het systeem pusht dus de personen.
>>
>>Mij lijkt dat pullen de voorkeur heeft omdat bij pushen het systeem
>>zich gaat bemoeien met de layout/indeling van de template.
>>
>>Hoe denken jullie hierover?
>>
>
>
> Oops ik heb iets te vlug op de post knop gedrukt. Toevoeging:
> lijst met personen is optioneel, het kan ook een lijst met locaties of
> een lijst met bijvoorbeeld urls zijn. Wat er in de lijst staat beslist
> te template ontwerper.

Dat lijkt me een slecht idee. Het is beter om in het ontwerp van je
systeem al eenduidig aan te geven wat zo'n lijst moet gaan bevatten.
Eventueel stop je meerdere Lijst objecten in het Organisatie object. Maar
een en dezelfde Lijst hergebruiken voor verschillende doeleinden lijkt mij
niet erg handig.

dus bv.

class Organisatie
{
var $id;
var $personen;
var $urls;

function loadPersonen()
{
$this->personen = new PersonenLijst();
$this->personen->load(this->id);
}

function loadUrls()
{
$this->urls = new UrlLijst();
$this->urls->load(this->id);
}

}

class Lijst
{
//basale Lijst
}

class PersonenLijst extends Lijst
{
//sepcifiek voor personen
}

class UrlLijst extends Lijst
{
//sepcifiek voor urls
}

>
> Mogelijkheden:
> 1. template ontwerp geeft aan via http request parameter welke lijst
> hij wil hebben van het systeem. Systeem leest de parameter uit en
> stopt de goede lijst in de context. (pushen)
> 2. template ontwerper roept een functie aan (van een object die zich
> in de context bevind) die de goede lijst terug geeft.
>
>
>
> Jaap

[Jaap de Bergen]

On Tue, 03 Aug 2004 14:47:25 +0200, Michiel de Roo
<yourlove@welovespam.nl> wrote:


>>
>> Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>> discussie punt. In m'n context zit een object "Lijst" met oa een
>> functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>> alle personen die in een bepaalde organisatie werken. Dit is dus
>> "pullen", je (template ontwerper) vraagt het systeem om data.
>
>Zo zou ik het nooit ontwerpen. Ik zou alleen een object Organisatie in
>mijn context zetten, waar op zijn beurt weer een object Lijst in zit met
>al die personen. Dit is voor mij een logischere plek om zulke gegevens op
>te slaan. Deze lijst heeft bijvoorbeeld een functie load() waarmee de
>juiste personen geladen worden.
>
>Een push is in dat geval als het systeem de load() functie automatisch
>aanroept, en een pull als de ontwerper eerst in zijn template aan moet
>geven dat load() aangeroepen moet worden. Het verschil is gering, een pull
>zou ik alleen gebruiken als het niet erg waarshcijnlijk is dat de
>ontwerper de data ook echt gaat gebruiken.

Kijk dat is handig. De load() tip die niet direct alle relaties
ophaalt ga ik zeker implementeren.

Bedankt!


Jaap

[Jaap de Bergen]

On Tue, 03 Aug 2004 14:54:19 +0200, Michiel de Roo
<yourlove@welovespam.nl> wrote:

>Jaap de Bergen wrote:
>> On Mon, 02 Aug 2004 11:16:20 +0200, Jaap de Bergen
>> <DEBERGEN.COM@REMOVE_THIS_TO_EMAILdomainsbyproxy.co m> wrote:
>>
>>
>>>Goedemorgen,
>>>
>>>Ik zit een beetje te twijfelen tussen of ik nu moet pushen of pullen
>>>in een bepaalde situatie.
>>>
>>>Stel ik heb een pagina met daar op en formulier voor het veranderen
>>>van een organisatie en daar onder een lijst met personen die voor de
>>>organisatie werken.
>>>
>>>Nu heb ik de rol "template ontwerper", ik maak dus templates. In m'n
>>>context (hier zitten alle objecten in die ik als template ontwerper
>>>kan gebruiken) zit een organisatie object met alle velden+waarden van
>>>een organisatie. Deze gebruik ik om het formulier voor het veranderen
>>>van een organisatie te vullen.
>>>
>>>Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>>>discussie punt. In m'n context zit een object "Lijst" met oa een
>>>functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>>>alle personen die in een bepaalde organisatie werken. Dit is dus
>>>"pullen", je (template ontwerper) vraagt het systeem om data.
>>>
>>>Maar je kunt ook pushen, het systeem zet de personen die in een
>>>bepaalde organisatie zit in de context. De template ontwerper kan dan
>>>meteen de personen uit de context halen en in een lijstje zetten.
>>>Klaar is kees. Het systeem pusht dus de personen.
>>>
>>>Mij lijkt dat pullen de voorkeur heeft omdat bij pushen het systeem
>>>zich gaat bemoeien met de layout/indeling van de template.
>>>
>>>Hoe denken jullie hierover?
>>>
>>
>>
>> Oops ik heb iets te vlug op de post knop gedrukt. Toevoeging:
>> lijst met personen is optioneel, het kan ook een lijst met locaties of
>> een lijst met bijvoorbeeld urls zijn. Wat er in de lijst staat beslist
>> te template ontwerper.
>
>Dat lijkt me een slecht idee. Het is beter om in het ontwerp van je
>systeem al eenduidig aan te geven wat zo'n lijst moet gaan bevatten.
>Eventueel stop je meerdere Lijst objecten in het Organisatie object. Maar
>een en dezelfde Lijst hergebruiken voor verschillende doeleinden lijkt mij
>niet erg handig.
>
>dus bv.
>
>class Organisatie
>{
> var $id;
> var $personen;
> var $urls;
>
> function loadPersonen()
> {
> $this->personen = new PersonenLijst();
> $this->personen->load(this->id);
> }
>
> function loadUrls()
> {
> $this->urls = new UrlLijst();
> $this->urls->load(this->id);
> }
>
>}
>
>class Lijst
>{
> //basale Lijst
>}
>
>class PersonenLijst extends Lijst
>{
> //sepcifiek voor personen
>}
>
>class UrlLijst extends Lijst
>{
> //sepcifiek voor urls
>}

Het probleem was het feit dat de pagina bestond uit een verander
organisatie formulier en 2 tabjes (url's en personen). Ik wilde niet
direct de data voor de 2 tabjes beschikbaar maken, maar indien er een
tab geactiveerd werd een de data voor de geactiveerde tab laden. Nu
met de load() tip uit je vorige post (en de code hierboven) kan dat
;-)


Jaap

[F]

In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
> Jaap de Bergen wrote:
>> [..]
>> Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>> discussie punt. In m'n context zit een object "Lijst" met oa een
>> functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>> alle personen die in een bepaalde organisatie werken. Dit is dus
>> "pullen", je (template ontwerper) vraagt het systeem om data.
>
> Zo zou ik het nooit ontwerpen. Ik zou alleen een object Organisatie in
> mijn context zetten, waar op zijn beurt weer een object Lijst in zit met
> al die personen. Dit is voor mij een logischere plek om zulke gegevens op
> te slaan. Deze lijst heeft bijvoorbeeld een functie load() waarmee de
> juiste personen geladen worden.
>

Ingewikkeld allemaal.

Wrom niet gewoon een java-class met een static method
getPersonsByOrganization(String orgid)? Kun je dat gedoe met load() en
andere caching gewoon in die api regelelen en aangezien het gewoon
een static method is hoef je ook niet te rotzooien met Context-spul
of beans en al die meuk.

En als je die method gewoon een String array laat retourneren
hoef je ook geen PersonenLijst.java te gaan zitten maken.
Als je er dan ook nog even aan denkt om in geval van een lege lijst
niet null, maar een leeg array terug te geven ben je helemaal
klaar.

dat moeilijke gedoe altijd maar....

F

[Michiel de Roo]

F wrote:
> In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>Jaap de Bergen wrote:
>>
>>>[..]
>>>Nu zijn we aangekomen bij de lijst met personen. Hier zit het
>>>discussie punt. In m'n context zit een object "Lijst" met oa een
>>>functie getPersonenVanOrganisatie(String orgid), deze functie returnt
>>>alle personen die in een bepaalde organisatie werken. Dit is dus
>>>"pullen", je (template ontwerper) vraagt het systeem om data.
>>
>>Zo zou ik het nooit ontwerpen. Ik zou alleen een object Organisatie in
>>mijn context zetten, waar op zijn beurt weer een object Lijst in zit met
>>al die personen. Dit is voor mij een logischere plek om zulke gegevens op
>>te slaan. Deze lijst heeft bijvoorbeeld een functie load() waarmee de
>>juiste personen geladen worden.
>>
>
>
> Ingewikkeld allemaal.
>
> Wrom niet gewoon een java-class met een static method
> getPersonsByOrganization(String orgid)? Kun je dat gedoe met load() en
> andere caching gewoon in die api regelelen en aangezien het gewoon
> een static method is hoef je ook niet te rotzooien met Context-spul
> of beans en al die meuk.

Omdat dat een slecht functioneel ontwerp is. Static methoden gebruik je in
Java zowieso zelden tot nooit. Om ze te gaan gebruiken omdat je geen zin
hebt om de boel op een ordelijke en algemeen aanvaardde OOP manier op te
zetten is het begin van een uitermate slecht stuk software.

Waarom ga je met objecten werken ? En waarom met Java ? Maak er dan gewoon
een C of PHP programmaatje met alleen een paar functies en een berg
globals van. Daar doe je zaken op deze manier. Vanwege de problemen die
dat oplevert hebben ze Java, objecten en design patterns uitgevonden.

>
> En als je die method gewoon een String array laat retourneren
> hoef je ook geen PersonenLijst.java te gaan zitten maken.
> Als je er dan ook nog even aan denkt om in geval van een lege lijst
> niet null, maar een leeg array terug te geven ben je helemaal
> klaar.

Omdat je aan een String array geen methoden kunt toevoegen en de data
volledig onbeschermd is. Encapsulatie heet dat, en het is zo'n beetje de
basis van modern (>1995) programmeren.

Die array kan door elke programmeur die even niet oplet in een willekeurig
ander deel van de software om zeep geholpen worden, waarna er in elk
willekeurig ander deel van de software bugs kunnen optreden die moeilijk
terug te vinden zijn. Het PersonenLijst object daarentegen kun je in hoge
mate beschermen, waardoor de interne toestand van het object gegarandeerd
is, en nare bugs uitgesloten worden.

>
> dat moeilijke gedoe altijd maar....

Dat moeilijke gedoe zorgt voor de drie belangrijkste eigenschappen van
software: flexibility, maintainability en stability.

Neem eens een lesje Object Orientend Programmeren zou ik zeggen.

[F]

In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
> F wrote:
>>
>> Wrom niet gewoon een java-class met een static method
>> getPersonsByOrganization(String orgid)? Kun je dat gedoe met load() en
>> andere caching gewoon in die api regelelen en aangezien het gewoon
>> een static method is hoef je ook niet te rotzooien met Context-spul
>> of beans en al die meuk.
>
> Omdat dat een slecht functioneel ontwerp is. Static methoden gebruik je in
> Java zowieso zelden tot nooit. Om ze te gaan gebruiken omdat je geen zin
> hebt om de boel op een ordelijke en algemeen aanvaardde OOP manier op te
> zetten is het begin van een uitermate slecht stuk software.
>
Wat is er dan mis met static methods? Scheelt het instancieren van
een object.

> Waarom ga je met objecten werken ? En waarom met Java ? Maak er dan gewoon
> een C of PHP programmaatje met alleen een paar functies en een berg
> globals van. Daar doe je zaken op deze manier. Vanwege de problemen die
> dat oplevert hebben ze Java, objecten en design patterns uitgevonden.
>
Ok...globals leveren problemen op, maar ik heb ook niets over
globals gezegd. Over wat voor problemen heb je het hier dan?
En design patterns zijn niet uitgevonden om
problemen op te lossen, maar om namen te geven aan mechanismen
die je kunt inzetten om veelvoorkomende problemen met object
georienteerde talen op te lossen. Je zou zelfs kunnen zeggen
dat het bestaan van design patterns aangeeft dat object orientatie
niet zo geslaagd is: polymorphisme, encalsulatie e.d. zijn blijkbaar
niet genoeg, want er is ook behoefte aan decorators, visitors,
facades, singletons, noem maar op... Zo af en toe moet je
een hack toepassen omdat je in een oo-taal, veel mensen deden
dat, en toen heeft men die dingen 'gestandaardiseerd' in een
boekje.

(De boekjes over design patterns zijn eigenlijk de
datastructuren & algoritme boekjes van de OO-talen.)

Overigens zijn in aspect georienteerde talen weer veel
dingen bedacht om onder die design patterns uit te komen. :)

>>
>> En als je die method gewoon een String array laat retourneren
>> hoef je ook geen PersonenLijst.java te gaan zitten maken.
>> Als je er dan ook nog even aan denkt om in geval van een lege lijst
>> niet null, maar een leeg array terug te geven ben je helemaal
>> klaar.
>
> Omdat je aan een String array geen methoden kunt toevoegen en de data
> volledig onbeschermd is. Encapsulatie heet dat, en het is zo'n beetje de
> basis van modern (>1995) programmeren.
>
Klopt. Maarja...als je er een object van maakt en je wilt er een
veld bij hebben moet je zowel in je template (jsp?) als in
die java-class dingen gaan aanpassen. Als je een array met strings
gebruikt hoeft dat weer niet. De prijs die je betaalt voor
encapsulatie is dat je code moeilijker onderhoudbaar is. En wat
krijg je er voor terug? Dat een of andere boef direct een string
kan uitlezen? Zou ik me niet zo'n zorgen over maken.

Natuurlijk was dat string-array wel weer het andere uiterste
en natuurlijk kun je beter iets hebben dat ook nog eens controleert
op invoer etc.etc.. Maar mijn punt is meer dat je beter kunt voorkomen
dat je aan het eind tegen een enorme hoeveelheid struct-classes
(dat is overigens een AntiPattern) te aan te hikken en een
simpele wijziging leidt tot relatief veel code-wijzigingen.

Misschien is het veel mooier oom een generieke form-class
te maken...misschien zelfs wel eentje die erft van de
collection-api en waar je een reguliere expressie aan elk
veld kunt hangen, zodat de invoer gecontroleerd wordt.

> Die array kan door elke programmeur die even niet oplet in een willekeurig
> ander deel van de software om zeep geholpen worden, waarna er in elk
> willekeurig ander deel van de software bugs kunnen optreden die moeilijk
> terug te vinden zijn. Het PersonenLijst object daarentegen kun je in hoge
> mate beschermen, waardoor de interne toestand van het object gegarandeerd
> is, en nare bugs uitgesloten worden.
>
Correct. Maar het vereist meer inspanning die volgens mij niet
altijd opweegt tegen die zg. bescherming. Als het om bescherming
gaat moet je er ook duidelijk bij vermelden dat die PersonenLijst-class
final wordt! :)

Overigens..de class java.util.ArrayList encapsuleert de data
ook prima :)

>>
>> dat moeilijke gedoe altijd maar....
>
> Dat moeilijke gedoe zorgt voor de drie belangrijkste eigenschappen van
> software: flexibility, maintainability en stability.
>
Ach ja....
Dat zijn van die kreten uit software-engineering boekjes. Moet je
met een korrel zout nemen. Zo leidt teveel flexibiliteit weer
tot over-engineering en voor je het weet is het programmeerwerk
vervangen tot configuratiewerk. En wat maintainability betreft: hoe minder
code, hoe gemakkelijker het onderhoudbaar is. Toch?
En stability is natuurlijk een open deur....en het is ook weer
geen opzichzelfstaande eigenschap. Iets wat ononderhoudbaar is wordt
bijvoorbeeld instabiel als je het gaat wijzigen en iets wat
niet flexibel is waarschijnlijk zeer stabiel. :)

> Neem eens een lesje Object Orientend Programmeren zou ik zeggen.

ok.


grtz,

F.

[Michiel de Roo]

F wrote:
> In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>F wrote:
>>
>>>Wrom niet gewoon een java-class met een static method
>>>getPersonsByOrganization(String orgid)? Kun je dat gedoe met load() en
>>>andere caching gewoon in die api regelelen en aangezien het gewoon
>>>een static method is hoef je ook niet te rotzooien met Context-spul
>>>of beans en al die meuk.
>>
>>Omdat dat een slecht functioneel ontwerp is. Static methoden gebruik je in
>>Java zowieso zelden tot nooit. Om ze te gaan gebruiken omdat je geen zin
>>hebt om de boel op een ordelijke en algemeen aanvaardde OOP manier op te
>>zetten is het begin van een uitermate slecht stuk software.
>>
>
> Wat is er dan mis met static methods? Scheelt het instancieren van
> een object.
>
>
>>Waarom ga je met objecten werken ? En waarom met Java ? Maak er dan gewoon
>>een C of PHP programmaatje met alleen een paar functies en een berg
>>globals van. Daar doe je zaken op deze manier. Vanwege de problemen die
>>dat oplevert hebben ze Java, objecten en design patterns uitgevonden.
>>
>
> Ok...globals leveren problemen op, maar ik heb ook niets over
> globals gezegd. Over wat voor problemen heb je het hier dan?
> En design patterns zijn niet uitgevonden om
> problemen op te lossen, maar om namen te geven aan mechanismen
> die je kunt inzetten om veelvoorkomende problemen met object
> georienteerde talen op te lossen. Je zou zelfs kunnen zeggen
> dat het bestaan van design patterns aangeeft dat object orientatie
> niet zo geslaagd is: polymorphisme, encalsulatie e.d. zijn blijkbaar
> niet genoeg, want er is ook behoefte aan decorators, visitors,
> facades, singletons, noem maar op... Zo af en toe moet je
> een hack toepassen omdat je in een oo-taal, veel mensen deden
> dat, en toen heeft men die dingen 'gestandaardiseerd' in een
> boekje.

Als jij een design pattern ziet als een 'hack' in de OO-taal vanwege een
gebrek van zo'n taal, dan heb je er wel een hele vreemde visie op. Een
fiets is ook niet uitgevonden om het gebrek van het wiel op te lossen, al
zou je het zo kunnen zien natuurlijk.

>
> (De boekjes over design patterns zijn eigenlijk de
> datastructuren & algoritme boekjes van de OO-talen.)

Volgens mij zijn die datastructuren en algoritmen in een OO-taal nog
steeds van toepassing. Design patterns zijn daar eerder een aanvulling op.

>
> Overigens zijn in aspect georienteerde talen weer veel
> dingen bedacht om onder die design patterns uit te komen. :)

Maar niet vanwege een vermeend gebrek van design patterns of OOP t.o.v.
procedureel programmeren. Veel eerder vanwege het success van OOP,
waardoor het zin krijgt om het idee nog verder uit bouwen.

>
>
>>>En als je die method gewoon een String array laat retourneren
>>>hoef je ook geen PersonenLijst.java te gaan zitten maken.
>>>Als je er dan ook nog even aan denkt om in geval van een lege lijst
>>>niet null, maar een leeg array terug te geven ben je helemaal
>>>klaar.
>>
>>Omdat je aan een String array geen methoden kunt toevoegen en de data
>>volledig onbeschermd is. Encapsulatie heet dat, en het is zo'n beetje de
>>basis van modern (>1995) programmeren.
>>
>
> Klopt. Maarja...als je er een object van maakt en je wilt er een
> veld bij hebben moet je zowel in je template (jsp?) als in
> die java-class dingen gaan aanpassen. Als je een array met strings
> gebruikt hoeft dat weer niet. De prijs die je betaalt voor
> encapsulatie is dat je code moeilijker onderhoudbaar is. En wat
> krijg je er voor terug? Dat een of andere boef direct een string
> kan uitlezen? Zou ik me niet zo'n zorgen over maken.

Het gaat hoogstwaarschijnlijk niet om lezen maar om schrijven. Maar je
hebt inderdaad websites waarbij het bijvoorbeeld van de ingelogde user
afhangt of die een stuk data (creditcard-nummer?) mag lezen of niet. Dit
kun je bij een object mooi op laag niveau afschermen. Bij een string niet.

>
> Natuurlijk was dat string-array wel weer het andere uiterste
> en natuurlijk kun je beter iets hebben dat ook nog eens controleert
> op invoer etc.etc.. Maar mijn punt is meer dat je beter kunt voorkomen
> dat je aan het eind tegen een enorme hoeveelheid struct-classes
> (dat is overigens een AntiPattern) te aan te hikken en een
> simpele wijziging leidt tot relatief veel code-wijzigingen.
>
> Misschien is het veel mooier oom een generieke form-class
> te maken...misschien zelfs wel eentje die erft van de
> collection-api en waar je een reguliere expressie aan elk
> veld kunt hangen, zodat de invoer gecontroleerd wordt.

Je begint je verhaal met de stelling dat al die objecten maar onzin zijn,
om te eindigen met de stelling dat het toch wel mooi zou zijn om met
objecten te werken.

>
>
>>Die array kan door elke programmeur die even niet oplet in een willekeurig
>>ander deel van de software om zeep geholpen worden, waarna er in elk
>>willekeurig ander deel van de software bugs kunnen optreden die moeilijk
>>terug te vinden zijn. Het PersonenLijst object daarentegen kun je in hoge
>>mate beschermen, waardoor de interne toestand van het object gegarandeerd
>>is, en nare bugs uitgesloten worden.
>>
>
> Correct. Maar het vereist meer inspanning die volgens mij niet
> altijd opweegt tegen die zg. bescherming. Als het om bescherming
> gaat moet je er ook duidelijk bij vermelden dat die PersonenLijst-class
> final wordt! :)

Niks geldt altijd. Als je een scriptje van twintig regels schrijft wat je
verder nooi meer gaat gebruiken, dan geldt het hoogstwaarschijnlijk niet.
De OP gaf al aan dat het niet om zoiets ging.

>
> Overigens..de class java.util.ArrayList encapsuleert de data
> ook prima :)

Tot op bepaalde hoogte, ondat het een object is. Het bewijst dus mijn
stelling en niet de jouwe.

>
>
>>>dat moeilijke gedoe altijd maar....
>>
>>Dat moeilijke gedoe zorgt voor de drie belangrijkste eigenschappen van
>>software: flexibility, maintainability en stability.
>>
>
> Ach ja....
> Dat zijn van die kreten uit software-engineering boekjes. Moet je
> met een korrel zout nemen.

Of je neemt ze serieus. Ik doe meestal het laatste.

> Zo leidt teveel flexibiliteit weer
> tot over-engineering en voor je het weet is het programmeerwerk
> vervangen tot configuratiewerk.

Klopt. Je moet de juiste balans vinden.

> En wat maintainability betreft: hoe minder
> code, hoe gemakkelijker het onderhoudbaar is. Toch?

Nee. Hoe makkelijker je iets terug kan vinden en hoe duidelijker en
herkenbaarder (voor een ander) je iets opgeschreven hebt, hoe makkelijker
onderhoudbaar. Ik heb liever twintig regels heldere code dan tien regels
spaghetti waarvan ik zelf morgen al niet meer weet wat ik aan het doen
was, laat staan een ander.

> En stability is natuurlijk een open deur....en het is ook weer
> geen opzichzelfstaande eigenschap. Iets wat ononderhoudbaar is wordt
> bijvoorbeeld instabiel als je het gaat wijzigen en iets wat
> niet flexibel is waarschijnlijk zeer stabiel. :)

Als je je functionaliteit goed afschermt kun je doelgericht testen en
debuggen. Dan kun je ook garanderen dat je wijzigingen geen gevolgen
hebben voor de rest van je code.

Je kunt ook op een OO manier slecht programmeren, dat klopt. Dat betekent
echter niet dat OOP daarom slecht is. Als je het goed gebruikt kan het je
wel helpen deze deze zaken te bereiken.

Groeten, Michiel.

[F]

In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
> [knip]
> Als jij een design pattern ziet als een 'hack' in de OO-taal vanwege een
> gebrek van zo'n taal, dan heb je er wel een hele vreemde visie op. Een
> fiets is ook niet uitgevonden om het gebrek van het wiel op te lossen, al
> zou je het zo kunnen zien natuurlijk.
>
Neem bijvoorbeeld een singleton, als we het toch over static methods
hebben...Soms zijn static methods niet handig, maar wil je toch dat
deze 'leven' in een object, maar je wilt ook weer niet dat er
meerdere instances zijn. OO-talen voorzien hier niet in dus
moet er een truc worden uitgehaald. Bij een procedurele of
functionele taal speelt dit hele probleem niet en dus
moet er voor een OO-taal een truc worden uitgehaald. In
volgende generaties talen worden bepaalde patterns wellicht
onderdeel van de taal.
In die zin is het dus een work-around voor een onvolkomenheid
van een systeem, een 'hack' zo je wilt.

>>
>> (De boekjes over design patterns zijn eigenlijk de
>> datastructuren & algoritme boekjes van de OO-talen.)
>
> Volgens mij zijn die datastructuren en algoritmen in een OO-taal nog
> steeds van toepassing. Design patterns zijn daar eerder een aanvulling op.
>
>>
>> Overigens zijn in aspect georienteerde talen weer veel
>> dingen bedacht om onder die design patterns uit te komen. :)
>
> Maar niet vanwege een vermeend gebrek van design patterns of OOP t.o.v.
> procedureel programmeren. Veel eerder vanwege het success van OOP,
> waardoor het zin krijgt om het idee nog verder uit bouwen.
>
Eh....dat ben ik niet helemaal met je eens. Een aspect doorkruist
juist een hele object-hierarchie, er wordt een extra dimensie
toegevoegd en dat vanwege het feit dat dit gewoon handig is en
niet kan met een OO-taal.
>>
>> Natuurlijk was dat string-array wel weer het andere uiterste
>> en natuurlijk kun je beter iets hebben dat ook nog eens controleert
>> op invoer etc.etc.. Maar mijn punt is meer dat je beter kunt voorkomen
>> dat je aan het eind tegen een enorme hoeveelheid struct-classes
>> (dat is overigens een AntiPattern) te aan te hikken en een
>> simpele wijziging leidt tot relatief veel code-wijzigingen.
>>
>> Misschien is het veel mooier oom een generieke form-class
>> te maken...misschien zelfs wel eentje die erft van de
>> collection-api en waar je een reguliere expressie aan elk
>> veld kunt hangen, zodat de invoer gecontroleerd wordt.
>
> Je begint je verhaal met de stelling dat al die objecten maar onzin zijn,
> om te eindigen met de stelling dat het toch wel mooi zou zijn om met
> objecten te werken.
>
Dat gaf ik al aan, toch? Die string-array was de meest simpele
oplossing met alle nadelen vandien, nadelen die je zelf al
opnoemde. Een class 'PersonenLijst' is juist weer heel specifiek
en dat is niet altijd handig. Implementeer bij wijze van spreken
een DingenLijst waarin zowel personen als ook credit card gegevens
in kunnen. Het doel is namelijk verwerking van ingevoerde data
op het scherm en dus maar je daar een class voor. Dat is toch
niet raar?
>>
>>
>>>Die array kan door elke programmeur die even niet oplet in een willekeurig
>>>ander deel van de software om zeep geholpen worden, waarna er in elk
>>>willekeurig ander deel van de software bugs kunnen optreden die moeilijk
>>>terug te vinden zijn. Het PersonenLijst object daarentegen kun je in hoge
>>>mate beschermen, waardoor de interne toestand van het object gegarandeerd
>>>is, en nare bugs uitgesloten worden.
>>>
>>
>> Correct. Maar het vereist meer inspanning die volgens mij niet
>> altijd opweegt tegen die zg. bescherming. Als het om bescherming
>> gaat moet je er ook duidelijk bij vermelden dat die PersonenLijst-class
>> final wordt! :)
>
> Niks geldt altijd. Als je een scriptje van twintig regels schrijft wat je
> verder nooi meer gaat gebruiken, dan geldt het hoogstwaarschijnlijk niet.
> De OP gaf al aan dat het niet om zoiets ging.
>
>>
>> Overigens..de class java.util.ArrayList encapsuleert de data
>> ook prima :)
>
> Tot op bepaalde hoogte, ondat het een object is. Het bewijst dus mijn
> stelling en niet de jouwe.
>
Ja, tjeempie. :)

Dan moet ik nu dus weer roepen dat die PersonenLijst overbodig is,
omdat je net zo goed een ArrayList kunt gebruiken omdat die ook
de data encapsuleert en dan kun jij weer zeggen dat die ArrayList
te algemeen is etc.etc. :)

Kunnen we nog wel langer doorgaan, terwijl we eigenlijk gewoon
op een lijn zitten wat dit betreft.

Mijn punt is alleen dat je voorzichtig moet zijn met het
in het leven roepen van allerlei hele specifieke classes, zoals
'PersonenLijst'. Maak dan een class Persoon en gooi die vervolgens
in een ArrayList o.i.d. en je hebt een lijst.

>
>> Zo leidt teveel flexibiliteit weer
>> tot over-engineering en voor je het weet is het programmeerwerk
>> vervangen tot configuratiewerk.
>
> Klopt. Je moet de juiste balans vinden.
>
Dat is het punt en ik ben een beetje huiverig voor classes
als 'PersonenLijst' die eigenlijk niets toevoegen. Straks wil
je je scherm uitbreiden en dan moet je eigenlijk
een HuisdierenLijst gaan maken, terwijl je eigenlijk een
DingenLijst hebt en dan gebruik je gewoon een List, Set of Map.

Op het moment dat je dit soort dilemma's tegenkomt is het vaak
tijd om dingen te refactoren om bloat te voorkomen.

>> En wat maintainability betreft: hoe minder
>> code, hoe gemakkelijker het onderhoudbaar is. Toch?
>
> Nee. Hoe makkelijker je iets terug kan vinden en hoe duidelijker en
> herkenbaarder (voor een ander) je iets opgeschreven hebt, hoe makkelijker
> onderhoudbaar. Ik heb liever twintig regels heldere code dan tien regels
> spaghetti waarvan ik zelf morgen al niet meer weet wat ik aan het doen
> was, laat staan een ander.
>
Maar nu heb je het over code-stijl. In de trant van return a?b:c; i.p.v.
if (a) return b; return c; en dan is dat laatste vaak leesbaarder.
Wat ik meer bedoelde is dat je moet voorkomen dat je een systeem
hebt met bijv. jsp's waarin een submit-actie van een form niet
in 1 of 2 stappen leidt tot de functie die uiteindelijk wordt aangeroepen,
maar dat er allerlei gelaagdheid ontstaat waardoor je ineens 6 editors
open moet hebben om te kijken waar er iets wordt uitgevoerd, omdat
je een simpele aanpassing moet maken.

Dit probleem is exact hetzelfde probleem als het verschuiven van
je problematiek naar configuratie, omdat je een te generiek framework
hebt gemaakt met teveel laagjes. Denk aan struts enzo.


>> En stability is natuurlijk een open deur....en het is ook weer
>> geen opzichzelfstaande eigenschap. Iets wat ononderhoudbaar is wordt
>> bijvoorbeeld instabiel als je het gaat wijzigen en iets wat
>> niet flexibel is waarschijnlijk zeer stabiel. :)
>
> Als je je functionaliteit goed afschermt kun je doelgericht testen en
> debuggen. Dan kun je ook garanderen dat je wijzigingen geen gevolgen
> hebben voor de rest van je code.
>
Nou heb ik mezelf klemgepraat :) Hoewel het natuurlijk niet
automatisch zo is (door de gelaagdheid en afscherming) dat je
garandeert dat je aanpassingen kunt maken zonder gevolgen in de rest.
Voor je het weet exploiteert een bepaalde component de bug van
een ander component, maar dat heb je altijd...

> Je kunt ook op een OO manier slecht programmeren, dat klopt. Dat betekent
> echter niet dat OOP daarom slecht is. Als je het goed gebruikt kan het je
> wel helpen deze deze zaken te bereiken.
>
Je doelt op C++ programmeren a la C met classes in plaats van
mooie dingen met inheritance en de C++ libraries gebruiken in plaats
van stiekum toch gewoon malloc en free gebruiken i.p.v. new en delete....

Soms is dat laatste wel een stuk handiger, hoor :) Ik geef toe, in
C++ maak ik ook gewoon een linked list met pointers i.p.v. een
fancy mechanisme met objecten. Misschien dat dit de reden is
dat ik - als ik wat in java maak - ook niet begin met allerlei
lege objecten met getters en setters en daarna de dingen aanelkaar
knoop :)


groet,
F

[Michiel de Roo]

F wrote:
> In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>[knip]
>>Als jij een design pattern ziet als een 'hack' in de OO-taal vanwege een
>>gebrek van zo'n taal, dan heb je er wel een hele vreemde visie op. Een
>>fiets is ook niet uitgevonden om het gebrek van het wiel op te lossen, al
>>zou je het zo kunnen zien natuurlijk.
>>
>
> Neem bijvoorbeeld een singleton, als we het toch over static methods
> hebben...Soms zijn static methods niet handig, maar wil je toch dat
> deze 'leven' in een object, maar je wilt ook weer niet dat er
> meerdere instances zijn. OO-talen voorzien hier niet in dus
> moet er een truc worden uitgehaald. Bij een procedurele of
> functionele taal speelt dit hele probleem niet en dus
> moet er voor een OO-taal een truc worden uitgehaald. In
> volgende generaties talen worden bepaalde patterns wellicht
> onderdeel van de taal.
> In die zin is het dus een work-around voor een onvolkomenheid
> van een systeem, een 'hack' zo je wilt.

Ik zie een singleton toch niet als een hack, het is gewoon een van de vele
patterns. De singleton is inderdaad static, maar dat neemt niet weg dat
static methoden in zijn algemeenheid niet zo veel voorkomen. Een singleton
pattern gebruik ik ook zelden trouwens. Natuurlijk is een static methode
soms noodzakelijk, anders zou het ook zeker niet in Java zitten. Maar ik
gebruik het alleen als ik het niet anders kan oplossen.

>
>
>>>(De boekjes over design patterns zijn eigenlijk de
>>>datastructuren & algoritme boekjes van de OO-talen.)
>>
>>Volgens mij zijn die datastructuren en algoritmen in een OO-taal nog
>>steeds van toepassing. Design patterns zijn daar eerder een aanvulling op.
>>
>>
>>>Overigens zijn in aspect georienteerde talen weer veel
>>>dingen bedacht om onder die design patterns uit te komen. :)
>>
>>Maar niet vanwege een vermeend gebrek van design patterns of OOP t.o.v.
>>procedureel programmeren. Veel eerder vanwege het success van OOP,
>>waardoor het zin krijgt om het idee nog verder uit bouwen.
>>
>
> Eh....dat ben ik niet helemaal met je eens. Een aspect doorkruist
> juist een hele object-hierarchie, er wordt een extra dimensie
> toegevoegd en dat vanwege het feit dat dit gewoon handig is en
> niet kan met een OO-taal.

OO is ook niet perfekt. Maar in de meeste gevallen wel beter dan
procedureel. AO is wellicht nog beter. Ik heb weinig ervaring met AO.

>
>>>Natuurlijk was dat string-array wel weer het andere uiterste
>>>en natuurlijk kun je beter iets hebben dat ook nog eens controleert
>>>op invoer etc.etc.. Maar mijn punt is meer dat je beter kunt voorkomen
>>>dat je aan het eind tegen een enorme hoeveelheid struct-classes
>>>(dat is overigens een AntiPattern) te aan te hikken en een
>>>simpele wijziging leidt tot relatief veel code-wijzigingen.
>>>
>>>Misschien is het veel mooier oom een generieke form-class
>>>te maken...misschien zelfs wel eentje die erft van de
>>>collection-api en waar je een reguliere expressie aan elk
>>>veld kunt hangen, zodat de invoer gecontroleerd wordt.
>>
>>Je begint je verhaal met de stelling dat al die objecten maar onzin zijn,
>>om te eindigen met de stelling dat het toch wel mooi zou zijn om met
>>objecten te werken.
>>
>
> Dat gaf ik al aan, toch? Die string-array was de meest simpele
> oplossing met alle nadelen vandien, nadelen die je zelf al
> opnoemde. Een class 'PersonenLijst' is juist weer heel specifiek
> en dat is niet altijd handig.

Klopt, je gaat ook geen class Jantje of Pietje maken, maar gewoon een
class Persoon. In de context van de vraag van OP vond ik het echter wel
handig. Iig. beter dan een Lijst object hanteren waar om het even
Personen, Url's of weet ik niet wat in zit. Bovendien kan zo'n specifieke
PersonenLijst de implementatie van het laden van de objecten die erin
zitten afschermen, dmv de load() functie. Die implementatie is voor
Personen geheel anders dan voor Url's, dus dat rechtvaardigt aparte klassen.

> Implementeer bij wijze van spreken
> een DingenLijst waarin zowel personen als ook credit card gegevens
> in kunnen.

Nee, dat is niet eenduidig. Je zult dan op een ander punt elke keer weer
moeten gaan kijken wat er nou precies in die Lijst zit. Je kunt dit wel
ondervangen door de specifieke inhoud van de lijst zelf weer als meta-data
in die lijst te stoppen, maar dat heeft alleen zijn als je heel veel
verschillende soorten Lijsten wilt maken in een totaal generiek systeem.
De hoeveelheid meerwerk die dit oplevert is ook behoorlijk groot.
Bovendien is het minder begrijpelijk.

Daarnaast dienen credit card gegevens op een andere manier afgeschermd te
worden dan persoons gegevens. Je zult dan al die specifieke manieren van
afschermen in die ene lijst moeten gaan stoppen, wat ook weer niet er
overzichtelijk is.

> Het doel is namelijk verwerking van ingevoerde data
> op het scherm en dus maar je daar een class voor. Dat is toch
> niet raar?

Als je data wilt verwerken zul je eerst moeten weten wat voor data je
hebt. Met een algemene Lijst kun je daar nooit zeker van zijn, dat lijkt
mij niet handig.

>
>>>
>>>>Die array kan door elke programmeur die even niet oplet in een willekeurig
>>>>ander deel van de software om zeep geholpen worden, waarna er in elk
>>>>willekeurig ander deel van de software bugs kunnen optreden die moeilijk
>>>>terug te vinden zijn. Het PersonenLijst object daarentegen kun je in hoge
>>>>mate beschermen, waardoor de interne toestand van het object gegarandeerd
>>>>is, en nare bugs uitgesloten worden.
>>>>
>>>
>>>Correct. Maar het vereist meer inspanning die volgens mij niet
>>>altijd opweegt tegen die zg. bescherming. Als het om bescherming
>>>gaat moet je er ook duidelijk bij vermelden dat die PersonenLijst-class
>>>final wordt! :)
>>
>>Niks geldt altijd. Als je een scriptje van twintig regels schrijft wat je
>>verder nooi meer gaat gebruiken, dan geldt het hoogstwaarschijnlijk niet.
>>De OP gaf al aan dat het niet om zoiets ging.
>>
>>
>>>Overigens..de class java.util.ArrayList encapsuleert de data
>>>ook prima :)
>>
>>Tot op bepaalde hoogte, ondat het een object is. Het bewijst dus mijn
>>stelling en niet de jouwe.
>>
>
> Ja, tjeempie. :)
>
> Dan moet ik nu dus weer roepen dat die PersonenLijst overbodig is,
> omdat je net zo goed een ArrayList kunt gebruiken omdat die ook
> de data encapsuleert en dan kun jij weer zeggen dat die ArrayList
> te algemeen is etc.etc. :)

Maar die ArrayList bevat bijv. geen functie om personen uit een database
te laden. Het bevat ook geen functie om te kijken of de achternaam van een
toegevoegde persoon wel ingevuld is. In de praktijk wil je toch al heel
snel speciefieke methoden gaan toevoegen.

>
> Kunnen we nog wel langer doorgaan, terwijl we eigenlijk gewoon
> op een lijn zitten wat dit betreft.
>
> Mijn punt is alleen dat je voorzichtig moet zijn met het
> in het leven roepen van allerlei hele specifieke classes, zoals
> 'PersonenLijst'. Maak dan een class Persoon en gooi die vervolgens
> in een ArrayList o.i.d. en je hebt een lijst.

Overbodige klassen moet je voorkomen. Maar om er vanuit te gaan dat je zo
min mogelijk specifieke klassen moet maken gaat mij veel te ver.

>
>
>>>Zo leidt teveel flexibiliteit weer
>>>tot over-engineering en voor je het weet is het programmeerwerk
>>>vervangen tot configuratiewerk.
>>
>>Klopt. Je moet de juiste balans vinden.
>>
>
> Dat is het punt en ik ben een beetje huiverig voor classes
> als 'PersonenLijst' die eigenlijk niets toevoegen. Straks wil
> je je scherm uitbreiden en dan moet je eigenlijk
> een HuisdierenLijst gaan maken, terwijl je eigenlijk een

Ik zou zo'n huisdier niet in een PersonenLijst gaan gooien. Daar krijg je
rare situaties van. Staat Bello ineens op de loonlijst enzo.. ;-)

Maar als het niets toevoegt en je weet vrij zeker dat dat in de toekomst
zo blijft, dan hoef je die aparte klasse natuurlijk ook niet te maken.
Maar mijn ervaring is dat het al snel iets toevoegt. Het is namelijk ook
een kwestie van je code op een logische plaats neerplanten. En zo'n
PersonenLijst is voor veel zaken al snel een logische plaats.

Als je een syteem hebt met al die verschillende entiteiten en die hebben
ook allemaal specieke implementaties, dan vind ik het inderdaad handiger
om daar allemaal aparte klassen voor te maken. Maar als een Huisdier of
een Persoon voor het systeem verder geen enkel verschil maakt, dan zou ik
er één klasse van maken.

> DingenLijst hebt en dan gebruik je gewoon een List, Set of Map.
>
> Op het moment dat je dit soort dilemma's tegenkomt is het vaak
> tijd om dingen te refactoren om bloat te voorkomen.
>
>
[...]
> Je doelt op C++ programmeren a la C met classes in plaats van
> mooie dingen met inheritance en de C++ libraries gebruiken in plaats
> van stiekum toch gewoon malloc en free gebruiken i.p.v. new en delete....
>
> Soms is dat laatste wel een stuk handiger, hoor :) Ik geef toe, in
> C++ maak ik ook gewoon een linked list met pointers i.p.v. een
> fancy mechanisme met objecten. Misschien dat dit de reden is
> dat ik - als ik wat in java maak - ook niet begin met allerlei
> lege objecten met getters en setters en daarna de dingen aanelkaar
> knoop :)

Ja, ik snap wel wat je bedoelt. Ik heb dat ook vaak zo gedaan, je denkt
dan dat je sneller klaar bent door het wat eenvoudiger op te zetten.
Scheelt vaak een hoop typewerk. Maar nadat ik bij verschillende projecten
uiteindelijk de boel weer heb omgegooid omdat het toch niet handig bleek,
maak ik tegenwoordig eerst een globaal ontwerp van welke klassen ik nodig
denk te gaan hebben (ook in de toekomst) en dan programmeer ik vanuit dat
ontwerp. Het is in het begin van het project meer werk, maar op de lange
termijn bespaart het een hoop werk. Het project moet dan wel een langere
termijn hebben natuurlijk, anders heeft het geen zin.

Ik geloof overigens dat we het niet eens zoveel oneens zijn als het erop
aan komt. Alleen de manier van aanpak en de specifieke wel/niet keuzes
zijn wellicht anders.

groet, Michiel.

[F]

In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
> F wrote:
>> In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>>
>>>[knip]
>>>Als jij een design pattern ziet als een 'hack' in de OO-taal vanwege een
>>>gebrek van zo'n taal, dan heb je er wel een hele vreemde visie op. Een
>>>fiets is ook niet uitgevonden om het gebrek van het wiel op te lossen, al
>>>zou je het zo kunnen zien natuurlijk.
>>>
>>
>> Neem bijvoorbeeld een singleton, als we het toch over static methods
>> hebben...Soms zijn static methods niet handig, maar wil je toch dat
>> deze 'leven' in een object, maar je wilt ook weer niet dat er
>> meerdere instances zijn. OO-talen voorzien hier niet in dus
>> moet er een truc worden uitgehaald. Bij een procedurele of
>> functionele taal speelt dit hele probleem niet en dus
>> moet er voor een OO-taal een truc worden uitgehaald. In
>> volgende generaties talen worden bepaalde patterns wellicht
>> onderdeel van de taal.
>> In die zin is het dus een work-around voor een onvolkomenheid
>> van een systeem, een 'hack' zo je wilt.
>
> Ik zie een singleton toch niet als een hack, het is gewoon een van de vele
> patterns. De singleton is inderdaad static, maar dat neemt niet weg dat
> static methoden in zijn algemeenheid niet zo veel voorkomen. Een singleton
> pattern gebruik ik ook zelden trouwens. Natuurlijk is een static methode
> soms noodzakelijk, anders zou het ook zeker niet in Java zitten. Maar ik
> gebruik het alleen als ik het niet anders kan oplossen.
>
Volgens mij heb je me verkeerd begrepen, hoor.

Wat ik bedoelde is dat het feit dat er een singleton pattern bestaat,
betekent dat het nogal eens nodig is om ervoor te zorgen dat er van
een object slechts 1 instance is. Aangezien het in - laten we zeggen
de taal Java - niet mogelijk is om met een bepaald keyword aan te
geven dat een class een singleton betreft, is er dus een trucje bedacht
waarin je de constructor private maakt en er in een static variabele
een pointer naar de instance wordt geregistreerd. Dat trucje hebben
ze een naampje gegeven zodat jij en ik weten waar het over gaat.

Zo is het toch? Het is toch een trucje waar men een naampje aan
gegeven heeft? Ik heb ooit zo'n design pattern-boekje doorgelezen en
daarin vond ik dingen die ik zelf ook al deed. Een singleton had
ik zelf ook al bedacht, maar wist ik veel dat dat tegenwoordig singleton
heet. Maar het is wel handig als iedereen het over hetzelfde heeft en
ook een standaard manier gebuikt om het te implementeren, maar het blijft
een trucje dat nodig is omdat je nou een maal niet kunt schrijven:

public singleton class PersonenLijst
{
public PersonenLijst()
{
}
}

En als je dan die constructor aanroept slaat ie - als je dat voor de
tweede keer doet - de constructor over en geeft de unieke referentie die
ergens wordt bijgehouden. Dat had een feature van de taal kunnen zijn
die dus klaarblijkelijk wel nodig is.

>>>Je begint je verhaal met de stelling dat al die objecten maar onzin zijn,
>>>om te eindigen met de stelling dat het toch wel mooi zou zijn om met
>>>objecten te werken.
>>>
>>

>> Dat gaf ik al aan, toch? Die string-array was de meest simpele
>> oplossing met alle nadelen vandien, nadelen die je zelf al
>> opnoemde. Een class 'PersonenLijst' is juist weer heel specifiek
>> en dat is niet altijd handig.
>
> Klopt, je gaat ook geen class Jantje of Pietje maken, maar gewoon een
> class Persoon. In de context van de vraag van OP vond ik het echter wel
> handig. Iig. beter dan een Lijst object hanteren waar om het even
> Personen, Url's of weet ik niet wat in zit. Bovendien kan zo'n specifieke
> PersonenLijst de implementatie van het laden van de objecten die erin
> zitten afschermen, dmv de load() functie. Die implementatie is voor
> Personen geheel anders dan voor Url's, dus dat rechtvaardigt aparte klassen.
>
Dat laatste weet ik nog niet zo...waarschijnlijk moeten ze alleen maar
op het scherm getoond worden en moet je wat kunnen invullen zodat
het weer wordt opgestuurd.

Zo is het bijvoorbeeld ook heel handig om bijvoorbeeld geldbedragen
niet in floats heen en weer te sturen maar gewoon een string te
gebruiken...dan voorkom je heel veel ellende precisie e.d. Niet voor
de handliggend en het klinkt naief, maar het maak de boel wel een
stuk simpeler.

>
> Als je data wilt verwerken zul je eerst moeten weten wat voor data je
> hebt. Met een algemene Lijst kun je daar nooit zeker van zijn, dat lijkt
> mij niet handig.
>

Nee, joh :)
Je wilt niet dat je programma weet om wat voor data het gaat. Dan moet
je allemaal classes maken voor al die data. Of het nou gaat om de
naam van een persoon of om de schoen maat...het gaat meestal gewoon
om dingen die een database inmoeten en het zal de database ook worst
wezen wat de inhoud is....het datatype is hooguit van belang.

>> Dan moet ik nu dus weer roepen dat die PersonenLijst overbodig is,
>> omdat je net zo goed een ArrayList kunt gebruiken omdat die ook
>> de data encapsuleert en dan kun jij weer zeggen dat die ArrayList
>> te algemeen is etc.etc. :)
>
> Maar die ArrayList bevat bijv. geen functie om personen uit een database
> te laden. Het bevat ook geen functie om te kijken of de achternaam van een
> toegevoegde persoon wel ingevuld is. In de praktijk wil je toch al heel
> snel speciefieke methoden gaan toevoegen.
>
Goed idee....van die ArrayList dingen kun je weer erven...

public class DBArrayList extends ArrayList
{
public DBArrayList(String sql_query,String field)
{
...
}
}

Of eigenlijk moet het met een Map. Dat is beter. Dat je
ineenkeer een HashMap vult ofzo.

>>
>> Kunnen we nog wel langer doorgaan, terwijl we eigenlijk gewoon
>> op een lijn zitten wat dit betreft.
>>
>> Mijn punt is alleen dat je voorzichtig moet zijn met het
>> in het leven roepen van allerlei hele specifieke classes, zoals
>> 'PersonenLijst'. Maak dan een class Persoon en gooi die vervolgens
>> in een ArrayList o.i.d. en je hebt een lijst.
>
> Overbodige klassen moet je voorkomen. Maar om er vanuit te gaan dat je zo
> min mogelijk specifieke klassen moet maken gaat mij veel te ver.
>
Van mij hoeft dat ook niet, hoor :)

> [..]
> Ik geloof overigens dat we het niet eens zoveel oneens zijn als het erop
> aan komt. Alleen de manier van aanpak en de specifieke wel/niet keuzes
> zijn wellicht anders.
>

Neuh...

Misschien komt het omdat ik te veel troep heb gezien. Je kent ze wel,
de uit de hand gelopen projecten met veel te veel mensen waarin vergaderd
wordt over het upgraden van de server om performance-winst te behalen en
waarin men bang geworden is voor de compiler en niet meer aan de code
durft te komen, omdat het anders misschien stuk gaat.
Daar wordt je op een gegeven moment kriegel van een package tree
met 40 directories met eindeloze reeksen classes met get() en set()-methods
waarin men gepoogd heeft het hele probleemdomein te modelleren...


F

[Michiel de Roo]

F wrote:
> In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>
>>F wrote:
>>
>>>In nl.comp.programmeren Michiel de Roo <yourlove@welovespam.nl> wrote:
>>>
>>>
>>>>[knip]
>>>>Als jij een design pattern ziet als een 'hack' in de OO-taal vanwege een
>>>>gebrek van zo'n taal, dan heb je er wel een hele vreemde visie op. Een
>>>>fiets is ook niet uitgevonden om het gebrek van het wiel op te lossen, al
>>>>zou je het zo kunnen zien natuurlijk.
>>>>
>>>
>>>Neem bijvoorbeeld een singleton, als we het toch over static methods
>>>hebben...Soms zijn static methods niet handig, maar wil je toch dat
>>>deze 'leven' in een object, maar je wilt ook weer niet dat er
>>>meerdere instances zijn. OO-talen voorzien hier niet in dus
>>>moet er een truc worden uitgehaald. Bij een procedurele of
>>>functionele taal speelt dit hele probleem niet en dus
>>>moet er voor een OO-taal een truc worden uitgehaald. In
>>>volgende generaties talen worden bepaalde patterns wellicht
>>>onderdeel van de taal.
>>>In die zin is het dus een work-around voor een onvolkomenheid
>>>van een systeem, een 'hack' zo je wilt.
>>
>>Ik zie een singleton toch niet als een hack, het is gewoon een van de vele
>>patterns. De singleton is inderdaad static, maar dat neemt niet weg dat
>>static methoden in zijn algemeenheid niet zo veel voorkomen. Een singleton
>>pattern gebruik ik ook zelden trouwens. Natuurlijk is een static methode
>>soms noodzakelijk, anders zou het ook zeker niet in Java zitten. Maar ik
>>gebruik het alleen als ik het niet anders kan oplossen.
>>
>
> Volgens mij heb je me verkeerd begrepen, hoor.
>
> Wat ik bedoelde is dat het feit dat er een singleton pattern bestaat,
> betekent dat het nogal eens nodig is om ervoor te zorgen dat er van
> een object slechts 1 instance is. Aangezien het in - laten we zeggen
> de taal Java - niet mogelijk is om met een bepaald keyword aan te
> geven dat een class een singleton betreft, is er dus een trucje bedacht
> waarin je de constructor private maakt en er in een static variabele
> een pointer naar de instance wordt geregistreerd. Dat trucje hebben
> ze een naampje gegeven zodat jij en ik weten waar het over gaat.
>
> Zo is het toch? Het is toch een trucje waar men een naampje aan
> gegeven heeft? Ik heb ooit zo'n design pattern-boekje doorgelezen en
> daarin vond ik dingen die ik zelf ook al deed. Een singleton had
> ik zelf ook al bedacht, maar wist ik veel dat dat tegenwoordig singleton
> heet. Maar het is wel handig als iedereen het over hetzelfde heeft en
> ook een standaard manier gebuikt om het te implementeren, maar het blijft
> een trucje dat nodig is omdat je nou een maal niet kunt schrijven:
>
> public singleton class PersonenLijst
> {
> public PersonenLijst()
> {
> }
> }
>
> En als je dan die constructor aanroept slaat ie - als je dat voor de
> tweede keer doet - de constructor over en geeft de unieke referentie die
> ergens wordt bijgehouden. Dat had een feature van de taal kunnen zijn
> die dus klaarblijkelijk wel nodig is.

Als je het zo zegt klopt het. Maar een singleton gebruik ik evengoed niet
zo vaak.

>
>
>>>>Je begint je verhaal met de stelling dat al die objecten maar onzin zijn,
>>>>om te eindigen met de stelling dat het toch wel mooi zou zijn om met
>>>>objecten te werken.
>>>>
>>>
>
>>>Dat gaf ik al aan, toch? Die string-array was de meest simpele
>>>oplossing met alle nadelen vandien, nadelen die je zelf al
>>>opnoemde. Een class 'PersonenLijst' is juist weer heel specifiek
>>>en dat is niet altijd handig.
>>
>>Klopt, je gaat ook geen class Jantje of Pietje maken, maar gewoon een
>>class Persoon. In de context van de vraag van OP vond ik het echter wel
>>handig. Iig. beter dan een Lijst object hanteren waar om het even
>>Personen, Url's of weet ik niet wat in zit. Bovendien kan zo'n specifieke
>>PersonenLijst de implementatie van het laden van de objecten die erin
>>zitten afschermen, dmv de load() functie. Die implementatie is voor
>>Personen geheel anders dan voor Url's, dus dat rechtvaardigt aparte klassen.
>>
>
> Dat laatste weet ik nog niet zo...waarschijnlijk moeten ze alleen maar
> op het scherm getoond worden en moet je wat kunnen invullen zodat
> het weer wordt opgestuurd.
>
> Zo is het bijvoorbeeld ook heel handig om bijvoorbeeld geldbedragen
> niet in floats heen en weer te sturen maar gewoon een string te
> gebruiken...dan voorkom je heel veel ellende precisie e.d. Niet voor
> de handliggend en het klinkt naief, maar het maak de boel wel een
> stuk simpeler.

In eerste instantie...... Als je klant gaat klagen dat er vreemde
geldbedragen in de database zitten en of dat anders kan, dan kun je alsnog
de hele boel omgooien.

>
>
>>Als je data wilt verwerken zul je eerst moeten weten wat voor data je
>>hebt. Met een algemene Lijst kun je daar nooit zeker van zijn, dat lijkt
>>mij niet handig.
>>
>
>
> Nee, joh :)
> Je wilt niet dat je programma weet om wat voor data het gaat. Dan moet
> je allemaal classes maken voor al die data. Of het nou gaat om de
> naam van een persoon of om de schoen maat...het gaat meestal gewoon
> om dingen die een database inmoeten en het zal de database ook worst
> wezen wat de inhoud is....het datatype is hooguit van belang.

datatype zeker, maar ook validatie, input type (checkbox, textveld,
select, textarea), field size, en zo nog wel wat meta data. Zoals ik zei,
je kunt dit generiek oplossen, niks mis mee (zelfs beter), maar wel meer
werk.

>
>
>>>Dan moet ik nu dus weer roepen dat die PersonenLijst overbodig is,
>>>omdat je net zo goed een ArrayList kunt gebruiken omdat die ook
>>>de data encapsuleert en dan kun jij weer zeggen dat die ArrayList
>>>te algemeen is etc.etc. :)
>>
>>Maar die ArrayList bevat bijv. geen functie om personen uit een database
>>te laden. Het bevat ook geen functie om te kijken of de achternaam van een
>>toegevoegde persoon wel ingevuld is. In de praktijk wil je toch al heel
>>snel speciefieke methoden gaan toevoegen.
>>
>
> Goed idee....van die ArrayList dingen kun je weer erven...
>
> public class DBArrayList extends ArrayList
> {
> public DBArrayList(String sql_query,String field)
> {
> ...
> }
> }

is ook een manier. Maar niet de mijne ;-)

>
> Of eigenlijk moet het met een Map. Dat is beter. Dat je
> ineenkeer een HashMap vult ofzo.
>
>
>>>Kunnen we nog wel langer doorgaan, terwijl we eigenlijk gewoon
>>>op een lijn zitten wat dit betreft.
>>>
>>>Mijn punt is alleen dat je voorzichtig moet zijn met het
>>>in het leven roepen van allerlei hele specifieke classes, zoals
>>>'PersonenLijst'. Maak dan een class Persoon en gooi die vervolgens
>>>in een ArrayList o.i.d. en je hebt een lijst.
>>
>>Overbodige klassen moet je voorkomen. Maar om er vanuit te gaan dat je zo
>>min mogelijk specifieke klassen moet maken gaat mij veel te ver.
>>
>
> Van mij hoeft dat ook niet, hoor :)
>
>
>>[..]
>>Ik geloof overigens dat we het niet eens zoveel oneens zijn als het erop
>>aan komt. Alleen de manier van aanpak en de specifieke wel/niet keuzes
>>zijn wellicht anders.
>>
>
>
> Neuh...
>
> Misschien komt het omdat ik te veel troep heb gezien. Je kent ze wel,
> de uit de hand gelopen projecten met veel te veel mensen waarin vergaderd
> wordt over het upgraden van de server om performance-winst te behalen en
> waarin men bang geworden is voor de compiler en niet meer aan de code
> durft te komen, omdat het anders misschien stuk gaat.
> Daar wordt je op een gegeven moment kriegel van een package tree
> met 40 directories met eindeloze reeksen classes met get() en set()-methods
> waarin men gepoogd heeft het hele probleemdomein te modelleren...

troep heb ik al veel te veel gezien ;-)

ik ga maar weer eens stoppen voor vandaag.

Groeten, Michiel.