OO vs datamodellering

[Verwijderd]

Op z'n lokers, 'juuuu', op z'n nederlands: 'hoi', op z'n simpsons 'hello everybody'.

Dit is een vraag gericht naar studenten van Toegepaste Informatica studeten, of studenten die ervaring hebben in zake van UML & Ontwerpen of programeurs of analisten die daarin ervaring hebben.

Ik volg Toegepaste Informatica op Hogeschool Gent, en zit nu in m'n tweede jaar.

Gisteren op een familliefeest heb ik wat gediscussieerd met m'n broer die in de afdeling zit van een bedrijf dat software maakt voor bedrijven i.v.m. hun boekhouding, bestandsbeheer, etc...
De discussie ging over datamodellering en over object oriented werken.

Bij ons op school is OO werken alles wat de klok slaat. Ik kom nog van de voorganger, en heb daarin ervaring van VB6 & VBA (ok, geen discussie over scripttaal of programmeertaal plz.). Nu op school heb ik ervaring gekregen in Java & de manier van deftig OO werken. Verder hebben we ook nog Cobol, (de niet OO-versie, dus cobol 85).

Nu moest ik vooral wijken aan de discussiepunten dat Datamodelering beter was dan OO, omdat iedereen het beter begrijpt, dat bedrijven tenonder gaan aan OO, omdat het chaotisch is, teveel tijd kost om iemand z'n werk te begrijpen, dat er geen tijd is voor handleidingen maken en commentaar, enz... Ik kan daar wel inkomen, maar m'n broer vermelde wel dat datamodelering al gebruikt werd sinds de jaren zestig. Ik kan me moeilijk voorstellen dat zo'n oude techniek, het moet halen van de nieuwe technieken. Is het dan niet eerder zo dat de nieuwe technieken niet verkeerd worden toegepast? Ik probeer altijd een deftig nut te vinden in't geen we leren op school, om toch het gevoel te hebben dat ik iets nuttig doe, maar ik denk dat iedereen dat wel heeft.
Verder vermelde hij ook dat zijn bedrijf de race van Javapolis won, en dat andere bedrijven eindelijk hem en zijn collega's feliciteren met de techniek waarop zij programeren. ( Ze gebruiken namelijk twee tools. een casetool, en een database tool, en aan de hand daarvan, programeren die tools voor hen.) Dus die techniek zal wel voldoende zijn, maar kan dat gelinkt worden aan Borland Together for Eclipse, dat ook code genereert aan de hand van UML?

Ik hoop dat ik hier een discussie kan teweeg brengen met deftige argumenten tussen de twee partijen, zodat ik er ook iets van bijleer. Als mensen niet willen reageren omwille van het bashen en het Fanboyen van een technologie, gelieve me d an te mailen, want ik zou er graag van bijleren.

Nog een fijn weekend iedereen.

[pasta]

Dit is meer iets voor Programming & Webscripting, ik verplaats je topic dan ook even.

[NMe]

Datamodellering en OO zijn helemaal geen inwisselbare technieken. Datamodellering heeft te maken met welke methoden je gebruikt om data op te slaan, terwijl OO beschrijft hoe je programmacode/denkwijze in elkaar zit. Zeggen dat het één beter is dan het ander zou hetzelfde zijn als zeggen dat de motor van een auto beter is dan de wielen, immers zonder motor zou de auto niet rijden. Echter, zonder wielen kan die dat ook niet.

Sowieso vind ik het vreemd dat je broer zegt niet OO te werken en dat de wereld ten onder gaat aan OO, aangezien je wel Javapolis noemt. Java is een taal die puur OO is, en daarmee is de programmeur dus gedwongen om OO te werken. Niet-OO werken in Java is onpraktisch, lelijk en onduidelijk, om niet te zeggen onmogelijk, want alles zit sowieso in een klasse.

[Orphix]

Eenzelfde discussie heb ik weleens gehad met COBOL programmeurs. Hoewel puur redenerend vanuit de 'data' kant vaak gemakkelijk lijkt op het eerste gezicht blijken de probleemstelling, gebruikte terminologie en de denkwijze van zowel de klant, analist en programmeur beter aan te sluiten bij objecten die aan te wijzen zijn in het probleemdomein.

