🚀 go-pugleaf

Passero wrote:
> we zijn bezig met een project met een programma te schrijven voor ons
> project van school. Dat programma moet klimatogrammen tekenen aan de hand
> van de gegevens die de gebruiker ingeeft. Hij moet ook gegevens kunnen
> importeren uit tekstfiles enzo.
> Wij hebben nu discussie gehad met onze docenten over het domeinmodel. In
> onze boek (Applying uml and patterns van Craig Larman) staat dat een
> domeinmodel enkel de conceptuele klassen zijn dus die hebben niets te maken
> met de GUI. Moet je die grens altijd strikt gescheiden houden of kan je daar
> over gaan? In ons geval vind ik het wel nuttig om in ons domeinmodel de
> klasse Grafiek in op te nemen. Later moeten we dan een package "Domein"
> maken waar die klasse implementeren. De klasse grafiek hebben we nu al
> geschreven en erft van een JPAnel in Java, dus is eigenlijk wel een beetje
> GUI. Mijn argumentatie is: je hebt toch geen klimatogram zonder grafiek dus
> die 2 dingen horen samen dus hoort het toch wel bij het domein en niet bij
> de gui. Mijn docenten willen nu dat ik die loskoppel van mijn domein. Dat is
> op zich niet veel werk maar kdenk toch dat mijn denkwijze relatief goed is.
> Daarom graag eens jullie mening hierover.

Als de opdracht is om de grafiek en de GUI los van elkaar te maken, dan 
zou ik dat ook doen.

Dat is ook het principe van OO-programmeren: "eilandjes" (classes) maken 
binnen je programma, die met weinig lijnen (method-calls/members) met 
elkaar zijn verbonden.

Om een voorbeeld te geven waar jouw methode de fout in gaat: stel dat de 
gebruiker een grafiek wil laten tekenen op een webserver waar helemaal 
geen GUI voorhanden is, om het resultaat in een HTML-pagina op te nemen?

Groeten,
Edwin Martin

-- 
http://www.bitstorm.org/

Edwin Martin wrote:

> Om een voorbeeld te geven waar jouw methode de fout in gaat: stel dat de 
> gebruiker een grafiek wil laten tekenen op een webserver waar helemaal 
> geen GUI voorhanden is, om het resultaat in een HTML-pagina op te nemen?

Dat geeft dus, met Java, in de praktijk inderdaad een probleem, omdat 
bijvoorbeeld font render informatie van de X server verkregen wordt. Een 
oplossing die ik in het verleden gebruikt heb is dingen omleiden naar 
een library die dit ondervangt (uiteraard niet allemaal zelf geschreven)

-- 
John

Freelance Perl / Java developer available  -  Mail for more info

In <RQ14c.31002$_L6.2008369@phobos.telenet-ops.be> Passero wrote:
> we zijn bezig met een project met een programma te schrijven voor ons
> project van school. Dat programma moet klimatogrammen tekenen aan de 
> hand van de gegevens die de gebruiker ingeeft. Hij moet ook gegevens 
> kunnen importeren uit tekstfiles enzo. Wij hebben nu discussie gehad 
> met onze docenten over het domeinmodel. In onze boek (Applying uml and 
> patterns van Craig Larman) staat dat een domeinmodel enkel de 
> conceptuele klassen zijn dus die hebben niets te maken met de GUI. 
> Moet je die grens altijd strikt gescheiden houden of kan je daar over 
> gaan? In ons geval vind ik het wel nuttig om in ons domeinmodel de
> klasse Grafiek in op te nemen. Later moeten we dan een package 
> "Domein" maken waar die klasse implementeren. De klasse grafiek hebben 
> we nu al geschreven en erft van een JPAnel in Java, dus is eigenlijk 
> wel een beetje GUI. Mijn argumentatie is: je hebt toch geen 
> klimatogram zonder grafiek dus die 2 dingen horen samen dus hoort het 
> toch wel bij het domein en niet bij de gui. Mijn docenten willen nu 
> dat ik die loskoppel van mijn domein. Dat is op zich niet veel werk 
> maar kdenk toch dat mijn denkwijze relatief goed is. Daarom graag eens 
> jullie mening hierover.

Iedere klasse die erft van JPanel of andere wijze gestoeld is op de 
Swing GUI moet uit het domeinmodel gehouden worden. Het moet voor jou 
domeinmodel niet uitmaken of hij nou wordt aangestuurd vanuit een Swing 
GUI of bijv. vanaf de command line of mogelijk zelfs vanuit een script.
Een domeinmodel bevat de abstracte kennis over een domein. Ik kan mij in 
het domein van klimatogrammen een Grafiek-klasse voorstellen waarin alle 
algemene kennis van grafieken is ondergebracht (bijv. bepaling van 
maximum, minimum, interpolatie, etc), zonder die klasse afhankelijk te 
maken van specifieke GUI-klassen. Oftewel, het concept grafiek is zelf 
abstract (het bestond immers lang voor Swing, Java of enige 
programmeertaal).
Ik zou voorstellen om in het domein een Grafiek-klasse op te nemen 
zonder enige UI afhankelijkheid, en in de UI een klasse GrafiekPanel die 
weet hoe hij een grafiek op het scherm zet.

