[discussie] OO programmeren

[Verwijderd]

Om onze programmeerskills te verbeteren zou ik graag onze oo programmeertechnieken even willen bespreken en er de slechte zaken uithalen en de ervaringen met elkaar delen

ik maak mijn klassen door te zoeken op zelfstandige naamwoorden en bij die zelfstandige naamwoorden dan de attributen bij te plaatsen, hoogstwaarschijnlijk zijn er andere en betere methoden .

hoe doen jullie dit? Hoe pakken jullie dit probleem op, is mijn werkwijze wel effectief,.
wat denken jullie hiervan?

[Verwijderd]

Die zoek je in de requirements? Dat werkt alleen bij informatiesystemen en dan nog komt er een stukje inzicht bij kijken. Adres is ook een zelfstandig naamwoord (en zou toch meestal een attribuut worden). Bij functionele requirements (b.v. het systeem moet een analyse uitvoeren op .... ) verzin je allereerst zelf een aanpak en daarna een design en de klassen die je daarvoor gebruikt zul je niet of nauwlijks terug vinden in de requirements.

En natuurlijk een hoop op gevoel doen

[Verwijderd]

Afgezien van het feit dat je vorige topic over dit onderwerp net dichtgegooid is, vraag ik me af wat je bedoelt met:

"ik maak mijn klassen door te zoeken op zelfstandige naamwoorden en bij die zelfstandige naamwoorden dan de attributen bij te plaatsen"

Klassen maken, zoeken op zelfstandige naamwoorden
Ik snap niet helemaal wat je bedoelt. Zou je dit beter kunnen uitleggen in je openingspost?

[simon]

Volgens mij is dit OO verhaal ook nog eens sterk taal afhankelijk, over welke taal hebben we het nu?

[Verwijderd]

die aanpak dat is nu juist het probleem denk ik bij de meeste mensen daar dit totaal niet gestandaardiseert is, terwijl uml definitie dit wel is toch raar waarom dat ze dan die aanpak niet standaardiseren
heb jij al voorgehad dat je bvb mis zat met je klassen en wat doet u dan

[Verwijderd]

Simon schreef op woensdag 19 januari 2005 @ 12:18:
Volgens mij is dit OO verhaal ook nog eens sterk taal afhankelijk, over welke taal hebben we het nu?

maakt niet uit algemeen oo

[simon]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:20:
[...]


maakt niet uit algemeen oo

Maakt volgens mij wel uit, ik bedoel, de OO in PHP is totaal niet te vergelijken met die in Java Heb ik laatst nog topic over gehad Waar is Allarmnummer?
stelletje spuit elven hieronder.. ik hebt het al door, mijn fout

[ Voor 16% gewijzigd door simon op 19-01-2005 12:27 ]

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:17:
Klassen maken, zoeken op zelfstandige naamwoorden
Ik snap niet helemaal wat je bedoelt. Zou je dit beter kunnen uitleggen in je openingspost?

Dat is een bepaalde methodiek die redelijk bekend is, maar eigenlijk heb ik 'm nog nooit toegepast.

En andere methodiek is bv 'Commonality/Variability analyse' (finding what varies and encapsulate it). Hierbij ga je oa kijken welke 'objecten' er bepaalde dingen gemeen hebben, en waarin ze van elkaar verschillen.

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:20:
die aanpak dat is nu juist het probleem denk ik bij de meeste mensen daar dit totaal niet gestandaardiseert is, terwijl uml definitie dit wel is toch raar waarom dat ze dan die aanpak niet standaardiseren
heb jij al voorgehad dat je bvb mis zat met je klassen en wat doet u dan

Refactoren.

[whoami]

Simon schreef op woensdag 19 januari 2005 @ 12:22:
[...]


Maakt volgens mij wel uit, ik bedoel, de OO in PHP is totaal niet te vergelijken met die in Java Heb ik laatst nog topic over gehad Waar is Allarmnummer?

De taal maakt niet uit; het gaat hier om OO ontwerp. Als een taal OO is, dan ondersteunt ze minimaal een aantal principes (inheritance, encapsulation, data hiding, etc... )
Het is dus taal-onafhankelijk.

