🚀 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/