Archief - OOP vs procedural

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.
R

RobinVdB

Legacy Member
Voor wat gebruiken jullie OOP en voor wat procedural? Ikzelf gebruik eigenlijk altijd procedural omdat dat mij vele beter ligt en ik toch het gevoel heb dat ik hetzelfde kan dan iemand die OOP zou gebruiken. :p
S

Shaddix

Legacy Member
Je kan dat wat vergelijken met het omspitten van je tuin.

Voor een kleine tuin kan je dat gerust met een schup doen. Dan moet je helemaal niet leren om met zo'n traktor te werken.

Aan een groot veld zou ik dan weer niet willen beginnen met een schup...

IMO is OOP altijd beter.
p

profound

Legacy Member
Shaddix zei:
IMO is OOP altijd beter.
Klik om te vergroten...

Idd.

Als je projecten gaat maken van enige omvang ben je bijna verplicht van oo te gaan programmeren/coderen om het overzicht wat te bewaren.

Wat voor zaken programmeer jij dan proceduraal?
d

dJeez

Legacy Member
Shaddix zei:
IMO is OOP altijd beter.
Klik om te vergroten...
Dat nu ook weer niet noodzakelijk, maar OOP laat je sowieso wel toe van je code veel logischer te gaan structureren, wat onderhoud en uitbreiding vergemakkelijkt (op voorwaarde dat je alles correct doet uiteraard).
R

RobinVdB

Legacy Member
@Shaddix: Zit wel wat in eigenlijk.
@Profound: Ik, gewoon sites en als ik geen aanvraag heb dan doe ik aan mijn eigen project. En dat is nu een homepage systeem. Maar ik heb ook al simpele forums gemaakt met procudural.
@dJeez: Alles correct doen is voor mij geen probleem, ik hoor van te veel mensen dat het bij mij te lang duurt omdat ik alles correct wil doen. ;')
D

Drone

Legacy Member
Gebruik je iets van tests in je code? Ik vind dat veel belangrijker dan de vraag oop/procedural. Want als je geen tests gebruikt is je code per definitie fout. Als je juist test dan wordt je zowiezo in de juiste richting geduwd.
D

Dieterg

Legacy Member
profound zei:
Idd.

Als je projecten gaat maken van enige omvang ben je bijna verplicht van oo te gaan programmeren/coderen om het overzicht wat te bewaren.

Wat voor zaken programmeer jij dan proceduraal?
Klik om te vergroten...

Waarschijnlijk zijn UCMS..

Ontopic: ik programmeer bijna altijd OOP.

@drone: pas jij unit testing toe op al je projecten? Op een grootschalig project oké.., maar gaat daar niet veel tijd in verloren?
D

Drone

Legacy Member
Mam zei:
Waarschijnlijk zijn UCMS..

Ontopic: ik programmeer bijna altijd OOP.

@drone: pas jij unit testing toe op al je projecten? Op een grootschalig project oké.., maar gaat daar niet veel tijd in verloren?
Klik om te vergroten...

@Mam
Met visueel te testen gaat er ook veel tijd verloren en de kans dat je iets vergeet is groot. Nu met tests gok ik dat een project ongeveer 1/3 langer duurt.

Voor mijn eigen projecten unit test ik alles. Nu het is iets dat je best in je vrije tijd oefent en dan toepast op projecten van klanten.

Ik neem aan dat je php niet in een console kan draaien dus je moet je testen wsl in een browser doen? Met javascript kan je dit ook zo doen maar het is traag en dat suckt de fun er direct uit.

@RobinVdB
Het komt er op neer dat je eerst een test schrijft die faalt en dan pas je productie code begint te schrijven. Je testen moet ook zo klein mogelijk zijn en meestal maar 1 ding testen. Het zelfde voor je productie code.

Bijvoorbeeld als je een calculator maakt begin je zo:

Eerste test:
Code: 
var c = new Calculator();
if (c.add(1, 1) !=2){
   throw 'adding 1 and 1 should equal 2 failed';
}

