[GS] Design schrijven

[Fristi]

hmm..men eigen handschrift will solve that

[cG`]

Maar ik wil dat object georienteerd maken, dus met wel dezelfde naam.. Receivers kan je dus niet in UML weergeven?
En die in, out, en inout, wat voor parameters zijn dat in oberon? (waar er enkel waarde parameters(gok 'in') en variabele parameters (gok 'inout') zijn)

Ik heb niet gezegd dat je het niet object-georienteerd kan maken he, ik zou gewoon geen exact dezelfde identifiers gebruiken voor procedures, aangezien dit in Oberon niet kan (het is wsl ook niet nodig om bv 2 create procedures te hebben en indien je dit toch wil noem die tweede dan createExt ofzo). Voor de rest doe je het gewoon zoals in je voorbeeld, je vermeldt de receiver niet aangezien je (zoals Robbe heeft gezegd) de methodes groepeert per ADT.

Gebruik dus ook bij de parameters 'in' en 'out', waarbij in gewoon een waardeparameter is en out een variabele parameter (in en out dient dus gewoon om aan te geven wat voor soort parameter het is).

En ivm het UML diagramma: ik heb dat iig nooit gedaan (en had toch 15 of 16/20 op het eindtotaal), maar teveel werk kan nooit kwaad natuurlijk (zolang het juist is ).

PS. Het design vertelt dus wat je met het ADT kan doen, zonder overbodige details over de implementatie te vermelden.
@Super Duck: die vermelding van 'INTEGER' bij keyType kan je dus mss best weglaten.

[Tom]

In C++ bestaan er geen receivers, daar kan je gewoon met een 'this' pointer aan je object. De methodes (procedures) declareer je zo:

return-type KlasseNaam::Methode(type parameter, ...)
{
...
return this->variable;
}