Rudi Angela

"Passero" <bla@bla.bla> wrote in message news:<RQ14c.31002$_L6.2008369@phobos.telenet-ops.be>...

> Mijn argumentatie is: je hebt toch geen klimatogram zonder grafiek dus
> die 2 dingen horen samen dus hoort het toch wel bij het domein en niet bij
> de gui. Mijn docenten willen nu dat ik die loskoppel van mijn domein. Dat is
> op zich niet veel werk maar kdenk toch dat mijn denkwijze relatief goed is.
> Daarom graag eens jullie mening hierover.

Ik zou het loskoppelen, en dit is waarschijnlijk ook de bedoeling van
de opdracht van je leraar. Wanneer je de GUI en het model gescheiden
houdt is het eenvoudig om je grafiek in een ander formaat te laten
zien, of in verschillende formaten tegelijk. Wanneer je klasse Grafiek
ook 'zichzelf tekent' wordt dit een stuk moeilijker. Daarom is het erg
gebruikelijk in OO om het model en de GUI in verschillende klassen te
stoppen. Je zou eens wat kunnen opzoeken over het
'model-view-controller' paradigma.

succes,

- Koen.

"Rudi Angela" <olmeca@netscape.net> schreef in bericht
news:20040312095007220+0100@aruba.etowns.net...

> Iedere klasse die erft van JPanel of andere wijze gestoeld is op de
> Swing GUI moet uit het domeinmodel gehouden worden. Het moet voor jou
> domeinmodel niet uitmaken of hij nou wordt aangestuurd vanuit een Swing
> GUI of bijv. vanaf de command line of mogelijk zelfs vanuit een script.
> Een domeinmodel bevat de abstracte kennis over een domein. Ik kan mij in
> het domein van klimatogrammen een Grafiek-klasse voorstellen waarin alle
> algemene kennis van grafieken is ondergebracht (bijv. bepaling van
> maximum, minimum, interpolatie, etc), zonder die klasse afhankelijk te
> maken van specifieke GUI-klassen. Oftewel, het concept grafiek is zelf
> abstract (het bestond immers lang voor Swing, Java of enige
> programmeertaal).
> Ik zou voorstellen om in het domein een Grafiek-klasse op te nemen
> zonder enige UI afhankelijkheid, en in de UI een klasse GrafiekPanel die
> weet hoe hij een grafiek op het scherm zet.
>

Ok bedankt, ik zal dat doen. Ik zal nu een nieuwe klasse maken in mijn
domeinmodel die enkel de niet gui elementen bijhoudt. Ik zal dan een
implementatie maken van die klasse en die abstract maken zodat wanneer je
een gui wil maken je die klasse moet laten erven van de grafiek. Als je dan
een grafiek in de commandline wil maken kan je gewoon een andere klasse
maken die ook erft van de abstracte klasse. Zo hoef je de veel gebruikte
methode zoals gemiddelde berekenen enzo niet meer implementeren want die
hebben niets te maken met de gui. Zou dat een goed idee zijn?

> Rudi Angela


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

Passero wrote:
> "Rudi Angela" <olmeca@netscape.net> schreef in bericht
> news:20040312095007220+0100@aruba.etowns.net...
> 
> 

[...]

> 
> 
> Ok bedankt, ik zal dat doen. Ik zal nu een nieuwe klasse maken in mijn
> domeinmodel die enkel de niet gui elementen bijhoudt. Ik zal dan een
> implementatie maken van die klasse en die abstract maken zodat wanneer je
> een gui wil maken je die klasse moet laten erven van de grafiek. Als je dan
> een grafiek in de commandline wil maken kan je gewoon een andere klasse
> maken die ook erft van de abstracte klasse. Zo hoef je de veel gebruikte
> methode zoals gemiddelde berekenen enzo niet meer implementeren want die
> hebben niets te maken met de gui. Zou dat een goed idee zijn?

Ik zou hier eerder composition toepassen ipv inheritance. Als je in een 
bepaalde situatie nood hebt aan een Grafiek object dan maak je hiervan 
een instantie aan. bvb een GrafiekPanel, afgeleid van JPanel met als 
field een Grafiek object. Indien je inheritance toepast ga je de 
twee(gui en business logic) toch weer op een bepaalde manier met elkaar 
vermengen.

Koen

"Koen Hautekeete" <koen.hautekeete.news@pandora.be> schreef in bericht
news:wzn4c.32180$b%6.2058340@phobos.telenet-ops.be...

