Hoe een goed software-ontwerp maken?

[Morax]

Jullie zullen wel denken, daar is weer zo'n topic, maar deze is net iets anders imho. Het sleutelwoord is namelijk goed.

Ik kan namelijk JAVA programmeren. Ik ken de OO principes, ik ken de taal, heb redelijke kennis van de libraries en durf wel te zeggen dat ik kan programmeren. Ook ken ik de principes achter Generics, interfaces, polymorfisme en kan deze ook toepassen.

Wat mijn vraag dan is? Ik heb moeite met het ontwerpen van een algemene architectuur van een applicatie. Welke klassen geef ik welke verantwoordelijkheid? Welke klassen geef ik een instantie van welke andere klassen? Ik heb het gevoel dat mijn huidige niveau namelijk ondermaats is, en dat een professionele java programmeur mij uit zou lachen als hij ziet hoe ik mijn applicaties bouw.

Het gaat met name om de koppeling tussen mijn UI, en de achterliggen klasses die het werk moeten doen. Hoe krijg ik het op een nette manier voor elkaar, dat wanneer ik op een knop druk een van de achterliggen klasses daarvan op de hoogte word gesteld en zijn ding gaat doen?

Bij het zoeken naar tutorials kom ik eigenlijk alleen maar Java tutorials tegen. Hoe programmeer je in JAVA, wat zijn de OO principes, tutorials over hoe ik een interface in SWING ontwerp en dergelijke, maar echte tutorials over het goed opbouwen van een applicatie met een goede structuur mis ik eigenlijk.

Dus, heeft iemand hier een suggestie welk boek ik zou moeten aanschaffen of welke on-line tutorial ik hiervoor zou kunnen gebruiken?

Het gaat dus voornamelijk om logische applicatiestructuur, delegatie van verantwoordelijkheden (en vooral het waarom), en met name ook de koppeling tussen UI en Business Logica. En dan het liefst met goede voorbeelden.

Ik sta open voor alle suggesties, en alvast bedankt voor eventuele input

_{Verkeerde forum Topic-move naar PRG is reeds aangevraagd}

[ Voor 3% gewijzigd door een moderator op 05-03-2008 10:40 ]

[Arne]

Misschien dat wanneer het voornamelijk om de koppeling tussen (G)UI en backend gaat dat je eens op het MVC-model (moddeler, viewer, controlen) zou moeten googlen (of hoe je dat ook spelt).

[RobIII]

Heb je hier al eens in gekeken?
[Alg] Centraal boekentopic - part II

[ Voor 28% gewijzigd door RobIII op 05-03-2008 10:38 ]

[JHS]

→ PRG .

[Anoniem: 140111]

Misschien een goed idee om eens wat over design patterns aan te schaffen. Ik zou beginnen met Head First Design Patterns (laat je niet afschrikken door de rare layout, ik vind het een erg prettig boek, het leest lekker weg en blijft goed hangen) om daarna het GoF boek te tackelen. In het centrale boekentopic staat overigens nog een schat aan designtechnischinformatieveboekentitels.

[ Voor 5% gewijzigd door Anoniem: 140111 op 05-03-2008 08:20 ]

[Webgnome]

Ik worstel ook altijd tijdens huis/tuin en keuken projectjes die ik doe met dit soort vragen. Ik heb al het nodige aan documentatie/tutorials en boeken door gelezen maar er is echter nooit een eenduidig antwoord gekomen op deze vraag:

"Mag ik een model-class gebruiken om data op te halen binnen GUI classes". Hier mee bedoel ik eigenlijk het volgende (heb helaas geen visio oid in de buurt):

Stel dat ik een view heb die extends van een JFrame (met daarin collectie van panels.. ) die via een controller aan mijn model geknoopt zit. In dit model bevindt zich een clas genaamd "fiets". Ik wil informatie kunnen tonen van deze "fiets" binnen mijn view. Mag de controller het fiets object naar de GUI sturen in de update of is het om wat voor reden beter om hier een array oid voor te gebruiken?

Het is een vraag die denk ik wel aansluit op die van jou wat betreft verantwoordelijkheden.

[TUX2K]

Webgnome schreef op woensdag 05 maart 2008 @ 08:25:
Ik worstel ook altijd tijdens huis/tuin en keuken projectjes die ik doe met dit soort vragen. Ik heb al .....

Dit is altijd een groot discusie punt, maar ik heb het volgende idee er bij.
De controler weet hoe hij het model moet vullen en view hoe hij het model moet weergeven.
Als de view een commando naar de controler stuurd, via aan delegate, event of wat dan ook dan stuurd de update functie van de controler de view weer aan om de gegvens te verversen.
Zo kan een controler meerdere views hebben die allemaal worden bij gewerkt.

En naatuurlijk mag de controler de het model doorsturen, het is tenslote de OO representatie van je data.

[whoami]

Domain Driven Design, tackling complexity in the heart of software kopen.
Lezen, herlezen, toepassen, herlezen, nieuwe inzichten toepassen, boel wegsmijten, herlezen, etc...

[Kwistnix]

Twijfelen aan de aanpak/werkwijze en het gevoel hebben dat "iets" altijd "beter" kan, daar heeft iedereen in meer of mindere mate wel last van (gehad), denk ik. Volgens mij is dat een goed iets, want het stimuleert je om je telkens verder te ontwikkelen en je niet te beperken tot reeds bekende kunstjes.
Het kan ook zeker nadelig zijn als je zo aan jouw manier van denken/werken gaat twijfelen, dat je bij voorbaat al opgeeft, omdat je het probleem toch niet, of niet op "de juiste manier" kunt oplossen.
Daar moet je denk ik voor wel voor oppassen. Het perfectionisme loslaten en gewoon accepteren dat ieder leerproces (want dat is en blijft het) gepaard gaat met vallen en opstaan.
De beste manier om je door te ontwikkelen is door dingen te doen. Boeken lezen helpt zeker, maar de kennis die je daar mee opdoet moet je wel praktisch toepassen, anders maak je het je niet eigen en heb je er uiteindelijk niets aan. Collega's (medestudenten/op het werk/vakidioten met een weblog/technische fora) zijn ook een belangrijke bron van informatie en praktische ervaring.
Ik vind niet dat je de vraag "Hoe leer ik goed programmeren?" eenvoudige kan beantwoorden met een verwijzing naar een boek.

[ Voor 5% gewijzigd door Kwistnix op 05-03-2008 10:12 ]

[The - DDD]

Simpel, ervaring opdoen. Ok niet zo simpel dan.

Applicatie structurering en architectuur wordt nooit simpel. Het blijft altijd een kwestie van afwegingen en keuzes maken.

[Donderwolk]

Ik denk dat je hier zoals gezegd het meeste kunt winnen in een korte tijd door je eens in Design Patterns te verdiepen. Voor elk probleem is er een manier hoe je het beste de koe bij de hoorns kunt vatten.

Deze design patterns zou je in verschillende categorien kunnen groeperen. Je kunt ze toepassen op verschillende niveaus van je ontwerp. Zie ook dit linkje. Waar je voor op moet passen zoals eerder ook al is gezegd is over-engineering. Soms is het pragmatischer om géén design pattern toe te passen.

[ Voor 15% gewijzigd door Donderwolk op 05-03-2008 10:15 ]

[GrooV]

Niettes

[ Voor 89% gewijzigd door RobIII op 05-03-2008 10:39 ]

[flowerp]

TUX2K schreef op woensdag 05 maart 2008 @ 09:25:
[...]
De controler weet hoe hij het model moet vullen en view hoe hij het model moet weergeven.
Als de view een commando naar de controler stuurd, via aan delegate, event of wat dan ook dan stuurd de update functie van de controler de view weer aan om de gegvens te verversen.
Zo kan een controler meerdere views hebben die allemaal worden bij gewerkt.

Dit is natuurlijk maar 1 aspect van wat de TS vraagt, maar wel een belangrijk punt. MVC in de traditionele zin van het woord (lees in desktop applicaties) is wel op punten anders als hoe het momenteel in web applicaties wordt geïmplementeerd.

Omdat we het toch over Java hebben neem ik even JSF als uitgangspunt (zit standaard in Java). Hierbij schrijf je zelf niet de controller. Deze wordt geleverd door JSF. Ook kun je als model of als controller niet een referentie hebben naar de view. In traditioneel MVC kan dat wel. Als een model daar wordt geupdate, kan die zelfstandig de view(s) hiervan op de hoogte brengen. Nu zijn er in de web wereld wel wat dingen zoals Comet die hier na toe werken, maar het is nog allemaal erg jong.

Vervolgens definieert Java (JSF) nog een 4de entiteit: de backing bean. Traditioneel MVC kent dit concept ook niet. Sommige mensen denken dat de backing bean de controller is. Andere mensen zien in de backing bean het model zelf, en weer andere mensen zien het als de programma logica van de view (b.v. vanwege de isRender() dingen en de programmatische formatting die je er in kunt doen).

IMHO is de backing bean echter gewoon een 4de ding. Een glue class tussen de model, view en controller in, die vanwege de manier waarop het web werkt (request based), en de manier waarop we in een web applicatie onze view willen samenstellen (XML/HTML layouts ipv programmatisch) nodig is.

[durian]

Ik mis een belangrijp aspect - je moet er ook talent voor hebben- Je kan nog zoveel boeken lezen, maar dan blijf je IMHO toch in het 'painting by numbers' steken. Je moet toch een bepaalde creativiteit bezitten om daar uit te springen, om goede, mooie en elegante oplossingen te zien voor een probleem.

[Haan]

durian schreef op woensdag 05 maart 2008 @ 10:25:
Ik mis een belangrijp aspect - je moet er ook talent voor hebben- Je kan nog zoveel boeken lezen, maar dan blijf je IMHO toch in het 'painting by numbers' steken. Je moet toch een bepaalde creativiteit bezitten om daar uit te springen, om goede, mooie en elegante oplossingen te zien voor een probleem.

Ik denk dat talent vooral helpt bij het snel oppaken van de materie. Uiteindelijk leer je toch door te doen en dat kan iemand met minder talent ook, alleen duurt het langer en kost het meer moeite om tot hetzelfde niveau te komen.

[whoami]

FallenAngel666 schreef op woensdag 05 maart 2008 @ 10:04:
Ik vind niet dat je de vraag "Hoe leer ik goed programmeren?" eenvoudige kan beantwoorden met een verwijzing naar een boek.

TS vroeg niet echt naar 'hoe leer ik goed programmeren', hij vroeg eerder hoe hij kan leren hoe een goede structuur op te zetten.
Een boek alleen gaat het idd niet doen. Het boek waar ik naar verwijs, kan echter wel helpen. Maar, dan moet je het ook lezen, doornemen, toepassen, leren van de dingen die je toepast, etc...
Maar één boek is idd nooit 'de heilige graal'. Je moet ervaring opdoen, leren van anderen, leren van je fouten, etc...

GrooV schreef op woensdag 05 maart 2008 @ 10:15:
[...]


Niettes

Idd, en dergelijke reacties geven niet echt krediet om er in te kunnen.

[ Voor 46% gewijzigd door een moderator op 05-03-2008 10:39 ]

[Kwistnix]

whoami schreef op woensdag 05 maart 2008 @ 10:35:
[...]

TS vroeg niet echt naar 'hoe leer ik goed programmeren', hij vroeg eerder hoe hij kan leren hoe een goede structuur op te zetten.

Same difference. Dat is ook niet iets wat je onder de knie hebt na het lezen van een paar gerenommeerde boeken over het onderwerp.

Edit: Ja hoor, snel editen

[ Voor 4% gewijzigd door Kwistnix op 05-03-2008 10:38 ]

[NMe]

Theorethische discussies als deze lijken me iets meer op zijn plek in Software Engineering & Architecture.

PRG>>SEA

[whoami]

FallenAngel666 schreef op woensdag 05 maart 2008 @ 10:37:
[...]


Same difference. Dat is ook niet iets wat je onder de knie hebt na het lezen van een paar gerenommeerde boeken over het onderwerp.

Edit: Ja hoor, snel editen

geef me gewoon ff de tijd om m'n reply af te maken ja
Moet je zo snel niet zijn.



/offtopic.

[flowerp]

Haan schreef op woensdag 05 maart 2008 @ 10:28:
[...]
Ik denk dat talent vooral helpt bij het snel oppaken van de materie. Uiteindelijk leer je toch door te doen en dat kan iemand met minder talent ook, alleen duurt het langer en kost het meer moeite om tot hetzelfde niveau te komen.

Ik ben het er mee eens dat inzet een wat minder talent zeker ruimschoots kan vervangen. Iemand die echt zeer gemotiveerd is om de materie onder de knie te krijgen en daar veel tijd en energie in steekt, komt in de regel verder dan iemand met talent, maar die er weinig moeite voor doet.

Het werkt natuurlijk wel tot op zekere hoogte. Als je op een bepaald punt echt talent of mentale capaciteit te kort schiet dan blijft het toch idd bij "painting by numbers".

Ik heb b.v. een jongen in mijn team zitten. Echt een schat van een gozer, die ook al lang met Java bezig is (8 jaar). Echter, hij mist gewoon het talent dat een developer verteld hoe de verantwoordelijkheden verdeeld moeten worden over de diverse delen (meestal classes) van een applicatie.

