The Rise and Fall of OOP?

[Groeneg2]

Ik hoor de laatste tijd veel verhalen over het minder populair zijn/worden van OOP?
Wat is er waar van deze verhalen?

http://c2.com/cgi/wiki?ArgumentsAgainstOop
http://programmers.stacke...popular-in-the-age-of-oop
http://www.drdobbs.com/cpp/why-code-in-c-anymore/240149452

[Bob]

Mijn mening, veel simpeler dan al die discussies en misschien te simpel:
Efficient programmeren is onder andere code hergebruiken zonder veel moeite. Wat in mijn geval wil zeggen dat ik zonder veel problemen losse functies hergebruik, soms templated, soms met basic argumenten als pointers en sizes waardoor ze nog steeds relatief onafhankelijk zijn van data types.
Basic objecten gebruik enkel als er overduidelijk state moet worden bijgehouden en wanneer het een geknoei wordt om die state 'los' bij te houden.

In mijn huidig project gebruik ik inheritance en polymorphisme op een fancy manier, het werkt prima maar het heeft me volgens mij ook al evenveel kopzorgen bezorgd omdat er erg veel dingen gebeuren die niet meer intuitief zijn (maar wel prima werken als je het zorgvuldig programmeert).

Conclusie: ik weet het niet goed. Als je OO tot het uiterste gebruikt moet je er heel erg goed je hoofd bij houden, anders schiet je jezelf in no time in je eigen voet. Tiens, dat lijkt heel erg op wat er op de gebruiksaanwijzing van C++ staat

[ Voor 34% gewijzigd door Bob op 22-01-2014 10:03 ]

[Groeneg2]

Wij van WC eend adviseren WC eend mits je je houdt aan de beperkingen van WC eend
Is dat wat je zegt

[Bob]

Groeneg2 schreef op woensdag 22 januari 2014 @ 10:19:
Wij van WC eend adviseren WC eend mits je je houdt aan de beperkingen van WC eend
Is dat wat je zegt

Nah niet echt. Als je gewoon zonder OO imperatief programmeert is het moeilijk(er) jezelf in de voet te schieten. OO, inclusief de fancy stuff, maakt het ingewikkelder.

[Groeneg2]

Bob schreef op woensdag 22 januari 2014 @ 10:21:
[...]OO, inclusief de fancy stuff, maakt het ingewikkelder.

Dat ben ik dus met je eens.
Maar vraag ging ook over hoe het momenteel gesteld is met OOP. Zweren we er nog bij of is het toch een beetje van zijn voetstuk gevallen?

[kwaakvaak_v2]

OO is geen religie, het is een manier om een doel te bereiken. Maar niet voor elke klus de manier om dat doel te bereiken. In webdevelopment land is het de heilige graal en worden relatief simpele dingen volledig uit zijn verband getrokken om het maar OO te doen. (ja ik beken direct schuld!)

Maar terug kijkend op ruim 15 jaar webdevven vraag ik mij de laatste tijd ook steeds vaker af, zijn wij niet doorgeslagen. Frameworks van een paar 100 classes om een relatief simpel formulier + opslaan facebook appje te maken wat je normaal in 3 a 4 bestanden maakt. Dus tja... Ik denk dat met het volwassen worden van mijn deel van de industrie ook het inzicht komt dat het geen schande is om terug naar de basis van eenvoud te gaan zonder uit het oog te verliezen dat je wel een bepaalde herbruikbaarheid van componenten wilt, al was het alleen maar om de scheiding tussen logica en presentatie af te dwingen en DRY tussen projecten te handhaven.

[farlane]

Het maakt geen hol uit wat je doet, als je het maar (zo) gestructureerd (mogelijk) doet.

[Bob]

kwaakvaak_v2 schreef op woensdag 22 januari 2014 @ 10:40:
OO is geen religie, het is een manier om een doel te bereiken. Maar niet voor elke klus de manier om dat doel te bereiken. In webdevelopment land is het de heilige graal en worden relatief simpele dingen volledig uit zijn verband getrokken om het maar OO te doen. (ja ik beken direct schuld!)

Maar terug kijkend op ruim 15 jaar webdevven vraag ik mij de laatste tijd ook steeds vaker af, zijn wij niet doorgeslagen. Frameworks van een paar 100 classes om een relatief simpel formulier + opslaan facebook appje te maken wat je normaal in 3 a 4 bestanden maakt. Dus tja... Ik denk dat met het volwassen worden van mijn deel van de industrie ook het inzicht komt dat het geen schande is om terug naar de basis van eenvoud te gaan zonder uit het oog te verliezen dat je wel een bepaalde herbruikbaarheid van componenten wilt, al was het alleen maar om de scheiding tussen logica en presentatie af te dwingen en DRY tussen projecten te handhaven.

2nd that.

Om even te kijken naar de libraries die ik momenteel gebruik in mijn project:
De helft is OO, de helft is platte C. Ook opmerkelijk: de libs die OO zijn, gebruiken allemaal template code om hun code herbruikbaar genoeg te maken. Ik denk dat er wel iets van aan is, dat pure OO moeilijk herbruikbaar is.

[SPee]

1. http://c2.com/cgi/wiki?ArgumentsAgainstOop
2. http://programmers.stacke...popular-in-the-age-of-oop

1. Dit zou ik niet classificeren als een serieuze site. Moeilijk te lezen, vol met meningen.
2. Hier gaat het over de #2 taal. De #1 taal (Java) is OOP gebaseerd.

[ZaZ]

farlane schreef op woensdag 22 januari 2014 @ 10:51:
Het maakt geen hol uit wat je doet, als je het maar (zo) gestructureerd (mogelijk) doet.

Ja.
Softwarelandschap zit vol met trends
Event driven programming, OOP, God classes, NoSQL, ORM's... Steeds is het weer iets anders wat je MOET gebruiken omdat je anders gek bent.
Over een paar jaar is een ORM bijv vast wel weer een slecht idee volgens ongeveer iedereen want ...

[kwaakvaak_v2]

Veel mensen lijken trends en tools door elkaar te gooien en willen kost wat het kost iets bouwen in iets waar het niet voor bedoeld is. Net als dat er toepassingen zijn waar een RDBMS gewoon nodig is, zijn er ook toepassingen waar juist een DocumentStore (noSQL) weer heel handig is. Of misschien juist wel een combinatie van

[NMe]

C behoudt zijn populariteit vanwege een paar dingen. Ten eerste is het gewoon relevant voor bepaalde toepassingen. Als je weinig resources tot je beschikking hebt (bijvoorbeeld op microcontrollers) wil je zelf zo veel mogelijk controle hebben over je CPU- en geheugengebruik op een niveau dat je met een managed taal als C# of Java nooit gaat lukken. Ten tweede is een aantal bedrijven en gebruikers enigszins verstokt in hun gewoonte om een bepaalde taal te gebruiken. Dat is niet puur bij C het geval; ik hoor nog steeds verhalen van mensen die recent in Cobol hebben geprogrammeerd omdat hun werkgever niet wil moderniseren.

Ik denk in elk geval dat het erg vroeg is om te spreken van een "val" van OOP. Zolang er geen beter paradigma de kop opsteekt zal OOP in de meeste gevallen de way to go blijven om je code te structureren.

farlane schreef op woensdag 22 januari 2014 @ 10:51:
Het maakt geen hol uit wat je doet, als je het maar (zo) gestructureerd (mogelijk) doet.

Inderdaad. Je zou in C met behulp van structs en slim gebruik van headerfiles best in de buurt kunnen komen bij het overzicht van OOP. Zonder inheritance en polymorphism en dergelijken, maar goed genoeg om goed gestructureerde code te schrijven in een "platte" taal.

ZaZ schreef op woensdag 22 januari 2014 @ 11:07:
[...]

Ja.
Softwarelandschap zit vol met trends

Klopt...

Event driven programming, OOP, God classes, NoSQL, ORM's... Steeds is het weer iets anders wat je MOET gebruiken omdat je anders gek bent.

...maar een groot deel van de dingen hier zijn geen trends. Die benaming doet geen recht aan de grote paradigmawijzigingen die ze teweeggebracht hebben.

[Waster]

Maar C is toch met name populair omdat het heel veel gebruikt wordt op embedded systems. Embedded system programming en software development zijn toch twee vakken apart en dat haal je niet uit de TIOBE index.

Ik merk zelf dat hoe meer ik aan de data kant zit, hoe minder OOP nuttig is. Dan gebruik ik veel static methodes en classes, immutables en is het functionele paradigma ook nuttig. Voor GUI programmeren is OOP denk ik zeer nuttig.

Het zijn ook andere manieren van denken. Denk je vanuit de data en welke transformaties en berekeningen nodig zijn. Of denk je vanuit het object en wat het moet kunnen (welke methodes) en wat het voor interface biedt. Je kan het ook prima combineren. Een class die iets abstraheert en daarachter de methodes die een library aanspreekt die data-georienteerd is opgebouwd.

Wat je ook niet moet vergeten is dat een object state bijhoudt. En zeker als je iets abstraheert in privates, dan heb je overal classes waar een deel van de state bijgehouden word die op de een of andere manier aan elkaar gekoppeld dienen te worden.Daarom vind ik webdevelopment en OOP zo raar. Alles is stateless, behalve wat in de database zit, dus wat heb je aan objecten? Je hebt alleen maar methodes nodig om iets uit de database te halen, iets te transformeren en weer in de database te stoppen.

[ZaZ]

NMe schreef op woensdag 22 januari 2014 @ 11:44:
[...]

...maar een groot deel van de dingen hier zijn geen trends. Die benaming doet geen recht aan de grote paradigmawijzigingen die ze teweeggebracht hebben.

True. Het woord trend is wat dat betreft een beetje ongelukkig gekozen omdat ik alles op 1 hoop gooi.
Dat soort technologien komen wel altijd met een grote klap binnen (net als de meeste trends) en hoewel soms (extreem) zinvol, niet altijd de juiste aanpak.
Een beetje "if all you have is a hammer..."

[NMe]

Waster schreef op woensdag 22 januari 2014 @ 11:55:
Ik merk zelf dat hoe meer ik aan de data kant zit, hoe minder OOP nuttig is. Dan gebruik ik veel static methodes en classes, immutables en is het functionele paradigma ook nuttig. Voor GUI programmeren is OOP denk ik zeer nuttig.

Ik zit zelf doorgaans niet dichter op de data dan nodig is voor een (complexe) website maar ik ben nog geen situatie tegengekomen waar goeie ORM een probleem vormt waardoor je alsnog terug zou moeten vallen op functioneel programmeren of stapels static methods. Ik kan me redelijk lastig voorstellen dat dat in andere situaties wél een probleem is, afgezien van situaties weer elke microseconde aan snelheidswinst telt.

[farlane]

Waster schreef op woensdag 22 januari 2014 @ 11:55:
Maar C is toch met name populair omdat het heel veel gebruikt wordt op embedded systems.

C is iha de eerste compiler die geschreven wordt voor een (hardware) platform, of dat nou embedded is of iets anders: Windows, Unix Linux en what not zijn allemaal geschreven in C.

Een belangrijke oorzaak daarvan zal zijn dat er nou eenmaal een schier oneindige voorraad code is die je kunt gebruiken als er een C compiler bestaat voor je platform.

[Patriot]

kwaakvaak_v2 schreef op woensdag 22 januari 2014 @ 10:40:
OO is geen religie, het is een manier om een doel te bereiken. Maar niet voor elke klus de manier om dat doel te bereiken. In webdevelopment land is het de heilige graal en worden relatief simpele dingen volledig uit zijn verband getrokken om het maar OO te doen. (ja ik beken direct schuld!)