[lier]

Simon schreef op woensdag 19 januari 2005 @ 12:22:
[...]


Maakt volgens mij wel uit, ik bedoel, de OO in PHP is totaal niet te vergelijken met die in Java Heb ik laatst nog topic over gehad Waar is Allarmnummer?

OO heeft niets maar dan ook echt helemaal niets te maken met de taal waarvoor je het gaat gebruiken. De taal zegt overigens niet per definitie of het "OO is", met bijv. Java is heel goed op een "niet OO manier" te programmeren

[Verwijderd]

Simon schreef op woensdag 19 januari 2005 @ 12:22:
[...]
Maakt volgens mij wel uit, ik bedoel, de OO in PHP is totaal niet te vergelijken met die in Java Heb ik laatst nog topic over gehad Waar is Allarmnummer?

Het gaat om het ontwerp, dat is taalonafhankelijk. Als je daar in de implementatiefase PHP voor kiest dan moet je je laten nakijken.

[Verwijderd]

whoami schreef op woensdag 19 januari 2005 @ 12:24:
[...]


Dat is een bepaalde methodiek die redelijk bekend is, maar eigenlijk heb ik 'm nog nooit toegepast.

En andere methodiek is bv 'Commonality/Variability analyse' (finding what varies and encapsulate it). Hierbij ga je oa kijken welke 'objecten' er bepaalde dingen gemeen hebben, en waarin ze van elkaar verschillen.

Ik heb serieus nog nooit van die techniek gehoord . De 'Commonality/Variability analyse' techniek ken ik wel. Ik moet ook zeggen dat die techniek mij ook veel geschikter lijkt. Het zoeken naar zelfstandige naamwoorden vind ik een beetje overkomen als: "ik weet niet precies hoe ik het aan moet pakken, dus dan gebruik ik maar een techniek die vaak wel werkt".

[Verwijderd]

Ik bepaal mijn klassen door eerst een analysestudie te doen naar de eisen van het systeem. Vervolgens de verantwoordelijkheden en de gewenste data te achterhalen en dit te beschrijven en onder te verdelen in subsystemen. Daarna door met testen de verwachte output van verschillende subsystemen te omschrijven en dan door per subsysteem opnieuw te bekijken welke verantwoordelijkheden, welke interfacen en welke data er gewenst is. Dan dat omzetten in een klassendiagram. Dan kijken of er nog het e.e.a. te abstraheren valt voor een algemenere en flexibelere toepassing, met oog op verschillende designpatterns en dan heb je wel ongeveer een klassendiagram.

Maar dat hangt natuurlijk heel erg af van de grote van je project. Bottomline is dat klassendiagram met een laatste stap is tijdens je designfase en niet de eerste.

Verwijderd schreef op woensdag 19 januari 2005 @ 12:26:
[...]


Het gaat om het ontwerp, dat is taalonafhankelijk. Als je daar in de implementatiefase PHP voor kiest dan moet je je laten nakijken.

[ Voor 15% gewijzigd door Verwijderd op 19-01-2005 12:31 ]

[Verwijderd]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:27:
[...]


Ik heb serieus nog nooit van die techniek gehoord . De 'Commonality/Variability analyse' techniek ken ik wel. Ik moet ook zeggen dat die techniek mij ook veel geschikter lijkt. Het zoeken naar zelfstandige naamwoorden vind ik een beetje overkomen als: "ik weet niet precies hoe ik het aan moet pakken, dus dan gebruik ik maar een techniek die vaak wel werkt".

Het is de eerste-klas-ontwerpen-aanpak waarbij je woorden als Mentor, Student, Vak, Docent en Cijfer uit een verhaaltje moet halen dat de requirements van een programma voorstellen. Ja dan werkt het wel...

[Verwijderd]

whoami schreef op woensdag 19 januari 2005 @ 12:24:
[...]


Dat is een bepaalde methodiek die redelijk bekend is, maar eigenlijk heb ik 'm nog nooit toegepast.