Na 8 jaar weet ie wel hoe Java werkt, maar in de regel kwam alles bij hem in 1 grote class. We hebben meerdere gesprekken gehad met hem om uit te leggen dat ie de dingen meer over diverse kleine classes moet verdelen die één ding doen, en dat éne ding dan ook goed doen (het mantra: low coupling, high cohesion). Echter telkens weer presteert ie het om dingen die logisch gezien bij elkaar horen apart te zetten, en dingen die logisch gezien niets met elkaar te maken hebben bij elkaar. De naamgeving geeft dan ook telkens precies -niet- weer wat de essentie is van een class. Na klachten van andere programmeurs ben ik weer met hem om de tafel gaan zitten en de frustratie is van z'n gezicht af te lezen: "Maar ik gebruik toch meerdere classes nu!". Het is duidelijk dat het geen onwil is, maar dat ie gewoon echt het talent mist om een logische abstractie te kunnen maken.

[Kwistnix]

flowerp schreef op woensdag 05 maart 2008 @ 10:56:
Het is duidelijk dat het geen onwil is, maar dat ie gewoon echt het talent mist om een logische abstractie te kunnen maken.

Om daar even op in te haken; dat is ook wel het lastige aan OOP.
In triviale systemen, of systemen waarbij Objecten min of meer direct aansluiten op fysieke entiteiten of ingeburgerde concepten (binnen een bepaal domein) is het opzetten van een OO structuur die aan de loose coupling / high cohesion doelstelling voldoet een relatief eenvoudig logisch / inzichtelijk proces.
Hoe meer je naar het abstracte toe beweegt, hoe minder inzichtelijk die opdeling wordt. Niet iedereen is goed in abstract denken. Ik weet ook niet of je zoiets echt kan leren. Denken in objecten sluit tot op zekere hoogte goed aan bij de manier waarop mensen de wereld zien, maar iets abstracts vertalen naar een object structuur (met een goede scheiding van verantwoordelijkheden) is niet zo vanzelfsprekend.

[ Voor 12% gewijzigd door Kwistnix op 05-03-2008 11:21 ]

[flowerp]

FallenAngel666 schreef op woensdag 05 maart 2008 @ 11:11:
Om daar even op in te haken; dat is ook wel het lastige aan OOP.
[...]
Hoe meer je naar het abstracte toe beweegt, hoe minder inzichtelijk die opdeling wordt.

Inderdaad. Ik ben zelf al best een poosje actief in de software ontwikkeling, heb een opleiding en ook mee kunnen kijken bij mensen met talent en ervaring. Toch blijf ik het zelf ook moeilijk vinden. Ik kan af en toe wel eens erg lang, tot wel dagen over een class diagram gebogen zitten om te bepalen waar bepaalde functionaliteit nu het best thuis hoort. Precies zoals je zegt, hoe meer je naar abstracte functionaliteit gaat, hoe minder inzichtelijk het wordt en des te meer opties heb je. Dingen als: "Hoort functie X nu bij een 'manager class' van class Y, of moet functie X uitgevoerd worden door een specifieke client van die manager class?". In het business domain kun je die vragen dikwijls snel oplossen, maar in het abstracte domain kan dat erg lastig zijn.

Niet iedereen is goed in abstract denken. Ik weet ook niet of je zoiets echt kan leren.

Waarschijnlijk is dat moeilijk. Je kunt er wat mee oefenen, maar als het -echt- niet in je zit... Zelf ben ik b.v. totaal amuzikaal. Ik zou wel zangles kunnen nemen, maar de kans dat ik ooit tot een popster uitgroei lijkt me zeer, zeer klein.

[corné]

Ik vind dat een applicatie alleen maar onoverzichtelijker wordt als je traditioneel MVC gebruikt in desktop applicaties. Vooral als je maar 1 view gebruikt waardoor het nut een beetje wegvalt.
En het beste leer je het toch door ervaring. Probeer gewoon verschillende design patterns uit en kijk wat jij het beste en makkelijkste vind werken.

[ Voor 28% gewijzigd door corné op 05-03-2008 12:49 ]

[The - DDD]

Opvallend vind ik wel dat er gelijk met design patterns gegooid wordt in dit topic.

Zo van: "Ga maar is dat GOF boek lezen." Op zich nuttig, maar besef wel dat design patterns op zich niet het doel zijn. Die dingen ontstaan juist om om tekortkomingen van een taal, framework, toolkit of paradigma heen te komen.

Hoe je leert ontwerpen te maken is echt in mijn beleving een kwestie van het gewoon doen. Maak maar gewoon iets op een manier die jou handig lijkt en loop tegen de beperkingen van je keuzes aan. Lees, evalueer en verbeter.

Ook moet je je bij zo'n leer proces niet blind staren op het maken van een formeel ontwerp. Het gaat om je gedachtengang en het creatieve proces. Probeer op zoveel mogelijk manieren naar een probleem te kijken. Niet alleen in code of UML. Teken ook plaatjes.

Begin globaal en zoom in. Klader is een paier vol met hoe je de zaken op systeem niveau wil verdelen. Veel meer dan wat doosjes kinder tekeningetjes enzo hoeft het niet te zijn. Praat erover. Laat het af en toe even liggen. Zoek oplossingen voor vergelijkbare problemen op internet en in literatuur.

Belangrijkste om te beseffen is dat het maken van een ontwerp geen exact proces is. Het is creatief, maar op een andere manier dan artistiek tekenen, beeldhouwen of architectuur. Niemand begint met de oplossing duidelijk voor ogen. Een oplossing ontstaat uit trial and error, ervaring, domein kennis en kennis van je gereedschap.

Hoe vaak ik al niet iets heb moeten ontwerpen en achter mijn PC gewoon geen idee had om vervolgens tijdens de middag pauze of onder het kladeren op een papiertje tot een idee voor de oplossing ben gekomen weet ik inmiddels al niet meer.

Ookal denken veel mensen van wel, informatica en automatisering is geen exacte wetenschap.

[Anoniem: 140111]

Zo van: "Ga maar is dat GOF boek lezen." Op zich nuttig, maar besef wel dat design patterns op zich niet het doel zijn. Die dingen ontstaan juist om om tekortkomingen van een taal, framework, toolkit of paradigma heen te komen.

Klopt helemaal, maar de TS gaf aan de taal en de OO begrippen an-sich goed te beheersen en gaf ook aan dat hij meer wilde weten over ontwerpen en architectuur. Een volgende logische stap lijkt me dan ook zeker om eens te kijken hoe er met bepaalde problemen die je tegenkomt in je ontwerp om kán gaan, vandaar design patterns.

Ik beweer ook niet dat ze een doel op zich zijn, maar ze bieden wel degelijk inzicht in hoe de mannen van het afgelopen decennium (en eerder) om zijn gegaan met bepaalde (alledaagse) problemen.

Nadat ik er een boek over had gelezen was ik écht wel beter in staat beter met bepaalde verantwoordelijkheden en de plaatsing van bepaalde verantwoordelijkheden om te gaan.

Ook moet je je bij zo'n leer proces niet blind staren op het maken van een formeel ontwerp. Het gaat om je gedachtengang en het creatieve proces. Probeer op zoveel mogelijk manieren naar een probleem te kijken. Niet alleen in code of UML. Teken ook plaatjes.

Plaatjes tekenen moet je sowieso blijven doen imho, als je gelijk gaat kloppen ben je fout bezig

[flowerp]

corné schreef op woensdag 05 maart 2008 @ 12:46:
Ik vind dat een applicatie alleen maar onoverzichtelijker wordt als je traditioneel MVC gebruikt in desktop applicaties.

Juist ja, dus jij gaat business logic in de paint methode van een widget zetten? Veel suc6 met je ontwerpen dan zou ik zeggen.

Vooral als je maar 1 view gebruikt waardoor het nut een beetje wegvalt.

Dat is natuurlijk de klassieke fout en tegelijk de klassieke drogreden.

Ten eerste blijven veel applicaties niet bij 1 view (1 scherm, 1 dialoog, 1 pagina, whatever). Applicaties hebben de neiging om te groeien. Het grote gevaar is dat je de mentaliteit dat "het geen nut heeft omdat je toch maar 1 view gebruikt" vast blijft houden. Als je applicatie opeens 30.000 regels is (dit is nog steeds relatief klein) dan bevind je je opeens in 1 grote spaghetti hoop. Moet je dan aanpassingen maken dan weet niemand meer welke code wat en hoe beïnvloed.

Ten tweede is het feit dat het voor een hele kleine applicatie misschien niet nodig is, geen reden om het concept als geheel te verwerpen. Dat je op je fiets geen helm op hoeft omdat het met een gangetje van 15km/uur niet zoveel nut heeft, betekent niet dat het op een motor die 120km/uur gaat nog steeds niet zoveel nut heeft.

Ik beweer ook niet dat ze een doel op zich zijn, maar ze bieden wel degelijk inzicht in hoe de mannen van het afgelopen decennium (en eerder) om zijn gegaan met bepaalde (alledaagse) problemen.

Vergeet de vrouwen niet

[ Voor 8% gewijzigd door flowerp op 05-03-2008 13:19 ]

[Anoniem: 140111]

flowerp schreef op woensdag 05 maart 2008 @ 13:17:
[...]


Vergeet de vrouwen niet

Excuses

[Morax]

arne schreef op woensdag 05 maart 2008 @ 01:27:
Misschien dat wanneer het voornamelijk om de koppeling tussen (G)UI en backend gaat dat je eens op het MVC-model (moddeler, viewer, controlen) zou moeten googlen (of hoe je dat ook spelt).

Met PHP gebruikt ik het MVC model altijd, niet b ij stil gestaan dat het een algemeen design pattern is en dus ook in JAVA toepasbaar is

FallenAngel666 schreef op woensdag 05 maart 2008 @ 10:04:
Twijfelen aan de aanpak/werkwijze en het gevoel hebben dat "iets" altijd "beter" kan, daar heeft iedereen in meer of mindere mate wel last van (gehad), denk ik. Volgens mij is dat een goed iets, want het stimuleert je om je telkens verder te ontwikkelen en je niet te beperken tot reeds bekende kunstjes.
Het kan ook zeker nadelig zijn als je zo aan jouw manier van denken/werken gaat twijfelen, dat je bij voorbaat al opgeeft, omdat je het probleem toch niet, of niet op "de juiste manier" kunt oplossen.
Daar moet je denk ik voor wel voor oppassen. Het perfectionisme loslaten en gewoon accepteren dat ieder leerproces (want dat is en blijft het) gepaard gaat met vallen en opstaan.
De beste manier om je door te ontwikkelen is door dingen te doen. Boeken lezen helpt zeker, maar de kennis die je daar mee opdoet moet je wel praktisch toepassen, anders maak je het je niet eigen en heb je er uiteindelijk niets aan. Collega's (medestudenten/op het werk/vakidioten met een weblog/technische fora) zijn ook een belangrijke bron van informatie en praktische ervaring.
Ik vind niet dat je de vraag "Hoe leer ik goed programmeren?" eenvoudige kan beantwoorden met een verwijzing naar een boek.

Ik verwacht ook niet 1 boek te kopen, te lezen en dat ik dan meteen een goede Java programmeur ben. Waar ik wel last van heb, is dat ik het gevoel heb dat ik ondermaats bezig ben, maar ik loop vast in hoe en waar ik me kan verbteteren. Ik hoop dus wel een (of meerdere) boek(en) te kunnen aanschaffen, welke mij een handvat geven om mezelf te verbeteren en mij inzicht te geven in hoe ik applicaties beter kan structureren

whoami schreef op woensdag 05 maart 2008 @ 10:35:
[...]

TS vroeg niet echt naar 'hoe leer ik goed programmeren', hij vroeg eerder hoe hij kan leren hoe een goede structuur op te zetten.
Een boek alleen gaat het idd niet doen. Het boek waar ik naar verwijs, kan echter wel helpen. Maar, dan moet je het ook lezen, doornemen, toepassen, leren van de dingen die je toepast, etc...
Maar één boek is idd nooit 'de heilige graal'. Je moet ervaring opdoen, leren van anderen, leren van je fouten, etc...

En dat is ook precies wat ik van plan ben. Zo ben ik namelijk 'goed' geworden met PHP. Zelf klooien, fouten maken en verbeteren. Uiteindelijk inzien hoe mijn eigen code beter kan en dat dan ook wijzigen. Na een dergelijk traject 4 jaar met plezier en motivatie te volgen durf ik best te zeggen dat ik goed PHP kan programmeren

FallenAngel666 schreef op woensdag 05 maart 2008 @ 11:11:
[...]


Om daar even op in te haken; dat is ook wel het lastige aan OOP.
In triviale systemen, of systemen waarbij Objecten min of meer direct aansluiten op fysieke entiteiten of ingeburgerde concepten (binnen een bepaal domein) is het opzetten van een OO structuur die aan de loose coupling / high cohesion doelstelling voldoet een relatief eenvoudig logisch / inzichtelijk proces.
Hoe meer je naar het abstracte toe beweegt, hoe minder inzichtelijk die opdeling wordt. Niet iedereen is goed in abstract denken. Ik weet ook niet of je zoiets echt kan leren. Denken in objecten sluit tot op zekere hoogte goed aan bij de manier waarop mensen de wereld zien, maar iets abstracts vertalen naar een object structuur (met een goede scheiding van verantwoordelijkheden) is niet zo vanzelfsprekend.