>
> Ik zou hier eerder composition toepassen ipv inheritance. Als je in een
> bepaalde situatie nood hebt aan een Grafiek object dan maak je hiervan
> een instantie aan. bvb een GrafiekPanel, afgeleid van JPanel met als
> field een Grafiek object. Indien je inheritance toepast ga je de
> twee(gui en business logic) toch weer op een bepaalde manier met elkaar
> vermengen.
>

Aja, dus gewoon in mijn GUI klasse een attribuut opnemen van de klasse
Grafiek?
Verlies ik niet zo een beetje het idee van inkapseling? De GUI klasse moet
alles kennen wat in de klasse Grafiek zit dus voor elk attribuut ga ik een
getter en/of setter moeten schrijven. Is dat wel handig? Is het dan niet
gewoon beter om te erven en om een attribuut JPanel te gebruiken en dan een
methode voorzien die dat JPAnel retourneert? Mijn klasse Grafiek is dan toch
nog altijd compleet onafhankelijk van mijn GUI want er zal geen enkele
methode zijn die met de GUI te maken heeft. Enkel de berekeningen en de
lijsten met waarden zullen er in die klasse zijn. Uiteindelijk moet mijn gui
klasse ook al die dingen kennen dus dan heb ik toch hoge koppeling, zeer
hoge koppeling en das toch niet zo goed?

> Koen


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

Passero wrote:

> "Koen Hautekeete" <koen.hautekeete.news@pandora.be> schreef in bericht
> news:wzn4c.32180$b%6.2058340@phobos.telenet-ops.be...
> 
> 
>>Ik zou hier eerder composition toepassen ipv inheritance. Als je in een
>>bepaalde situatie nood hebt aan een Grafiek object dan maak je hiervan
>>een instantie aan. bvb een GrafiekPanel, afgeleid van JPanel met als
>>field een Grafiek object. Indien je inheritance toepast ga je de
>>twee(gui en business logic) toch weer op een bepaalde manier met elkaar
>>vermengen.
>>
> 
> 
> Aja, dus gewoon in mijn GUI klasse een attribuut opnemen van de klasse
> Grafiek?

Inderdaad.

> Verlies ik niet zo een beetje het idee van inkapseling? De GUI klasse moet
> alles kennen wat in de klasse Grafiek zit dus voor elk attribuut ga ik een
> getter en/of setter moeten schrijven.

Enkel voor de velden die je wil tonen (of "mogen" getoond worden aan de 
gebruiker) in je GUI een getter, een setter is niet direct noodzakelijk.

> Is dat wel handig? Is het dan niet
> gewoon beter om te erven en om een attribuut JPanel te gebruiken en dan een
> methode voorzien die dat JPAnel retourneert? Mijn klasse Grafiek is dan toch
> nog altijd compleet onafhankelijk van mijn GUI want er zal geen enkele
> methode zijn die met de GUI te maken heeft.

De klasse Grafiek is even onafhankelijk van de GUI als je ze gebruikt in 
  een Panel klasse. Er zal geen enkele method op voorkomen die met de 
GUI te maken heeft.

> Enkel de berekeningen en de
> lijsten met waarden zullen er in die klasse zijn. Uiteindelijk moet mijn gui
> klasse ook al die dingen kennen dus dan heb ik toch hoge koppeling, zeer
> hoge koppeling en das toch niet zo goed?

Je GUI-klasse mag die zaken niet kennen, dat is de verantwoordelijkheid 
van de klasse Grafiek. De GUI kan de klasse Grafiek wel gebruiken om de 
resultaten ervan te tonen, bvb de waarden tonen die door Grafiek 
berekend zijn of input van de gebruiker doorgeven aan Grafiek om de 
Grafiek instantie vervolgens berekeningen te laten uitvoeren.

Je kan dit oplossen door bvb gebruik te maken van het Observer pattern 
zodat de gui automatisch verwittigt wordt als het grafiek object wijzigt 
en zichzelf dan automatisch update.

Een goed boek over oa deze problematiek is Design patterns van "The gang 
of four" of Refactoring van Martin Fowler.

Groeten

Koen

"Passero" <bla@bla.bla> wrote in message
news:8Yn4c.32247$Jq.2162811@phobos.telenet-ops.be...
>
> "Koen Hautekeete" <koen.hautekeete.news@pandora.be> schreef in bericht
> news:wzn4c.32180$b%6.2058340@phobos.telenet-ops.be...
>

> Aja, dus gewoon in mijn GUI klasse een attribuut opnemen van de klasse
> Grafiek?
> Verlies ik niet zo een beetje het idee van inkapseling?

Neen want met inheritance is er totaal geen inkapseling. Daar geef je de
hele klasse open en bloot.

