Archief - [PROG] Leuk voer ter discussie

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

passero

Legacy Member
Ik kwam zopas dit artikel tegen en er stan een aantal toffe quote's in ter discussie vind ik...

Developers who actively seek to apply patterns to every coding problem are adding unnecessary complexity

Dit vind ik toch niet 100% waar. Ik heb extreme gevallen gezien van serieus grote applicaties waar je het zo zot niet kon bedenken of het had zijn eigen object... maar man, flexibel dat da was, niet te geloven... en niet zo moeilijk om te begrijpen.
Als het complex is, is het tegen dat je de verkeerde zaken gebruikt en dus verkeerd ontwopen hebt imo :)

Enthusiastic UML modeling is typically done by those who aren’t strong coders, but consider themselves software architects anyway.

Hier viel ik toch even van achterover hoor :s
Diene auteur heeft wss nog nooit met grote projecten moeten werken vermoed ik ofwel is hij beetje gefrustreerd :)

jodeman

Legacy Member
in my pov

1) Denk dat dat niet waar is, de java api is bijna helemaal gebaseerd op OO patronen. Kijk naar de FileStream (en onderliggende streamers) die gemaakt zijn met decorator pattern dat gewoon functionaliteit toevoegt. Als het goed gedocumenteerd is maakt dat toch helemaal niets uit.
2) Als je een team van UML modeling hebt (die wsl niet goed kunnen programmeren), dan is dat toch perfect voor een groot project te maken? Ge weet welke klassen er gemaakt moeten worden, hoe de objecten zich moeten gedragen, welke waarden er doorgegeven moeten worden... Dan kunt ge ook heel goed werk verdelen binnen uw project. Iemand maakt die klasses, iemand maakt ander deel...
Dan kunde véél beter werk verdelen dan gewoon iets te programmeren dat voor u het beste lijkt. Als ge dat met UML team doet kunde ook standaarden vastleggen qua post-en precondities en daarna kunt ge nog de klassen veranderen door enkel rekening te houden met deze voorwaarden.

Open for comment ;)

Cu

den Acid Burn

Legacy Member
OO is mooi kwa onderhoud en uitbreidbaarheid, dat is een feit
maar zoals alles heeft ook OO zijn voor- en nadelen.

de overhead om iets simpel te doen is enorm.

als ge zelf iets ineen steekt, niet te uitgebreid, waar niemand anders aan moet werken programmeert ge op de rapste manier

als ge een groter project aan het ontwikkelen zijt waar een aantal mesnen aan moeten werken houdt ge u best aan de OO regels en maakt ge voor elk prulleke getters en setters.
dit zal de productiviteit toch verhogen imo

killgore

Legacy Member
Eerste: 100% waar imho, zoeken om patterns toe te passen gaat erover, je moet gewoon herkennen in welke situatie een bepaald pattern handig is.

Over het 2e: al uw klassen in uml gaan steken en zo gaat er idd over. Je zorgt dat je basissysteem geschetst is, uw hoofdklassen, ..., de nodige zaken opdat jouw team (dit is dus steeds anders) voldoende info heeft. Achteraf kan je met genoeg programma's gedetailleerdere info laten creëren (al dan niet uml).
Ik maak enkel uml schemas voor basissystemen of voor het geheel te schetsen (en zelfs dan nog valt het te zien hoe groot de app is en zo).

Bubbling Zombie

Legacy Member
killgore zei:
Eerste: 100% waar imho, zoeken om patterns toe te passen gaat erover, je moet gewoon herkennen in welke situatie een bepaald pattern handig is.

Over het 2e: al uw klassen in uml gaan steken en zo gaat er idd over. Je zorgt dat je basissysteem geschetst is, uw hoofdklassen, ..., de nodige zaken opdat jouw team (dit is dus steeds anders) voldoende info heeft. Achteraf kan je met genoeg programma's gedetailleerdere info laten creëren (al dan niet uml).
Ik maak enkel uml schemas voor basissystemen of voor het geheel te schetsen (en zelfs dan nog valt het te zien hoe groot de app is en zo).


ik volg killgore (gelijk gewoonlijk) volledig. En voor de rest lijkt mij dit weer een gefrustreerde blogpost. Wat niet wegneemt dat ik zijn code waarschijnlijk niet zou willen lezen :p

jodeman

Legacy Member
lol, daarmee graakt er in Belgie bijna geen één game van de grond, iedereen maakt programma's en daarna UML schema's ter info. In bedrijven gaat het er wel omgekeerd aan toe ;).

killgore

Legacy Member
jodeman zei:
lol, daarmee graakt er in Belgie bijna geen één game van de grond, iedereen maakt programma's en daarna UML schema's ter info. In bedrijven gaat het er wel omgekeerd aan toe ;).
waar staat dat er uml-schemas achteraf worden gemaakt :wtf:?