Dat is dus ook waar ik nu een beetje tegenaan loop. De tutorials die OO uitleggen, komen altijd met van die overduidelijke voorbeelden van abstracte klasse dier, met als child dan hond en kat en dergelijke. Maar op het moment dat het abstract word, heb ik er ook best moeite mee welke klasses ik moet maken en welke verantwoordelijkheid ik waar leg.

[whoami]

Morax schreef op woensdag 05 maart 2008 @ 17:22:
[...]
En dat is ook precies wat ik van plan ben. Zo ben ik namelijk 'goed' geworden met PHP. Zelf klooien, fouten maken en verbeteren. Uiteindelijk inzien hoe mijn eigen code beter kan en dat dan ook wijzigen. Na een dergelijk traject 4 jaar met plezier en motivatie te volgen durf ik best te zeggen dat ik goed PHP kan programmeren

Hmm, maar als je 'goed' geworden bent door zelf te klooien / zelfstudie, hoe ben je dan zeker dat je goed bezig bent ?
Heb je iemand die je op 'WTF's gewezen heeft, en je gewezen heeft op de slechte gewoontes die je aangeleerd hebt, en hoe het wel moet ?
En als je zo iemand hebt, hoe weet je dan dat die persoon het wel bij het rechte eind had ?

[Alarmnummer]

Een van de meest belangrijke boeken voor mij en mijn enterprise (java) kennis (dus ook het aansluiten van ui's) is "Patterns of Enterprise Application Architecture" van Martin Fowler. Design patterns zijn erg nuttig, maar vaak pas je ze toe op een veel lager niveau. Met architectural patterns kun je ook op een veel hoger niveau met standaard structuren werken (het begint interessant te worden als je probleem niet standaard is btw). "Domain Driven Design" en "Enterprise Integration Patterns" zijn ook hele interessante boeken als je het boek van Fowler kunt waarderen.

Maar naast het leren is het ook een stuk ervaring: zorg dat je bij een bedrijf komt waar je je kennis kunt uitbouwen. Er zijn genoeg bedrijven waar je terecht kunt als je laat zien dat je een bepaalde drive hebt om te groeien. Kennis is dan ondergeschikt. Ik zit zelf zo nu en dan bij sollicitatie gesprekken en assessments en ik zie het liefst een spirit in de ogen... kennis pomp je er snel genoeg in.

Peper in de ogen en vuur in de kont... of was het nou andersom...

[ Voor 9% gewijzigd door Alarmnummer op 05-03-2008 18:03 ]

[corné]

flowerp schreef op woensdag 05 maart 2008 @ 13:17:
[...]


Juist ja, dus jij gaat business logic in de paint methode van een widget zetten? Veel suc6 met je ontwerpen dan zou ik zeggen.


[...]


Dat is natuurlijk de klassieke fout en tegelijk de klassieke drogreden.

Ten eerste blijven veel applicaties niet bij 1 view (1 scherm, 1 dialoog, 1 pagina, whatever). Applicaties hebben de neiging om te groeien. Het grote gevaar is dat je de mentaliteit dat "het geen nut heeft omdat je toch maar 1 view gebruikt" vast blijft houden. Als je applicatie opeens 30.000 regels is (dit is nog steeds relatief klein) dan bevind je je opeens in 1 grote spaghetti hoop. Moet je dan aanpassingen maken dan weet niemand meer welke code wat en hoe beïnvloed.

Ten tweede is het feit dat het voor een hele kleine applicatie misschien niet nodig is, geen reden om het concept als geheel te verwerpen. Dat je op je fiets geen helm op hoeft omdat het met een gangetje van 15km/uur niet zoveel nut heeft, betekent niet dat het op een motor die 120km/uur gaat nog steeds niet zoveel nut heeft.


[...]


Vergeet de vrouwen niet

Ik bedoelde niet alles in 1 klasse, maar meer iets van M(VC) als je swing gebruikt. Dus model los en view en controller in 1.
Maar ik doe zelf wel zoveel mogelijk MVC dus ik probeer niet te zeggen dat ik het hele concept onzin vind

[Webgnome]

En dat is nou net het probleem. De controller is niet voor niks los van een view. Zover ik het begrepen heb is de controller namelijk de handle van de view om te communiceren met het model.

[Orphix]

Webgnome schreef op woensdag 05 maart 2008 @ 20:14:
En dat is nou net het probleem. De controller is niet voor niks los van een view. Zover ik het begrepen heb is de controller namelijk de handle van de view om te communiceren met het model.

Alle interpretaties van MVC hebben een opsplitsing in de drie ontkoppelde concepten (maar dit is self-fulfilling natuurlijk als je het MVC noemt), maar de verantwoordelijkheden van elk concept en de onderlinge afhankelijkheid is helaas niet eenduidig gedefinieerd waardoor het hele MVC denken een beetje wazig is geworden.

Zie bijvoorbeeld van martin fowler:
MVC (view/controller afhankelijk van elkaar en view kan model updaten) en
Passive View (Of Model View Presenter) waarbij controller model en view aanstuurt, maar view niet de controller. En de view de model niet kan updaten.


Dit staat btw los van jouw opmerking van de opsplitsing, wat altijd een goed idee is. Dit is meer een pre-emptive opmerking om holy wars te voorkomen

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 95% gewijzigd door Ruudjah op 01-12-2009 22:29 ]

[whoami]

Mwoah. Expert C# Business Objects heeft wel een paar goede ideeën, maar de aangeboden oplossing is ook niet heilig of de heilige graal ofzo.

[Tuxie]

[Kwistnix]

Tuxie schreef op maandag 10 maart 2008 @ 13:19:
[afbeelding]

Waarschijnlijk zijn veel mensen het hier mee oneens, maar dit vind ik een boek waar te vaak onterecht aan gerefereerd wordt. Overgewaardeerd zou ik het niet durven noemen, maar een be all, end all referentie over hoe je tot een goed software ontwerp komt is het gewoon niet naar mijn mening.
Wat biedt dit boek meer dan een uitleg over wat design patterns zijn en een catalogus van veel toegepaste design patterns? Absoluut nuttig en verplicht leesvoer, maar aan samenhang wordt verder geen aandacht besteed; het blijft los zand. Het boek Pattern Oriënted Software Architecture: A System Of Patterns doet het op dat gebied wat beter. Toch is ook dat niet echt een boek dat je van kaft tot kaft kan lezen, waarna je een goede indruk hebt over hoe je een software systeem dient te ontwerpen.

[Anoniem: 140111]

Tuxie schreef op maandag 10 maart 2008 @ 13:19:
[afbeelding]

Ik zou toch, zeker als je nog niet thuis bent in de materie, beginnen met Head First.

[Webgnome]

Anoniem: 140111 schreef op maandag 10 maart 2008 @ 13:56:
[...]

Ik zou toch, zeker als je nog niet thuis bent in de materie, beginnen met Head First.

Ook voor iemand die wel thuis is in de materie (al zegt ie hetzelf..) is dit een goed boek voor "Hoe zdat dat ook alweer ' momenten

[ Voor 6% gewijzigd door Webgnome op 10-03-2008 15:00 ]

[Anoniem: 140111]

Ik verkeer nog meer in de fase dat ik het nog niet zo goed weet allemaal, dus daar kan ik nog niet over meepraten

[Michali]

Design Patterns is toch zeker wel een essentieel boek. De patterns die erin besproken worden zijn echt behoorlijk fundamenteel voor allerlei zaken. Het is een lastig boek als je nog niet zo thuis bent in OO en patterns. Toen ik het de eerste keer las ging veel toch wel langs me heen. Nu, een aantal jaar later, ben ik de meeste patterns toch wel meester, en begrijp ik pas echt in hoeveel zaken je ze ziet terug komen. Om dan een boek te hebben waarin dit allemaal besproken wordt is wel heel fijn, essentieel eigenlijk.

[Anoniem: 140111]

Michali schreef op maandag 10 maart 2008 @ 15:59:
Design Patterns is toch zeker wel een essentieel boek.

Natuurlijk, maar niet altijd even eenvoudig te begrijpen voor mensen. Daarom zeg ik ook: begin met Head First en koop daarna GoF

Overigens van de week Domain Driven Design & Patterns of Enterprise Application Architecture binnengekregen, ben benieuwd

[ Voor 18% gewijzigd door Anoniem: 140111 op 10-03-2008 16:04 ]

[Tuxie]

FallenAngel666 schreef op maandag 10 maart 2008 @ 13:54:
[...]


Waarschijnlijk zijn veel mensen het hier mee oneens, maar dit vind ik een boek waar te vaak onterecht aan gerefereerd wordt. Overgewaardeerd zou ik het niet durven noemen, maar een be all, end all referentie over hoe je tot een goed software ontwerp komt is het gewoon niet naar mijn mening.
Wat biedt dit boek meer dan een uitleg over wat design patterns zijn en een catalogus van veel toegepaste design patterns? Absoluut nuttig en verplicht leesvoer, maar aan samenhang wordt verder geen aandacht besteed; het blijft los zand. Het boek Pattern Oriënted Software Architecture: A System Of Patterns doet het op dat gebied wat beter. Toch is ook dat niet echt een boek dat je van kaft tot kaft kan lezen, waarna je een goede indruk hebt over hoe je een software systeem dient te ontwerpen.

Ok, ik ben het met je eens dat dit boek meer een 'best practice' is. Overigens vind ik dit boek zeker veplichte kost voor elke IT'er.

Als je meer een boek zoekt over 'hoe je tot een goede architectuur komt', kun je deze proberen:



Overigens is de opleiding Software Engineering op de Universiteit Twente erg gericht op het construeren van software architecturen. Hier worden ook methodes ontwikkeld, zoals 'Synthesis based software architecture'. Google daar maar eens op, daar kun je ook een hoop informatie uithalen...

[Michali]

Anoniem: 140111 schreef op maandag 10 maart 2008 @ 16:03:
Natuurlijk, maar niet altijd even eenvoudig te begrijpen voor mensen. Daarom zeg ik ook: begin met Head First en koop daarna GoF

Ik heb zelf Design Patterns Explained als ondersteuning gehad. Legt heel mooi uit hoe je vanuit basis OO principes vanzelf bij de patterns uitkomt. Het laat je de patterns dus als het ware zelf ontdekken door op een nette manier te ontwerpen. Heeft mij erg geholpen.

Verder legt het boek Agile Software Development, Principles & Patterns ook de patterns heel goed uit, maar gaat veel verder dan dat. Heeft ook een mooi overzicht van een aantal belangrijke ontwerp principes.

Overigens van de week Domain Driven Design & Patterns of Enterprise Application Architecture binnengekregen, ben benieuwd

Erg goede boeken ook. Je kunt ook eens kijken naar Data Access Patterns kijken. Die sluit op zich mooi aan op PEAA, overlapt een klein beetje, maar introduceert wel een aantal mooie concepten.

[Anoniem: 140111]

Data Access Patterns

Die had ik toevallig laatst geleend van de mediatheek op school, maar ben er niet aan toe gekomen hem helemaal door te spitten. Het is bij vluchtig doorbladeren gebleven. Snel nog maar eens lenen dan

Ik heb zelf Design Patterns Explained als ondersteuning gehad.

Nog niet gelezen, maar is wel een aanrader dus?

Ik vind het altijd een beetje lastig om te bepalen wat nu weer te lezen, laatst: http://www.amazon.com/Fra...Development/dp/0321246756 gelezen, maar dat vond ik (op het moment) niet echt meerwaarde bieden. Beetje open deuren gevoel kreeg ik erbij.

[ Voor 27% gewijzigd door Anoniem: 140111 op 10-03-2008 16:39 ]

[Alarmnummer]

Anoniem: 140111 schreef op maandag 10 maart 2008 @ 16:36:
Nog niet gelezen, maar is wel een aanrader dus?

Het hebben van boeken betekent niet je ze ook meester bent.

Ik zou eerst maar eens proberen om PEAA en DDD goed te begrijpen (lees ook in de praktijk toepassen). Ik lees nog regelmatig 'oude' boeken en haal er keer op keer een schat aan informatie uit.

[EfBe]

Waarom zou een boek of patterns in vredesnaam 'essentieel' of 'verplicht' moeten zijn? Patterns zijn helemaal niet zo belangrijk. Het punt is nl. dat wanneer je in patterns denkt je niet snapt waar ze de oplossing voor zijn: pas ze alleen toe wanneer je het probleem waar het pattern de oplossing (of beter: de default design oplossing) voor is in jouw project voordoet. ANDERS NIET.

Lees "Code Complete" van Steve McConnell. Dat biedt genoeg stof tot nadenken en het zelf vormen van een mening hoe iets wel en niet gedesigned moet worden.
--------------------------

Je kunt ook eens kijken naar Data Access Patterns kijken. Die sluit op zich mooi aan op PEAA, overlapt een klein beetje, maar introduceert wel een aantal mooie concepten.

Om wat te doen? Fowler cs. kunnen dagen bomen over de meest onzinnige oplossingen voor problemen die er helemaal niet zijn. Het toppunt van ironie vind ik altijd dat Fowlerianen en DDD-aanhangers heel erg hard bezig zijn met het wegdesignen en wegprogrammeren van plumbing code, maar .... dat doen ze dan wel met ... plumbing code: grote, complexe designs waar helemaal NIETS in gebeurt wat maar enige relatie heeft met business rules of dedicated functionaliteit voor het project wat moet worden opgeleverd.