Casetools zijn trouwens ook object georienteerd. Men specificeert dat een 'factuur' object wordt weergegeven of een 'order' object kan worden ingevoerd, etc. Dat daar wellicht non-OO programmatuur uit gegenereerd wordt neemt nog niet weg dat de denkwijze object georienteerd is.

[Not Pingu]

-NMe- schreef op zondag 08 januari 2006 @ 15:08:
Sowieso vind ik het vreemd dat je broer zegt niet OO te werken en dat de wereld ten onder gaat aan OO, aangezien je wel Javapolis noemt. Java is een taal die puur OO is, en daarmee is de programmeur dus gedwongen om OO te werken. Niet-OO werken in Java is onpraktisch, lelijk en onduidelijk, om niet te zeggen onmogelijk, want alles zit sowieso in een klasse.

Zijn broer gebruikt de gewonnen race van Javapolis als anectodisch 'bewijs' van het feit dat hun manier van werken beter is.
Maar ik heb het idee dat de broer van TS eerder relationele databases en object-oriented databases door elkaar haalt. Want OO is natuurlijk op applicatieniveau een mogelijke koppeling met je datamodel.

[misfire]

Data modellering en Object Oriëntatie zijn verschillende begrippen. Wat je waarschijnlijk bedoelt is een relationeel gegevensontwerp vs een object-georienteerd gegevensontwerp.

Een relationeel gegevensontwerp is eenvoudiger dan een OO gegevensontwerp, omdat je minder modelleert: alleen gegevens en de relaties tussen gegevens. In OO modelleer je verantwoordelijkheden, en relaties tussen verantwoordelijkheden. Daarbij ga je in OO meestal met veel meer verschillende types aan de gang, en is de typering ook veel rijker (type-hiërarchie, polymorfisme). Dat is meteen ook het voordeel van OO: je kunt meer opnemen in het model en het heeft meer uitdrukkingskracht.

Wat je broer bedoelt is waarschijnlijk dat heel veel mensen als ze OO doen hun hoofd gaan breken over allerlei foefjes en patterns. Als je in OO echter moet nadenken of je iets wel of niet nodig hebt dan betekent dat één ding: dat je het niet nodig hebt. De beste manier om een OO model op te stellen is volgens een iteratieve aanpak, waarbij je steeds het model aanpast zodra je ziet dat er bepaalde behoeftes ontstaan. Veel OO modelers hebben echter de reflex om alles in één keer goed te willen doen en om maar zo veel mogelijk patterns erbij te halen, omdat ze eigenlijk niet goed nagedacht hebben over de concrete behoeftes, en dan "is het er tenminste". Iteratief werken wordt bovendien lang niet altijd op een goede manier ingevuld door management, wat met name rampzalig kan zijn voor het opstellen van een goed OO model.

De afgelopen Javapolis werd inderdaad een mini-RAD-race gehouden, waar men in 12 uur een product moest opleveren. De winnaars (er waren 3 nummer 1 winnaars) waren inderdaad Oracle Headstart producten, die niet volgens een OO principe werken, maar een soort 4GL omgeving zijn. Nu was Oracle toevallig ook hoofdsponsor van dat evenement. Als jouw broer denkt dat een mini-RAD-race representatief is voor alle software-ontwikkeling ter wereld dan is de discussie denk ik snel voorbij. Ik ben het eens dat een OO model niet altijd nuttig of goed is voor een oplossing, maar er komt veel meer bij kijken dan het goed/slecht doen op een RAD-race.

[whoami]

Een OO model kan goed zijn; mits dat dit OO model :
1) goed in elkaar steekt
2) niet over-engineered is

Een goed OO model ontwikkelen kost inderdaad tijd (en dan ook geld), maar, als het goed gedaan is, kan je model wel veel onderhoudbaarder en duidelijker zijn.

Echter, ik zie ook niet in hoe je OO en datamodellering tegenover elkaar kunt stellen ? Wat bedoel je met 'datamodellering' ? Het ontwerpen van een 'opslagstructuur' voor je data ?
Dit is idd heel iets anders; het is niet omdat je een OO domain model hebt, dat je je data daarom niet volgens het Codd/relationeel concept kunt opslaan. Er bestaan O/R mappers die die 'mismatch' voor jou kunnen oplossen. Er bestaan tegenwoordig ook OO databases, al twijfel ik of een OO database wel zo'n goed idee is.

