[GS] Design schrijven

[Super Duck]

Voor de eerste opdracht moeten wij een design schrijven en later implementeren in oberon. (het antwoord staat bijna letterlijk in de cursus)

Alle 'conventions' van het UML-object-georienteerd design staan ook in onze cursus. Maar hoe moet ge receivers 'declareren' in UML? (omdat ons design voor oberon moet geschreven worden)

Code: Select all

+createBinaryTree()

// Creëert een lege binaire boom.



+createBinaryTree(in rootItem:TreeItemType)

// Creëert een binaire boom met 1 knoop, de wortel, die rootItem bevat.

=> dit gaat niet in oberon2, enkel in C++ e.d., wij moeten nog werken met receivers..

[cG`]

Mja UML staat voor "Unified Modeling Language" m.a.w. zou je bij het maken van het design geen tot weinig rekening mogen houden met hoe het in Oberon geimplementeerd wordt he.. Een design zou in theorie moeten horen bij een bepaald ADT bijvoorbeeld en a.d.h.v. het design kan je dan de implementatie maken in een programmeertaal naar keuze. Dat denk ik toch tenminste
Conclusie: maak het design gewoon zoals je voorbeeld, zo heb ik het vorig jaar normaal toch ook gedaan.

[Yannick]

werkt ge in C++ ook niet met receivers?
Thomas vroeg mij ook al hoe dat dit kwam omdat de een geen parameters heeft en de andere wel. Das een fenomeen in de nieuwere (hippere :p) programmeertalen en heeft niets te maken met objecten dacht ik. Is gewoon eenzelfde procedure schrijven maar dan met een ander aantal parameters.
Dit combineren met polymorfisme (als dat mogelijk is, weetk niks van iig) geeft volges mij wel een shítload aan procedures xD .

[Fristi]

hmm, design, moeten dat ding dus in UML schrijven fzo?
of niet?

lat me stellen dat ik die les ni echt heb opgelet -_-"

[Tom]

Ja, dat design moeten we in UML schrijven,
we moeten niet echt letten op Oberon-2-specifieke dingen.


Het verschijnsel waarbij we meerdere functies met dezelfde naam en verschillende parameters gebruiken noemen we "Overloading".

Zo is het bijvoorbeeld mogelijk om vier som procedures te maken...
- INTEGER + INTEGER
- FLOAT + FLOAT
- INTEGER + INTEGER + INTEGER
- FLOAT + FLOAT + FLOAT

Ook bestaat er een verschijnsel dat "Template" noemt, hier maakt het weinig uit van welk type de parameters zijn. Zo kan je één som procedure maken waar je elk paar types aan kan geven. (SHORTINT + SHORTINT, INTEGER + INTEGER, REAL + REAL, ...)

Ook zal het mogelijk worden om operators (+ - * / ++ --, ...) te overloaden, dit noemen we dan "Operator Overloading". Zo kunnen we een andere bewerking aan een operator toe wijzen.

Maarja, dit is shizzle voor eind dit semester en volgend jaar.

[cG`]

Ah het niet gezien dat het in je code om functies met dezelfde identifier ging.
Ja in C++ e.d. kan je dus functies maken die dezelfde identifier hebben, maar met een verschillend aantal en/of type parameters, dit is in Oberon inderdaad niet mogelijk.
Ik zou dan toch aanraden om in je design een andere naam te nemen voor die 2de create functie (als je er 2 nodig hebt) omdat het design ook een soort hulp moet zijn om je programma te begrijpen, dus als je in het design een bepaalde functie X noemt dan hoort die eigenlijk in je code ook zo te noemen.

[Super Duck]

Ah het niet gezien dat het in je code om functies met dezelfde identifier ging.
Ja in C++ e.d. kan je dus functies maken die dezelfde identifier hebben, maar met een verschillend aantal en/of type parameters, dit is in Oberon inderdaad niet mogelijk.
Ik zou dan toch aanraden om in je design een andere naam te nemen voor die 2de create functie (als je er 2 nodig hebt) omdat het design ook een soort hulp moet zijn om je programma te begrijpen, dus als je in het design een bepaalde functie X noemt dan hoort die eigenlijk in je code ook zo te noemen.

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)

[0g1op]

kan je niet iets van watson ofzoiets gebruiken?

[joeri]

Wel, zoals door cG` al opgemerkt zoudt ge niet teveel rekening moeten houden met implementatie.
Een in parameter kan je dus implementeren met een waarde parameter of een variabele parameter (dat laatste dan voor efficientie), terwijl inout en out parameters allebei met variabele parameters moeten geimplementeerd worden, maar in se dient die in/out/inout annotatie enkel om aan te duiden waar de parameter voor dient, het zegt niet noodzakelijk iets over de implementatie.

[Robbe]

Zoals cG` zei, zegt UML niets over de implementatie. Ze hebben je echter niet genoeg verteld over UML, want normaal worden alle methodes van een object gegroepeerd per object zodat het duidelijk is dat het altijd met dat object te maken heeft.

Die receiver moet dus niet opgeschreven worden, maar groepeer je methodes per object als je er meerdere zou hebben.

Ik heb het in die tijd iets anders gedaan omdat ik dit toen allemaal niet wist: ik heb mijn design "procedureel" geschreven. Ik gaf dus het object mee als parameter in de procedure.

[Fristi]

Mja, Robbe slaat hier wel de spijker op de kop
Amper iets over UML verteld, zo beetje van dit, beejte van dat..kweet op de mometn geeneens hoek eraan moet beginne, waar dak het meot me maken, ...
Ale da mag stom klinken en zijn, maar kben gwn beetje verward ^^

[Robbe]

Mja, Robbe slaat hier wel de spijker op de kop
Amper iets over UML verteld, zo beetje van dit, beejte van dat..kweet op de mometn geeneens hoek eraan moet beginne, waar dak het meot me maken, ...
Ale da mag stom klinken en zijn, maar kben gwn beetje verward ^^

awel,Google is your friend

[Super Duck]

(..) kweet op de mometn geeneens hoek eraan moet beginne, waar dak het meot me maken, ...
Ale da mag stom klinken en zijn, maar kben gwn beetje verward ^^

Is het ni gwn word opene en zoiets make:

Code: Select all

// KeyType is het type van de keys die in de binaire boom

// worden opgeslagen. (INTEGER)



//BinaryTree is het type van een knooppunt



+createBinaryTree()

// Creëert een lege binaire boom.



+createBinaryTree(in key:KeyType)

// Creëert een binaire boom met 1 knoop, de wortel, die de meegegeven key bevat.

Of moet dat in zo'n datagram gevisualiseerd worde?

[Fristi]

Das dus exact wattek me ook afvraag

ps:Whatever it is, ik ga het proberen te maken in een nog irritanter lettertype als comic sans ms, my god da mens

[Pieter Belmans]

Wingdings will do fine. Of anders zo'n speciaal font voor wekkerradio's of zo'n handgeschreven iets .