verantwoordelijkheid waar, in dubio
Ozzie PHP op 30/03/2014 17:31:13:
Haha... je gebruikt wel een bijzondere uitleg om te verklaren waarom je geen voorstander van OO bent. Volgens mij kun je de nadelen die je noemt met bepaalde patterns ondervangen. Maar ieder z'n ding uiteraard :)
Nou, het is niet dat ik geen voorstander van OO ben, maar ik ben heel erg tegen het zinloos gebruik van OO. ;-)
Natuurlijk kun je allerlei dingen opvangen met patterns, maar feit blijft dat je dan een stuk gereedschap gaat gebruiken voor iets waar het niet voor is bedoeld. OO is nu eenmaal geen haarlemmerolie. Het is een stuk gereedschap, en voor elk stuk gereedschap in je koffer moet je per karwei bepalen of je het gaat gebruiken en (zo ja) hoe je het gaat gebruiken.
Programmeurs zijn soms net kinderen: als ze een nieuw truukje leren, willen ze dat te pas en te onpas gebruiken. Leren ze OO programmeren, dan moet dus voortaan alles OO worden, ook als dat helemaal niet nodig/nuttig/handig is. Die fase ben ik zelf inmiddels voorbij. ;-) Bovendien helpt het niet echt dat opleidingen dat OO ook erin blijven drammen. Een beetje opleiding levert tegenwoordig geen OO-pragmatisten af, maar OO-fundamentalisten.
Mijn voornaamste reden om OO te gebruiken zou zijn als ik per regel code zou worden betaald. Want dat is zo ongeveer wat OO in de meeste gevallen doet: het genereert veel code voor weinig functionaliteit, ten koste van de leesbaarheid. Het meest extreme voorbeeld dat ik daar zelf van heb meegemaakt is die keer dat ik 1200+ regels C++-code heb weten samen te vatten in 1 of 2 regels Perl. Dat is weliswaar een valse vergelijking, want het was niet alleen het afstappen van OO, maar ook het toepassen van een andere programmeertaal, maar het geeft wel mooi aan hoe improductief je kunt zijn als je het verkeerde gereedschap gebruikt.
Toch heb ik ook wel projecten gehad waar ik nuttig gebruik kon maken van OO. En dat was zelfs in een semi-realtime omgeving, waar performance dus belangrijk was. (Meestal zijn realtime-omgevingen een contra-indicatie voor het gebruik van OO...)
Veel belangrijker dan het toepassen van OO is het toepassen van de principes van OO. Bijvoorbeeld: zorg ervoor dat je data niet door iedere willekeurige functie wordt bewerkt, maar kanaliseer de bewerkingen op je data. In een procedurele taal zal dat soort dingen misschien wat meer discipline van de programmeur vergen dan in een OO-taal, maar het is goed te doen. Het scheelt al een heleboel als je gewend bent geen globale variabelen te gebruiken.
Ozzie PHP op 30/03/2014 19:52:43:
Ka, begrijp ik... maar ik ben benieuwd hoe de opbouw van zoiets eruit ziet. Werk je met bestanden die per bestand een bepaalde taak hebben (vergelijkbaar met classes)?
In PHP zou ik dat inderdaad zo doen. Functies die bij elkaar horen in een include-bestand zetten en dat includen op plaatsen waar ik het nodig heb.
In de praktijk werk ik vrijwel nooit in PHP (vraag me maar niet wat ik op dit forum doe... ;-) ) maar in Perl. Daar werkt het niet met includes, maar met libraries (eigenlijk ook een soort includes, maar dan net even anders). Ik gooi daar mijn code in een library die ik vervolgens gebruik in de scripts waar ik het nodig heb. Het maakt dan ook eigenlijk niet uit of ik in een library OO-code of procedurele code gebruik. In de praktijk gebruik ik dus vaak een mix van procedurele en objectgeoriënteerde libraries.
Gewijzigd op 30/03/2014 22:35:25 door Willem vp
Ja, dat heb ik vaker gemerkt. Er worden hier vaak allerlei trucs uitgehaald of voorgesteld, waarvan ik denk... dat kan toch makkelijker. Nu ben ik van huis uit geen programmeur, dus dan ga je wel eens af op de expertise van anderen en dan loop je regelmatig tegen dit soort dingen aan. Dus ja, wel herkenbaar.
>> In de praktijk werk ik vrijwel nooit in PHP (vraag me maar niet wat ik op dit forum doe... ;-) )...
Nou, als je zoiets zegt wil ik het juist weten :)
Maar fijn dat je er bent. Je klinkt als een (niet negatief bedoeld) ouwe rot in het vak met veel verstand van zaken :D