Deze run je direct om te kijken of ze faalt. Pas als deze faalt mag je productie code beginnen schrijven.

Production code:

Code: 
var Calculator = function(){}
Calculator.prototype.add = function(first,second){
  return 2;
}

Run test om te kijken of ze werkt. Éénmaal deze werkt mag je opnieuw een test schrijven die faalt. Dit blijf je herhalen tot je het gewenste resultaat hebt. Er zijn nog een paar andere aspecten maar dit is de basis. Google maar eens TDD/BDD + de taal die je gebruikt.
W

W0utR

Legacy Member
Ik ben het ermee eens dat je tests moet schrijven, maar om echt alles te testen.

Wij doen ook heel veel test tijdens het programmeren zelf, vaak word er ook gewoon een dag onderbroken om alles is deftig te testen.
Maar dit is dan ook maar enkel bij de grote projecten.

Testen is goed, maar je verliest er vaak heel veel tijd mee.
D

Disa

Legacy Member
W0utR zei:
Ik ben het ermee eens dat je tests moet schrijven, maar om echt alles te testen.

Wij doen ook heel veel test tijdens het programmeren zelf, vaak word er ook gewoon een dag onderbroken om alles is deftig te testen.
Maar dit is dan ook maar enkel bij de grote projecten.

Testen is goed, maar je verliest er vaak heel veel tijd mee.
Klik om te vergroten...

Testen schrijven (dus niet eens op alles klikken..) wint je later tijd.

Moet je alles testen? Neen, uiteraard niet maar een grondige coverage kan je wel veel miserie besparen. Als je TDD gebruikt zoals Drone dan verplicht je jezelf om je interface goed uit te werken en toch al minstens 1x een mini analyse te maken van hoe je het gaat aanpakken.

Voor een project waar ik nog aan meegewerkt heb was het de gewoonte om voor iedere bug die binnenkwam een testcase te schrijven. Kwam je in een stuk van het project terecht dan probeer je de code coverage voor dat stuk te verhogen. Een aantal voordelen:
  • Omdat tests worden uitgevoerd op iedere build (of toch zeker iedere release, iets wat het PHP team nu ook heeft ondervonden...) kunnen bugs moeilijker geherintroduceerd worden.
  • Als een nieuwe developer een stuk code voor zich krijgt met een aantal testen bij, is het meestal duidelijker waarom die code zo in mekaar steekt.
D

Drone

Legacy Member
Testen achteraf vind ik altijd zo raar. Wat test je dan eigenlijk en hoe weet je wat je getest hebt wel relevant is? Voor algemene testen kan ik dat nog begrijpen dat je zekerheid wil hebben dat alles goed samen werkt.
C

Cycloon

Legacy Member
W0utR zei:
Ik ben het ermee eens dat je tests moet schrijven, maar om echt alles te testen.

Wij doen ook heel veel test tijdens het programmeren zelf, vaak word er ook gewoon een dag onderbroken om alles is deftig te testen.
Maar dit is dan ook maar enkel bij de grote projecten.

Testen is goed, maar je verliest er vaak heel veel tijd mee.
Klik om te vergroten...

Haha, een halve dag onderbreken om te testen :lol:

Good luck als je ooit eens een upgrade van je technologie moet doen. En nog véél meer good luck als je eens aan grondige rewrite begint. Dan ben je alle speciale testgevallen al lang vergeten en zal je 100% zeker bugs introduceren. Of nog beter, je gaat ooit code moeten herwerken die je zelf niet kent zonder unit tests.
W

W0utR

Legacy Member
Een halve dag om te testen is echt niet veel hoor ...

Het gaat hier ook over het testen met echte users, niet alleen over code testen...
Testen van interfaces en usability.

Ik weet dat jullie het hadden over het puur testen van code ... (wss was mijn zins opbouw gewoon slecht)
Maar een goed werkende code is niet alles in een website.