En andere methodiek is bv 'Commonality/Variability analyse' (finding what varies and encapsulate it). Hierbij ga je oa kijken welke 'objecten' er bepaalde dingen gemeen hebben, en waarin ze van elkaar verschillen.

en welke methodiek gebruikt u
ps die commonallity /variability analyse hebt u daar informatie over

[Verwijderd]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:30:
[...]


Het is de eerste-klas-ontwerpen-aanpak waarbij je woorden als Mentor, Student, Vak, Docent en Cijfer uit een verhaaltje moet halen dat de requirements van een programma voorstellen. Ja dan werkt het wel...

Dat noem ik geen zelfstandige naamwoorden zoeken, maar entiteiten onderscheiden. Mwah, misschien pas ik het onbewust toch toe, maar weet ik niet hoe het beestje heet

[ Voor 50% gewijzigd door Verwijderd op 19-01-2005 12:32 ]

[Zoijar]

Ik denk dat het ook erg op gevoel en ervaring aan komt. Als je een probleem leest, dan zie je de objecten vaak al voor je, en meteen mogelijke design patterns... Die zelfstandig naamwoorden manier, is een beetje een "school" techniek, om je aan te leren zo te denken.

[Verwijderd]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:30:
[...]


Het is de eerste-klas-ontwerpen-aanpak waarbij je woorden als Mentor, Student, Vak, Docent en Cijfer uit een verhaaltje moet halen dat de requirements van een programma voorstellen. Ja dan werkt het wel...

Ja dat is waar. Je maakt tijdens je analyse-studie vaak ook al een soort concept voor het uiteindelijke klassendiagram. Athans, dat zou je kunnen doen, en dan is dit misschien wel een handige methode. Maar je hebt het dan nog helemaal niet over het klassendiagram die je ook daadwerkelijk gaat programmeren.

Verwijderd schreef op woensdag 19 januari 2005 @ 12:31:
[...]


(...)
ps die commonallity /variability analyse hebt u daar informatie over

/me ook in geïnterresseerd

[ Voor 16% gewijzigd door Verwijderd op 19-01-2005 12:33 ]

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:31:
[...]


en welke methodiek gebruikt u
ps die commonallity /variability analyse hebt u daar informatie over

Die commonality/variablity analyse doe je eigenlijk als je al een stapje verder bent in het proces denk ik.
Ik geloof dat er ooit eens iemand een thesis heeft over geschreven voor de VUB; je moet eens zoeken op Coplien ofzo.

Tja, hoe ga ik te werk: ik ga eerst entiteiten onderscheiden zoals Quist zegt. Dat kan door oa te kijken naar 'zelfstandige naamwoorden', maar eigenlijk komt daar ook een beetje ervaring bij kijken. Op een gegeven moment kun je eigenlijk zien van 'dit en dat worden een class, dat worden attributen, ... '.

[Verwijderd]

Een artikel over CVS.

Ik ben het met Whoami eensch, dat het gewoon op ervaring neerkomt. Elk begin is moeilijk, maar oefening baart kunst. Het onderscheiden van entiteiten is voor mij nummer 1 in het design. Vervolgens kijk ik naar deelproblemen en probeer daar oplossingen voor te bedenken met de verschillende design patterns al in het achterhoofd.

[Verwijderd]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:32:
[...]

Ja dat is waar. Je maakt tijdens je analyse-studie vaak ook al een soort concept voor het uiteindelijke klassendiagram. Athans, dat zou je kunnen doen, en dan is dit misschien wel een handige methode. Maar je hebt het dan nog helemaal niet over het klassendiagram die je ook daadwerkelijk gaat programmeren.

[...]

/me ook in geïnterresseerd

Die entiteiten zijn misschien alleen nuttig als datastructuur - slechts een klein onderdeel van je totale systeem in principe. Ik heb die aanpak ooit geleerd bij het vak inleiding informatiesystemen en het heeft daarna alleen z'n nut gehad bij het ontwerpen van databases en absoluut niet bij het ontwerpen van software.

[Creepy]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:32:
[...]