Zou dat de reden zijn waarom Fowler naar Ruby is overgestapt en niets meer wil weten van static typed languages (dus bedenk je dat wel wanneer je zn boeken leest)

Alarmnummer schreef op maandag 10 maart 2008 @ 17:55:
Ik zou eerst maar eens proberen om PEAA en DDD goed te begrijpen (lees ook in de praktijk toepassen). Ik lees nog regelmatig 'oude' boeken en haal er keer op keer een schat aan informatie uit.

"DDD" begrijpen? Wat valt er aan te begrijpen, behalve dat je moet zorgen dat iedereen over dezelfde dingen praat wanneer er termen worden gebruikt? Evans zelf heeft geen antwoord op een essentiele vraag die iedere DDD-er vroeg of laat tegenkomt: moet een entity nu wel of niet references naar repositories hebben?

[ Voor 17% gewijzigd door EfBe op 10-03-2008 18:08 ]

[Kwistnix]

Tuxie schreef op maandag 10 maart 2008 @ 16:04:

[...]

Overigens vind ik dit boek zeker veplichte kost voor elke IT'er.

Als je meer een boek zoekt over 'hoe je tot een goede architectuur komt', kun je deze proberen:

[afbeelding]

Dat het verplichte kost is ben ik met je eens.
Overigens heb ik het boek dat jij aanhaalt hier naast mij op de boekenplank staan
Samen met Software Engineering 7 van Sommerville was dat verplichte lectuur voor de module Software Architecture op de Hogeschool Zeeland.

[Michali]

Je moet absoluut uitkijken met Design Patterns. Maar juist met het lezen van de juiste boeken kom je hier veel sneller achter. Waarom Design Patterns imo. essentieel zijn? Omdat het je inzicht geeft in de ervaring van mensen die al vrij lang oplossingen bedenken voor OO problemen. En van die ervaring kun je best veel leren. Natuurlijk kun je dit op je eigen houtje ook allemaal leren, maar als je zo kennis opdoet uit een boek, dan is dat wel prettig.

Dan ben je er natuurlijk nog niet, want de praktijk is altijd anders dan wat je in de boeken leest, maar dit zul je hoe dan ook meemaken, of je nu deze boeken leest of niet. Het toepassen van technieken vereist altijd een leerweg, die vaak toch wel moeizaam is.

Juist die Design Patterns Explained is daarom heel erg goed. Dit boek begint namelijk met de basis principes van OO design en legt daarna aan de hand van verschillende problemen uit waarom de bijbehorende pattern een goede oplossing is. Op deze manier leer je vooral te denken van die principes en niet gelijk aan een pattern te denken. Ik merk zelf ook vaak dat ik een oplossing bedenk, en er pas later achterkom dat het eigenlijk een van de patterns is, of een variant ervan.

PEAA en Data Access Patterns bevatten helemaal niet zo veel onzin oplossingen. Ik werk bijvoorbeeld veel met PHP, waarvoor imo. niet zo veel sterke ORM pakketten zijn. Ik schroef dan zelf wat in elkaar waarbij ik deze kennis goed kan gebruiken. Ik kan zo iets op maat maken dat precies aan mijn eisen voldoet. En ik overengineer daarbij helemaal niets.

Die Code Complete die je noemt is natuurlijk een heel sterk boek. Die is ook gewoon essentieel natuurlijk.

[Morax]

Hmmm, ik zie dat er nu wel erg veel boeken genoemd worden. Een boek over Design Patterns stond sowieso al op mijn lijstje van boeken die ik nog weleens zou willen aanschaffen, dus die komt er sowieso wel gok ik
Daarnaast wil ik dan nog een boek aanschaffen over ontwerpen in het algemeen.

Er werden geloof ik 3 boeken genoemd over Design Patterns:
Design Patterns
Design Patterns, Elements of Reusable Object Oriented Software
Head First

Daarnaast worden er een aantal andere boeken genoemd op het gebied van software design:
Domain-Driven Design: Tackling Complexity in the Heart of Software
Patterns of Enterprise Application Architecture
Software Architecture in Practise
Code Complete

Van dit lijstje boeken zou ik niet weten welke ik nou het beste kan nemen....

[ Voor 14% gewijzigd door Morax op 10-03-2008 19:05 ]

[Michali]

Code Complete hoe dan ook, en ik zou deze als eerste nemen. Daarna een Design Patterns introductie boek, zoals Head First, of die Explained waar ik het over had.

Daarna een van de andere boeken, volgorde maakt dan op zich niet zo veel uit.

[Morax]

Wat is dat Code Complete boek dan precies? Als ik die moet lezen voor ik uberhaupt ga beginnen aan een boek over design patterns of software architectuur, vraag ik me af waar dat over gaat dan

Ik zie net overigens ook dat er een Head First versie is over design in het algemeen:
Head First Object-Oriented Analysis and Design, is dat misschien nog wat ?

[Anoniem: 140111]

Ik denk dat je die eigenlijk nog vóór patterns zou 'moeten' lezen.

[Michali]

Lees maar eens een aantal reviews op Amazon, die leggen het wel uit.

[RobIII]

Morax schreef op maandag 10 maart 2008 @ 19:11:
Wat is dat Code Complete boek dan precies?

Kom op zeg...

quote: http://www.nl.bol.com/is-...scription&Section=BOOK_EN

For more than a decade, Steve McConnell, one of the premier authors and voices in the software community, has helped change the way developers write code'and produce better software. Now his classic book, CODE COMPLETE, has been fully updated and revised with best practices in the art and science of constructing software. Whether you're a new developer seeking a sound introduction to the practice of software development or a veteran exploring strategic new approaches to problem solving, you'll find a wealth of practical suggestions and methods for strengthening your skills. Topics include design, applying good techniques to construction, eliminating errors, planning, managing construction activities, and relating personal character to superior software. This new edition features fully updated information on programming techniques, including the emergence of Web-style programming, and integrated coverage of object-oriented design. You'll also find new code examples'both good and bad'in C++, Microsoft(r) Visual Basic(r), C#, and Java, though the focus is squarely on techniques and practices.

Hoe moeilijk was dat?

Vind ik overigens wel een aanrader en zou ik idd gebruiken als 'basis' voordat je aan andere boeken begint.

[ Voor 6% gewijzigd door RobIII op 10-03-2008 19:23 ]

[Oguz286]

Geweldig, dit topic! Net wat ik nodig had. Ik was altijd een persoon die gewoon ging programmeren zonder een plan, zonder klassen, zonder documentatie, totdat ik eindelijk doorhad dat het gewoon niet werkt op deze manier. Zodra je een programma hebt dat langer dan een paar honderd regels is, kom je al in de problemen zonder een goed plan.

Om toch wat waarde aan mijn post toe te voegen: Als je denkt (semi)complexe programma's te kunnen schrijven uit je bolle hoofd, zonder een design, dan denk je verkeerd. Een goed design is meer dan de helft van het werk.

Ik zeg dit omdat ik vroeger nooit het nut zag van bijv. MVC, abstractie, design enz. omdat het allemaal zoveel tijd kost en ik dat een verspilling van tijd vond (ja, het klinkt ongelovelijk, i know ), maar ervaring leert wel dat ontwerpen toch een stuk lastiger en belangrijker kan zijn/is dan een programma schrijven. Om jezelf een programmeur / software-engineer te noemen moet je m.i. toch wel minstens goede designs kunnen maken en daarom vind ik mezelf dan ook geen programmeur. Low level kan ik wel aardig goed programmeren (asm, C en dat soort ongein), maar als ik een echte applicatie zou willen schrijven...

[ Voor 14% gewijzigd door Oguz286 op 10-03-2008 19:42 ]

[Morax]

Goed, de boeken "Code Complete" en "Head First Design Patterns" heb ik net besteld, ben benieuwd. Daarna alleen nog even kijken welk software architectuur boek ik ga aanschaffen

In ieder geval bedankt voor alle input tot zover!

Edit:

Oguz286 schreef op maandag 10 maart 2008 @ 19:38:
Geweldig, dit topic! Net wat ik nodig had. Ik was altijd een persoon die gewoon ging programmeren zonder een plan, zonder klassen, zonder documentatie, totdat ik eindelijk doorhad dat het gewoon niet werkt op deze manier. Zodra je een programma hebt dat langer dan een paar honderd regels is, kom je al in de problemen zonder een goed plan.

Om toch wat waarde aan mijn post toe te voegen: Als je denkt (semi)complexe programma's te kunnen schrijven uit je bolle hoofd, zonder een design, dan denk je verkeerd. Een goed design is meer dan de helft van het werk.

Ik zeg dit omdat ik vroeger nooit het nut zag van bijv. MVC, abstractie, design enz. omdat het allemaal zoveel tijd kost en ik dat een verspilling van tijd vond (ja, het klinkt ongelovelijk, i know ), maar ervaring leert wel dat ontwerpen toch een stuk lastiger en belangrijker kan zijn/is dan een programma schrijven. Om jezelf een programmeur / software-engineer te noemen moet je m.i. toch wel minstens goede designs kunnen maken en daarom vind ik mezelf dan ook geen programmeur. Low level kan ik wel aardig goed programmeren (asm, C en dat soort ongein), maar als ik een echte applicatie zou willen schrijven...

Erg herkenbaar! En precies de reden dat ik mezelf dus wil verbeteren, met een aantal boeken als basis van die ontwikkeling.

[ Voor 75% gewijzigd door Morax op 10-03-2008 19:47 ]

[Alarmnummer]

EfBe schreef op maandag 10 maart 2008 @ 18:06:
Waarom zou een boek of patterns in vredesnaam 'essentieel' of 'verplicht' moeten zijn?

Omdat je daarmee fundamenteel gedachtengoed kweekt. Patterns zijn niet de oplossing, maar een belangrijke stap die iedere zichzelf respecterende software ontwikkelaar een keer moet nemen.

Patterns zijn helemaal niet zo belangrijk. Het punt is nl. dat wanneer je in patterns denkt je niet snapt waar ze de oplossing voor zijn: pas ze alleen toe wanneer je het probleem waar het pattern de oplossing (of beter: de default design oplossing) voor is in jouw project voordoet. ANDERS NIET.

Niemand zegt dat je patterns om de patterns moet proberen Frans. Het over-doing is ook een natuurlijk proces (alhoewel je dat na een tijdje ook wel van jezelf ziet).

Lees "Code Complete" van Steve McConnell. Dat biedt genoeg stof tot nadenken en het zelf vormen van een mening hoe iets wel en niet gedesigned moet worden.

Zeker een goed boek, maar het hoeft echt niet het een of het ander te zijn.

Om wat te doen? Fowler cs. kunnen dagen bomen over de meest onzinnige oplossingen voor problemen die er helemaal niet zijn. Het toppunt van ironie vind ik altijd dat Fowlerianen en DDD-aanhangers heel erg hard bezig zijn met het wegdesignen en wegprogrammeren van plumbing code, maar .... dat doen ze dan wel met ... plumbing code: grote, complexe designs waar helemaal NIETS in gebeurt wat maar enige relatie heeft met business rules of dedicated functionaliteit voor het project wat moet worden opgeleverd.

Je bent weer lekker op dreef Frans en je hebt er volgens mij bitter weinig van begrepen. Op zich niet erg,maar probeer het niet te verkondigen als het woord van god.

"DDD" begrijpen? Wat valt er aan te begrijpen, behalve dat je moet zorgen dat iedereen over dezelfde dingen praat wanneer er termen worden gebruikt? Evans zelf heeft geen antwoord op een essentiele vraag die iedere DDD-er vroeg of laat tegenkomt: moet een entity nu wel of niet references naar repositories hebben?

Repositories zijn persistent collections en entities mogen gewoon references naar persistent collections hebben. Repositories zijn onderdeel uit de domein laag, niet een onderdeel van de datalaag. De Repositories mogen op hun buurt weer gebruik maken van functionaliteit uit een lagere laag: database drivers, connections, sql etc. Dit zijn meer technische services en hebben totaal geen kennis van het domein (vaak zijn het reusable componenten).

[ Voor 3% gewijzigd door Alarmnummer op 11-03-2008 07:48 ]

[EfBe]

Je bent weer lekker op dreef Frans en je hebt er volgens mij bitter weinig van begrepen. Op zich niet erg,maar probeer het niet te verkondigen als het woord van god.

Hehehe, ja ik heb er echt bitter weinig van begrepen Peter... Daarom ben jij ook bekend over de gehele wereld en ik niet.

Neem nou jouw opmerkingen over repositories hierboven. Het geeft blijk van het feit dat je niet snapt wat voor discussies er binnen de DDD-community elke dag weer gevoerd worden. Dat jij vindt dat die references er mogen zijn betekent nog niet dat anderen daar net zo over denken of dat het hebben van die references beter is of niet. Je kunt nl. ook zeggen dat het hebben van die references je systeem erg ingewikkeld maakt want er ligt een heel web van references in je domain model en bij 500 entities is dat dus onbeheersbaar.