passero

Legacy Member
Nu we hierover toch bezig zijn :)
heb nog een bijkomend vraagje:

moet code volgens de "regels van kunst van OO" opgesteld zijn om deftige code te zijn? Uiteindelijk zijn het richtlijnen, hulpmiddelen om code leesbaar, flexiber te maken enzo.
Kan iemand minder goed programmeren omdat hij minder snel een pattern herkent dan iemand anders? Is daarom de kwaliteit van de code minder goed?

Nog zo iets... kwaliteit van de code... Wat is belangrijker? Kwaliteit van de applicatie of kwaliteit van de code? Ik geef gerust toe dat wanneer de code van goede kwaliteit is (goed gedocumenteerd, goed ontworpen is,...) de applicatie hoogst waarschijnlijk ook een goede kwaliteit zal hebben maar wil dat daarom zeggen dat een minder goed ontwerp, ook een slechtere applicatie geeft?
er moet ook rekening gehouden worden met het feit dat je vanuit het bedrijfsleven niet altijd de tijd krijgt om een deftige analyse/ontwerp te doen van een applicatie.
Bij ons opt werk worden de analyse's meestal gedaan door de PM (project manager) en die heeft de balle verstand van UML of patterns enzo. Het is meer een functionele analyse waar use cases zeker tot hun recht zouden komen... Wanneer dat klaar is, krijgt de developer dit document (.doc) en moet die direct beginnen developen en krijg een deadline mee... Tijd voor analyse? Geen...
Is dit eigen aan de informaticawereld want ik verschoot wel ff als ik daar werd tewerkgesteld... NU, het is een bedrijf met 8 developers, 2 designers en een stuk of 3 salesmensen... Mss dat het beter is in grotere bedrijven?

jodeman

Legacy Member
Hoe kunt ge nu trouwens in gods naam zoeken voor patronen toe te passen? Het gaat of het gaat niet. Patronen beschrijven allemaal een specifieke situatie, ge kunt geen patronen op een juiste manier gebruiken waar het niet nodig is imho. Dat zijn toch gewoon problemen die zich voordoen in een bepaalde situatie en die kun je met bepaalde patronen oplossen.

killgore

Legacy Member
jodeman zei:
Der staat toch achteraf?
Gedetailleerde info, eventueel voor verder op te werken.

Ik bedoel niet als heel het project klaar is he, als jouw stukje code (interpreteer stuk gelijk ge wilt) af is generate je er documents over met de nodige tools zodat mensen "vlot" kunnen rondneuzen als ze gebruik maken van je klasse. Ik zei dat een uml schema hierbij kan gebruikt worden (ter illustratie), niet moet.

Gewone uml-schemas (eigenlijk ontwerpschetsen :p) maak je natuurlijk op voorhand.

Deguchi

Legacy Member
jodeman zei:
Hoe kunt ge nu trouwens in gods naam zoeken voor patronen toe te passen? Het gaat of het gaat niet. Patronen beschrijven allemaal een specifieke situatie, ge kunt geen patronen op een juiste manier gebruiken waar het niet nodig is imho. Dat zijn toch gewoon problemen die zich voordoen in een bepaalde situatie en die kun je met bepaalde patronen oplossen.

Voor een bepaald probleem bestaat niet noodzakelijk slechts één oplossing he ;) Maar het is inderdaad imo niet nodig om echt actief te gaan zoeken naar waar ge een bepaald patroon kunt gebruiken. De oplossing wijst zichzelf meestal wel uit.

Enthusiastic UML modeling is typically done by those who aren’t strong coders, but consider themselves software architects anyway.

Dat is zeggen dat een racepiloot ook een goede constructeur moet zijn... Zolang hij weet hoe zijn auto in elkaar zit is het voldoende om hem goed te tweaken en op punt te stellen zonder ooit een moersleutel vast te nemen.
Het kan toch goed zijn dat iemand die niet noodzakelijk goed kan coderen wel iemand is met een goed inzicht in probleemoplossing.

Bubbling Zombie

Legacy Member
passero zei:
Nog zo iets... kwaliteit van de code... Wat is belangrijker? Kwaliteit van de applicatie of kwaliteit van de code? Ik geef gerust toe dat wanneer de code van goede kwaliteit is (goed gedocumenteerd, goed ontworpen is,...) de applicatie hoogst waarschijnlijk ook een goede kwaliteit zal hebben maar wil dat daarom zeggen dat een minder goed ontwerp, ook een slechtere applicatie geeft?

Kwaliteit van de applicatie wordt op voorhand gemaakt - als coder kan je alleen de kwaliteit van je code onder controle houden.

Is dit eigen aan de informaticawereld want ik verschoot wel ff als ik daar werd tewerkgesteld... NU, het is een bedrijf met 8 developers, 2 designers en een stuk of 3 salesmensen... Mss dat het beter is in grotere bedrijven?