Ja dat is waar. Je maakt tijdens je analyse-studie vaak ook al een soort concept voor het uiteindelijke klassendiagram. Athans, dat zou je kunnen doen, en dan is dit misschien wel een handige methode. Maar je hebt het dan nog helemaal niet over het klassendiagram die je ook daadwerkelijk gaat programmeren.

[...]

/me ook in geïnterresseerd

http://www.google.nl/sear...ality+variability&spell=1

Wat is er gebeurd met zelf eens rondzoeken? Wat is er gebeurd met zelf je eerst flink in een topic verdiepen? Wat is er gebeurd met het commentaar van gorgi_19 op topicstart nummer 1, want daarvan zie ik bar weinig terug in de topicstart?

[Verwijderd]

Creepy schreef op woensdag 19 januari 2005 @ 12:38:
[...]

http://www.google.nl/sear...ality+variability&spell=1

Wat is er gebeurd met zelf eens rondzoeken? Wat is er gebeurd met zelf je eerst flink in een topic verdiepen? Wat is er gebeurd met het commentaar van gorgi_19 op topicstart nummer 1, want daarvan zie ik bar weinig terug in de topicstart?

Nou sorry hoor Commentaar is meer op de TS gericht dan op mij hoop ik...?

Ik zal thuis vanavond wel google doorspitten

[Verwijderd]

/me aait The_Tzar

Niet te zwaar aantrekken joh
En vanavond Google doorspitten is niet nodig. Mwah, Creepy bedoelde gewoon dat je beter eerst zelf kan zoeken naar artikelen over CVS, voordat je iets vraagt.

Nu weer even ontopic:

Verwijderd schreef op woensdag 19 januari 2005 @ 12:36:
[...]


Die entiteiten zijn misschien alleen nuttig als datastructuur - slechts een klein onderdeel van je totale systeem in principe. Ik heb die aanpak ooit geleerd bij het vak inleiding informatiesystemen en het heeft daarna alleen z'n nut gehad bij het ontwerpen van databases en absoluut niet bij het ontwerpen van software.

Hoezo zijn entiteiten alleen nuttig als klein onderdeel van je totale systeem? Ben je het niet met me eens dat het onderscheiden van entiteiten stap nummer 1 is in het hele process? Zo niet, dan ben ik erg benieuwd naar jou aanpak

[ Voor 58% gewijzigd door Verwijderd op 19-01-2005 12:53 ]

[Verwijderd]

Creepy schreef op woensdag 19 januari 2005 @ 12:38:
[...]

http://www.google.nl/sear...ality+variability&spell=1

Wat is er gebeurd met zelf eens rondzoeken? Wat is er gebeurd met zelf je eerst flink in een topic verdiepen? Wat is er gebeurd met het commentaar van gorgi_19 op topicstart nummer 1, want daarvan zie ik bar weinig terug in de topicstart?

opzoeken ik heb 4 boeken over uml waar telkens hetzelfde wordt gezegd van die zelfstandige naamwoorden
dus heb ik er me toch al in verdiept
ik heb aan de hand van de commentaar mijn topic aangepast

[Creepy]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:49:
[...]

Nou sorry hoor Commentaar is meer op de TS gericht dan op mij hoop ik...?

Ik zal thuis vanavond wel google doorspitten

offtopic:
Commentaar was zowel voor jou als de TS. Als ik namelijk commonality + variability in google intik vliegen de links me om de oren. Daarnaast zie ik documenten waarin meer methoden dan alleen deze worden behandeld. Vandaar dat ik bot reageerde op de opmerkingen "heb je daar meer info" over omdat dat makkelijk zelf te achterhalen is.

Tomvdh: Als je die achtergrond info die je al hebt kort had kunnen weergeven in je post dan was je eerste topic zeer waarschijnlijk niet eens gesloten Niets voor niets is er de quickstart waarin wordt vertelt dat je wat achtergrond info moet posten zodat je dit soort zaken gewoon uitsluit

[ Voor 3% gewijzigd door Creepy op 19-01-2005 13:09 ]

[Alarmnummer]