(edit) oh en btw, de enige reden dat ik reageerde was het blindelings adviseren van patterns en aanverwante nonsense in deze thread. Dat jij dat dan weer afdoet alsof ik pretendeer alles beter te weten is dan weer jammer, maar goed, c'est la vie. Het adviseren van patterns en zoveel mogelijk boeken daarover is PRECIES waar het NIET om gaat. Patterns zijn geen bouwstenen van een goede applicatie, het zijn oplossingen voor problemen die je KUNT tegenkomen en je moet ze alleen gebruiken wanneer je ook die problemen hebt, de volgorde is dan: probleem constateren -> BESTE oplossing uitzoeken -> oplossing implementeren. En niet andersom.

[ Voor 83% gewijzigd door EfBe op 11-03-2008 09:32 ]

[whoami]

EfBe schreef op maandag 10 maart 2008 @ 18:06:
Om wat te doen? Fowler cs. kunnen dagen bomen over de meest onzinnige oplossingen voor problemen die er helemaal niet zijn. Het toppunt van ironie vind ik altijd dat Fowlerianen en DDD-aanhangers heel erg hard bezig zijn met het wegdesignen en wegprogrammeren van plumbing code, maar .... dat doen ze dan wel met ... plumbing code: grote, complexe designs waar helemaal NIETS in gebeurt wat maar enige relatie heeft met business rules of dedicated functionaliteit voor het project wat moet worden opgeleverd.

Huh, DDD is net gericht op de business logica; om je business logica in een goed domein model te representeren, en dat model zo goed mogelijk te laten voldoen aan het werkelijke probleem.
Bij DDD zijn veel dingen (zoals bv de manier waarop entities gesaved worden) implemenatie details. Veel DDD aanhangers zijn net fan van IoC, O/R mappers, etc... net omdat ze zich daardoor meer op de business logica kunnen richten, en de plumbing al door reeds bestaande oplossingen gedaan wordt.

"DDD" begrijpen? Wat valt er aan te begrijpen, behalve dat je moet zorgen dat iedereen over dezelfde dingen praat wanneer er termen worden gebruikt? Evans zelf heeft geen antwoord op een essentiele vraag die iedere DDD-er vroeg of laat tegenkomt: moet een entity nu wel of niet references naar repositories hebben?

Ik denk dat Evans heel duidelijk is in z'n boek over repositories: repositories zijn 'first class citizens' in een domain model. Ze behoren tot het domein. (zal vanavond eens het stukje daarover opzoeken in het boek)
Meestal zie je dan ook dat de interfaces van de repositories in dezelfde assembly zitten als de domain classes, en de implementatie van die interfaces gewoon in een andere assembly zitten.

Verder ben ik het wel eens met EfBe dat de pattern boeken niet blindelings moeten aangeraden worden. Het is wel handig als je er noties van hebt, maar je moet wel weten wanneer je iets kunt toepassen.
Het GoF boek is eigenlijk niet veel meer dan een 'catalogus' van een aantal 'low level' patterns. Die kan je wel toepassen, maar die gaan je niet helpen bij het uittekenen van de grote lijnen van een applicatie.
Het is eigenlijk belangrijker dat je de concepten achter die patterns snapt; en hoe je zelf tot een oplossing kunt komen die goed gebruik maakt van OO technieken.

[ Voor 14% gewijzigd door whoami op 11-03-2008 09:33 ]

[Alarmnummer]

EfBe schreef op dinsdag 11 maart 2008 @ 08:53:
Neem nou jouw opmerkingen over repositories hierboven. Het geeft blijk van het feit dat je niet snapt wat voor discussies er binnen de DDD-community elke dag weer gevoerd worden. Dat jij vindt dat die references er mogen zijn betekent nog niet dat anderen daar net zo over denken of dat het hebben van die references beter is of niet.

Ik ben niet op de hoogte van discussies binnen .NET maar wel binnen de Java community (vooral de Spring afdeling) en daar is het injecteren van oa repositories zeker geen ongebruikelijke oplossing (bv via AspectJ icm Spring).

De vraag of een dependency hoort binnen een klasse is een andere vraag, maar daar kun je DDD niet voor afbranden. DDD is en blijft een goed boek. Als mensen het boek verkeerd interpreteren of zich fundamentalistisch gaan gedragen kan een boek niet verweten worden.

Je kunt nl. ook zeggen dat het hebben van die references je systeem erg ingewikkeld maakt want er ligt een heel web van references in je domain model en bij 500 entities is dat dus onbeheersbaar.

Een model van 500 entitieiten is sowieso al erg lastig te beheersen, ongeacht of je nu een anemic domain model of een rich domain model hebt.

Daarom ben jij ook bekend over de gehele wereld en ik niet.

Hard schreeuwen en gelijk hebben zijn 2 verschillende dingen.

[ Voor 6% gewijzigd door Alarmnummer op 11-03-2008 09:40 ]

[Alarmnummer]

whoami schreef op dinsdag 11 maart 2008 @ 09:28:
[...]
Huh, DDD is net gericht op de business logica; om je business logica in een goed domein model te representeren, en dat model zo goed mogelijk te laten voldoen aan het werkelijke probleem.
Bij DDD zijn veel dingen (zoals bv de manier waarop entities gesaved worden) implemenatie details. Veel DDD aanhangers zijn net fan van IoC, O/R mappers, etc... net omdat ze zich daardoor meer op de business logica kunnen richten, en de plumbing al door reeds bestaande oplossingen gedaan wordt.

pcies.

Verder ben ik het wel eens met EfBe dat de pattern boeken niet blindelings moeten aangeraden worden. Het is wel handig als je er noties van hebt, maar je moet wel weten wanneer je iets kunt toepassen.

Dat geldt overal voor en daar kan je het boek niet op afrekenen en dat is wel de toon die ik proef bij de Frans. Als hij ergens kritiek op zou moeten geven dan is het wel op fundamentalistisch en dogmatisch gedrag bij developers.

Het GoF boek is eigenlijk niet veel meer dan een 'catalogus' van een aantal 'low level' patterns. Die kan je wel toepassen, maar die gaan je niet helpen bij het uittekenen van de grote lijnen van een applicatie.

Daarom bv PEAA. Ik ben niet bekend met .NET maar binnen de Java wereld zie je toch vrij veel terug van PEAA en DDD. Het boek geeft je een houvast en het is aan het team/architect/developer te bepalen wat er wel en niet gebruikt gaat worden.

[ Voor 3% gewijzigd door Alarmnummer op 11-03-2008 09:46 ]

[EfBe]

whoami schreef op dinsdag 11 maart 2008 @ 09:28:
[...]
Huh, DDD is net gericht op de business logica; om je business logica in een goed domein model te representeren, en dat model zo goed mogelijk te laten voldoen aan het werkelijke probleem.
Bij DDD zijn veel dingen (zoals bv de manier waarop entities gesaved worden) implemenatie details. Veel DDD aanhangers zijn net fan van IoC, O/R mappers, etc... net omdat ze zich daardoor meer op de business logica kunnen richten, en de plumbing al door reeds bestaande oplossingen gedaan wordt.

Dat is dus de mythe waar ik op reageerde. Ga maar een tijdje op de DDD mailinglist van Yahoo groups zitten, je zult zien dat het niet zo ligt.

Tuurlijk, DDD is erop gericht om eensgezind te praten over welke zaken er wel en niet toe doen in het domain, maar daarna houdt het hard op. Evans voorstel om een uniforme taal te gebruiken is goed, maar de technische invulling van hoe een applicatie gebouwd moet worden is niet zo simpel op te zetten. De meest gestelde vragen mbt DDD is nl. hoe bouw ik een goed systeem? Mensen komen nl. snel in problemen wanneer ze dingen als 'get all customers with an order filed by employee X and at least 10 products Y' moeten gaan oplossen.

Veel wordt afgedaan als 'infastructuur', of 'implementatie details', maar daar draait de vraag nu juist om.

Neem alleen al de onnozele term anemic domain model. Hoeveel manjaren er al niet verkloot zijn om dat soort self-created spookbeeld te voorkomen... terwijl niemand ooit wetenschappelijk heeft aangetoond dat het ook daadwerkelijk slecht is. Tenenkrommend.

Ik denk dat Evans heel duidelijk is in z'n boek over repositories: repositories zijn 'first class citizens' in een domain model. Ze behoren tot het domein. (zal vanavond eens het stukje daarover opzoeken in het boek)
Meestal zie je dan ook dat de interfaces van de repositories in dezelfde assembly zitten als de domain classes, en de implementatie van die interfaces gewoon in een andere assembly zitten.

Dat bedoelde ik niet. Dat idee is an sig prima. Waar het om gaat is: als jij een anemic domain model wilt voorkomen ga jij behavior plaatsen in entity classes, en als die behavior andere entities nodig heeft, dan MOET je dus de repositories voor die entities gebruiken, wat inhoudt dat je dus in entities references naar repositories van andere entities moet hebben. Dit resulteert in een zeer gefragmenteerde logica en een web van references tussen classes. Kijk de archive van de DDD yahoo groups group (waar Evans ook zit btw) maar na, echt vele discussies zijn hier al aan gewijd en ze zijn steevast bron voor veel moddergooien, want er is echt geen consensus hierover.

Mijn eerste post in deze thread werd door meneer Veentjer met de grond gelijk gemaakt maar het zijn wel precies DEZE zinloze discussies (terwijl ik er kennelijk geen reet van begrijp ) waarom ik Code Complete aanraadde omdat juist dat boek dingen aandraagt als WANNEER je een nieuwe class moet aanmaken en wanneer NIET. Die kennis is dan te gebruiken in je eigen applicatie, zodat je beslissingen neemt op basis van kennis en niet op basis van een boekje van meneer Fowler die er zelf al heel lang geen brood meer in zag. (Patterns worden nl. veelal gezien als een noodgreep ivm bepaalde gebreken in de gebruikte taal, in dit geval single-inheritance static typed OO talen. Ruby heeft daar minder last van). Daarom zei ik ook dat Code Complete stof tot nadenken oplevert en je dus verder helpt. Het aanleren van patterns doet dat absoluut niet, want je leert truukjes en niet eens waarom.

Om een voorbeeld te geven: als je code complete leest en je neemt de kennis tot je en je SNAPT waar het over gaat, dan kun je dat toepassen op java/C#, maar ook op ruby. Leer je patterns aan, dan zijn die zinloos wanneer je overstapt naar een static typed taal of functionele taal. En dan? Weer een boek lezen?

Alarmnummer schreef op dinsdag 11 maart 2008 @ 09:35:
[...]
Ik ben niet op de hoogte van discussies binnen .NET maar wel binnen de Java community (vooral de Spring afdeling) en daar is het injecteren van oa repositories zeker geen ongebruikelijke oplossing (bv via AspectJ icm Spring).

Dat is een technisch detail, snap je dat dan niet? Wat boeit het waar ik definieer of de order repository bekend is in de customer entity? Of dat in een aop config / annotation is of in harde code, dat is om het even. Het gaat om het idee dat zo'n repository uberhaupt bekend is in een entity. Dat is nl. van invloed hoe je je logica verdeelt.

De vraag of een dependency hoort binnen een klasse is een andere vraag, maar daar kun je DDD niet voor afbranden. DDD is en blijft een goed boek. Als mensen het boek verkeerd interpreteren of zich fundamentalistisch gaan gedragen kan een boek niet verweten worden.

Ik brand DDD niet af daarom, ik zet alleen een dikke kanttekening bij het aanprijzen van DDD an sig: veel mensen komen er niet uit, domweg omdat het hen niet brengt wat ze denken dat het brengt: het is geen turn-key oplossing van doe-dit-en-het-zal-goed-komen. DDD is meer een manier van denken omtrent wat centraal staat in je applicatie. Daarom vind ik het ook jammer dat er uberhaupt een technische oplossing geboden wordt in Evans' boek. Dat had hij achterwege moeten laten, want daar gaat het nl. helemaal niet om: de technische oplossing is toch niet te vertalen naar veel applicaties want mensen hebben daar grote moeite mee, en het haalt de focus af van waar het om ging.

Hard schreeuwen en gelijk hebben zijn 2 verschillende dingen.

Wil je nog inhoudelijk ergens op reageren of blijf je krampachtig verdedigen met domme opmerkingen? JIJ begon met persoonlijk gezeik, meneer Veentjer.

Alarmnummer schreef op dinsdag 11 maart 2008 @ 09:44:
Dat geldt overal voor en daar kan je het boek niet op afrekenen en dat is wel de toon die ik proef bij de Frans. Als hij ergens kritiek op zou moeten geven dan is het wel op fundamentalistisch en dogmatisch gedrag bij developers.

Erm... is dat niet precies wat ik deed, nl. het aankaarten van de kanttekeningen bij bv 'patterns' ? Waar de voorspelbare reactie van jou niet lang op zich liet wachten? Het GoF is helemaal geen slecht boek, nl. de 1e 100 pagina's zijn prima. Die patterns kun je overslaan.

Daarom bv PEAA. Ik ben niet bekend met .NET maar binnen de Java wereld zie je toch vrij veel terug van PEAA en DDD. Het boek geeft je een houvast en het is aan het team/architect/developer te bepalen wat er wel en niet gebruikt gaat worden.