Maar terug kijkend op ruim 15 jaar webdevven vraag ik mij de laatste tijd ook steeds vaker af, zijn wij niet doorgeslagen. Frameworks van een paar 100 classes om een relatief simpel formulier + opslaan facebook appje te maken wat je normaal in 3 a 4 bestanden maakt. Dus tja... Ik denk dat met het volwassen worden van mijn deel van de industrie ook het inzicht komt dat het geen schande is om terug naar de basis van eenvoud te gaan zonder uit het oog te verliezen dat je wel een bepaalde herbruikbaarheid van componenten wilt, al was het alleen maar om de scheiding tussen logica en presentatie af te dwingen en DRY tussen projecten te handhaven.

Je kunt ook gebruik maken van OO zonder een framework te gebruiken. Dat gezegd hebbende, als iets echt zo klein is dan maakt het niet uit hoe je het programmeert. Als je het later moet aanpassen is het bij zoiets kleins namelijk toch geen moeite om even te kijken hoe het werkt.

Wat webdevelopment betreft is MVC gewoon heel belangrijk, en dat is gewoon lekker makkelijk te doen met OO. Je kunt het ook wel op een andere manier doen, maar ik betwijfel dat dat makkelijker is.

[HawVer]

Wat ik persoonlijk een nadeel vind van OOP is dat het al snel leidt tot een warboel aan classes. Met name als er ook interfaces en overerving worden toegepast. Zodra er nieuwe mensen in je team komen kost het redelijk wat tijd om ze in te werken en ervoor te zorgen dat ze voldoende vertrouwen krijgen om een deel van de applicatie aan te passen.

Vanuit een ontwikkelaars oogpunt is het gaaf om een ingewikkelde structuur neer te zetten die goed werkt. Als het je eigen werk is kun je er goed mee werken, snel aanpassingen doen, etc. Maar zodra de oorspronkelijke architect het team verlaat zit de volgende met de gebakken peren.

Ik denk dat we steeds meer gaan naar talen die puur een functioneel doel dienen. Hoe kun je met zo min mogelijk regels code zoveel mogelijk functionaliteit realiseren. Data layers, interfaces, inheritance, ORM, etc. zijn technische gimmicks die vaak meer problemen (performance, onderhoudbaarheid, etc) opleveren dan dat je er winst mee behaalt.

De populariteit van platformen zoals NodeJS onderstrepen dat.er meer behoefte is aan eenvoud. Hergebruik van code wordt gerealiseerd door library's en de eenvoud waarmee ze gedeployed worden. (npm).

[Hydra]

Bob schreef op woensdag 22 januari 2014 @ 10:21:
Nah niet echt. Als je gewoon zonder OO imperatief programmeert is het moeilijk(er) jezelf in de voet te schieten. OO, inclusief de fancy stuff, maakt het ingewikkelder.

Het hele idee van OOP is dat je code, vooral in grote projecten, beter te begrijpen maar. Hoe class X werkt is alleen de zaak van class X, en niet van allerhande andere scripts. Als OOP je werk 'complexer' maakt, doe je iets niet goed.

[NMe]

Hydra schreef op woensdag 22 januari 2014 @ 13:07:
[...]

Het hele idee van OOP is dat je code, vooral in grote projecten, beter te begrijpen maar. Hoe class X werkt is alleen de zaak van class X, en niet van allerhande andere scripts. Als OOP je werk 'complexer' maakt, doe je iets niet goed.

Het klopt wel redelijk dat OOP je bestandsstructuur wat uitgebreider maakt, maar IMO is dat tegelijkertijd inderdaad overzichtelijker. Zeker omdat je bij bugs niet verder hoeft te graven dan noodzakelijk en OOP dat gedrag niet afdwingt maar wel beloont.

[Hydra]

Waster schreef op woensdag 22 januari 2014 @ 11:55:
Maar C is toch met name populair omdat het heel veel gebruikt wordt op embedded systems.

Dat, en veel linux open source, vooral kernel spul. En dat is een compleet andere wereld dan waar de meeste developers in werken, enterprise (web) applicaties.

HawVer schreef op woensdag 22 januari 2014 @ 12:58:
Wat ik persoonlijk een nadeel vind van OOP is dat het al snel leidt tot een warboel aan classes. Met name als er ook interfaces en overerving worden toegepast. Zodra er nieuwe mensen in je team komen kost het redelijk wat tijd om ze in te werken en ervoor te zorgen dat ze voldoende vertrouwen krijgen om een deel van de applicatie aan te passen.

Wat heeft dat met OOP te maken? Toen ik hier kwam werken moest ik ook een hoop niet-OO code leren begrijpen. Omdat de samenhang (door het gebrek aan OO) weinig duidelijk is, is dat echt niet eenvoudiger hoor.

Vanuit een ontwikkelaars oogpunt is het gaaf om een ingewikkelde structuur neer te zetten die goed werkt. Als het je eigen werk is kun je er goed mee werken, snel aanpassingen doen, etc. Maar zodra de oorspronkelijke architect het team verlaat zit de volgende met de gebakken peren.

Een slecht ontwerp heeft niks met OO te maken, een goed ontwerp ook niet.

Ik denk dat we steeds meer gaan naar talen die puur een functioneel doel dienen. Hoe kun je met zo min mogelijk regels code zoveel mogelijk functionaliteit realiseren. Data layers, interfaces, inheritance, ORM, etc. zijn technische gimmicks die vaak meer problemen (performance, onderhoudbaarheid, etc) opleveren dan dat je er winst mee behaalt.

Het aantal regels code maakt code niet meer/minder leesbaar. Voor iemand die 'into Java' is, is java code perfect leesbaar. Het heeft veel meer met ervaring te maken dan met hoeveel regels je precies nodig hebt. Daarnaast is wat extra spul voor een classdefinition ook het issue niet; de complexe algorithmische dingen zijn in vrijwel elke taal vrijwel net zo complex.

De populariteit van platformen zoals NodeJS onderstrepen dat.er meer behoefte is aan eenvoud. Hergebruik van code wordt gerealiseerd door library's en de eenvoud waarmee ze gedeployed worden. (npm).

Gebruik zelf Node.js ook, en de populariteit heeft vooral te maken met de integratie van backend en frontend. Daarnaast kun je in JavaScript prima OO programmeren, doe ik zelf ook.

[ Voor 75% gewijzigd door Hydra op 22-01-2014 13:27 ]

[Dricus]

HawVer schreef op woensdag 22 januari 2014 @ 12:58:
Wat ik persoonlijk een nadeel vind van OOP is dat het al snel leidt tot een warboel aan classes. Met name als er ook interfaces en overerving worden toegepast.

Dit is volgens mij niet uniek voor OOP. Welke taal je ook gebruikt, bij een niet-triviaal systeem zul je op een gegeven moment een warboel aan dingen hebben, als je geen/weinig aandacht besteedt aan het goed organiseren van je code. Bij OOP talen kun je dit organiseren door packages of namespaces te gebruiken, bij C door .c/.h files in directories te groeperen, etc.

Laatst ben ik weer eens op het aloude Entity-Control-Boundary pattern gestuit. Dit is een voorbeeld van een pattern dat je helpt om je code op zo'n manier te structureren dat het enigszins inzichtelijk blijft, ook als het systeem wat groter wordt. Zo zijn er nog wel meer patterns die je daarbij helpen. Net zoals het probleem van de "warboel" speelt voor alle talen, zijn dit soort patterns in alle talen bruikbaar.

[Bigs]

Als Ruby programmeur (een taal waarin alles een object is) zit ik toch stevig in het OOP kamp. Soms kom ik wel problemen tegen waar een functionele aanpak (immutable data, geen side effects) tot een nettere oplossing of betere prestaties leidt, maar ik merk toch dat ik de meeste problemen het eenvoudigst uit kan drukken in OOP patronen. Alternatieven voor OOP (denk LISP) bestaan al sinds eind jaren 60 en toch heeft OOP al die tijd de overhand gehad als meest populaire manier van ontwikkelen. Dit wil niet zeggen dat het technisch superieur is, maar wellicht dat het in te praktijk beter te begrijpen en toe te passen is voor mensen.

Vergelijk het een beetje met de NoSQL hype; ineens moesten we allemaal van SQL af (en staken er zelfs weer immutable database de kop op) maar een paar jaar later zie je dat mensen toch weer naar 'traditionele' SQL databases grijpen. Het is (net als OOP) toch een bewezen tool waar mensen zich prettig bij voelen.

[kwaakvaak_v2]

Patriot schreef op woensdag 22 januari 2014 @ 12:15:
[...]

Wat webdevelopment betreft is MVC gewoon heel belangrijk, en dat is gewoon lekker makkelijk te doen met OO. Je kunt het ook wel op een andere manier doen, maar ik betwijfel dat dat makkelijker is.

Dat is dus per definitie waar! MVC is niet de heilige graal, zoals die webdevelopment land gepreekt wordt!

Webdevelopment draait om het HTTP protocol en het gegeven dat een request *altijd* een response moet opleveren. En hoe je dat in je router/controller/script oplost is jouw zaak. Dat een view en een controller daar handig bij zijn ben ik met je eens. Maar het kan ook gewoon een closure in je router zijn die een repsonse terug geeft zonder dat daar een model of een view bij nodig is. Het is maar net wat de context van je webapp is.

[RayNbow]

SPee schreef op woensdag 22 januari 2014 @ 10:54:
[...]

1. Dit zou ik niet classificeren als een serieuze site. Moeilijk te lezen, vol met meningen.

Het is daarentegen wel de allereerste wiki site.

[Hydra]

kwaakvaak_v2 schreef op woensdag 22 januari 2014 @ 13:32:
Webdevelopment draait om het HTTP protocol en het gegeven dat een request *altijd* een response moet opleveren. En hoe je dat in je router/controller/script oplost is jouw zaak. Dat een view en een controller daar handig bij zijn ben ik met je eens. Maar het kan ook gewoon een closure in je router zijn die een repsonse terug geeft zonder dat daar een model of een view bij nodig is. Het is maar net wat de context van je webapp is.

Het gaat natuurlijk om grotere / complexere applicaties. Het MVC model is primair bedoeld om onderhoudbare applicaties te bouwen.

RayNbow schreef op woensdag 22 januari 2014 @ 13:32:
Het is daarentegen wel de allereerste wiki site.

Waarom het niet de meeste gebruikte is is wel duidelijk.

[ Voor 14% gewijzigd door Hydra op 22-01-2014 13:35 ]

[HawVer]

Dricus schreef op woensdag 22 januari 2014 @ 13:15:
[...]
Dit is volgens mij niet uniek voor OOP. Welke taal je ook gebruikt, bij een niet-triviaal systeem zul je op een gegeven moment een warboel aan dingen hebben, als je geen/weinig aandacht besteedt aan het goed organiseren van je code. Bij OOP talen kun je dit organiseren door packages of namespaces te gebruiken, bij C door .c/.h files in directories te groeperen, etc.

Laatst ben ik weer eens op het aloude Entity-Control-Boundary pattern gestuit. Dit is een voorbeeld van een pattern dat je helpt om je code op zo'n manier te structureren dat het enigszins inzichtelijk blijft, ook als het systeem wat groter wordt. Zo zijn er nog wel meer patterns die je daarbij helpen. Net zoals het probleem van de "warboel" speelt voor alle talen, zijn dit soort patterns in alle talen bruikbaar.