Verwijderd schreef op woensdag 19 januari 2005 @ 12:36:
[...]
Die entiteiten zijn misschien alleen nuttig als datastructuur - slechts een klein onderdeel van je totale systeem in principe. Ik heb die aanpak ooit geleerd bij het vak inleiding informatiesystemen en het heeft daarna alleen z'n nut gehad bij het ontwerpen van databases en absoluut niet bij het ontwerpen van software.

De entiteiten zijn de allerbelangrijkste structuren die in je systeem maar terug te vinden zijn, want dit zijn de objecten die een abstractie zijn van het probleem domein. Dus als een object belangrijk is, dan is het wel een entiteit.


Als je er meer over wilt weten, raad ik je dit boek aan.
Domain-Driven Design: Tackling Complexity in the Heart of Software

[ Voor 14% gewijzigd door Alarmnummer op 19-01-2005 13:14 ]

[Verwijderd]

Over stap 1 zijn we het dus wel eens: entiteiten onderscheiden

Ik ben benieuwd hoe de rest stap 2 aanpakt. Alarmnummer, whoami, rest... Wat doen jullie in stap 2? Ik probeer in stap twee deelproblemen te onderscheiden; onder andere relaties tussen entiteiten bepalen. Vervolgens probeer ik standaard probleem oplossingen te herkennen; design patterns.

[Verwijderd]

Creepy schreef op woensdag 19 januari 2005 @ 13:03:
[...]

offtopic:
Commentaar was zowel voor jou als de TS. Als ik namelijk commonality + variability in google intik vliegen de links me om de oren. Daarnaast zie ik documenten waarin meer methoden dan alleen deze worden behandeld. Vandaar dat ik bot reageerde op de opmerkingen "heb je daar meer info" over omdat dat makkelijk zelf te achterhalen is.

offtopic:
Je google-link was ook wel terecht, maar er zat gelijk zo'n felle reactie achter. Ik google normaal gesproken alles wat ik niet weet op, anders had ik per project aardig wat topics kunnen openen . Zo'n discussie verloopt hier alleen best snel en als normaal gesproken iets gezegd wordt wat je niet weet dan vraag je daar normaal gesproken op door.
Maargoed, dit is internet en dit is een algemene discussie, dus ja, je hebt met je google-link op zich wel gelijk
Goed, ontopic dan maar

Verwijderd schreef op woensdag 19 januari 2005 @ 13:16:
Over stap 1 zijn we het dus wel eens: entiteiten onderscheiden

Ik ben benieuwd hoe de rest stap 2 aanpakt. Alarmnummer, whoami, rest... Wat doen jullie in stap 2? Ik probeer in stap twee deelproblemen te onderscheiden; onder andere relaties tussen entiteiten bepalen. Vervolgens probeer ik standaard probleem oplossingen te herkennen; design patterns.

Stap één is de eisen voor je systeem achterhalen.
Stap 2 is de entiteiten achterhalen.
Stap drie is dan deelproblemen te onderscheiden. Ik probeer ook een beetje te kijken naar verschillende verantwoordelijkheden die je moet hebben op basis van de eisen om zo achter control-klassen te komen. Eh... dat is meer stap 4 of 5 dan.

[ Voor 30% gewijzigd door Verwijderd op 19-01-2005 13:18 ]

[Verwijderd]

hoe pakken ze zo een probleem aan in een professionele omgeving
ik heb al gehoord van zo een rollenspel dat iedereen een klasse uitbeeld enzo, zijn er nog zo van die technieken en wat denken jullie zou dit een beetje van nut kunnen zijn

[Alarmnummer]

Verwijderd schreef op woensdag 19 januari 2005 @ 13:46:
hoe pakken ze zo een probleem aan in een professionele omgeving
ik heb al gehoord van zo een rollenspel dat iedereen een klasse uitbeeld enzo, zijn er nog zo van die technieken en wat denken jullie zou dit een beetje van nut kunnen zijn