Dat het in de .NET wereld een heel stuk minder gebruikt wordt terwijl .net en java niet fundamenteel verschillen van elkaar geeft wellicht aan dat hoe het 'altijd gedaan is' gewoon wordt gecontinueerd? Jij voelt je meteen aangevallen wanneer iemand een kanttekening plaatst bij wat jij kennelijk als fundamenteel beschouwt. Ipv dat je gaat nadenken waarom die kanttekening geplaatst wordt, ga jij die persoon aanvallen en beticht je hem van het niet snappen van waar deze persoon het over heeft en dat hou je een paar posts vol.

Allemaal prima, maar daar schiet de TS niets mee op. Waarom denk je niet wat fundamenteler na over dingen? Ik zeg helemaal niet dat patterns slecht zijn, ik zeg alleen dat het geen bouwstenen zijn en ook geen verplichte kost: men kan prima software maken zonder 1 pattern ooit te kennen.

[ Voor 31% gewijzigd door EfBe op 11-03-2008 10:02 ]

[Michali]

@EfBe: Ik vind dat je goede punten hebt hoor, maar je schrijft de boeken voor verkeerde redenen af. Als software ontwikkelaar kom je vroeg of later toch wel in aanraking met patterns. Ze worden veel genoemd in literatuur, alleen al daarom is het prettig om op dat gebied een goede basis te hebben.

Maar nog belangrijker imo. is dat zo'n boek je juist kan helpen om pattern niet in de verkeerde situaties te gebruiken. Toegegeven past het originele Design Patterns boek niet in dat straatje, daarom zou ik het ook niet zo snel als eerste boek aanraden. De punten die jij noemt heb ik ook zeker in een aantal boeken terug gevonden en die hebben me er erg bewust van gemaakt hoe goed ik moet opletten bij het toepassen van patterns voor problemen waar ze niet voor bedoeld zijn. Mijns inziens ben ik dan juist blij dat ik zo'n boek heb gelezen, juist omdat deze me beter om een valkuil heen leiden.

Om een voorbeeld te geven: als je code complete leest en je neemt de kennis tot je en je SNAPT waar het over gaat, dan kun je dat toepassen op java/C#, maar ook op ruby. Leer je patterns aan, dan zijn die zinloos wanneer je overstapt naar een static typed taal of functionele taal. En dan? Weer een boek lezen?

Dit is ook niet helemaal waar. Een goed patterns boek geeft je inzicht in de achterliggende reden en totstandkoming van die patterns. Ik denk dat het opdoen van die kennis nooit een zinloze investering is. Het enige wat je behoort te leren is de ervaring van anderen en inzicht in waarom ze voor bepaalde oplossingen gekozen hebben.

[ Voor 11% gewijzigd door Michali op 11-03-2008 10:10 ]

[EfBe]

Michali schreef op dinsdag 11 maart 2008 @ 10:09:
@EfBe: Ik vind dat je goede punten hebt hoor, maar je schrijft de boeken voor verkeerde redenen af. Als software ontwikkelaar kom je vroeg of later toch wel in aanraking met patterns. Ze worden veel genoemd in literatuur, alleen al daarom is het prettig om op dat gebied een goede basis te hebben.

Je bedoelt: als je weet wat het visitor pattern inhoudt ben je sneller bij machte om een AST crawler te maken? Ok, daar ga ik hier beneden op in

Maar nog belangrijker imo. is dat zo'n boek je juist kan helpen om pattern niet in de verkeerde situaties te gebruiken. Toegegeven past het originele Design Patterns boek niet in dat straatje, daarom zou ik het ook niet zo snel als eerste boek aanraden. De punten die jij noemt heb ik ook zeker in een aantal boeken terug gevonden en die hebben me er erg bewust van gemaakt hoe goed ik moet opletten bij het toepassen van patterns voor problemen waar ze niet voor bedoeld zijn. Mijns inziens ben ik dan juist blij dat ik zo'n boek heb gelezen, juist omdat deze me beter om een valkuil heen leiden.

Dat lijkt maar zo. . Het lezen van een boek vol met oplossingen is leuke kost: het lijkt allemaal logisch, zeker gezien de problemen die ze oplossen en die zijn keurig beschreven. Het punt is dat het de wereld op zn kop is: je verdiept je in een serie oplossingen, met daarbij de problemen die ze oplossen, echter moet de ingang zijn: een serie problemen met een SERIE mogelijke oplossingen, waaruit jij dan 1 gaat kiezen die het beste bij je project past. Dat lijkt hetzelfde maar dat is fundamenteel anders. Ik kan prima uitleggen waarom O/R mapping de beste pattern / methodiek is om met data te werken in een OO systeem. Echter, is dat de beste oplossing voor jouw project? Dat is helemaal niet gezegd. Wellicht denkt jouw team in tabellen en SQL en zijn ze veel meer geholpen met een tabulaire aanpak. Als je een boek leest van patterns en je leest daar over o/r mappers, ga je denken dat dat dus de beste oplossing is, immers het probleem wat het oplost is precies het probleem waar jij mee zit en de oplossing lijkt prima te passen bij het probleem. Echter, het is niet de ENIGE oplossing voor dat probleem, en dat staat er dus niet bij!

Wat je dus over het hoofd gaat zien wanneer je in patterns denkt is dat je de essentiele stap over slaat die toetst of de geboden oplossing voor het probleem inderdaad de beste is voor jouw project uit de mogelijke oplossingen.

Een ander nadeel van het denken in patterns is dat de nadelen van een pattern niet of nauwelijks benadrukt worden. Zie hieronder. Nadelen van patterns zijn er wel degelijk, sommige kun je weer oplossen met het toepassen van nog meer patterns, wat vroeg of laat leidt tot over-engineered rommel waar veel code in zit maar bitter weinig functionaliteit.

Dit is ook niet helemaal waar. Een goed patterns boek geeft je inzicht in de achterliggende reden en totstandkoming van die patterns. Ik denk dat het opdoen van die kennis nooit een zinloze investering is. Het enige wat je behoort te leren is de ervaring van anderen en inzicht in waarom ze voor bepaalde oplossingen gekozen hebben.

Tuurlijk, maar dat leer je niet uit patternboeken. Neem het visitor pattern (of double dispatch). Dat is een oplossing om dmv polymorphism tree handlers te maken zonder dat je hechte afhankelijkheden inbouwt. Allemaal prima. Het probleem is dat wanneer je bij het visitor pattern begint ipv bij het probleem, je niet snapt waarom het zo ingenieus in elkaar steekt en tegelijkertijd waarom zo weinig mensen het maar gebruiken. het is nl. zo dat wanneer je tegen het probleem van dependencies oploopt je je DAN pas moet gaan afvragen of het visitor pattern wellicht een oplossing biedt voor dat probleem. Echter, het hoeft helemaal geen verbetering te zijn, want het visitor pattern levert fragmentatie van overzicht op: je bent volledig de weg kwijt waar wanneer iets uitgevoerd wordt. Wanneer je dan daarnaast ook subtrees met verschillende visitors gaat bezoeken is de boot echt aan. Voorzie je dat wanneer je bij het visitor pattern begint, wat prima te verkopen is als zijnde een prima oplossing, gezien het feit dat het probleem goed uit te leggen is? Ik denk het niet. Maar wanneer je tegen het probleem oploopt wat het visitor pattern oplost (net als andere oplossingen) dan kun je beter overwogen besluiten wat je echt nodig hebt: je kent het probleem, de scope waarin het probleem zich voordoet en ook waar de oplossing aan moet voldoen. En dan kan een externe handler routine ipv een visitor wellicht een veel betere oplossing zijn.

Ideaal zou zijn dat wanneer je een probleem constateert, dus bv je voorziet veel code-wijzigingen want je moet een node-type toevoegen aan je tree, je dan gaat zoeken naar een oplossing daarvoor, en niet andersom. En dat leer je juist NIET uit patternboeken, want die zijn erop gericht de oplossingen uit te leggen. maar een boek met louter probleembeschrijvingen is er niet

[ Voor 3% gewijzigd door EfBe op 11-03-2008 10:42 ]

[Alarmnummer]

EfBe schreef op dinsdag 11 maart 2008 @ 09:46:
[...]
Ik brand DDD niet af daarom, ik zet alleen een dikke kanttekening bij het aanprijzen van DDD an sig: veel mensen komen er niet uit, domweg omdat het hen niet brengt wat ze denken dat het brengt: het is geen turn-key oplossing van doe-dit-en-het-zal-goed-komen.

Dat geldt voor ieder boek.

Wil je nog inhoudelijk ergens op reageren of blijf je krampachtig verdedigen met domme opmerkingen? JIJ begon met persoonlijk gezeik, meneer Veentjer.

Pardon. Jij bent hier degene zich hier onvolwassen loopt te gedragen.

Jij voelt je meteen aangevallen wanneer iemand een kanttekening plaatst bij wat jij kennelijk als fundamenteel beschouwt. Ipv dat je gaat nadenken waarom die kanttekening geplaatst wordt, ga jij die persoon aanvallen en beticht je hem van het niet snappen van waar deze persoon het over heeft en dat hou je een paar posts vol.

Zorg er dan voor dat je commentaar duidelijker is en minder lomp. Je hele wijze van reageren doet mijn nekharen reizen. Dat is ook een van de redenen dat ik bijna nooit op je reageer.

Allemaal prima, maar daar schiet de TS niets mee op. Waarom denk je niet wat fundamenteler na over dingen? Ik zeg helemaal niet dat patterns slecht zijn, ik zeg alleen dat het geen bouwstenen zijn en ook geen verplichte kost: men kan prima software maken zonder 1 pattern ooit te kennen.

De consequentie is dat je dan veel patterns meestal zelf opnieuw loopt uit te vinden maar slechter. Dat je ad hoc design krijgt ipv dat het duidelijk is wat iets moet doen. Uit de naamgeving van classes en patterns gebruikt in classes kan ik meestal al vrij veel informatie halen. Ik wil niet zeggen dat je zonder patterns geen goeie software kan schrijven, maar met een relatief kleine investering kun je er veel meer uit halen.

[whoami]

EfBe schreef op dinsdag 11 maart 2008 @ 09:46:
[...]
Dat bedoelde ik niet. Dat idee is an sig prima. Waar het om gaat is: als jij een anemic domain model wilt voorkomen ga jij behavior plaatsen in entity classes, en als die behavior andere entities nodig heeft, dan MOET je dus de repositories voor die entities gebruiken, wat inhoudt dat je dus in entities references naar repositories van andere entities moet hebben. Dit resulteert in een zeer gefragmenteerde logica en een web van references tussen classes. Kijk de archive van de DDD yahoo groups group (waar Evans ook zit btw) maar na, echt vele discussies zijn hier al aan gewijd en ze zijn steevast bron voor veel moddergooien, want er is echt geen consensus hierover.

Mja, als repositories first class citizens zijn, dan vraag ik me af waarom het niet zou mogen ?
En zelfs dan nog, waarom zou het niet mogen ?

Het probleem is, dat veel mensen (en ik (was) daar ook bij), veel te puristisch willen zijn na het lezen van een dergelijk boek.
Als de simpelste oplossing is om een repository in je class te gebruiken, en je code er nog onderhoudbaar bij blijft, waarom zou je het dan niet doen.

In boeken als DDD worden goede ideeën naar voren gebracht, maar het is niet altijd mogelijk om die ideeën zo puur te gaan gebruiken zoals ze daar naar voren gebracht worden.

[Anoniem: 140111]

Je gaat er wel direct van uit dat mensen klakkeloos iets overnemen zonder na te denken over het probleem wat ze op proberen te lossen. Ik heb júist door te lezen over patterns meer houvast gekregen bij OOkreten, niet door de concrete toepassing van een pattern, maar door te proberen een abstractielaag hoger te denken. 'Encapsulate what varies', 'Program to interfaces, not implementations' etc. Je hoeft die patterns toch ook niet letterlijk over te nemen?
Zonder te doen alsof ik (veel) verstand heb van zaken kan ik wel zeggen dat het mij, persoonlijk, wél heeft geholpen.

Dat ik een pattern in een boek zie staan betekent niet automatisch dat ik m'n code om dat pattern heen ga ontwerpen. Ik maak een ruwe opzet, werk deze uit (op papier) en als ik problemen tegenkom ga ik eens kijken of er misschien al een oplossing voor bestaat, niet andersom.

[ Voor 3% gewijzigd door Anoniem: 140111 op 11-03-2008 11:05 ]

[whoami]

Het gaat niet over 'klakkeloos overnemen'. Het gaat erover dat mensen iets lezen in een bepaald boek, daar iets zien, evt iets veronderstellen, en zich dan soms in alle soorten bochten gaan wringen om iets dat ze in dat boek gelezen hebben, te gaan toepassen. Omdat ze denken dat het zo moet.

De boeken die ik heb gelezen, hebben me zeker ook geholpen, maar ik kan niet ontkennen dat ik ook een periode gekend heb waarin ik bepaalde ideeën veel te puristisch wou gaan toepassen.

[Anoniem: 140111]

whoami schreef op dinsdag 11 maart 2008 @ 11:07:
Het gaat niet over 'klakkeloos overnemen'. Het gaat erover dat mensen iets lezen in een bepaald boek, daar iets zien, evt iets veronderstellen, en zich dan soms in alle soorten bochten gaan wringen om iets dat ze in dat boek gelezen hebben, te gaan toepassen. Omdat ze denken dat het zo moet.

Dus eigenlijk zeggen we precies hetzelfde

[EfBe]