Op school leer je nu wellicht wel de basisprincipes van OO denken / ontwikkelen. Dat heb ik ook gehad een aantal jaar geleden, echter, uit mijn ervaring kan ik je zeggen dat hetgeen je op school leert (qua OO -ttz, in mijn tijd toch-) gewoon de 'basisconcepten' zijn. Als je dan eens verder kijkt naar wat er mogelijk is in de OO wereld, dan zal je wel merken dat hetgeen je op school leert, slechts peanuts is.

[Verwijderd]

Dit is meer iets voor Programming & Webscripting, ...

hierbij mijn excuses en bedankt voor het verplaatsen

Datamodellering en OO zijn helemaal geen inwisselbare technieken...

Aha, Bedankt voor de opheldering. Ik wist dat ik op een bepaald moment dat we naast elkaar gingen praten.

//off topic

_{Java is een taal die puur OO is, en daarmee is de programmeur dus gedwongen om OO te werken...}

_{Het is toch niet zo dat als iets werkt met één klasse dat het OO is? Nuja, weer een regeltje van de schoolreglementen, dat je perfect non-OO code zou kunnen schrijven met java, of andere talen. Of is het eerder zo: Het is niet omdat je java schrijft , dat je oo kunt schrijven. Het zal zo wel bedoeld zijn.}

Men specificeert dat een 'factuur' object wordt weergegeven of een 'order' object kan worden ingevoerd, etc. Dat daar wellicht non-OO programmatuur uit gegenereerd wordt ...

Kan je me verduidelijkingen hoe van een object, (oo dus) niet oo-programeertaal wordt gemaakt? Ik denk dat ik je denkpiste snap, maar bent niet helemaal zeker.
Nu verder herinner ik me ook uit het gesprek, dat Microsoft zit achter het OO denken, en achter de eerste case tools. En wat er op een school geleerd wordt , namelijk afstamd van MS. Nu, dat bedrijf is nogal anti-ms, en zijn vooral aanhanger van IBM. En MS zou OO gepushed hebben via hun .NET omgeving door die gratis of aan goedkopere licenties aan te bieden aan hun scholen, en zo de hype (object oriented) denken de leven hebben ingeblazen. Nu ik weerlegde dat argument door te zeggen dat wij op school nogal tools gebruiken van Borland, maar MS zou belang hebben in Borland... Ik weet niet hoever ik dat moet geloven en of dit waar is.? Ik weet dat de ene technologie gepushed moet worden door een liefst zo groot mogelijk bedrijf, omdat het anders niet goed doorkomt, maar zou deze redenering kloppen dan?

Zijn broer gebruikt de gewonnen race van Javapolis als anectodisch 'bewijs' van het feit dat hun manier van werken beter is.

Hij is en blijft wel vertegenwoordiger van zijn bedrijf, dus probeert hij ook (onrechtstreeks i suppose) zijn product en manier van werken te verdedigen. Nuja, Je hebt wel gelijk. Probleem is dat je zoiets moeilijk kunt weerleggen (als student dan toch). En niet dat ik er een sport van wil maken om iets te weerleggen é

Want OO is natuurlijk op applicatieniveau een mogelijke koppeling met je datamodel

Inderdaad, nu herinner ik 't me. Zij werken aan de hand van je datamodel, zo uit naar je applicatie. Dus ze denken een heel datamodel uit, en daaraan wordt pas je applicatie gekoppeld (wat logisch is). Maar dit is dan toch ook OO? Ik leer hier nu ook trouwens OO van Laarman, en daarin heb ik toch gezien dat je werkt met drie lagen, UI, domein, en persistentie. En je geeft inderdaad de persistentie mee aan je domein. Nu werkt dat bedrijf anders, éénmaal de perisitentie ( database dus) af is, wordt namelijk je applicatie ver automatisch daaruit opgebouwd via zo'n casetool. Je hebt ook een andere filosofie volgens mijn broer (ik kan die niet verifiëren wegen gebrek aan kennis) en dat je eerst je applicatie schrijft, en dan een weerspiegeling schrijft van je applicatie in je database. Maar dat zou niet de bedoeling zijn, en zou trager werken. Klinkt deze manier van denken enigzins bekend in jullie oren? zoja, hebben jullie daar nog info over?