In 1e instantie gaat het erom dat jij een gemeenschappelijk vocabulair gaat vinden met de mensen waar de software voor geschreven gaat worden. Dat komt er dus op neer dat jij objecten gaat maken die een abstractie zijn van termen waar zij in denken. Dit is erg belangrijk doordat je nu ook met elkaar kunt praten..

Kom jij een order,klant,artikel,factuur tegen.. dan weet je dat de kans erg groot is dat die objecten ook in je domein model zullen terug komen. Maar er zullen ook veel objecten zijn waar je niet zo 1 2 3 op zult komen (bv Proces). En dan zal het gedeeltelijk neerkomen op inzicht/kennis. En dat moet je opdoen door ervaring en veel lezen (bij mij is het ook vaak natte vinger werk)

[ Voor 7% gewijzigd door Alarmnummer op 19-01-2005 14:00 ]

[Verwijderd]

btw een leuke topic.

ik heb ook op school geleerd te kijken naar zelfstandige naamwoorden en werkworden in de requirement die je hebt opgesteld (use case beschrijvingen en of probleem beschrijving). Vervolgens wordt er gekeken wat nou de daadwerkelijk een klasse is en welke niet. etc etc. Op deze manier te werk gaan krijg je ontzettend veel klassen.

door common & variality analyse uit te voeren zoek je naar families en welke verschillen er zijn tussen deze families. (bijvoorbeeld figuren als familie, vierkant, rondje als subklasse van deze familie). je kijkt als het ware naar het probleem.

daarnaast heb je design patterns. je kijkt naar de verantwoordelijkheden van elke klassen. welke klasse is verantwoordelijk. wat is verantwoordelijk voor wat?

naast design patterns heb je ook refactoring. er wordt ook gekeken naar verantwoordelijkheden.

ik heb op al deze onderwerpen redelijk in verdiept maar vind het nog steeds moeilijk.

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 13:46:
hoe pakken ze zo een probleem aan in een professionele omgeving
ik heb al gehoord van zo een rollenspel dat iedereen een klasse uitbeeld enzo, zijn er nog zo van die technieken en wat denken jullie zou dit een beetje van nut kunnen zijn

Zie je mij al de class Factuur ofzo spelen hier....

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 14:23:
door common & variality analyse uit te voeren zoek je naar families en welke verschillen er zijn tussen deze families. (bijvoorbeeld figuren als familie, vierkant, rondje als subklasse van deze familie). je kijkt als het ware naar het probleem.

Dat gaat dan nog iets verder door het encapsuleren van de 'commonality'.

daarnaast heb je design patterns. je kijkt naar de verantwoordelijkheden van elke klassen. welke klasse is verantwoordelijk. wat is verantwoordelijk voor wat?

Een design pattern is eerder een patroon van hoe verschillende klassen met elkaar samenwerken om een bepaald probleem op te lossen.

naast design patterns heb je ook refactoring. er wordt ook gekeken naar verantwoordelijkheden.

Refactoren is re-designen zonder functionaliteit toe te voegen. Die zin die jij hier neerzet slaat eigenlijk nergens op.

[Verwijderd]

das waar vooral als beginneling als ik is het heeeeeeeeel moeilijk
nu welke techniek gebruikt u nu voor het moment

[Orphix]

Ik vind zelf de common & variability analyse een zeer belangrijke stap. Het bepaalt namelijk in grote mate in hoeverre je design flexibel, maar uitgebreid (en misschien complexer) is, of wat minder flexibel, maar kleiner en sneller. De eeuwige trade-off natuurlijk.

C&V analyse leidt dan ook niet automatisch tot een bepaald ontwerp, het maakt de keuze die je maakt expliciet. Bijvoorbeeld: is de database afhandeling common (ga je ervan uit dat je tot in de lengte van dagen gebruik maakt van dezelfde database server), of is het variabel (mogelijkheid tot overstappen naar andere database servers)? Dat is een vrije keuze.

Na deze keuzes vind ik het altijd een stuk gemakkelijk om vervolgens functionaliteit, verantwoordelijkheden en onderlinge relaties tussen klassen te bepalen.

Het zoeken naar zelfstandige naamwoorden is inderdaad een goed startpunt, maar ik neem eigenlijk nooit expliciet deze stap. Naarmate je meer ervaring hebt ga je deze entiteiten steeds sneller onderscheiden in een situatie.

Refactoring vind ik niet echt onder OO programmeren vallen trouwens, dat is meer het idee dat je bestaande code aanpast om tot een beter design te komen.

[ Voor 1% gewijzigd door Orphix op 19-01-2005 14:36 . Reden: sneller maar doorgestreept, vallen vast mensen over ;) ]

[Verwijderd]

whoami schreef op woensdag 19 januari 2005 @ 14:31:
[...]



Zie je mij al de class Factuur ofzo spelen hier....

neen eerder order
en ik genre

[Verwijderd]

Refactoring wordt inderdaad gebruikt voor het herstructuren van bestaande applicaties etc. maar las je de verschillende refactorings technieken kent dan weet je bij het designen van een nieuwe applicatie waar je op moet letten. het help dus wel bij het designen.

ik beschouw common & variability analyse als het ware een stap voor het toepassen van design patterns. De meeste patterns maakt gebruik van families.

Design patterns zijn uiteraard oplossingen van problemen zoals whoami al zij. maar als ontwerpers een pattern ontdekt in een probleem dan weten zij ook wat voor verantwoordelijk heden zij hebben.

[whoami]

Orphix schreef op woensdag 19 januari 2005 @ 14:34:
Ik vind zelf de common & variability analyse een zeer belangrijke stap. Het bepaalt namelijk in grote mate in hoeverre je design flexibel, maar uitgebreid (en misschien complexer) is, of wat minder flexibel, maar kleiner en sneller. De eeuwige trade-off natuurlijk.

Dit vind ik zelf ook een handige techniek; echter, het is een die pas later komt kijken.
Je zult zowiezo eerst je probleem-domein moeten specifieren en de entiteiten proberen te herkennen.
Daarna kan je gaan kijken welke relaties die entiteiten met elkaar hebben, hoe ze samen werken.

C&V analyse leidt dan ook niet automatisch tot een bepaald ontwerp, het maakt de keuze die je maakt expliciet. Bijvoorbeeld: is de database afhandeling common (ga je ervan uit dat je tot in de lengte van dagen gebruik maakt van dezelfde database server), of is het variabel (mogelijkheid tot overstappen naar andere database servers)? Dat is een vrije keuze.

Tja, als je een verkeerde keuze gemaakt hebt, dan kan je altijd je ontwerp gaan her-bekijken. Echter, hoe later dat je dit doet, hoe meer het kost.
Het is dus vaak noodzaak om van in het begin idd zo flexibel mogelijk te kunnen zijn.

Na deze keuzes vind ik het altijd een stuk gemakkelijk om vervolgens functionaliteit, verantwoordelijkheden en onderlinge relaties tussen klassen te bepalen.

Het zoeken naar zelfstandige naamwoorden is inderdaad een goed startpunt, maar ik neem eigenlijk nooit expliciet deze stap. Naarmate je meer ervaring hebt ga je deze entiteiten steeds sneller onderscheiden in een situatie.

Idd, same here. Expliciet doe ik het ook niet. Echter, na ervaring weet je wel wat er zo een class kan zijn en wat niet.


Ook iets dat je in je achterhoofd moet houden: een class heeft z'n eigen verantwoordelijkheden en deze moet weten hoe die verantwoordelijkheden moeten uitgevoerd worden.
Een andere class die een relatie heeft met die class moet wel weten kunnen 'zeggen' aan die class van doe nu dit, maar hoe deze class dat moet doen moet hij niet weten. (loose coupling).
Bv, jij volgt een opleiding, en volgt een bepaalde les. Op het einde van die les zegt de docent, ok, de les is afgelopen, ga maar naar jullie volgende les. Dan hoeft die docent niet te weten wat de volgende les is van iedere student of waar die student moet zijn om z'n volgende les te volgen. De student zelf moet dat weten.

[Verwijderd]