Mee eens. Het hangt absoluut af van de mentaliteit en de kennis van de ontwikkelaar. Als je designpatterns, inheritance, etc goed doorvoert kan dat alsnog leiden tot een complexe niet te onderhouden structuur. Ik denk dat de ene taal er meer vatbaar voor is dan een andere taal.

Designpatterns zijn een soort van onofficiële code onder ontwikkelaars om er voor te zorgen dat het niet uit de hand loopt. Mijn punt is dat het een lapmiddel is voor problemen van het concept.

Overigens denk ik niet dat er een silver bullet is. Ik hoop alleen wel dat die er ooit komt.

[kwaakvaak_v2]

Hydra schreef op woensdag 22 januari 2014 @ 13:33:
[...]


Het gaat natuurlijk om grotere / complexere applicaties. Het MVC model is primair bedoeld om onderhoudbare applicaties te bouwen.

Dat snap ik, en dat bedoel ik dus met de context. Maar niet elke webapp is een complexe of grote applicatie, net als dat MVC niet altijd de beste keuze is. Alles hangt van die context af.

[Hydra]

kwaakvaak_v2 schreef op woensdag 22 januari 2014 @ 13:36:
Dat snap ik, en dat bedoel ik dus met de context. Maar niet elke webapp is een complexe of grote applicatie, net als dat MVC niet altijd de beste keuze is. Alles hangt van die context af.

Het is nogal duidelijk dat hij het over webapplicaties had en niet over een simpel statusscriptje.

HawVer schreef op woensdag 22 januari 2014 @ 13:35:
Mee eens. Het hangt absoluut af van de mentaliteit en de kennis van de ontwikkelaar. Als je designpatterns, inheritance, etc goed doorvoert kan dat alsnog leiden tot een complexe niet te onderhouden structuur. Ik denk dat de ene taal er meer vatbaar voor is dan een andere taal.

Waarom? Je kunt rotzooi in iedere taal produceren.

Designpatterns zijn een soort van onofficiële code onder ontwikkelaars om er voor te zorgen dat het niet uit de hand loopt. Mijn punt is dat het een lapmiddel is voor problemen van het concept.

Want?

[ Voor 45% gewijzigd door Hydra op 22-01-2014 13:40 ]

[raptorix]

NMe schreef op woensdag 22 januari 2014 @ 12:00:
[...]

Ik zit zelf doorgaans niet dichter op de data dan nodig is voor een (complexe) website maar ik ben nog geen situatie tegengekomen waar goeie ORM een probleem vormt waardoor je alsnog terug zou moeten vallen op functioneel programmeren of stapels static methods. Ik kan me redelijk lastig voorstellen dat dat in andere situaties wél een probleem is, afgezien van situaties weer elke microseconde aan snelheidswinst telt.

Content Management Systemen hebben meestal een database structuur die desastreus is voor ORM mappers (aan de achterkant dus!), aan de voorkant kun je natuurlijk uitermate geschik ORM en of NoSql gebruiken.

[raptorix]

Ik ben zelf geen enorme fan van OO, komt ook omdat ik meer een scripter ben dan een hardcore developer, echter het laatste jaar krijg ik er steeds meer mee te maken omdat we onze webapplicaties beter structureren, zelf vind ik dat sommige OO liefhebbers nog wel eens willen doorschieten, en tot in het oneindige blijven abstraheren omdat het "puurder" is, leuk vanuit OO perspectief, maar in de praktijk vaak omslachtig en nutteloos.

[Hydra]

raptorix schreef op woensdag 22 januari 2014 @ 13:41:
Content Management Systemen hebben meestal een database structuur die desastreus is voor ORM mappers (aan de achterkant dus!), aan de voorkant kun je natuurlijk uitermate geschik ORM en of NoSql gebruiken.

In ORM mappers kun je over het algemeen prima zelf ingrijpen. Maar je maakt nu een (terechte) case tegen ORMs, niet een case tegen OOP.

raptorix schreef op woensdag 22 januari 2014 @ 13:44:
Ik ben zelf geen enorme fan van OO, komt ook omdat ik meer een scripter ben dan een hardcore developer, echter het laatste jaar krijg ik er steeds meer mee te maken omdat we onze webapplicaties beter structureren, zelf vind ik dat sommige OO liefhebbers nog wel eens willen doorschieten, en tot in het oneindige blijven abstraheren omdat het "puurder" is, leuk vanuit OO perspectief, maar in de praktijk vaak omslachtig en nutteloos.

Da's een fase waar iedere junior > medior doorheen gaat

[ Voor 40% gewijzigd door Hydra op 22-01-2014 13:45 ]

[raptorix]

Hydra schreef op woensdag 22 januari 2014 @ 13:45:
[...]


In ORM mappers kun je over het algemeen prima zelf ingrijpen. Maar je maakt nu een (terechte) case tegen ORMs, niet een case tegen OOP.


[...]


Da's een fase waar iedere junior > medior doorheen gaat

Klopt, je kunt natuurlijk ook een stored procedure of view gebruiken, maar dan nog is het niet ideaal, simpelweg omdat he databasemodel daar niet op gemaakt is, ik gebruik zelf veel Umbraco, in versie 5 hebben ze het geprobeerd met nHibernate, is een fiasco geworden en na 1.5 jaar development hebben ze er zelf maar de stekker uit getrokken

[NMe]

Hydra schreef op woensdag 22 januari 2014 @ 13:45:
[...]

In ORM mappers kun je over het algemeen prima zelf ingrijpen. Maar je maakt nu een (terechte) case tegen ORMs, niet een case tegen OOP.

Dat inderdaad. ORM mappers zijn leuk maar je kan maar tot een bepaald punt automatiseren, de rest zul je zelf moeten doen. Als je het echter eenmaal goed hebt zitten kan ik zeker voor webdevelopment eigenlijk geen situatie bedenken waar OOP géén goed idee is.

[Caelorum]

Hydra schreef op woensdag 22 januari 2014 @ 13:45:
[...]
Da's een fase waar iedere junior > medior doorheen gaat

Dat hoeft helemaal niet. Sommige mensen gaan ook van weinig abstractie naar precies het goede niveau. Ja, je hebt er die lui bij die extreem doorschieten en denken dat je zover moet door abstraheren dat een class nog maar 1 regel code bevat, maar dat is echt niet een standaard onderdeel van het leerproces.

[Hydra]

Caelorum schreef op woensdag 22 januari 2014 @ 13:55:
Dat hoeft helemaal niet.

Klopt. Vandaar de smiley.

raptorix schreef op woensdag 22 januari 2014 @ 13:49:
Klopt, je kunt natuurlijk ook een stored procedure of view gebruiken, maar dan nog is het niet ideaal, simpelweg omdat he databasemodel daar niet op gemaakt is, ik gebruik zelf veel Umbraco, in versie 5 hebben ze het geprobeerd met nHibernate, is een fiasco geworden en na 1.5 jaar development hebben ze er zelf maar de stekker uit getrokken

Ik vind Hibernate zelf ook een aardige draak. M.i. ben je in veel gevallen eigenlijk een hoop programmeerwerk aan het verplaatsen naar XML files. ORMs zijn m.i. ook een mixed blessing. Heb voor simpele projecten wel graag gebruik gemaakt van http://ormlite.com/, gewoon met annotations.

[ Voor 69% gewijzigd door Hydra op 22-01-2014 14:03 ]

[farlane]

Bigs schreef op woensdag 22 januari 2014 @ 13:21:
Alternatieven voor OOP (denk LISP) bestaan al sinds eind jaren 60 en toch heeft OOP al die tijd de overhand gehad als meest populaire manier van ontwikkelen.

Euhm, dat heb je niet goed volgens mij. OOP werd pas eind jaren 80 *echt* populair. En aangezien C nog altijd ergens bovenaan staat zou ik OOP zelfs niet 'meest populair' durven noemen.

[ Voor 12% gewijzigd door farlane op 22-01-2014 14:04 ]

[Bigs]

farlane schreef op woensdag 22 januari 2014 @ 14:00:
[...]

Euhm, dat heb je niet goed volgens mij. OOP werd pas eind jaren 80 *echt* populair. En aangezien C nog altijd ergens bovenaan staat zou ik OOP zelfs niet 'meest populair' durven noemen.

Je hebt gelijk, ik dacht even teveel vanuit m'n eigen wereld waar je nooit C tegen komt. Er zijn natuurlijk ook eindeloze gigabytes aan C, Perl PHP, Javascript gekeken waar van OOP of een andere gestructureerde aanpak geen sprake is dus als je het zo bekijkt is OOP inderdaad niet zo populair. Echter voor enterprise, web en GUI applicaties leent het zich m.i. wel uitstekend.

[Hydra]

farlane schreef op woensdag 22 januari 2014 @ 14:00:
Euhm, dat heb je niet goed volgens mij. OOP werd pas eind jaren 80 *echt* populair.

Jij hebt exacte cijfers van het gebruik van OO concepten van begin tot eind jaren 80?

En aangezien C nog altijd ergens bovenaan staat zou ik OOP zelfs niet 'meest populair' durven noemen.

Je noemt 1 hele niet-OO taal die veel gebruikt wordt in embedded / kernel systemen waar het belangrijkste gewoon geheugenruimte is. Dat is gewoon een aparte tak van sport.

Bigs schreef op woensdag 22 januari 2014 @ 14:14:
Je hebt gelijk, ik dacht even teveel vanuit m'n eigen wereld waar je nooit C tegen komt. Er zijn natuurlijk ook eindeloze gigabytes aan C, Perl PHP, Javascript gekeken waar van OOP of een andere gestructureerde aanpak geen sprake is dus als je het zo bekijkt is OOP inderdaad niet zo populair. Echter voor enterprise, web en GUI applicaties leent het zich m.i. wel uitstekend.

Dan nog: ik redeneer vooral vanuit mensen die als professioneel oogpunt aan complexe applicaties werken. Als ik zelf een simpel stuk tekst moet parsen maak ik daar ook gewoon een scriptje voor. Best tool for the job.

[ Voor 37% gewijzigd door Hydra op 22-01-2014 14:17 ]

[Dricus]

HawVer schreef op woensdag 22 januari 2014 @ 13:35:
Mee eens. Het hangt absoluut af van de mentaliteit en de kennis van de ontwikkelaar. Als je designpatterns, inheritance, etc goed doorvoert kan dat alsnog leiden tot een complexe niet te onderhouden structuur. Ik denk dat de ene taal er meer vatbaar voor is dan een andere taal.

Designpatterns zijn een soort van onofficiële code onder ontwikkelaars om er voor te zorgen dat het niet uit de hand loopt. Mijn punt is dat het een lapmiddel is voor problemen van het concept.

En mijn punt is dat je bij élk concept, of dat nu OOP of gestructureerd- of functioneel programmeren is of wat anders, tegen dit soort problemen aan zult lopen. Dit is geen probleem van het concept, maar een probleem van de mensen die het proberen toe te passen.

In de hoogtijdagen van de ICT zijn er hele volksstammen aan "ontwikkelaars" op de markt gekomen die leuk kunnen knutselen, maar totaal geen verstand hebben van hoe je een systeem op een degelijke manier ontwerpt. Daar hebben we tot op de dag van vandaag last van. De verleiding is dan groot om dit soort problemen te wijten aan een tekortkoming van een bepaald programmeerconcept, maar ik vraag me serieus af hoe de invloed van dat soort vermeende tekortkomingen zich verhoudt tot de tekortkomingen van ontwikkelaars.

Mijn gevoel is dat dit vooral een probleem is van gebrek aan vakmanschap bij ontwikkelaars. Dit is vooral gebaseerd op ervaringen die ik heb opgedaan in de teams waarin ik de afgelopen jaren gewerkt heb.