Alarmnummer schreef op dinsdag 11 maart 2008 @ 10:49:
[...]
Dat geldt voor ieder boek.

Niet echt, maar je bent hierin toch niet te overtuigen.

Pardon. Jij bent hier degene zich hier onvolwassen loopt te gedragen.

Ik plaats kanttekeningen, en oh low and behold, ik ga dus niet met de gevestigde 'Predikt Den Fowleriaanse Spreuken'-orde mee. Tja, dat zal dan wel onvolwassen gedrag zijn...

Zorg er dan voor dat je commentaar duidelijker is en minder lomp. Je hele wijze van reageren doet mijn nekharen reizen. Dat is ook een van de redenen dat ik bijna nooit op je reageer.

Mja, volgens mij was ik behoorlijk duidelijk, en als je niet wilt reageren, doe dat dan ook niet.

De consequentie is dat je dan veel patterns meestal zelf opnieuw loopt uit te vinden maar slechter.

Hoezo? dat impliceert dat patterns dus altijd toepasbaar zijn, maar dat is kolder.
Overigens geldt wat jij zegt wel voor algorithms, waar ik je nooit over hoor en geen mens hier heeft het erover in deze thread. Weten wat een priority heap is etc. zijn dingen die ook voorkomen dat je het wiel opnieuw uitvindt. Het nadeel voor jou is dat algorithms bewezen effectief zijn in _alle gevallen_ voor wat ze doen, en dus WEL kunnen worden gedoceerd bij het uitleggen van het algorithme.

[Michali]

EfBe schreef op dinsdag 11 maart 2008 @ 10:40:
Je bedoelt: als je weet wat het visitor pattern inhoudt ben je sneller bij machte om een AST crawler te maken? Ok, daar ga ik hier beneden op in

Euh, sorry maar ik AST crawler doet niet echt een belletje bij me rinkelen, dus kan hier moeilijk antwoord op geven.

Dat lijkt maar zo. . Het lezen van een boek vol met oplossingen is leuke kost: het lijkt allemaal logisch, zeker gezien de problemen die ze oplossen en die zijn keurig beschreven. Het punt is dat het de wereld op zn kop is: je verdiept je in een serie oplossingen, met daarbij de problemen die ze oplossen, echter moet de ingang zijn: een serie problemen met een SERIE mogelijke oplossingen, waaruit jij dan 1 gaat kiezen die het beste bij je project past. Dat lijkt hetzelfde maar dat is fundamenteel anders. Ik kan prima uitleggen waarom O/R mapping de beste pattern / methodiek is om met data te werken in een OO systeem. Echter, is dat de beste oplossing voor jouw project? Dat is helemaal niet gezegd. Wellicht denkt jouw team in tabellen en SQL en zijn ze veel meer geholpen met een tabulaire aanpak. Als je een boek leest van patterns en je leest daar over o/r mappers, ga je denken dat dat dus de beste oplossing is, immers het probleem wat het oplost is precies het probleem waar jij mee zit en de oplossing lijkt prima te passen bij het probleem. Echter, het is niet de ENIGE oplossing voor dat probleem, en dat staat er dus niet bij!

Wat je dus over het hoofd gaat zien wanneer je in patterns denkt is dat je de essentiele stap over slaat die toetst of de geboden oplossing voor het probleem inderdaad de beste is voor jouw project uit de mogelijke oplossingen.

Een ander nadeel van het denken in patterns is dat de nadelen van een pattern niet of nauwelijks benadrukt worden. Zie hieronder. Nadelen van patterns zijn er wel degelijk, sommige kun je weer oplossen met het toepassen van nog meer patterns, wat vroeg of laat leidt tot over-engineered rommel waar veel code in zit maar bitter weinig functionaliteit.

Daar ligt zeker een groot gevaar, dat ben ik helemaal met je eens. Maar ik ben nog steeds wel van mening dat een goed boek je daar wel bij kan helpen dat ook in te zien. Zo'n boek plaatst ook kanttekeningen bij de oplossing. En benaderd het niet vanuit de patterns zelf, maar vanuit de problemen. Veel van die boeken doen dat idd. niet.

Tuurlijk, maar dat leer je niet uit patternboeken.
...
Ideaal zou zijn dat wanneer je een probleem constateert, dus bv je voorziet veel code-wijzigingen want je moet een node-type toevoegen aan je tree, je dan gaat zoeken naar een oplossing daarvoor, en niet andersom. En dat leer je juist NIET uit patternboeken, want die zijn erop gericht de oplossingen uit te leggen. maar een boek met louter probleembeschrijvingen is er niet

Dat probeer ik juist te zeggen, dat heb ik dus WEL uit bepaalde patternboeken geleerd. Design Patterns Explained gaat juist vanuit een probleem naar de oplossing toe dermate van, en dit is heel belangrijk, basis OO principes, niet vanuit patterns. Door deze basis principes toe te passen kom je dan tot een bepaald pattern. Wat je hieruit leert is welke principes het pattern ondersteunen, en bij wat voor soort problematiek het toepasselijk is.

Nog belangrijker is dat je leert niet vanuit die patterns te denken, maar vanuit de basis principes, zo gewoon naar je probleem te kijken en hoe dit op een nette manier kan oplossen. Als ik nu met een probleem zit ga ik niet mijn pattern boek zitten doorspitten naar een passende oplossing. Ik ga juist kijken naar een geschikte en meest simpele oplossing. Soms kom ik er dan achteraf achter dat ik een pattern heb geïmplementeerd, soms herken ik er niet zo veel in.

Ik probeerde daarom te zeggen dat het pattern zelf niet eens zo belangrijk is, maar de beredenatie erachter wel. Volgens mij is dat ook precies wat jij zegt, maar is het punt alleen dat je dat naar mijn mening wel uit een boek kan leren (ik heb dit ook geleerd, dus meer kan ik daarover niet zeggen) en naar jouw mening niet.

Wat raad je dan aan? Patterns gewoon volledig te negeren en alleen de achterliggende principes te leren? Dat is misschien ook een hele goede aanpak, maar ik denk dat je via patterns wel een soort shortcut kunt maken. Deze principes zitten daar namelijk vaak in verpakt en als je ze op een dergelijke manier benaderd snap je het ook veel sneller. Met als nadeel de mogelijke gevaren, zoals hierboven genoemd.

[Morax]

EfBe schreef op dinsdag 11 maart 2008 @ 11:31:
[...]

Niet echt, maar je bent hierin toch niet te overtuigen.

Wat is dan wel een boek in de zin van "doe-dit-en-het-zal-goed-komen"? Daar ben ik dan wel erg nieuwsgierig naar

[Tuxie]

whoami schreef op dinsdag 11 maart 2008 @ 11:07:
Het gaat niet over 'klakkeloos overnemen'. Het gaat erover dat mensen iets lezen in een bepaald boek, daar iets zien, evt iets veronderstellen, en zich dan soms in alle soorten bochten gaan wringen om iets dat ze in dat boek gelezen hebben, te gaan toepassen. Omdat ze denken dat het zo moet.

De boeken die ik heb gelezen, hebben me zeker ook geholpen, maar ik kan niet ontkennen dat ik ook een periode gekend heb waarin ik bepaalde ideeën veel te puristisch wou gaan toepassen.

Daar heb je helemaal gelijk in. Maar als je goed kijkt in het patterns boek staat daar nergens dat je zomaar een pattern moet gebruiken, maar vanuit het probleemdomein moet redeneren. Als je daarnaast een goede kennis van patterns hebt, kun je zelf kiezen wat je wel en niet moet toepassen.

Ik vind het ook een redelijk simplistische gedachte van een zeker iemand hier dat als er een patterns boek genoemd wordt dat het alleen maar "patterns om patterns" is. Wat een onzin, heb je het boek zelf wel eens gelezen en waarom breng je dat meteen zo stellig? Niemand zegt dat hier, alleen jij en daar heeft de TS helemaal niets aan...

[whoami]

Morax schreef op dinsdag 11 maart 2008 @ 11:48:
[...]


Wat is dan wel een boek in de zin van "doe-dit-en-het-zal-goed-komen"? Daar ben ik dan wel erg nieuwsgierig naar

Een dergelijk boek bestaat niet, want niet ieder probleem is hetzelfde.
Er bestaat geen 'silver bullet'.

[Morax]

whoami schreef op dinsdag 11 maart 2008 @ 12:02:
[...]

Een dergelijk boek bestaat niet, want niet ieder probleem is hetzelfde.
Er bestaat geen 'silver bullet'.

Die opvatting deel ik met je Maar als EfBe beweerd dat er wel dergelijke boeken bestaan, dan ben ik dus zeer nieuwsgierig welke boeken hij dan als zodanig beschouwd

[ Voor 5% gewijzigd door Morax op 11-03-2008 12:09 ]

[EfBe]

Morax schreef op dinsdag 11 maart 2008 @ 11:48:
[...]
Wat is dan wel een boek in de zin van "doe-dit-en-het-zal-goed-komen"? Daar ben ik dan wel erg nieuwsgierig naar

Algorithms in C, Robert Sedgewick. (er zijn latere versies verschenen voor andere talen, je kunt ook het werk van Knuth pakken, idem) Het is een vergeten onderdeel van computer science aan het worden zo lijkt het wanneer je kijkt naar de hoeveelheid informatie op internet mbt ruby, patterns, ddd, tdd etc. terwijl dat nu juist de basis is waar het vaak aan ontbreekt.

Developers zijn altijd driftig op zoek naar datgene wat hun werk EN makkelijker maakt EN ervoor zorgt dat hetgeen ze opleveren GOED is. Echter, dat is er niet: patterns toepassen levert je geen systeem op wat gegarandeerd goed is, DDD toepassen idem, het allemaal negeren echter ook niet. Het probleem is veelal dat de developer denkt dat de dingen die moeten worden opgelost uniek zijn in de wereld, maar dat is veelal niet zo: algorithms zijn veelal al erg oud en bewezen correct. Ze toepassen kan dus in alle gevallen en je hoeft niet te kijken of het algorithme goed is, dat is het. Het verschil met patterns is dat patterns een specifiek toepassingsgebied hebben, algorithms niet: een fibonacci heap is niet een pattern, maar een algorithme en wel zodanig dat je het uniform kunt toepassen in veel andere algorithmes (graph shortest path etc.).

Het zou IMHO dan ook beter zijn als developers zich wat meer gingen verdiepen in wat voor algorithmes er allemaal al bedacht (of beter: ontdekt) zijn en hoe simpel sommigen zijn te implementeren. Bv in .NET 3.5 kun je mbv lambda expressions die algorithmes erg generiek maken en is het hergebruik van dat soort code erg simpel.

Het druist tegen de heilige huisjes in van OO: algorithmes zijn vaak imperatief en niet echt gericht op OO-dogmas, maar dat is juist goed: immers, 'OO-compliant' zijn is niet een doel. het probleem van de opdrachtgever oplossen, dat is het doel.

Omtrent het aanreiken van een turn-key boek en dat dat overeenkomt met een silver bullet: nee dat is niet zo. Zoals je ziet is wat ik aandraag op een vrij low level vlak: de developer moet de kennis toepassen om verder te komen en daar kun je veel fouten mee maken. De developer heeft echter wel een aantal problemen minder en itt patterns zijn algorithmes wel te pas en te onpas toe te passen zonder kopzorgen. Ik weet ook wel dat Brooks gelijk had/heeft, en dat was ook niet wat ik bedoelde met die opmerking. Ik doelde meer op dat het lezen van bv Sedgewick of Knuth's werk direct toepasbare onderdelen oplevert die de nadelen van patterns niet hebben. Dus als je shellsort implementeert dan krijg je ook de sort characteristics die bij het algorithme horen, klaar. Heb je een bak met objects en je moet ze in een bepaalde volgorde plaatsen waarbij afhankelijkheden worden afgevangen? Graph -> topological sort -> klaar. Simpele algorithmes vaak die op een half a4-tje passen maar die wel in alle gevallen werken. Dus probleem -> _vaststaande oplossing_ -> opgelost. I.t.t. patterns waar het afwachten is of het pattern wel toepasbaar is in de situatie waarin je zit.

[ Voor 22% gewijzigd door EfBe op 11-03-2008 12:26 ]

[Michali]

Wat denk je overigens van dit boek? Ik vroeg daar laatst al over in het boekentopic, maar blijkbaar heeft niemand deze gelezen.

Ik ben wel van plan die te gaan aanschaffen.

Dit boek kan ik ook iedereen aanraden trouwens: Programming Language Pragmatics. Vrij lastig boek, maar wel goed geschreven en bevat enorm veel informatie. Als je dit soort zaken weet, dan komt dat ook vaak wel van pas.

[whoami]

EfBe, ik ben het eens dat je , als developer kennis moet hebben van algoritmes & data structuren. Dat is ook één van de redenen waarom ik vind dat een IT opleiding belangrijk is voor iemand die iets wil doen in software ontwikkeling.
Echter, de vraag van de TS was hoe hij een goed 'software ontwerp' kan maken. Maar dan denk ik persoonlijk dat algoritmes & datastructuren -hoe belangrijk ze ook zijn- te low level zijn om in deze vraagstelling te betrekken

[EfBe]