klassieke analyse werd bij ons door een analyst gemaakt, en met die analyse deden wij het :)

passero

Legacy Member
Bubbling Zombie zei:
Kwaliteit van de applicatie wordt op voorhand gemaakt - als coder kan je alleen de kwaliteit van je code onder controle houden.
Snap ik niet helemaal hoor...
Met slechte code kan je toch voor veel bugs zonder => slechte kwaliteit van de applicatie :)

Linwe

Legacy Member
Met dat eerste statement geef ik dien mens nu eens 100% gelijk seh !
Je kan zoeken, zoeken en blijven zoeken om in situatie x elk pattern in te steken > overkill :/

ALLES in uml steken lijkt mij inderdaad ook niet nodig. Zoals boven al aangehaald werd door killgore, lijkt me het gewoon het belangrijkste dat voor heel het team het geheel duidelijk is + hoe zijn gedetailleerd stuk in dat geheel zal passen. Al wat er extra bijkomt is misschien goed om ooit in de docs te verwerken ;)

Moto

Legacy Member
lol, daarmee graakt er in Belgie bijna geen één game van de grond, iedereen maakt programma's en daarna UML schema's ter info. In bedrijven gaat het er wel omgekeerd aan toe .

Ge denkt toch niet dat bijvoorbeeld voor de Quake-series er ooit 1 UML schema gemaakt is geweest, is trouwens ook qua structuur nogal chaotisch, maar het werkt tenminste :)

Met een team een goed programma afleveren op tijd, waarmee ge later weinig problemen hebt voor onderhoud heeft niks te maken met patterns, UML en hippe program-methodologien

Tijd voor analyse? Geen...
Waarom ook wel voor kleinere projecten waar ge alleen aan werkt?

Mja zie enkel ook maar functionele analyses, maarja die staan zowiezo altijd wel vol gaten.

hoge kwaliteit is op de eerste plaats die analyse zelf eens goed doorlopen :)
+ ook eens nadenken hoe de uiteindelijke applicatie gaat gebruikt worden door de gebruiker

jodeman

Legacy Member
Moto zei:
Met een team een goed programma afleveren op tijd, waarmee ge later weinig problemen hebt voor onderhoud heeft niks te maken met patterns, UML en hippe program-methodologien

Maakt al niet uit, als jij liever programmeert zonder en als uw baas (of wie dan ook) dat goed vindt is dat positief voor u. Iedereen heeft zijn eigen programmeerstijl. Ik vind patronen heel handig omdat ge dan uw klassen kunt maken zodat ze flexibel zijn en ge makkelijk objecten kunt toevoegen in plaats van code te gaan aanpassen.
Heb vakantiewerk gedaan bij dhl en daar is er een team dat UML's maakt en een team dat code schrijft, zo zou het moeten zijn vind ik.

Quake 1 is trouwens bijna helemaal geschreven door één gast (Carmack), dus geen al te groot team (in totaal 4 coders dacht ik) ;).

Bubbling Zombie

Legacy Member
passero zei:
Snap ik niet helemaal hoor...
Met slechte code kan je toch voor veel bugs zonder => slechte kwaliteit van de applicatie :)

True, true. Maar dat lijkt me vrij irrelevant: als je met je team deftige, solide code schrijft zal je applicatie er niet onder lijden. Het ergste wat kan gebeuren is dat je programma sneller gaat lopen. En dat is een ramp natuurlijk :O.

QplQyer

Legacy Member
jodeman zei:
Maakt al niet uit, als jij liever programmeert zonder en als uw baas (of wie dan ook) dat goed vindt is dat positief voor u. Iedereen heeft zijn eigen programmeerstijl. Ik vind patronen heel handig omdat ge dan uw klassen kunt maken zodat ze flexibel zijn en ge makkelijk objecten kunt toevoegen in plaats van code te gaan aanpassen.
Heb vakantiewerk gedaan bij dhl en daar is er een team dat UML's maakt en een team dat code schrijft, zo zou het moeten zijn vind ik.

Quake 1 is trouwens bijna helemaal geschreven door één gast (Carmack), dus geen al te groot team (in totaal 4 coders dacht ik) ;).
Er zou nog een team moeten zijn om er formele methoden op los te laten en het is compleet :p.

Maar aan de reacties te zien vindt al meer dan de helft niet dat er UML-schema's moeten gemaakt worden, zelfs bij grote projecten, of enige andere voorbereiding, probeer dan maar eens het belang van formele methoden uit te leggen :/.

(Ja, voor je huis-tuin-keuken-programmaatje is dat overkill, als je software schrijft die op andermans pc moet draaien heb je wel enige vorm van verantwoordelijkheid om het gegarandeerd stabiel te doen draaien lijkt me).
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan