🚀 go-pugleaf

"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