> De GUI klasse moet
> alles kennen wat in de klasse Grafiek zit dus voor elk attribuut ga ik een
> getter en/of setter moeten schrijven.

Merk even het verschil op: de GUI klasse moet helemaal niet alles kennen wat
je grafiek klasse kent maar het moet wel aan alle waardes aankunnen. Je
Domeinklasse berekent, de GrafiekUI klasse tekent. Dat zijn 2 fundamenteel
verschillende dingen. Je gaat helemaal geen code duplicatie hebben.

Verantwoordelijkheden:
Domeinklasse : de berekingen etc
GUIklasse :  waardes op een bepaalde manier op een scherm brengen

Is dat wel handig? Is het dan niet
> gewoon beter om te erven en om een attribuut JPanel te gebruiken en dan
een
> methode voorzien die dat JPAnel retourneert? Mijn klasse Grafiek is dan
toch
> nog altijd compleet onafhankelijk van mijn GUI want er zal geen enkele
> methode zijn die met de GUI te maken heeft. Enkel de berekeningen en de
> lijsten met waarden zullen er in die klasse zijn. Uiteindelijk moet mijn
gui
> klasse ook al die dingen kennen dus dan heb ik toch hoge koppeling, zeer
> hoge koppeling en das toch niet zo goed?

Er bestaat geen hogere koppeling in OO dan inheritance, compositie is altijd
minder gekoppeld dan inheritance. hoe gaat je interface naar je JPanel
attribuut er uit zien, denk je? ga je veel van de interface van een  JPanel
moeten gebruiken of weinig?

Een sterke koppeling naar een interface is niet perse slecht. Zeker voor
klassen die verantwoordelijk zijn om een bepaald iets op het scherm te
brengen is het te verwachten dat ze alle attributen van die domein klasse
gebruiken.

gC

"Koen Hautekeete" <koen.hautekeete.news@pandora.be> schreef in bericht
news:5go4c.32289$Pf2.2296964@phobos.telenet-ops.be...

> >
> > Aja, dus gewoon in mijn GUI klasse een attribuut opnemen van de klasse
> > Grafiek?
>
> Inderdaad.
>
> > Verlies ik niet zo een beetje het idee van inkapseling? De GUI klasse
moet
> > alles kennen wat in de klasse Grafiek zit dus voor elk attribuut ga ik
een
> > getter en/of setter moeten schrijven.
>
> Enkel voor de velden die je wil tonen (of "mogen" getoond worden aan de
> gebruiker) in je GUI een getter, een setter is niet direct noodzakelijk.
>
> > Is dat wel handig? Is het dan niet
> > gewoon beter om te erven en om een attribuut JPanel te gebruiken en dan
een
> > methode voorzien die dat JPAnel retourneert? Mijn klasse Grafiek is dan
toch
> > nog altijd compleet onafhankelijk van mijn GUI want er zal geen enkele
> > methode zijn die met de GUI te maken heeft.
>
> De klasse Grafiek is even onafhankelijk van de GUI als je ze gebruikt in
>   een Panel klasse. Er zal geen enkele method op voorkomen die met de
> GUI te maken heeft.
>
> > Enkel de berekeningen en de
> > lijsten met waarden zullen er in die klasse zijn. Uiteindelijk moet mijn
gui
> > klasse ook al die dingen kennen dus dan heb ik toch hoge koppeling, zeer
> > hoge koppeling en das toch niet zo goed?
>
> Je GUI-klasse mag die zaken niet kennen, dat is de verantwoordelijkheid
> van de klasse Grafiek. De GUI kan de klasse Grafiek wel gebruiken om de
> resultaten ervan te tonen, bvb de waarden tonen die door Grafiek
> berekend zijn of input van de gebruiker doorgeven aan Grafiek om de
> Grafiek instantie vervolgens berekeningen te laten uitvoeren.
>
> Je kan dit oplossen door bvb gebruik te maken van het Observer pattern
> zodat de gui automatisch verwittigt wordt als het grafiek object wijzigt
> en zichzelf dan automatisch update.
>
> Een goed boek over oa deze problematiek is Design patterns van "The gang
> of four" of Refactoring van Martin Fowler.
>

Heel boeiende materie vind ik persoonlijk ;)
Het probleem is dat ik moeilijk al die patterns kan implementeren in het
project. We zijn tijd gebonden en ik moet al 2 pattersn uitwerken voor mijn
opdracht voor ontwerp + nog eens dit project met de grafiek.
We moeten het adapter pattern bespreken voor het importeren en exporteren
van de klimatogramgegevens naar bestanden en het iterator pattern voor het
doorlopen van de klimatogrammanen. Als ik daarbij nog eens observer moet
leren en implementeren sla ik volledig tilt denk ik ;). Kzal maken dak het
ken tegen volgend jaar, dan kan ik het mss gebruiken voor ons project :d.

> Groeten
>
> Koen


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004