[HMS]

Het wel of niet populair zijn van OOP ligt helemaal aan waar je zit qua software ontwikkeling. Zoals al eerder is aangehaald is C een populaire taal voor realtime / embedded / kernel applicaties.

Ik ben zelf erg geinteresseert in distributed systems. Daar zie je vaak developers richting functionele programmeertalen gaan, met name Erlang.

Dit heeft met name te maken met hoe applicaties met elkaar communiceren, wat bij distributed systems altijd message passing is. Of dit nou met RPC, IPC, SOAP, een message bus, of wat dan ook is maakt niet uit.

Tegenwoordig is de kern van het OO programmeren, wat ook message passing is, verloren gegaan door allerlei technische hoogstandjes. Want argumenten op de stack duwen en dan naar een ander geheugenadres gaan en ze er weer afhalen is eigenlijk een snelle manier van een bericht sturen .
Als je bijvoorbeeld TDD doet, zul je merken dat als je je functie als blackbox behandelt, je tests logischer worden en je code stabieler. Je flow wordt dan: eventuele state die nodig is initialiseren, functie aanroepen, kijken of de state gewijzigd is zoals je verwacht. Oftewel: message in -> functie -> message out.

Als je het message passing concept in je OO code hanteert, zul je zien dat het al een stuk logischer wordt om op die manier te programmeren. Maar goed, had je dan niet beter in Erlang kunnen programmeren?

Daarnaast, wat ik vaak zie (en zelf ook fout gedaan heb), is veel inheritance gebruiken. Maar een grondregel van OO is, composition over inheritance. Al je objecten moeten meer dan dan de som van alle onderdelen. Door simpele regels kan je complex gedrag krijgen.

Al die lagen van abstractie puur om een veelal overdreven gevoel van 'puurheid' te krijgen, dat is gewoon killing voor de architectuur van je applicatie. Zal wel een junior -> medior inzicht zijn, zodra je die pijn een keer gevoeld hebt weet je dat je dat niet moet doen

[farlane]

Hydra schreef op woensdag 22 januari 2014 @ 14:15:
Jij hebt exacte cijfers van het gebruik van OO concepten van begin tot eind jaren 80?

Nee, ik baseer dat mede op een Wikipedia artikel en uiteraard mijn eigen ervaring.

Je noemt 1 hele niet-OO taal die veel gebruikt wordt in embedded / kernel systemen waar het belangrijkste gewoon geheugenruimte is. Dat is gewoon een aparte tak van sport.

Ik baseer die uitspraak met name op deze index. Overigens worden iha systeem libraries voor de verschillende OS'en ook in C geschreven, ik denk eerlijk gezegd dat dat het merendeel van de C code is die er geproduceerd is. ( Daar heb ik geen cijfers van ) en dan heb je het echt niet meer over "embedded/kernelsystemen".
Dit afdoen als een 'aparte tak van sport' is trouwens ook wel apart, op diezelfde manier is "server side software" ook een aparte tak van sport.

Maar een grondregel van OO is, composition over inheritance.

Die 'guideline' is er pas gekomen nadat men er achter kwam dat diepe inheritance trees eigenlijk niet zo heel handig waren. Het is geen grondregel van OO trouwens.

[ Voor 16% gewijzigd door farlane op 22-01-2014 15:25 ]

[Bigs]

HMS schreef op woensdag 22 januari 2014 @ 15:17:
[..]

Als je het message passing concept in je OO code hanteert, zul je zien dat het al een stuk logischer wordt om op die manier te programmeren. Maar goed, had je dan niet beter in Erlang kunnen programmeren?

[..]

Nee, want geen (complete, encoding aware) strings Dat gezegd hebbende vind ik het Actor model erg interessant en gebruik ik het in Ruby d.m.v. het Celluloid framework wat veel concepten van Erlang heeft overgenomen. In een wereld van gedistribueerde applicaties vind ik het Actor model zeer goed passen.

[HawVer]

Dricus schreef op woensdag 22 januari 2014 @ 14:37:
[...]

En mijn punt is dat je bij élk concept, of dat nu OOP of gestructureerd- of functioneel programmeren is of wat anders, tegen dit soort problemen aan zult lopen. Dit is geen probleem van het concept, maar een probleem van de mensen die het proberen toe te passen.

In de hoogtijdagen van de ICT zijn er hele volksstammen aan "ontwikkelaars" op de markt gekomen die leuk kunnen knutselen, maar totaal geen verstand hebben van hoe je een systeem op een degelijke manier ontwerpt. Daar hebben we tot op de dag van vandaag last van. De verleiding is dan groot om dit soort problemen te wijten aan een tekortkoming van een bepaald programmeerconcept, maar ik vraag me serieus af hoe de invloed van dat soort vermeende tekortkomingen zich verhoudt tot de tekortkomingen van ontwikkelaars.

Mijn gevoel is dat dit vooral een probleem is van gebrek aan vakmanschap bij ontwikkelaars. Dit is vooral gebaseerd op ervaringen die ik heb opgedaan in de teams waarin ik de afgelopen jaren gewerkt heb.

Begrijp me niet verkeerd, OOP is geen slecht concept. Ik zal dat zeker niet beweren. Je kunt er mooie dingen mee bereiken. Alleen het feit dat je er een zooi kan maken van de architectuur is een tekortkoming van het concept. Onbeperkte diepe inheritance vind ik daarin een mooi voorbeeld.

Dan zijn er twee oplossingen; één ervan is er voor zorgen dat de gebruikers beter geschoold worden en de andere oplossing is het oplossen van de problemen in het concept. Bijvoorbeeld maximaal drie niveaus diep inheritance toestaan.

Ik ben het ook met je eens dat alle huidige talen/concepten het toestaan om er een zooi van te maken. Ultiem zou zijn een taal/concept waarin je het 'zooi-risico' tot een minimum beperkt met wel zoveel mogelijk flexibiliteit. Alleen ik besef dat dat een paradox is omdat met flexibiliteit ook tegelijk complexiteit toeneemt.

[Hydra]

farlane schreef op woensdag 22 januari 2014 @ 15:18:
Nee, ik baseer dat mede op een Wikipedia artikel en uiteraard mijn eigen ervaring.

Ik denk dat het vooral draait om een beetje een misinterpretatie van zijn bericht. Ik ging er niet vanuit dat hij bedoelde dat OOP vanaf de jaren 60 altijd de dominante / meest gebruikte vorm van programmeren was.

Ik baseer die uitspraak met name op deze index. Overigens worden iha systeem libraries voor de verschillende OS'en ook in C geschreven, ik denk eerlijk gezegd dat dat het merendeel van de C code is die er geproduceerd is. ( Daar heb ik geen cijfers van ) en dan heb je het echt niet meer over "embedded/kernelsystemen".

Ik vind die index echt volkomen waardeloos. Er zijn andere bronnen die gebaseerd zijn op zaken als jobpostings, SO vragen en google hits die een veel beter beeld geven, afgezien van dat het onmogelijk is een echt beeld te krijgen van 'populariteit'. Ik bedoel; Javascript en Transact SQL zijn even 'populair'? Gebaseerd op google result? Google er maar eens op...

Helaas wordt die index te pas en te onpas gebruikt om aan te tonen dat C zo populair is. Sorry, maar als je naar stackoverflow, monsterboard en google kijkt is er steeds een redelijke 5:1 verhouding op hits tussen java en C, en dan heb je nog het issue dat je als je op C zoekt vaak ook hits op objective C, C# en C++ krijgt.

Ze gebruiken een groot aantal verschillende search engines. Ik heb hiervoor bij een search engine 'fabrikant' gewerkt en weet hoe moeilijk text search is.

Dit afdoen als een 'aparte tak van sport' is trouwens ook wel apart, op diezelfde manier is "server side software" ook een aparte tak van sport.

Er wordt gewoon reteweinig in C gedaan in verhouding tot enterprisy applicaties, ongeacht de mening van een brakke index.

HawVer schreef op woensdag 22 januari 2014 @ 16:25:
Begrijp me niet verkeerd, OOP is geen slecht concept. Ik zal dat zeker niet beweren. Je kunt er mooie dingen mee bereiken. Alleen het feit dat je er een zooi kan maken van de architectuur is een tekortkoming van het concept. Onbeperkte diepe inheritance vind ik daarin een mooi voorbeeld.

Da's net zo iets als zeggen dat een auto slecht is omdat slechte chauffeurs er mee crashen.

Dan zijn er twee oplossingen; één ervan is er voor zorgen dat de gebruikers beter geschoold worden en de andere oplossing is het oplossen van de problemen in het concept. Bijvoorbeeld maximaal drie niveaus diep inheritance toestaan.

En dan heb je er net een keer 4 nodig? Wat een onzin. Een objectstructuur hoort logisch te zijn. Een onlogische structuur geforceerd in 4 niveau's is slechter dan een logische met 5. Je gaat arbitraire limieten bedenken omdat sommige mensen slechte software schrijven? Echt?

Ik ben het ook met je eens dat alle huidige talen/concepten het toestaan om er een zooi van te maken. Ultiem zou zijn een taal/concept waarin je het 'zooi-risico' tot een minimum beperkt met wel zoveel mogelijk flexibiliteit. Alleen ik besef dat dat een paradox is omdat met flexibiliteit ook tegelijk complexiteit toeneemt.

Euh, of je neemt gewoon geen incompetente lui aan. Problem solved.

[ Voor 26% gewijzigd door Hydra op 22-01-2014 16:35 ]

[NMe]

Hydra schreef op woensdag 22 januari 2014 @ 16:28:
[...]

Euh, of je neemt gewoon geen incompetente lui aan. Problem solved.

Ook competente lui kunnen minder netjes schrijven. Proof of concepts die onder tijdsdruk ineens gepromoot worden tot release, of (wederom onder tijdsdruk of door spec-herzieningen vanuit de klant) wordt er niet vastgehouden aan het oorspronkelijke design en daardoor komt er rotzooi uit. Soms kom je daar gewoon niet onderuit als je mee wil komen in de markt.

[farlane]

Hydra schreef op woensdag 22 januari 2014 @ 16:28:
[...]
Er wordt gewoon reteweinig in C gedaan in verhouding tot enterprisy applicaties, ongeacht de mening van een brakke index.

Heb je daar een bron voor?

[Hydra]

farlane schreef op woensdag 22 januari 2014 @ 17:09:
Heb je daar een bron voor?

Je quote je eigen ervaring, ik ook. Daarnaast kun je zelf ook eens gaan zoeken op bijvoorbeeld monster.com (heb ik zelf ook gedaan) en dan kom je uit op een 5:1 hit rate verhouding tussen C en Java (daarin niet gecompenseerd voor het probleem dat je met C hits krijgt op C, C++, Objective C en C#). Da's NOGAL wat anders dan wat die brakke index meldt.

NMe schreef op woensdag 22 januari 2014 @ 17:01:
Soms kom je daar gewoon niet onderuit als je mee wil komen in de markt.

Dit valt nogal buiten deze discussie m.i.

[NMe]

Hydra schreef op woensdag 22 januari 2014 @ 17:19:
[...]

Dit valt nogal buiten deze discussie m.i.

Jij was degene die competentie gelijk stelde aan nette code terwijl dat net zo min enkel daarvan afhankelijk is als van het gekozen paradigma. Met genoeg tijd kan een competente developer nette code schrijver in elk paradigma. Wanneer tijd wél een factor is, is de invloed van de gekozen taal en/of paradigma groter.

[majoh]

Groeneg2 schreef op woensdag 22 januari 2014 @ 09:53:
Ik hoor de laatste tijd veel verhalen over het minder populair zijn/worden van OOP?
Wat is er waar van deze verhalen?

http://c2.com/cgi/wiki?ArgumentsAgainstOop
http://programmers.stacke...popular-in-the-age-of-oop
http://www.drdobbs.com/cpp/why-code-in-c-anymore/240149452

Ik vraag me af waar je deze vele verhalen hoort. Ik hoor ze totaal niet namelijk...

Daarbij geef je links die uit mei 2013, maart 2012 en februari 2013 komen. Niet heel erg recent toch?

En ik deel de mening niet, in mij wereldje, enterprise software, is het nog steeds OOP wat de dienst uitmaakt. Daarnaast kijkend naar mobile is het ook OOP (iOS, Android development).

OOP is here to stay, zou ik zeggen. Het is alleen niet de Holy Grail die in elke situatie het beste werkt. Maar dat is elke taal / concept / pattern enz. niet...

[farlane]

Hydra schreef op woensdag 22 januari 2014 @ 17:19:
Je quote je eigen ervaring, ik ook.

Ja en dat was niet voldoende dus ik vraag jou ook of je een bron hebt, naast je eigen subjectieve waarneming.

Daarnaast kun je zelf ook eens gaan zoeken op bijvoorbeeld monster.com (heb ik zelf ook gedaan) en dan kom je uit op een 5:1 hit rate verhouding tussen C en Java (daarin niet gecompenseerd voor het probleem dat je met C hits krijgt op C, C++, Objective C en C#).

Er van uitgaande dat een search op monster.com wel een goede indicatie zou zijn ( de vraag naar developers in een bepaalde taal is vergelijkbaar als de populariteit van een taal? ) zou dat dus betekenen dat de vraag naar Java developers 5x zo groot is als de vraag naar C, C++, Objective C en C# *bij elkaar*. Waaruit je dan volgens jou kunt concluderen dat de populariteit van Java ( en OOP ) dus ook 5 maal zo hoog zou zijn.

Hier ook een site waar C nog altijd behoorlijk hoog eindigt (Java ook trouwens) : http://langpop.com

Ik kan niet anders concluderen dat C na 40 jaar nog behoorlijk populair is. ( en daarmee dus ook non-OOP programmeren ).

[HawVer]

Hydra schreef op woensdag 22 januari 2014 @ 16:28:
[...]
Da's net zo iets als zeggen dat een auto slecht is omdat slechte chauffeurs er mee crashen.

Lees mijn bericht nog eens. Ik zeg niet dat OOP slecht is. In tegendeel. Ikzelf dat het een tekortkoming is. Net als dat het een tekortkoming is van een auto dat hij kan crashen.

[...]
En dan heb je er net een keer 4 nodig? Wat een onzin. Een objectstructuur hoort logisch te zijn. Een onlogische structuur geforceerd in 4 niveau's is slechter dan een logische met 5. Je gaat arbitraire limieten bedenken omdat sommige mensen slechte software schrijven? Echt?

Mijn punt is meer dat als een taal/concept onlogische structuren toestaat dit een tekortkoming is.

[...]
Euh, of je neemt gewoon geen incompetente lui aan. Problem solved.

Ik denk dat er vanuit de markt behoefte is aan talen/concepten die minder complex zijn. Dit is met name om een grotere groep (nieuwe) ontwikkelaars aan te kunnen spreken. Want er is nog altijd een tekort. En nee ze hoeven niet direct 3D games te kunnen schrijven.

[Dricus]

HawVer schreef op woensdag 22 januari 2014 @ 18:49:
Lees mijn bericht nog eens. Ik zeg niet dat OOP slecht is. In tegendeel. Ikzelf dat het een tekortkoming is. Net als dat het een tekortkoming is van een auto dat hij kan crashen.

Tsja, dit principe geldt zo'n beetje voor alles dat ooit door de mens uitgevonden en gemaakt is. Kort door de bocht: Geef een willekeurig iets aan een idioot en hij doet er idiote dingen mee. Of in het Engels: A fool with a tool is still a fool.

Kun je dit aan de tool wijten? Volgens mij niet. Het feit dat je met een tool (of taal of concept for that matter) iets compleet idioots neer kunt zetten zegt mijns inziens nog het meest over de gebruiker van die tool. De enige idiot-proof tool is een tool waar je niks mee kunt.

Mijn punt is meer dat als een taal/concept onlogische structuren toestaat dit een tekortkoming is.

Dus het feit dat je met een hamer iemand dood kunt knuppelen is een tekortkoming van de hamer? Verder, zie hierboven.

Ik denk dat er vanuit de markt behoefte is aan talen/concepten die minder complex zijn. Dit is met name om een grotere groep (nieuwe) ontwikkelaars aan te kunnen spreken. Want er is nog altijd een tekort. En nee ze hoeven niet direct 3D games te kunnen schrijven.

Een aantal hier genoemde talen zijn talen die vanaf op MBO niveau onderwezen worden. Het meerendeel van de vacatures voor ontwikkelaars is op HBO niveau. Van een HBO niveau werknemer mag je mijns inziens verwachten dat hij/zij in staat is om concepten zoals OOP, gestructureerd programmeren, functioneel programmeren, etc zich eigen te maken.

Beweringen zoals die hierboven hoor je managers (vooral hoog in de boom) ook vaak roepen: "We moeten meer van hetzelfde doen", "we moeten de standaards en richtlijnen aanscherpen zodat we niet overal zo over hoeven nadenken" en meer van dit soort zinsnedes. Ze gaan hiermee volledig voorbij aan het feit dat het maken van software een echt vak is. Een vak waar niet alleen een gedegen opleiding, maar ook jaren aan praktijkervaring voor nodig is om het goed te beheersen.

[Hydra]

NMe schreef op woensdag 22 januari 2014 @ 17:31:
Jij was degene die competentie gelijk stelde aan nette code

Je weet nogal wat informatie te halen uit een enkel zinnetje.

HawVer schreef op woensdag 22 januari 2014 @ 18:49:
Lees mijn bericht nog eens. Ik zeg niet dat OOP slecht is. In tegendeel. Ikzelf dat het een tekortkoming is. Net als dat het een tekortkoming is van een auto dat hij kan crashen.

En net zoals dat het onmogelijk is een nuttige auto die werk op het hedendaagse net uit te vinden die niet kan crashen, is het onmogelijk een bruikbaar logisch programmeerparadigma uit te vinden dat alle fouten van z'n gebruikers voorkomt. Net zoals dat een chirurg een opleiding nodig heeft om op een goeie manier te opereren is voor developers een gedegen opleiding nodig om op een goeie manier software te ontwikkelen.

Mijn punt is meer dat als een taal/concept onlogische structuren toestaat dit een tekortkoming is.

Zie boven. Een programmeerparadigma voorkomt geen fouten, het biedt een raamwerk om je te helpen. Het is een denkfout van jouw kant dat je denkt dat het uberhaupt een doel of mogelijkheid is dat een paradigma fouten 100% voorkomt.

Ik denk dat er vanuit de markt behoefte is aan talen/concepten die minder complex zijn. Dit is met name om een grotere groep (nieuwe) ontwikkelaars aan te kunnen spreken. Want er is nog altijd een tekort. En nee ze hoeven niet direct 3D games te kunnen schrijven.

Er is niks complex aan Java. Er is niks complex aan assembly. Wat complex is, is de software zelf. Vooral grote enterprise systemen zijn enorm complex. OO biedt houvast in dergelijke omgevingen, helpt structuur aan te brengen. Maar het ook daadwerklijk structuur aanbrengen is een taak van een software dev, daar zit de ervaring in. Of je dan OO of een ander paradigma aanhangt is om het even.

[ Voor 6% gewijzigd door Hydra op 22-01-2014 19:23 ]

[HawVer]

Je hebt middelen om een bepaald doel te bereiken. Zodra het middel negatieve gevolgen heeft is dat een tekortkoming van dat middel. En dan kan het zijn dat het middel verkeerd ingezet is. Het kan ook zijn dat het middel je beter had kunnen beschermen.

Wij ontwikkelen hier financiële software. Als je daar toestaat om een journaalpost te maken die niet in evenwicht is kun je dat de gebruiker verwijten. Hij had beter kunnen weten. De gebruiker zet juist een tool in om hem te helpen om het op de juiste manier te doen. Spreekt dan ook voor zich dat de tool dit niet toestaat.

Als een tool bedacht wordt zou het streven altijd moeten zijn om het systeem foolproof te maken. Heb je dat streven niet dan zul je er ook niet in de buurt komen. Op het gebied van OOP is die noodzaak er nooit geweest omdat we de tekortkomingen wijten aan het tekort aan kennis en ervaring of opleiding. En waarom zou je het streven voor een foolproof systeem hebben? Je maakt jezelf overbodig om dat de kennis en ervaring in het systeem zit.

Eerder werd gezegd dat meer denken in standaarden een management kreet is. Ik denk het niet. Bij het bedrijf waar ik werk hebben we het streven om de code 100% te laten genereren. Dit wordt afgeleid van een model die het domein beschrijft icm met code templates. Voordeel is dat wanneer een template aangepast wordt dit direct overal in je systeem door verwerkt wordt. De best practices qua applicatie architectuur liggen vast in de code templates. Dit is een systeem wat prima werkt voor enterprise applicaties.

Edit. Overigens is dit niet de heilige graal. Ik ben me er van bewust dat specialistische software specialisten vereist.

[ Voor 3% gewijzigd door HawVer op 22-01-2014 20:15 ]

[Dricus]

@HawVer: Ik denk niet dat een programmeerconcept één op één te vergelijken is met een stuk programmatuur dat met behulp van dat programmeerconcept gemaakt is. Programmeertalen zijn enorm generiek. Ze bieden je simpele onderdelen die je kunt gebruiken om iets complex mee te maken. Dat is het doel van een programmeertaal. Een programmeertaal zou je foolproof kunnen noemen omdat deze een bepaalde syntax afdwingt. Als een ontwikkelaar daar fouten in maakt compileert het niet en krijg je geen werkende software. Als je die verschillende simpele onderdelen op een verkeerde manier combineert, krijg je ook geen werkende software.

Door codegeneratoren toe te passen kun je het verkeerd combineren van die onderdelen deels voorkomen. Als je dat doet, dan ontstaat er al snel iets dat je een domain specific language (DSL) zou kunnen noemen. Je maakt feitelijk met een programmeertaal een andere taal die je binnen een bepaald probleemdomein helpt om minder fouten te maken bij het maken van software. Die DSL is zelf alleen weer net zo goed als die generieke talen onderhevig aan de problemen die onkunde met zich meebrengen.

En dat is nu eenmaal de aard van programmeerconcepten. Ze bieden je de nuts en bolts, maar kunnen niet voor 100% vookomen dat je die verkeerd gebruikt om een specifiek probleem op te lossen. Dat is niet het probleem van de nuts en bolts, maar van degene die ze op een verkeerde manier gebruikt.

Edit: Wat ik tegen heb op die "managementkreten" is dat die in mijn werkomgeving vaak bedoeld zijn om het ontwikkelen van software te reduceren tot een soort van lopendebandproces. Standaarden en richtlijnen zijn uiteraard goed om te hebben en na te leven. Het gaat mij met die opmerking dus om de intentie, niet om de standaards op zich.

[ Voor 10% gewijzigd door Dricus op 22-01-2014 20:50 ]

[Zoijar]

Wat is OOP? Een tool om de heilige graal van development te bereiken: separation of concerns. SoC bereik je meestal door data hiding, en veel "OO" talen bieden data hiding dmv encapsulation. Vandaar dat ik denk dat encapsulation de steunpilaar van OOP is. Elke taal die het dus mogelijk maakt efficient SoC te bereiken dmv encapsulation is in wezen OO -- gevolg is dat C dus ook een OO taal kan zijn. De linux kernel is bv imo net zo goed OO als een of ander C++ programma.

Verder wil je meestal een vorm van polymorphisme. Dat hoeft niet per se inheritance en virtual functions te zijn, dat kunnen ook templates zijn en/of duck typing.

Wat wel duidelijk zo is, is dat slechte OO code slecht is... mensen, zeker beginners, willen het vaak "te OOP" maken. Alles behalve interface inheritance is bv bijna altijd slecht, toch leer je dat als eerste. Die websites gaan ook allemaal op dit soort voorbeelden in.

[Dricus]

Teruggrijpend op de posts over ORM's eerder in dit topic is er denk ik wel een probleem met puur OOP denken. Objecten zijn lastig te zien als een datastructuur. Wat zie je als je vanaf de buitenkant naar een object kijkt: Methods. Eventuele state is vanaf de buitenkant niet direct zichtbaar. Het is indirect zichtbaar doordat het gedrag van een object wijzigt als zijn state wijzigt. Die wijziging van state is het gevolg van het aanroepen van een method op dat object door een ander object. Een object is vanaf de buitenkant gezien dus een abstractie van gedrag, niet van data.

Zie deze blog van Robert Martin voor een iets uitgebreidere (en humoristischere ) uitleg op dit punt.

In veel OO programma's leidt dit tot een rare, verwarrende mix van datastructuren, validatie en persistence in de vorm van domeinclasses die zowel business logica bevatten als informatie over hoe de data gepersisteerd moet worden in een database (dmv annotations en/of mappings in een XML file).

Dit is denk ik deels te wijten aan de aard van het OO paradigma. OO biedt je niet echt een manier om datastructuren te modelleren. Je kunt natuurlijk classes maken die niets meer zijn dan een setje private fields met bijbehorende getters en setters, maar dan houd je jezelf denk ik een beetje voor de gek. Je doet dan net alsof een datastructuur uit te drukken is in termen van gedrag terwijl dit in werkelijkheid niet echt kan omdat data en gedrag conceptueel orthogonale concepten zijn.

[NMe]

Dricus schreef op woensdag 22 januari 2014 @ 22:00:
Teruggrijpend op de posts over ORM's eerder in dit topic is er denk ik wel een probleem met puur OOP denken. Objecten zijn lastig te zien als een datastructuur. Wat zie je als je vanaf de buitenkant naar een object kijkt: Methods. Eventuele state is vanaf de buitenkant niet direct zichtbaar. Het is indirect zichtbaar doordat het gedrag van een object wijzigt als zijn state wijzigt. Die wijziging van state is het gevolg van het aanroepen van een method op dat object door een ander object. Een object is vanaf de buitenkant gezien dus een abstractie van gedrag, niet van data.

Maar dat is toch juist een goed iets? Iemand die de class niet geschreven heeft en dus niet weet hoe die intern werkt hoeft dat ook niet te weten en hoeft ook niks te weten over de data-opslag of -structuur. Gebruikers van een klasse zijn juist domweg meer geïnteresseerd in gedrag in plaats van de datastructuur die erbij hoort.

[Dricus]

NMe schreef op woensdag 22 januari 2014 @ 22:26:
Maar dat is toch juist een goed iets? Iemand die de class niet geschreven heeft en dus niet weet hoe die intern werkt hoeft dat ook niet te weten en hoeft ook niks te weten over de data-opslag of -structuur. Gebruikers van een klasse zijn juist domweg meer geïnteresseerd in gedrag in plaats van de datastructuur die erbij hoort.

Helemaal mee eens. Het probleem dat ik probeer te beschrijven is dat er binnen OOP niet echt een ondubbelzinnig gedefinieerde manier is om datastructuren te modelleren. In het geval van te-persisteren data voelt het raar aan dat je binnen OOP die data moet modelleren in termen van gedrag.

[Zoijar]

Dricus schreef op woensdag 22 januari 2014 @ 22:35:
Helemaal mee eens. Het probleem dat ik probeer te beschrijven is dat er binnen OOP niet echt een ondubbelzinnig gedefinieerde manier is om datastructuren te modelleren. In het geval van te-persisteren data voelt het raar aan dat je binnen OOP die data moet modelleren in termen van gedrag.

Ik snap dat niet helemaal: je kan elke data structuur toch juist perfect modelleren? Dat iets data opneemt en daar gedrag aan koppelt is een extra abstractie. Als ik puur een alleen de data structuur wil benader ik bv de database wel direct. Wat je in een programma wilt is juist gedrag toevoegen aan data. Ook wil je die data dan encapsuleren, zoals hierboven ook gezegd. Wat is er mis met een object dat aan de ene kant een interface heeft om zichzelf te serialisen, en aan de andere kant functionaliteit op de data biedt? Het lijkt dubbelop, maar dat is het niet: het is een volgende abstractie. Wederom separation of concerns, abstractere concepten modelleren en de details hiden.

[Dricus]

Zoijar schreef op woensdag 22 januari 2014 @ 23:37:
Ik snap dat niet helemaal: je kan elke data structuur toch juist perfect modelleren?

Tuurlijk, dat kan in elke OO taal op zich prima, daar zijn allerhande praktische oplossingen voor. Echter, als je er wat meer beschouwend naar kijkt, dan zou je kunnen concluderen dat een datastructuur onmogelijk een object kan zijn.

quote: http://blog.8thlight.com/...10/01/Dance-You-Imps.html

What is a data structure? It's a bunch of public data with no methods. Compare that to an object which is a bunch of public methods with no visible data. These two things are the exact opposites of each other!

Dat iets data opneemt en daar gedrag aan koppelt is een extra abstractie. Als ik puur een alleen de data structuur wil benader ik bv de database wel direct. Wat je in een programma wilt is juist gedrag toevoegen aan data. Ook wil je die data dan encapsuleren, zoals hierboven ook gezegd.

Ik denk dat er een verschil is tussen de concepten data en state. Data is wat we uiteindelijk willen persisteren en waar we in veel gevallen zonder al te veel omwegen bij willen kunnen vanuit allerlei plekken in onze programmatuur. Encapsulatie van data wordt over het algemeen niet zo belangrijk gevonden. We doen dan vaak net alsof we encapsulatie doen door domeinclasses te maken die private fields hebben met getters en setters om die fields te manipuleren. Dit is natuurlijk geen echte encapsulatie, de complete interne state van zo'n object is via de getters en setters zichtbaar en manipuleerbaar.

State is de verzameling aan object-eigen gegevens die bedoeld is om een object de mogelijkheid te geven zijn gedrag over tijd aan te passen. State willen we encapsuleren en mag van buitenaf niet anders zichtbaar zijn dan indirect, door verandering in observeerbaar gedrag van dat object.

Wat is er mis met een object dat aan de ene kant een interface heeft om zichzelf te serialisen, en aan de andere kant functionaliteit op de data biedt? Het lijkt dubbelop, maar dat is het niet: het is een volgende abstractie. Wederom separation of concerns, abstractere concepten modelleren en de details hiden.

Daar is mis mee dat zo'n object het Single Responsibility Principle schendt. Het is het tegenovergestelde van separation of concerns. Je maakt één object verantwoordelijk voor meerdere concerns: Het vasthouden en manipuleren van data én het persisteren van die data.

[Hydra]

Ik snap niet hoe je kunt claimen dat je data niet als objecten kunt modeleren, sorry.

[Dricus]

Kijk eens naar onderstaande class. Is een instance van onderstaande class een object?

Java:

class Persoon {
  private Long id;
  private String voornaam;
  private String achternaam;

  public Long getId() {
    return id;
  }

  public void setId(Long id) {
    this.id = id;
  }

  public String getVoornaam() {
    return voornaam;
  }

  public void setVoornaam(String voornaam) {
    this.voornaam = voornaam;
  }

  [...]
}

[Hydra]

Ja?

[Dricus]

Waarom?

[Hydra]

Dricus schreef op donderdag 23 januari 2014 @ 09:39:
Waarom?

Je vraagt waarom een instance van een class een object is?

[Janoz]

Eigenlijk is het meer een 'struct' dan een 'object'.

[Dricus]

Is een instance van een class per definitie een object in de pure OO zin van het woord?

[CodeCaster]

Ja, dat is in dit geval een Data Transfer Object. Zonder zo'n klasse zouden al je methoden die iets met een Persoon doen een verschrikkelijk onleesbare en ononderhoudbare signature krijgen.

Waarom zou het ontbreken van methods op de klasse een instantie ineens geen object maken?

[ Voor 83% gewijzigd door CodeCaster op 23-01-2014 09:47 ]

[Hydra]

Janoz schreef op donderdag 23 januari 2014 @ 09:43:
Eigenlijk is het meer een 'struct' dan een 'object'.

Dat is een taal specifiek iets, het gaat hier vooral om OO termen. In Java worden dat over 't algemeen beans genoemd. Data met getters en setters.

[Waster]

OOP heeft één heel groot nadeel. Data hiding heeft voordeel dat je complexiteit verbergt, maar je koppelt wel je methodes aan je data! Coupling is altijd een zonde, dus dan is dit eigenlijk ook een no no. Als je je leven lang OO programmeert, dan heb je dat niet eens door. Wat als je 100 methodes hebt die op dezelfde data moeten werken en niet allemaal bij elkaar horen? Dan moet je snel teruggrijpen op static methodes en losse structs aan je methodes meegeven.

Dus data-hiding komt ten koste van coupling van data en methodes. Als dat geen probleem is, gebruik een object, maar ik ben genoeg situaties tegengekomen waar dat wel probleem was.

[Janoz]

@Hydra: Klopt, vandaar ook de quotes. Maar ik begrijp het punt wel dat Dricus probeert te maken. Als je echt naar de puurste OO vorm zou kijken zou zo'n object bv ook zelf zijn persisteren moeten implementeren. In de praktijk wordt dat (gelukkig) gewoon door bv een entitymanager of een DAO gedaan.


@Waster: Ik ben erg benieuwd naar zo'n situatie.

[ Voor 9% gewijzigd door Janoz op 23-01-2014 09:54 ]

[Waster]

Janoz schreef op donderdag 23 januari 2014 @ 09:52:
@Hydra: Klopt, vandaar ook de quotes. Maar ik begrijp het punt wel dat Dricus probeert te maken. Als je echt naar de puurste OO vorm zou kijken zou zo'n object bv ook zelf zijn persisteren moeten implementeren. In de praktijk wordt dat (gelukkig) gewoon door bv een entitymanager of een DAO gedaan.

Dan krijg je al snel god-objecten. Als een object zichzelf moet persisteren, tekenenen, reageren op updates etc. dan overtreed je al snel het single responsibility principe.

@Waster: Ik ben erg benieuwd naar zo'n situatie.

Het simpelste voorbeeld is een Convert. Is het Convert.ToInt(string) of myString.ToInt(). Verschillende talen en libraries gaan er anders mee om. Dit lijkt simpel, maar als je alle mogelijke transformatie methodes aan het object koppelt dan heeft ieder object oneindig veel methodes. Maar de eerste is gewoon een C-style methode.

[ Voor 28% gewijzigd door Waster op 23-01-2014 10:11 ]

[Hydra]

Janoz schreef op donderdag 23 januari 2014 @ 09:52:
@Hydra: Klopt, vandaar ook de quotes. Maar ik begrijp het punt wel dat Dricus probeert te maken. Als je echt naar de puurste OO vorm zou kijken zou zo'n object bv ook zelf zijn persisteren moeten implementeren. In de praktijk wordt dat (gelukkig) gewoon door bv een entitymanager of een DAO gedaan.

Ik vind absoluut niet dat volgens de "puurste vorm van OO" een object zijn eigen persistentie zou moeten regelen. Ik ken ook geen enkele definitie waarin dat aangedragen wordt.

Waster schreef op donderdag 23 januari 2014 @ 09:52:
OOP heeft één heel groot nadeel. Data hiding heeft voordeel dat je complexiteit verbergt, maar je koppelt wel je methodes aan je data! Coupling is altijd een zonde, dus dan is dit eigenlijk ook een no no. Als je je leven lang OO programmeert, dan heb je dat niet eens door. Wat als je 100 methodes hebt die op dezelfde data moeten werken en niet allemaal bij elkaar horen? Dan moet je snel teruggrijpen op static methodes en losse structs aan je methodes meegeven.

Het verbergen van implementatiedetails zorgt juist voor loose coupling, alles aan iedereen beschikbaar maken zorgt voor strong coupling. Je hebt je definities nogal backwards, sorry.

Dus data-hiding komt ten koste van coupling van data en methodes. Als dat geen probleem is, gebruik een object, maar ik ben genoeg situaties tegengekomen waar dat wel probleem was.

Klinkt meer als OO verkeerd toepassen, sorry. Een simpele bean heeft alleen maar getters en setters, ik zie niet waar daar ononderhoudbare verbindingen zouden ontstaan. De buitenwereld is sowieso alleen maar geinteresseerd in het gebruik van een object. De onderliggende implementatie zou je niet moeten interesseren. Oftewel; separation of concerns / encapsulation.

[ Voor 5% gewijzigd door Hydra op 23-01-2014 10:05 ]

[Janoz]

Waster schreef op donderdag 23 januari 2014 @ 10:00:
[...]

Dan krijg je al snel god-objecten. Als een object zichzelf moet persisteren, tekenenen, reageren op updates etc. dan overtreed je al snel het single responsibility principe.

Uiteraard, en niet alleen dat, je krijgt ook nog een heleboel dubbele code aangezien persisteren echt een cross cutting concern is. Het single responsibility principe is zeker iets wat bij OO toegepast zou moeten worden, maar dat is niet iets wat perse bij (pure, academische) OO hoort. Een god object is duidelijk een anti-pattern, maar is niet strijdig met (pure, academische) OOP-regels.

Ik zie echter liever dat je mijn tweede opmerking beantwoord.

[ Voor 4% gewijzigd door Janoz op 23-01-2014 10:16 ]

[Waster]

Hydra schreef op donderdag 23 januari 2014 @ 10:02:
Het verbergen van implementatiedetails zorgt juist voor loose coupling, alles aan iedereen beschikbaar maken zorgt voor strong coupling. Je hebt je definities nogal backwards, sorry.

Kort door de bocht. Tuurlijk zul je ergens anders in je design loose coupling krijgen, aangezien andere objecten niet bij de data kan. Maar ik bracht specifiek in dat de methode van je object die je schrijft gekoppeld is aan je data in je object. Dus geen object coupling, maar methode coupling! Dat valt niet te ontkennen. Dus wil jij dezelfde methode gebruiken voor andere data, dan moet je je methode kopieren of je krijgt die walgelijke inheritance trees. Hier heeft het procedurele/functionele paradigma geen last van.

[Janoz]

Hydra schreef op donderdag 23 januari 2014 @ 10:02:
Ik vind absoluut niet dat volgens de "puurste vorm van OO" een object zijn eigen persistentie zou moeten regelen. Ik ken ook geen enkele definitie waarin dat aangedragen wordt.

Ik vind ook niet dat een object zijn eigen pesistentie moet regelen. Ik ben alleen bang dat ik wat moeilijk onder woorden weet te brengen wat ik met 'pure OO' bedoel. Ik bedoel eigenlijk het originele OO idee, zonder alle latere inzichten die geleid hebben tot de designpatterns die we nu kennen.

[Hydra]

Waster schreef op donderdag 23 januari 2014 @ 10:16:
Kort door de bocht. Tuurlijk zul je ergens anders in je design loose coupling krijgen, aangezien andere objecten niet bij de data kan. Maar ik bracht specifiek in dat de methode van je object die je schrijft gekoppeld is aan je data in je object. Dus geen object coupling, maar methode coupling! Dat valt niet te ontkennen. Dus wil jij dezelfde methode gebruiken voor andere data, dan moet je je methode kopieren of je krijgt die walgelijke inheritance trees. Hier heeft het procedurele/functionele paradigma geen last van.

Als jij een methode hebt die op meerdere object-types moet werken dan is gewoon je implementatie fout als je die in een dergelijke bean stop. Sowieso zijn dergelijke beans over het algemeen gewoon data-containers. Wat jij beschrijft is een symptoom van slecht ontwerp, geen symptoom van OO. Als je in elke bean class met String members "toBase64()" methodes gaat bouwen bijvoorbeeld doe je het gewoon heel erg fout.

Janoz schreef op donderdag 23 januari 2014 @ 10:21:
Ik vind ook niet dat een object zijn eigen pesistentie moet regelen. Ik ben alleen bang dat ik wat moeilijk onder woorden weet te brengen wat ik met 'pure OO' bedoel. Het is eigenlijk het originele OO idee, zonder alle latere inzichten die geleid hebben tot de designpatterns die we nu kennen.

Dan nog ken ik geen "originele OO" ideeën waarin gespecificeerd wordt dat een object zelf voor z'n persistentie verantwoordelijk is. Sterker nog; in mijn lesmateriaal 'destijds' was storage ook een voorbeeld waarin je overerving gebruikt voor een persistentiemechanisme. Concreet heb je dus een abstract class (huhu) 'ObjectStore' met concrete implementaties ('RelationalObjectStore', 'FileObjectStore') etc. De te storen objecten hebben geen weet van de implementatie, alleen de concrete implementaties van de stores hebben die kennis.

Ik ken geen enkel voorbeeld waarbij een bean-achtig type die verantwoordelijkheid heeft.

[ Voor 33% gewijzigd door Hydra op 23-01-2014 10:33 ]

[Dricus]

Je ziet dat je op minstens 2 verschillende manieren tegen het begrip object kunt aankijken: Abstractie van gedrag en instance van een class. De eerste komt denk ik dicht in de buurt van het pure OO denken. De tweede manier is wat pragmatischer en in de praktijk bruikbaarder.

Beschrijft mijn Persoon class nu eigenlijk gedrag? Op het eerste gezicht wel. Hij heeft toch methods? Echter, als je er wat langer over doorfilosofeert kun je tot de conclusie komen dat Persoon helemaal geen gedrag beschrijft. Als je die getters en setters weglaat en de fields public maakt, dan verandert de interface van de class wel, maar het gedrag dat van buitenaf zichtbaar is totaal niet. Sterker nog: Er is van buitenaf geen enkel gedrag te zien!

Die getters en setters geven je in feite de illusie dat je met een abstractie van gedrag te maken hebt, terwijl dit helemaal niet zo is. Persoon is niet meer dan een beschrijving van data. Het is een datatype. En dát is wat volgens mij ontbreekt in het OO paradigma. Het is enorm goed in het beschrijven en structureren van gedrag, maar het biedt je geen duidelijke manier om data te beschrijven.

Hydra schreef op donderdag 23 januari 2014 @ 10:30:
Ik ken geen enkel voorbeeld waarbij een bean-achtig type die verantwoordelijkheid heeft.

Volgens mij zou je het Active Record pattern dat o.a. in Ruby on Rails gebruikt wordt als een voorbeeld kunnen beschouwen.

[ Voor 12% gewijzigd door Dricus op 23-01-2014 10:39 ]

[Hydra]

Dricus schreef op donderdag 23 januari 2014 @ 10:37:
Je ziet dat je op minstens 2 verschillende manieren tegen het begrip object kunt aankijken: Abstractie van gedrag en instance van een class. De eerste komt denk ik dicht in de buurt van het pure OO denken. De tweede manier is wat pragmatischer en in de praktijk bruikbaarder.

Euh nee? Een object is een vertaling van een functioneel concept naar een concrete implementatie. In bijvoorbeeld Java is een class een blauwdruk van een object. In javascript werkt het anders en gebruik je prototyping, daar bestaan classes niet (echt).

Beschrijft mijn Persoon class nu eigenlijk gedrag? Op het eerste gezicht wel. Hij heeft toch methods? Echter, als je er wat langer over doorfilosofeert kun je tot de conclusie komen dat Persoon helemaal geen gedrag beschrijft. Als je die getters en setters weglaat en de fields public maakt, dan verandert de interface van de class wel, maar het gedrag dat van buitenaf zichtbaar is totaal niet. Sterker nog: Er is van buitenaf geen enkel gedrag te zien!

Je sprint echt van de hak op de tak. Er hoort van buitenaf niks anders te zien dan de interface van een object. Of je members nu een public String hatseFlats is of public String getHatseFlats() maakt conceptueel helemaal niks uit. Alleen als het om de implementatie gaat, zorg je ervoor dat deze details met de methode verborgen worden, want achter die "getHatseFlats()" zou wel eens een complexe berekening kunnen zitten.

In C# is dit nog veel duidelijker: C# heeft properties die sprekend lijken op "public" members maar eigenlijk gewoon methods zijn.

Die getters en setters geven je in feite de illusie dat je met een abstractie van gedrag te maken hebt, terwijl dit helemaal niet zo is.

Complete onzin. Zie boven: de buitenwereld interesseert het alleen maar wat er in en uit die methodes komt, hoe een object aan die gegevens komt is niet interessant voor de buitenwereld.

Persoon is niet meer dan een beschrijving van data. Het is een datatype. En dát is wat volgens mij ontbreekt in het OO paradigma. Het is enorm goed in het beschrijven en structureren van gedrag, maar het biedt je geen duidelijke manier om data te beschrijven.

Sorry maar wat een kolder. Je hebt wat mij betreft een redelijk bizar denkproces gekoppeld aan een flinke dosis "klok-klepel".

Objecten ZIJN data. Alleen waar die data precies vandaan komt, wordt voor jou verborgen. En dat is met opzet; want het maakt je werk als developer makkelijker. Het enige moment wanneer het je interesseert hoe dat object aan die data komt, en wat er mee gedaan wordt, is als je aan de implementatie van dat object zelf moet werken.

Objecten hebben een strik gedefinieerde interface naar hun data, maar dat betekent niet dat ze dan opeens geen data zouden zijn. Ik snap echt niet hoe je uberhaupt op dat idee kunt komen.

[Waster]

Hydra schreef op donderdag 23 januari 2014 @ 10:30:
Als jij een methode hebt die op meerdere object-types moet werken dan is gewoon je implementatie fout als je die in een dergelijke bean stop. Sowieso zijn dergelijke beans over het algemeen gewoon data-containers. Wat jij beschrijft is een symptoom van slecht ontwerp, geen symptoom van OO. Als je in elke bean class met String members "toBase64()" methodes gaat bouwen bijvoorbeeld doe je het gewoon heel erg fout.

Ik geef een voorbeeld en het nadeel van OOP als je een object methodes en verantwoordelijkheden geeft die te algemeen zijn voor een specifiek object. En vervolgens zeg je ook gewoon dat het een implementatie fout is, dus dat het een zwakte is van OOP? Volgens mij zijn we het dan eens

Tenzij je data-containers ook OOP noemt, want dat noem ik geen OOP. Er is geen abstractie, geen enkele methode met logica. In de strikte definitie een object, maar niet hoe OOP bedoeld is.

[Hydra]

Waster schreef op donderdag 23 januari 2014 @ 10:49:
Ik geef een voorbeeld en het nadeel van OOP als je een object methodes en verantwoordelijkheden geeft die te algemeen zijn voor een specifiek object. En vervolgens zeg je ook gewoon dat het een implementatie fout is, dus dat het een zwakte is van OOP? Volgens mij zijn we het dan eens

Een implementatiefout is de fout van een taal? Dat is nieuw. In mijn wereld maken developers die fouten. En kom niet met dat gelul aan dat een taal moet voorkomen dat je fouten maakt, dat is gewoon onrealistisch.

Tenzij je data-containers ook OOP noemt, want dat noem ik geen OOP. Er is geen abstractie, geen enkele methode met logica. In de strikte definitie een object, maar niet hoe OOP bedoeld is.

Wat een onzin? Waarom zou een bean met alleen getters en setters geen OO zijn?

Fuck hee, ik zou zorgen dat je manager deze onzin niet leest

[ Voor 3% gewijzigd door Hydra op 23-01-2014 10:56 ]

[CodeCaster]

Dricus schreef op donderdag 23 januari 2014 @ 10:37:
[...]

Waster schreef op donderdag 23 januari 2014 @ 10:49:
[...]

Jullie denken te veel en te letterlijk in 'functionaliteit'. Denk eens aan 'verantwoordelijkheid'. De verantwoordelijkheid van de Persoon-klasse is het in runtime vasthouden van wat aan één persoon gerelateerde gegevens per instantie.

Nogmaals, dat deze klasse (afgezien van getters en setters) geen methodes heeft, neemt het OO-aspect niet weg.

[ Voor 14% gewijzigd door CodeCaster op 23-01-2014 11:05 ]

[Waster]

Hydra schreef op donderdag 23 januari 2014 @ 10:55:
[...]


Een implementatiefout is de fout van een taal? Dat is nieuw. In mijn wereld maken developers die fouten. En kom niet met dat gelul aan dat een taal moet voorkomen dat je fouten maakt, dat is gewoon onrealistisch.

Doe is normaal man. Ik heb nergens gezegd dat dit een fout in de taal is en dat dat moest worden voorkomen. Ik noemde alleen een nadeel van OOP. Wat een discussie zeg

[Dricus]

Hydra schreef op donderdag 23 januari 2014 @ 10:47:
Euh nee? Een object is een vertaling van een functioneel concept naar een concrete implementatie.
[...]

Ik zie niet hoe dat in tegenspraak is met wat ik schrijf. We kijken volgens mij allebei naar hetzelfde ding en belichten vervolgens verschillende aspecten daarvan die niet met elkaar in tegenspraak zijn, maar elkaar aanvullen en het beeld completer maken.

Je sprint echt van de hak op de tak. Er hoort van buitenaf niks anders te zien dan de interface van een object. Of je members nu een public String hatseFlats is of public String getHatseFlats() maakt conceptueel helemaal niks uit. Alleen als het om de implementatie gaat, zorg je ervoor dat deze details met de methode verborgen worden, want achter die "getHatseFlats()" zou wel eens een complexe berekening kunnen zitten.

En in dat geval kun je je afvragen of die complexe berekening wel in die class thuishoort. De meningen zijn daar sterk over verdeeld.

Complete onzin. Zie boven: de buitenwereld interesseert het alleen maar wat er in en uit die methodes komt, hoe een object aan die gegevens komt is niet interessant voor de buitenwereld.

In elke applicatie waarin je iets van CRUD doet komt er een moment dat een object geïnteresseerd is in data. Dat zo'n object methodes van een ander object nodig heeft om aan die data te komen doet daar niks aan af.

Sorry maar wat een kolder. Je hebt wat mij betreft een redelijk bizar denkproces gekoppeld aan een flinke dosis "klok-klepel".

Zullen we het gewoon bij de argumenten houden? Met dit soort opmerkingen verpest je de sfeer van de discussie alleen maar.

Objecten ZIJN data. Alleen waar die data precies vandaan komt, wordt voor jou verborgen. En dat is met opzet; want het maakt je werk als developer makkelijker. Het enige moment wanneer het je interesseert hoe dat object aan die data komt, en wat er mee gedaan wordt, is als je aan de implementatie van dat object zelf moet werken.

IS een DAO data? IS een service data? In deze twee gevallen zou ik eerder zeggen: Objecten ZIJN gedrag. Tuurlijk hebben ze vaak wel state, maar het is hun gedrag dat voor de rest van de applicatie de échte toegevoegde waarde heeft. De stellingen "objecten ZIJN data" en "objecten ZIJN gedrag" zijn beide niet van toepassing op 100% van de objecten die je in het wild tegenkomt.

[Hydra]

Dricus schreef op donderdag 23 januari 2014 @ 11:18:
Zullen we het gewoon bij de argumenten houden? Met dit soort opmerkingen verpest je de sfeer van de discussie alleen maar.

De sfeer van de discussie wordt verpest door mensen die gelijk willen krijgen, ongeacht hun kennisniveau, die misconcepties over wat OO is afdoen als feit. Ik ben dus ook wel een beetje klaar met jou en Waster; dit is vechten tegen de bierkaai. Je verdraait je verhaal iedere keer zoals je het zelf uitkomt, goed voorbeeld:

IS een DAO data? IS een service data? In deze twee gevallen zou ik eerder zeggen: Objecten ZIJN gedrag. Tuurlijk hebben ze vaak wel state, maar het is hun gedrag dat voor de rest van de applicatie de échte toegevoegde waarde heeft. De stellingen "objecten ZIJN data" en "objecten ZIJN gedrag" zijn beide niet van toepassing op 100% van de objecten die je in het wild tegenkomt.

Als je wat ik schrijf volledig uit zijn context gaat halen (we hadden het net nog over datacontainers als Persons, in die context schreef ik dat) ben je gewoon geen discussie meer aan het voeren maar aan het trollen.

[NMe]

Hydra schreef op donderdag 23 januari 2014 @ 11:31:
[...]

De sfeer van de discussie wordt verpest door mensen die gelijk willen krijgen, ongeacht hun kennisniveau, die misconcepties over wat OO is afdoen als feit.

Hetzelfde wat jij óók doet dus; sterker nog, jij bent degene met krachttermen die helemaal niet op hun plaats zijn. Zullen we daar nu dan allemaal maar mee ophouden?

[ Voor 10% gewijzigd door NMe op 23-01-2014 11:50 ]

[Dricus]

Hydra schreef op donderdag 23 januari 2014 @ 11:31:
De sfeer van de discussie wordt verpest door mensen die gelijk willen krijgen,

Ik ben er niet op uit om gelijk te krijgen hoor. Ik vind het alleen af en toe wel leuk om de zaken eens op een andere manier te bekijken, that's all...

ongeacht hun kennisniveau, die misconcepties over wat OO is afdoen als feit.

En ik doe nog zo mijn best om niet al te stellig te zijn door zinsnedes als "denk ik" en "zou [...] kunnen" te gebruiken. Dus bij deze mijn disclaimer: Als het lijkt alsof ik een mening of mogelijke visie op de zaken als feit probeer te brengen, dan was dat niet mijn bedoeling. Als je dit bij mij constateert, voel je dan vrij om me daarop aan te spreken.

Ik ben dus ook wel een beetje klaar met jou en Waster; dit is vechten tegen de bierkaai. Je verdraait je verhaal iedere keer zoals je het zelf uitkomt, goed voorbeeld:
[...]
Als je wat ik schrijf volledig uit zijn context gaat halen (we hadden het net nog over datacontainers als Persons, in die context schreef ik dat) ben je gewoon geen discussie meer aan het voeren maar aan het trollen.

Dat vind ik lastig aan geschreven tekst. Misschien lees ik niet goed, maar mijn indruk was dat je met je opmerking "objecten ZIJN data" over meer had dan alleen datacontainers.

Je lijkt aan te nemen dat ik bewust de boel loop te verdraaien om mijn gelijk te halen. Wat hier aan de hand is, is dat het bij geschreven tekst niet altijd even duidelijk is wat iemand precies bedoelt. Ik zal proberen in het vervolg om verduidelijking te vragen ipv aannames te doen.

CodeCaster schreef op donderdag 23 januari 2014 @ 11:04:
Jullie denken te veel en te letterlijk in 'functionaliteit'. Denk eens aan 'verantwoordelijkheid'. De verantwoordelijkheid van de Persoon-klasse is het in runtime vasthouden van wat aan één persoon gerelateerde gegevens per instantie.

Dit vind ik wel een goed punt. Ook als je geen gedrag op een class definieert d.m.v. methods, kun je inderdaad nog prima verdedigen dat die class wel degelijk een verantwoordelijkheid heeft.

Nogmaals, dat deze klasse (afgezien van getters en setters) geen methodes heeft, neemt het OO-aspect niet weg.

Het neemt het OO aspect niet helemaal weg nee, maar ik vraag me soms wel eens af of het overgieten van datacontainers met een OO sausje een zinvolle exercitie is. Dit komt met name omdat het van daaruit met de huidige ORM's enorm makkelijk is om aan zo'n class meteen ook maar de mappings naar je database toe te voegen (met annotations als @Entity, @Table, @Column, @OneToMany, etc). Dat ziet er allemaal prachtig declaratief uit en is ook enorm handig, maar ben je dan niet bezig om je class met meer dan één verantwoordelijkheid op te zadelen?

Het is dan niet meer alleen een container van data, maar definieert (welliswaar declaratief) ook een deel van het gedrag van je DAO's. Of om in verantwoordelijkheden te spreken: Het object is verantwoordelijk voor het vasthouden van data én voor de mapping van interne state naar een tabel en kolommen in de database. Als je daar validatie aan toe gaat voegen (@Constraint) dan komt daar een derde verantwoordelijkheid bij.

Dit is natuurlijk niet 100% accuraat. De mappings zijn geen onderdeel van het object, maar van de metadata die aan een class hangt. Het probleem blijft alleen dat als je naar je source kijkt, je ziet dat bepaalde verantwoordelijkheden (persistency, validatie) verdeeld zijn over meerdere classes.

Precies hierom vind ik het wel interessant om te kijken of er een duidelijke scheidslijn te trekken is tussen objecten en datacontainers, of state en data. Als ik dan met een enigszins filosofische bril naar OOP kijk, dan krijg ik de indruk dat die scheidslijn binnen de grenzen van het OOP paradigma niet zo duidelijk te trekken is, zonder concessies te doen aan de praktische bruikbaarheid van OO talen en frameworks.

De logische tegenvragen zijn natuurlijk: Waarom zou je dat willen? Praktisch gezien is OO toch hardstikke goed bruikbaar, ook voor dit soort gevallen? Mijn antwoord: Tsja, da's ook wel weer zo. Ik denk dat OO nog steeds rising en is er geen sprake van een fall. Je ziet wel dat het steeds vaker vermengd wordt met concepten uit het Functionele paradigma (lambda's in C++, C# en straks eindelijk ook Java) en meer dynamische talen (mixins, duck typing). Daardoor worden OO talen IMO alleen maar fijner om mee te programmeren.

[ Voor 46% gewijzigd door Dricus op 23-01-2014 13:43 ]