en hoe herkennen jullie dan de attributen juist ?
want dit ligt soms toch wel dicht bij klassen dus dat je er echt gaat aan twijfelen of het nu objecten of attributen zijn

[whoami]

Verwijderd schreef op woensdag 19 januari 2005 @ 15:13:
en hoe herkennen jullie dan de attributen juist ?

In jouw genre geval, kan een genre toch wel meer zijn dan enkel een naam ?

want dit ligt soms toch wel dicht bij klassen dus dat je er echt gaat aan twijfelen of het nu objecten of attributen zijn

Een class kan attributen hebben waarvan het type een class is.

[Verwijderd]

ja dat begrijp ik maar hoe zie je dan dat die attributen eigenlijk klassen zijn ?

[Michali]

Attributen zijn alle eigenschappen van een concept/entiteit. Maar het kan ook een geaggregeerd of gecompositeerd (hoe je dat ook schijft ) object zijn. Een film heeft bijvoorbeeld een titel, een (of meerdere) regiseurs, een tijdsduur, een release datum etc...

Een titel kan een simpele string zijn terwijl een regiseur toch weer een entiteit op zich is. Maar dan nog kan het een veld worden binnen de class die een film moet representeren.

[Verwijderd]

De kracht zit hem verder in herhaling/ervaring.
Bij je eerste klassendiagrammen veranderd het klassendiagram nog naar je code tijdens de implementatie en pas na wat ervaring zul je echt bereiden dat je met je code zuiver je klassendiagram kunt volgen.
Als je ervaring hebt, weet je beter waar je op moet letten en waar je rekening mee moet houden.

Als je de klassen kunt achterhalen heb je het meeste al gedaan. De methoden is al datgene wat je moet kunnen met dat ding en de attributen zijn al die dingen je moet weten.
En als je dan later nog bedenkt dat je wat globale boolean's nodig hebt om die methoden goed te kunnen realiseren dan zijn dat nog steeds geen dingen die je nu echt mist in een klassendiagram.
Soms moet je oppassen dat je niet te technische nadenkt. Persoonlijk merk ik dat ik per fase met mijn gedachte al een fase verder neig.

[ Voor 10% gewijzigd door Verwijderd op 19-01-2005 16:06 ]

[prototype]

Goede voorbereiding is het halve(al dan niet meer) werk bij een goede OO ontwerp die ook nog bruikbaar is in de toekomst. Modeleer eerst de probleemstelling door het te vertalen in termen van objecten/klassen; abstractie en compositie zijn hierbij key. Bedenk je wat voor eigenschappen(properties) een object moet hebben en de betreffende functionaliteit die het moet hebben. Kijk of je patronen kunt herkennen of dat je nieuwe klassen kunt maken op basis van reeds bestaande klassen (zie: composition, dependencies en inheretence, doe dit overigens met 'caution', zie Law of Demeter). Ontwerp een statische klassendiagram (UML), die onderlinge relaties en verbanden tussen klassen schematisch weergeeft. Evalueer je ontwerp nog eens en begin dan pas daadwerkelijk met de implementatie.
Ga dus niet als een kip zonder kop, zonder enig benul van wat je daadwerkelijk doet in een geheel verband te werk; ik kan je bijna garanderen dat je 9/10 keren dingen dan zult moeten herschrijven. Nu is het zo dat software systemen zelden 'goed' zijn, en herschrijven ongetwijfeld wel een keer plaats zal vinden maar bovenstaande tips beperken het tot een minimum. Kennis over design patterns is zeker ook een pre; dit zijn algoritmes die door jarenlange OO ervaring door de 'gang of four' grotendeels gecatalogiseerd zijn in het gelijknamige boek Design Patterns met als doel flexibele structuren te schrijven en geloof me, structuur is key voor OO. Waarschijnlijk zul je wel wat dingen al onbewust doen, maar ze krijgen bij design patterns een naam ofwel worden toegekend aan je vocabulair. Communiceert wat makkelijker bij het ontwikkelen van een software systeem in teamverband

[ Voor 9% gewijzigd door prototype op 19-01-2005 19:39 ]