whoami schreef op dinsdag 11 maart 2008 @ 12:38:
EfBe, ik ben het eens dat je , als developer kennis moet hebben van algoritmes & data structuren. Dat is ook één van de redenen waarom ik vind dat een IT opleiding belangrijk is voor iemand die iets wil doen in software ontwikkeling.
Echter, de vraag van de TS was hoe hij een goed 'software ontwerp' kan maken. Maar dan denk ik persoonlijk dat algoritmes & datastructuren -hoe belangrijk ze ook zijn- te low level zijn om in deze vraagstelling te betrekken

Dat lijkt een logische conclusie, maar daar ben ik het dus niet mee eens (anders bracht ik die santemekraam niet naarvoren ) Het punt is nl, dat een applicatie an sig eigenlijk alleen maar functionaliteit omvat. Dit kun je vertalen naar algoritmes, die je steeds verder verfijnt. Bij die algorithmes horen datastructuren, en op lagere niveaus ga je die verder uitwerken. Alleen... doordat je de algorithmes neemt die bewezen zijn en vaststaan, wordt je design al gestuurd. Het voordeel is dat je EN logica hebt die je doel dient, EN een design krijgt wat dat ook doet.

Ga je daar vanaf stappen en kijken hoe je goede OO designs op zet dan is het doel verworden tot het goed opzetten van een OO model, maar dat dient het doel niet: je OO model is dan nog altijd de plumbing waar je feitelijke code in moet komen te hangen, met als nadeel dat je aan de grenzen van je model vastzit hoeveel vrijheid je krijgt bij het implementeren van de feitelijke functionaliteit.

Dus omgekeerde wereld: ipv te kijken hoe je het beste de functionaliteit moet implementeren, ga je kijken hoe je het beste een omgeving kunt creeeren (met overhead en complexiteit) om die functionaliteit in te hangen. Maar dat kan alleen als de omgeving die je creeert totaal geen grenzen oplegt aan het bouwen van de functionaliteit: m.a.w.: wanneer je de algorithmen gaat kiezen om je functionaliteit te bouwen mag je totaal niet gehinderd worden door de omgeving die je gecreeerd hebt met de OO design principes die je EERST hebt toegepast.

Ik zie geen bewijs dat dat altijd zo is, mede omdat OO juist beperkend werkt: encapsulation zorgt ervoor dat er overhead gecreeerd wordt wanneer je voor een bepaald process de geencapsuleerde data nodig hebt, etc. etc.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 01-12-2009 22:29 ]

[EfBe]

hoe een order aangemaakt wordt in het systeem is ook een algorithme, om maar een voorbeeld te noemen ( en dan doel ik niet op "run insert statement" maar op de stappen die doorlopen worden om een order succesvol in het systeem te plaatsen).

Om aan te geven dat dit de essentiele zaak is: je wilt een overzicht uitdraaien waar acties in de juiste volgorde staan dus op afhankelijkheden, zodat iemand dat overzicht kan gebruiken voor het vullen van een vrachtauto, noem maar iets. Dan kan het algorithme zijn om dat overzicht te maken op hoog niveau zijn: (ja, het ziet er simpel uit)
1) haal gegevens op voor overzicht
2) bepaal volgorde acties
3) start report engine
4) laadt juiste report
5) start report door het doorgeven van alle bepaalde gegevens.

En nu ga je uitspecificeren, dus bij 1) ga je bepalen welke gegevens dat allemaal zijn. Bij 2) ga je topoligical sorting toepassen op die gegevens.

DIT is wat er gebeuren moet, en dit bepaalt dus ook hoe het in elkaar zit. Als stap 2) vereist dat je alles in een graph stopt, dan doe je dat, want dat lost stap 2 op. Als de report engine zoals meestal het geval is, van erbarmelijke kwaliteit is, dan zul je wellicht projecties moeten uitvoeren in stap 5). Dat bepaalt je design. Als je vooraf daar grenzen voor gaat opstellen door in UML voor het vaderland weg te gaan designen zonder na te denken over dit soort zaken, prima, maar grote kans dat je je werk kunt weggooien OF dat je een moeilijke implementatie tegemoet gaat.

[ Voor 87% gewijzigd door EfBe op 11-03-2008 16:14 ]

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 97% gewijzigd door Ruudjah op 01-12-2009 22:30 ]

[flowerp]

Tuxie schreef op maandag 10 maart 2008 @ 16:04:
Als je meer een boek zoekt over 'hoe je tot een goede architectuur komt', kun je deze proberen:
[afbeelding]
(Bass, Clements, Kazman, Software architecture in practice)

Dit boek wordt gebruikt bij colleges van diverse universiteiten. Ik heb zelf jaren geleden de eerste editie gelezen en was er zeker over te spreken. Dit gaat niet over design patterns, maar over grotere organisatie structuren (software architectuur). De case studies waar de architectuur van bestaande systemen onder de loep wordt genomen is een aardig aspect. In de eerste editie werd b.v. oa Corba bekeken.

[Webgnome]

EfBe schreef op dinsdag 11 maart 2008 @ 16:06:
hoe een order aangemaakt wordt in het systeem is ook een algorithme, om maar een voorbeeld te noemen ( en dan doel ik niet op "run insert statement" maar op de stappen die doorlopen worden om een order succesvol in het systeem te plaatsen).

Om aan te geven dat dit de essentiele zaak is: je wilt een overzicht uitdraaien waar acties in de juiste volgorde staan dus op afhankelijkheden, zodat iemand dat overzicht kan gebruiken voor het vullen van een vrachtauto, noem maar iets. Dan kan het algorithme zijn om dat overzicht te maken op hoog niveau zijn: (ja, het ziet er simpel uit)
1) haal gegevens op voor overzicht
2) bepaal volgorde acties
3) start report engine
4) laadt juiste report
5) start report door het doorgeven van alle bepaalde gegevens.

En nu ga je uitspecificeren, dus bij 1) ga je bepalen welke gegevens dat allemaal zijn. Bij 2) ga je topoligical sorting toepassen op die gegevens.

DIT is wat er gebeuren moet, en dit bepaalt dus ook hoe het in elkaar zit. Als stap 2) vereist dat je alles in een graph stopt, dan doe je dat, want dat lost stap 2 op. Als de report engine zoals meestal het geval is, van erbarmelijke kwaliteit is, dan zul je wellicht projecties moeten uitvoeren in stap 5). Dat bepaalt je design. Als je vooraf daar grenzen voor gaat opstellen door in UML voor het vaderland weg te gaan designen zonder na te denken over dit soort zaken, prima, maar grote kans dat je je werk kunt weggooien OF dat je een moeilijke implementatie tegemoet gaat.

Bedoel je hier niet gewoon dat je moet onderkennen welke processen ( workflow ) er binnen een bedrijf zijn zodat je daar je systeem op kunt bouwen en niet dat het systeem processen in de weg gaat zitten? (alleen als dat bittere noodzaak is)

[Anoniem: 140111]

offtopic:
Ik ben nu een goede maand bezig met afstuderen, bij een vrij grote software ontwikkelaar, maar het komt mij over alsof VERUIT de meeste mensen TOTAAL geen interesse hebben om zich bezig te houden met meer dan codekloppen om de uren tussen 09:00 en 17:00 vol te maken.
Ik weet niet of dit inherent is aan grotere bedrijven (heb alleen ervaring bij een verzekeraar waar geen programmeurs werken, vandaar dat ik daar weg ben gegaan), maar ik vind het toch wel opvallend.

[whoami]

Anoniem: 140111 schreef op woensdag 12 maart 2008 @ 12:16:

offtopic:
Ik ben nu een goede maand bezig met afstuderen, bij een vrij grote software ontwikkelaar, maar het komt mij over alsof VERUIT de meeste mensen TOTAAL geen interesse hebben om zich bezig te houden met meer dan codekloppen om de uren tussen 09:00 en 17:00 vol te maken.
Ik weet niet of dit inherent is aan grotere bedrijven (heb alleen ervaring bij een verzekeraar waar geen programmeurs werken, vandaar dat ik daar weg ben gegaan), maar ik vind het toch wel opvallend.

offtopic:
2 types of programmers

[Alarmnummer]

EfBe schreef op dinsdag 11 maart 2008 @ 11:31:
Ik plaats kanttekeningen, en oh low and behold, ik ga dus niet met de gevestigde 'Predikt Den Fowleriaanse Spreuken'-orde mee.

Prima dat je een kanttekening plaatst en dat hoort iedere developer te doen. Maar om dan meteen maar boeken af te gaan serveren gaat veel te ver.

Tja, dat zal dan wel onvolwassen gedrag zijn...

In ieder geval niet professioneel. Je zorgt dat discussies worden gepolariseerd doordat je veel te extreem reageert en radicale conclusies trekt. Er is een totaal gebrek aan nuance.

Hoezo? dat impliceert dat patterns dus altijd toepasbaar zijn, maar dat is kolder.

Dit vind ik een vreemde redenatie. Patterns zijn een waardevol middel om betere code te produceren, maar als je de verkeerde patterns toepast (of een pattern toepast waar het niet hoeft) dan ben je verkeerd bezig. Maar afgezien van wat pattern extremisten en beginnende developers, hebben professionals hier geen last van (zou je mogen verwachten )

Patterns zijn een handige tool in de toolbox, maar er zit nog veel meer in de toolbox.
Bier is lekker, maar dat wil niet zeggen dat je het de hele dag moet drinken.

Waarom reageer je zo fel op het 'verkeerd' toepassen van DDD/Patterns? Heeft jouw personeel daar ooit een last van gehad of heb je zo weinig vertrouwen in je medemens?

Overigens geldt wat jij zegt wel voor algorithms, waar ik je nooit over hoor en geen mens hier heeft het erover in deze thread.

Veel algoritmes zijn erg domein specifiek en het heeft dus weinig nut om dat in dit topic te plaatsen.

Weten wat een priority heap is etc. zijn dingen die ook voorkomen dat je het wiel opnieuw uitvindt.

Zeker. Maar ik zou me dan eerder focussen op wat je sdk te bieden heeft. Je hoeft dan over het algemeen de nitty gritty details van allerlei oplossingen niet te begrijpen om ze te kunnen gebruiken.

Het nadeel voor jou is dat algorithms bewezen effectief zijn in _alle gevallen_ voor wat ze doen, en dus WEL kunnen worden gedoceerd bij het uitleggen van het algorithme.

Ik heb ook nooit beweerd dat algoritmes slecht zijn en ik zie dus niet in hoe dit een nadeel voor mij kan zijn.

Patterns en kennis over algoritmes zijn allemaal tools voor in de toolbox.. Niet meer, niet minder. Het eens is niet slechter dan het andere.

[Tuxie]

Flauwe grappen mag je in de HK maken; SEA is daar geen plek voor

[ Voor 82% gewijzigd door RobIII op 12-03-2008 14:22 ]

[PrisonerOfPain]

Anoniem: 140111 schreef op maandag 10 maart 2008 @ 16:03:
Natuurlijk, maar niet altijd even eenvoudig te begrijpen voor mensen. Daarom zeg ik ook: begin met Head First en koop daarna GoF

Dit heb ik altijd gezien als de meest nuttige eigenschap van dat boek; en dat is niet om elitair te doen. Zodra je de essentie van de design patterns zelf hebt uitgezocht blijven ze een stuk beter hangen en heb je veel meer aan je kennis. Het is met GoF ook vrij makkelijk om een week over een design pattern te doen omdat je het gewoon niet door hebt, maar de kennis die je in die week op doet is veel nuttiger als wanneer je de hapklare brokken uit Head First tot je neemt al is het alleen maar omdat de dingen die je zelf uitvind veel beter blijven hangen als dingen die je verteld worden.

[Anoniem: 140111]

Tja, ik vind Head First een goed instap boek en derhalve raad ik het ook aan.
Hoe je met de opgedane kennis omgaat moet je zelf weten, maar er is in dit topic al een keer of 1000 gezegd dat je niet zomaar moet gaan bouwen om aan een pattern te kunnen voldoen. Dat geldt ook als je GoF hebt gelezen.

[Michali]

Ik denk dat je gewoon moet accepteren dat veel mensen van hun fouten leren. Vroeg of laat schiet je jezelf toch wel een keer in de voet; dan gebruik je een pattern voor een situatie waarbij een veel simpelere oplossing beter was of waarbij hij toch niet van pas blijkt te komen. Achteraf blijk je dan beter te beseffen waar het nu om draait. Maar is dat zo erg? Ik denk dat iedereen wel een dergelijk leerproces doorgaat.

Met een goed boek word je hiervoor beter gewaarschuwd, met een slecht boek minder of niet. Maar ik denk ook dat je het een keer fout moet hebben gedaan wil je echt begrijpen hoe het goed moet. Geef eerlijk toe, hebben jullie het nooit fout gedaan dan?

[Anoniem: 140111]

Ik maak alleen maar fouten, daarom leer ik de laatste tijd zoveel
^{I just invented another way how I shouldn't do...}

[ Voor 29% gewijzigd door Anoniem: 140111 op 12-03-2008 16:05 ]

[AaroN]

Het hele proces van probleem tot implementatie van een oplossing door gebruik van een Agile ontwikkelingsmethode waarbij je gebruik maakt van o.a. UML en patterns kun je beschreven vinden in Applying UML and Patterns, 3rd edition van Craig Larman, mijns inziens een heerlijk boek voor mensen die op zoek zijn naar hoe het complete plaatje er nou uit moet zien.