Veel OO modelers hebben echter de reflex om alles in één keer goed te willen doen en om maar zo veel mogelijk patterns erbij te halen, omdat ze eigenlijk niet goed nagedacht hebben over de concrete behoeftes, en dan "is het er tenminste".

De programeurs die in contact komen met m'n broer zouden dezelfde manier van denken hebben. Zij rechtvaardigen die manier, omdat ze éénmaal zitten in een project, van bovenaf al een ander project krijgen dat ook moet worden afgewerkt, en dat ze geen tijd hebben omdaar allemaal geld aan te besteden. En vervolgens ook geen tijd hebben voor commentaar in hun code. (is dat in alle bedrijven zo, geen commentaar/ geen tijd voor handleidingen/ etc...? dat zou ik héél jammer vinden.)

De afgelopen Javapolis werd inderdaad een mini-RAD-race gehouden, waar men in 12 uur een product moest opleveren. De winnaars (er waren 3 nummer 1 winnaars) waren inderdaad Oracle Headstart producten, die niet volgens een OO principe werken, maar een soort 4GL omgeving zijn...

Inderdaad, blijkbaar is er één op de hoogte!
Nu een vraagje over Oracle. Het bedrijf maakt gebruik van Oracle Forms. Maar nu dacht ik toch dat Forms! was gabasseerd op een Java Virtual Machine omgeving. Ben ik hier nu zo verkeerd in? Dat had ik toch opgemaakt uit de dat product van Oracle.

Een OO model kan goed zijn; mits dat dit OO model :
1) goed in elkaar steekt
2) niet over-engineered is

Een goed OO model ontwikkelen kost inderdaad tijd (en dan ook geld), maar, als het goed gedaan is, kan je model wel veel onderhoudbaarder en duidelijker zijn.

Ok, dus blijkbaar zijn er dus nadelen aan OO. Een bedrijf wilt zoveel mogelijk geld verdienen en zoveel mogelijk kosten uitsparen. Ik weet vandaar te werken als vakantiejobstudent dat inderdaad onderhoudbaarheid belangrijk is in een product. Dus OO is dus een dure ontwikkeling voor een bedrijf? Zal de opvolger van OO zich dan daar niet vooral op gaan specificieren zodat meer bedrijven de opkomende technologie beter gaan toepassen, en ook snel en efficient kan? Want zoals je aanhalat, kost blijkbaar goed OO geld, en geld geven ze niet graag uit, en kost blijkbaar ook tijd, en tijd is geld, en ...

[ Voor 1% gewijzigd door Verwijderd op 08-01-2006 20:08 . Reden: corrected tags ]

[.oisyn]

Verwijderd schreef op zondag 08 januari 2006 @ 20:07:
Nu verder herinner ik me ook uit het gesprek, dat Microsoft zit achter het OO denken, en achter de eerste case tools. En wat er op een school geleerd wordt , namelijk afstamd van MS. Nu, dat bedrijf is nogal anti-ms, en zijn vooral aanhanger van IBM. En MS zou OO gepushed hebben via hun .NET omgeving door die gratis of aan goedkopere licenties aan te bieden aan hun scholen, en zo de hype (object oriented) denken de leven hebben ingeblazen. Nu ik weerlegde dat argument door te zeggen dat wij op school nogal tools gebruiken van Borland, maar MS zou belang hebben in Borland... Ik weet niet hoever ik dat moet geloven en of dit waar is.? Ik weet dat de ene technologie gepushed moet worden door een liefst zo groot mogelijk bedrijf, omdat het anders niet goed doorkomt, maar zou deze redenering kloppen dan?