@Drone, test achteraf gaan meer over het goed werken van code binnen andere onderdelen.
Specifieke dingen worden nog altijd apart getest.
Maar zoals je zelf zegt, soms wil je gewoon testen of iets goed werkt als je er iets anders aan toevoegt.
d

dJeez

Legacy Member
Mam zei:
pas jij unit testing toe op al je projecten? Op een grootschalig project oké.., maar gaat daar niet veel tijd in verloren?
Klik om te vergroten...
Elk project, hoe kleinschalig ook, is gebaat bij unit en functional testing. En ja, je steekt daar tijd in, maar als die klant later terugkomt om zijn klein startproject om te toveren in een mastodont, dan ben je blij dat je vooruit hebt gedacht :p.

En een extra voordeel : ipv als een aapje een heel scenario weer eens te doorlopen om na te gaan of alles nog werkt (tenzij je dat enkel aan de gebruikers overlaat, persoonlijk zou ik dat echt afraden) start je gewoon een geautomatiseerd proces dat alle tests (volgens een script) uitvoert en controleert of wat je als output verwacht ook effectief nog klopt (en dat gaat dan over zowel unit als functional testing). En de volgende morgen zie je dan het resultaat - en weet je direct welke dingen je moet aanpakken. Geef mij maar automated tests... Idealiter voer je de tests geautomatiseerd uit bij elke release (of merge met je master branch), zodat je vrij zeker bent dat het geheel werkt als je gaat deployen (er kan nog steeds iets over 't hoofd gezien worden hé).

Het Play! framework (Java/Scala) was wat dat betreft echt een verademing om mee te werken (met cobertura plugin voor coverage reporting).
D

Dieterg

Legacy Member
@djeez, drone: Bedankt voor de uitleg!

Het Play! framework wil ik al een langer tijdje van dichterbij bekijken. Ben atm nog teveel bezig met PHP (dit komt jammergenoeg door 't school). Zelf zou ik me liever verdiepen in java!
d

dJeez

Legacy Member
Play! gaat echter wel steeds meer richting Scala... Dat was 1 van de redenen waarom we het na mijn testproject (dat nog live moet gaan) hebben gedropt. Nu gaan we voluit voor Symfony2 (en PHP dus).
M

Moto

Legacy Member
OOP is overrated, OOP was geweldig 10 jaar geleden, nu is meer functional programming dat intressanter word (multi-processors/threading) , immutability, currying, zaken die veel intressanter zijn dan uw OOP en uw GOF DP maar precies geen enkele beginnende developer die er naar kijkt.

Nuja eigenlijk hangt het puur van de context af, maar meeste "die-hard" OOP developers zijn vooral goed in het complexer maken van simpele applicaties.

Cargo Cult Programming is echt wel een groot probleem tegenwoordig.


Met visueel te testen gaat er ook veel tijd verloren en de kans dat je iets vergeet is groot. Nu met tests gok ik dat een project ongeveer 1/3 langer duurt.
Klik om te vergroten...
Visueel aka zelf zaken testen is het enigste (dat in de meeste gevallen) ECHT belangrijk is, automatische testen draaien is geen reden geldig excuus/reden om minder visueel te testen.

Good luck als je ooit eens een upgrade van je technologie moet doen. En nog véél meer good luck als je eens aan grondige rewrite begint
Klik om te vergroten...
Alles hangt af van de Context, als ge fixed-price maatwerk projectjes doet voor de klant, of als ge als bedrijf een software-produkt verkoopt dat regelmatig een update krijgt (bv boekhoud-pakket) is een groot verschil
R

RobinVdB

Legacy Member
Voor wat is al dat testen eigenlijk goed? Moest het gewoon goed werken is er toch geen probleem?
D

Dieterg

Legacy Member
RobinVdB zei:
Voor wat is al dat testen eigenlijk goed? Moest het gewoon goed werken is er toch geen probleem?
Klik om te vergroten...

Hoe ga jij er vanuit dat het 'gewoon goed' werkt..?
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