Pfffff, wat een kul zeg. OO bestond al lang voor .Net, en OO op scholen was er ook al lang voor .Net. Wellicht dat er op een aantal scholen pas OO wordt gedoceerd sinds .Net er is, maar dan lagen die scholen sowieso al achter en waren ze nodig aan vernieuwing toe. MS is er zeker niet de uitvinder van, en al zou dat zo zijn dan is het nog altijd ontzettend kinderachtig om het te negeren omdat het van MS af komt. Het is een dom argument en een slap excuus en getuigt allesbehalve van professionaliteit.

Oh, en als concurrent op het gebied van compilers en IDE's heeft Microsoft echt geen belang in Borland hoor

[ Voor 11% gewijzigd door .oisyn op 09-01-2006 02:59 ]

[whoami]

Zoals .oisyn al zegt, OO bestond al van voor MS bestond.
Smalltalk (wat beschouwd wordt als de eerste OO - taal), kende z'n ontstaan in de jaren '70. MS heeft 'OO' helemaal niet 'uitgevonden'.
En eigenlijk vind ik niet dat MS 'OO' echt pushed, aangezien zij -voor hun enterprise applicaties- vooral hameren met hun (typed) datasets (wellicht dat dit toch in de nabije toekomst veranderd).

ij werken aan de hand van je datamodel, zo uit naar je applicatie. Dus ze denken een heel datamodel uit, en daaraan wordt pas je applicatie gekoppeld (wat logisch is). Maar dit is dan toch ook OO

Je hebt verschillende 'paradigma's'. Eén dat nu algemeen aanvaard is, en wellicht ook het meest gebruikt is, is dat je idd eerst je datamodel opzet, en vandaaruit dan vertrekt naar je applicatie.
Een ander paradigma is echter 'domain driven design', waar je eerst je 'domein-model' gaat opbouwen (je classes en de relaties daartussen dus, waar je applicatie mee zal werken), en dan pas gaat kijken naar je data-model. Dit wil dan echter niet zeggen dat je data-model een volledige weerspiegeling is van je domain-model. Je zal je data nog steeds op een zo efficiënt mogelijke manier gaan opslaan, maar, wel met je domain model in je achterhoofd.

En vervolgens ook geen tijd hebben voor commentaar in hun code. (is dat in alle bedrijven zo, geen commentaar/ geen tijd voor handleidingen/ etc...? dat zou ik héél jammer vinden.)

Dat zou idd heel jammer, en een grote fout zijn.
Ikzelf probeer m'n code zo 'self-documenting' mogelijk te maken: intention revealing interface, voldoende (nuttig!) commentaar (dus niet iedere regel gaan commentariëren, maar bij een method gaan beschrijven wat die method doet, bij functionele blokken indien nodig een stukje uitleg schrijven, etc....).

Dus OO is dus een dure ontwikkeling voor een bedrijf?

Dat heb ik niet gezegd. Als je een applicatie hebt die goed opgezet is, betaald dat zich terug in onderhoudbaarheid en flexibiliteit.

_{waar werkt jouw broer als ik vragen mag ?}

[NMe]

Verwijderd schreef op zondag 08 januari 2006 @ 20:07:
En vervolgens ook geen tijd hebben voor commentaar in hun code. (is dat in alle bedrijven zo, geen commentaar/ geen tijd voor handleidingen/ etc...? dat zou ik héél jammer vinden.)

Iemand die, naast al die andere rare opmerkingen en vergelijkingen die je noemt, ook nog eens zegt geen tijd te hebben voor commentaar is lang niet zo professioneel als hij zich voordoet. Commentaar schrijven bespaart juist tijd, wanneer het goed geschreven wordt. Natuurlijk kost het voor de schrijver ervan even wat meer moeite, maar stel je voor dat je 2 maanden later die code nog eens door moet nemen en aanpassen zonder commentaar...daar gaat je tijdwinst hoor, want die gaat dan ineens zitten in het opnieuw begrijpen van je eigen code.

[Feyd-Rautha]

Het is toch niet zo dat als iets werkt met één klasse dat het OO is? Nuja, weer een regeltje van de schoolreglementen, dat je perfect non-OO code zou kunnen schrijven met java, of andere talen. Of is het eerder zo: Het is niet omdat je java schrijft , dat je oo kunt schrijven. Het zal zo wel bedoeld zijn.

Java is geen pure OO-taal, maar het is eerder een hybride taal. Pure OO-talen zijn enkel gebaseerd op de OO principes. Daarmee wordt dus bedoeld: een pure OO-taal kent alleen maar de noties van objecten, message-sends, inheritance, ... . Een IF/WHILE/...-structuur in een pure OO-taal is daarom ook geen speciale constructie, maar (in het geval van SmallTalk, welke een pure OO-taal is) een message-send naar een Boolean-object. Een IF in Java is een speciale constructie die door de compiler een beetje bewerkt wordt. Bijvoorbeeld ook alle primitive datatypes zijn objecten in pure OO-talen. En niet zoals in Java dat je wrappers hebt rond je datatypes.

Hybride talen hebben een niet OO-model, die uitgebreid is met OO concepten. Zoals C++ een oo-uitbreiding is van C.

In Java kun je perfect op een niet-OO manier applicaties schrijven. In SmallTalk is zou dat praktisch onmogelijk moeten zijn.

[ Voor 19% gewijzigd door Feyd-Rautha op 09-01-2006 10:14 ]

[Michali]

-NMe- schreef op maandag 09 januari 2006 @ 09:16:
[...]

Iemand die, naast al die andere rare opmerkingen en vergelijkingen die je noemt, ook nog eens zegt geen tijd te hebben voor commentaar is lang niet zo professioneel als hij zich voordoet. Commentaar schrijven bespaart juist tijd, wanneer het goed geschreven wordt. Natuurlijk kost het voor de schrijver ervan even wat meer moeite, maar stel je voor dat je 2 maanden later die code nog eens door moet nemen en aanpassen zonder commentaar...daar gaat je tijdwinst hoor, want die gaat dan ineens zitten in het opnieuw begrijpen van je eigen code.

Een beetje commentaar is goed, maar niet te veel. Het meeste moeite moet gestoken worden in het maken van begrijpelijke code (voor zover het domein voor de programmeur begrijpbaar is natuurlijk). Als zaken dat nog niet helder zijn kan er een stukje commentaar bij geschreven worden. Meestal behoeft begrijpelijke code weinig commentaar. En code veranderd, en commentaar wordt niet altijd in sync gehouden met de code. Dat kan het ook gevaarlijk maken. Maar deze discussie hebben wel laatst nog gehad. Dus terug ontopic

[4of9]

Word er niet bedoelt dat een (relationeel) Datamodel niet 1 op 1 mapt op een OO ontwerp.

Er wordt veel gebruik gemaakt van OO applicaties met een onderliggend relationeele database.
Dit gaat altijd ergens wringen want die 2 zijn niet 'compatible' met elkaar, met als gevolg dat je of in je OO ontwerp wat aanpassingen moet maken die niet geheel OO meer zijn of in de je datamodel zodat deze niet helemaal relationeel meer is. (dat is iig mijn ervaring)

[qless]

Ik denk dat het zeer moeilijk is om een programmeer race te winnen door zeer zuiver OO te doen. 4GL talen hebben dan zeer zeker een voordeel, net als Quick and Dirty oplossingen.

OO vindt ik echter beter, zeker als je een (goed) ontwerp hebt, en is ook beter onderhoudbaar.

[bille]

naar mijn idee staan OO en datamodelleren helemaal los van elkaar. OO Modelleren doet men doorgaans om:

• complexe processen in kaart te brengen
• herbruikbaarheid van code te realiseren
• het mogelijk te maken design patterns te gebruiken
• eenvoudig abstracties te implementeren als "multi-tier architectuur"
• etc

daar je gaat datamodelleren om:

• informatie persistent te maken
• redundantie in data-opslag te voorkomen
• etc

Naar mijn idee zijn dat los staande zaken.

[whoami]

bille schreef op maandag 09 januari 2006 @ 11:55:
naar mijn idee staan OO en datamodelleren helemaal los van elkaar. OO Modelleren doet men doorgaans om:

• complexe processen in kaart te brengen
• herbruikbaarheid van code te realiseren
• het mogelijk te maken design patterns te gebruiken
• eenvoudig abstracties te implementeren als "multi-tier architectuur"
• etc

Het gebruiken van design patterns is geen doel op zich. Het is een middel om je code duidelijker / begrijpbaarder te maken, maar het mag niet de bedoeling zijn om 'het gebruiken van design patterns' een doel te maken.

[.oisyn]

Daarnaast zijn design patterns natuurlijk niet inherent OO, het zijn gewoon gestandaardiseerde oplossingen voor bepaalde problemen, en die kun je in een procedurele omgeving net zo goed hebben.

[ Voor 3% gewijzigd door .oisyn op 09-01-2006 12:11 ]

[bille]

De reden dat ik dat argument heb opgenomen is de volgende: een groot probleem (imho) is dat er vaak eigenzinnige oplossingen worden bedacht om een bepaald probleem op te lossen. Op zich natuurlijk niets mis mee, dat doen we allemaal.

Echter zijn er problemen die reeds opgelost zijn en beschikbaar zijn in de vorm van een heel aantal "design patterns" (en ja ik weet dat er ook design patterns zijn die niet een probleem oplossen. Verdere nuancering omtrent verschillende design patterns gaat me in dit topic te ver.. al ben ik het niet eens met de stelling dat design patterns er zijn om code duidelijker te maken ). Met die gedachte zou je er voor kunnen kiezen om OO te gaan ontwerpen. Je voorkomt valkuilen waar anderen al in zijn getuimeld (en creeërt er waarschijnlijk zelf een aantal waarvoor je zelf een design pattern zal bedenken).

In die zin is het kunnen toepassen van design patterns geen doel, maar wel een argument (en thus misschien ook wel overbodig in het lijstje dat ik gaf ).

[Michali]

Design Patterns zijn eigenlijk het natuurlijke resultaat van het op de juiste manier toepassen van bepaalde principes. In het geval van OO zijn dat dan de fundamentele principes die je moet kennen wil je echt effectief kunnen werken op een dergelijke manier. Design Patterns maken het ook gemakkelijker om die principes te leren en los van de patterns zelf toe te passen. In mijn geval heeft dat zeker geholpen.

Ook zijn het geen kant-en-klare oplossingen voor problemen. Eerder een zetje in de goede richting, tonend hoe een bepaald probleem opgelost kan worden op een acceptabel nette manier. Laat je je echter de verkeerde kant op duwen en gebruik je patterns waar het niet toepasselijk is, dan werkt het eerder in je nadeel dan in je voordeel.

Design Patterns kunnen je code absoluut duidelijker maken, omdat je kunt zien voor wat voor ontwerp gekozen is. Als je bekend bent met de pattern, dan heb je veel sneller door hoe het in elkaar steekt. Daarbij is het wel van belang dat de redenen achter het gebruik van de patterns juist zijn en hij ook effectief toegepast is. Het moet een logische oplossing zijn voor het probleem. Als dat niet zo aanvoelt is het vaak ook niet goed. Ook niet geheel onbelangrijk (behoorlijk belangrijk zelfs) is dat je over het ontwerp kunt praten in de vorm van de gebruikte patterns, dat maakt het voor de ander ook duidelijker (als hij de patterns kent natuurlijk). Je code moet daarbij natuurlijk ook communiceren dat er zo'n pattern is gebruikt, anders raakt dat effect ook snel verloren.

[H!GHGuY]

hoi mede-student aan de Hogeschool Gent
Ik volg echter geen toegepaste informatica maar Industrieel Ingenieur Informatica.

Wij krijgen lessen Systeem Analyse van Jan Cnops en hij heeft ook zijn eigen boek geschreven waaruit hij doceert. boek: Systeemontwerp en -realisatie, Jan Cnops, ISBN 90-209-6130-6
Op zich geen slecht boek, het is de docent die... never mind Je kan het hem voor zijn verjaardag cadeau doen (jijzelf kan het mss wel in de bib van school vinden)

Datamodellering is een deel van het ontwerp, terwijl OO een manier van realisatie van een ontwerp is.
Je kan perfect een OO-gericht ontwerp in een niet-OO taal gieten, maar daar schiet je weinig mee op aangezien je dan wel OO moet nabootsen natuurlijk.

Datamodellering komt grotendeels overeen met het statisch model in UML en is dan ook heel eenvoudig van daaruit om te zetten in een OO-klassenstructuur. OO-ontwerp is imo een evolutie die je niet kan laten links liggen als ze mogelijk is. Je kan namelijk de verantwoordelijkheid van klassen/objecten heel nauw definieren. Dit is in een niet-OO ontwerp minder zo.
(een veld in een C-struct is van gelijk waar zomaar aangepast)

Ik kan me niet inbeelden dat een modern bedrijf waar mogelijk niet met OO werkt en betwijfel dan ook aan de kwaliteit van hun producten. Ik verwonder me gelijk ook over het feit dat ze met een (moderne?) CASE-tool werken (en data modellering doen) en dan niet OO werken.
OO stimuleert namelijk van nature uit hergebruik van code wat in de meeste gevallen ook een mooie tijdswinst kan opleveren. En dan reken ik de tijd van documentatie mee.

Volgens mij ligt het probleem eerder in de structuur van het bedrijf en hun manier van werken.
Als zij niet genoeg tijd hebben om EN te coden EN hun te documenteren EN hun code te testen, dan zijn ze misschien fout bezig?

Dit alles tenzij ik natuurlijk niet genoeg info heb uit de startpost om conclusies zoals deze te trekken
(waar werkt je broer trouwens?)

[misfire]

Verwijderd schreef op zondag 08 januari 2006 @ 20:07:
[...]

De programeurs die in contact komen met m'n broer zouden dezelfde manier van denken hebben. Zij rechtvaardigen die manier, omdat ze éénmaal zitten in een project, van bovenaf al een ander project krijgen dat ook moet worden afgewerkt, en dat ze geen tijd hebben omdaar allemaal geld aan te besteden. En vervolgens ook geen tijd hebben voor commentaar in hun code. (is dat in alle bedrijven zo, geen commentaar/ geen tijd voor handleidingen/ etc...? dat zou ik héél jammer vinden.)

Geen tijd hebben voor voldoende documentatie is in principe een drogreden, want je bespaart er juist tijd mee op de langere termijn. De vraag is alleen: wat is "voldoende informatie"? Ik vind het bijvoorbeeld persoonlijk veel belangrijker dat code goed gestructureerd is en goed automatisch wordt getest dan dat er overal commentaar staat. Voor mij is de structuur van de applicatie en tests ook een heel belangrijke bron van informatie.

Inderdaad, blijkbaar is er één op de hoogte!
Nu een vraagje over Oracle. Het bedrijf maakt gebruik van Oracle Forms. Maar nu dacht ik toch dat Forms! was gabasseerd op een Java Virtual Machine omgeving. Ben ik hier nu zo verkeerd in? Dat had ik toch opgemaakt uit de dat product van Oracle.

Ik zat in de zaal toen ze de prijs uitreikten. Oracle Forms is inderdaad (nu) gebaseerd op Java. Ik zou het echter niet als OO bestempelen, maar eerder als een soort 4GL tool zien.

Ik zou verder ook niet al te veel focussen op één modelleertechniek. Een modelleertechniek is een stuk gereedschap en geen doel op zich. Net zoals een hamer voor sommige problemen heel handig is en voor andere problemen een schroevendraaier efficiënter is. Het is ook zeker niet ongebruikelijk om zowel een relationeel model als een objectmodel op te stellen.

Het doel van een model opstellen zou niet moeten zijn om lekker duur te doen en geld te verspillen, maar om op een hoog niveau problemen op te lossen en zaken te structureren, waardoor je geld bespaart en een beter resultaat hebt. Dan is het wel handig om eerst goed na te denken wélke modelleertechnieken je wilt gebruiken en op welke manier. Daar is een goede kennis voor nodig en wat ervaring hoe je dit moet doen (dus geen ervaring hoe het niét moet).

In de praktijk blijkt dat OO een ingewikkelder gereedschap is waar men eerder de plank mee misslaat. Dit wordt extra gevoed door opleidingen en tool vendors die je laten geloven dat je product per definitie shit is als je geen OO doet. Een gemiddeld software ontwikkelproject kent talloze factoren die de kwaliteit van het resultaat beïnvloeden, en ik denk dat factoren als goed/slecht management, plannen, geautomatiseerd testen een veel grotere stempel drukken op de kwaliteit van het eindresultaat.