Vergroot OO programmeren de schaalbaarheid van software?

[Reveller]

Na een afwezigheid van enkele maanden, vond ik het wel weer eens tijd worden voor een nieuwe post op mijn tweakblog.

Zonder vooralsnog teveel op de inhoud in te gaan, ben ik op zoek naar argumenten waarom software ontwikkelen vandaag de dag productiever kan dan vroeger. In oude artikelen wordt vaak gezegd dat software, in tegenstelling tot hardware, niet lineair schaalbaar is.

Volgens mij klopt dat steeds minder, onder andere door de introductie van gemoduleerd, object georienteerd programmeren. Maar omdat ik financieel (in plaats van technisch) ben opgeleid ben ik hiervan niet zeker. Vandaar de vraag: is mijn aanname juist?

[ Voor 7% gewijzigd door Reveller op 26-09-2010 16:21 ]

[CyBeR]

Niet inzichzelf. Alleen, mits goed uitgevoerd, de onderhoudbaarheid.

[Aloys]

Lineair zal het zeker niet zijn, maar het zal een stuk beter gaan dan vroeger. Door OOP is zeker het makkelijker om delen code aan je applicatie te "plakken" of her te gebruiken.

[Avalaxy]

Inderdaad met name de reusability is een stuk beter met OOP omdat je een object meerdere keren kunt gebruiken ipv elke keer dezelfde code te kopiëren en ergens anders neer te plakken. Ook overerving (inheritance) maakt het net wat makkelijker omdat je in subklassen gewoon een kleine aanpassing kan doen zonder dat je compleet nieuwe code moet tikken.

[Soultaker]

Avalaxy schreef op zondag 26 september 2010 @ 16:27:
Inderdaad met name de reusability is een stuk beter met OOP omdat je een object meerdere keren kunt gebruiken ipv elke keer dezelfde code te kopiëren en ergens anders neer te plakken.

Dat is een valse vergelijking. Je kunt ook modulair maar niet object-geörienteerd programmeren, zonder te hoeven kopiëren en plakken. De vraag is dan of object-geörienteerde software zich beter leent voor grote projecten dan bijvoorbeeld functioneel of procedureel-geörienteerde software. Dat is een andere vergelijking dan met kopiëren-en-plakken (wat natuurlijk niemand als zinnige techniek beschouwd).

Persoonlijk denk ik dat het in grote projecten essentieel is om implementatie-details te abstraheren van de interface van software. Dát maakt componenten herbruikbaar en grote, complexe projecten beter doorgrondbaar. OOP leent zich daar relatief goed voor, maar in andere paradigma's is abstractie vaak ook mogelijk. In een taal als Ocaml bijvoorbeeld, zie je vaak dat in de praktijk de OO-mogelijkheden niet gebruikt worden, omdat je met generieke functies al het gewenste niveau van abstractie kunt bereiken. Een ander voorbeeld is de C++ standard library: die is slechts gedeeltelijk gebaseerd op OO, en voor een groot deel op template programming, waarbij abstracties als iterators en functors gebruikt worden om generieke code te schrijven. Dat is een heel andere vorm van abstractie.

Voor hergebruikmogelijkheden en toepasbaarheid in grote projecten gaat het naar mijn idee dus om de mogelijkheid tot abstractie en niet zozeer welk paradigma daarbij gebruikt wordt.

[frickY]

In OOP ben je ook eerder geneigd om gelaagder te bouwen. Die lagen kun je later soms hergebruiken, of vervangen met een nieuwe uitgebreidere laag. In procedurele code zie je vaker dat de lagen meer met elkaar verweven zijn, ookal is dat technisch gezien helemaal niet nodig.

In de praktijk zal het elkaar niet ver ontlopen.

[ Voor 8% gewijzigd door frickY op 26-09-2010 17:09 ]

[Herko_ter_Horst]

Reveller schreef op zondag 26 september 2010 @ 16:20:
In oude artikelen wordt vaak gezegd dat software, in tegenstelling tot hardware, niet lineair schaalbaar is.

Volgens mij klopt dat steeds minder, onder andere door de introductie van gemoduleerd, object georienteerd programmeren. Maar omdat ik financieel (in plaats van technisch) ben opgeleid ben ik hiervan niet zeker. Vandaar de vraag: is mijn aanname juist?

Wat voor schaalbaarheid bedoel je dan? Heb je het over de productiviteit (ontwikkelsnelheid vs fouten/maintenance) van het softwareontwikkelproces? Of over de performance en capaciteit van het eindproduct?

[SH4D3H]

Reveller schreef op zondag 26 september 2010 @ 16:20:
Zonder vooralsnog teveel op de inhoud in te gaan, ben ik op zoek naar argumenten waarom software ontwikkelen vandaag de dag productiever kan dan vroeger.

Het ligt er ook een beetje aan wat je met 'vroeger' bedoelt. De eerste OO geschreven programma's zijn al 40 jaar oud en zeker na de introductie van C++ 30 jaar geleden werd het een stuk simpeler om in objecten te denken en ermee aan de slag te gaan. De echte, ehh, 'OOP omslag' is pas van de laatste 5(10?) jaren.

[Haan]

Reveller schreef op zondag 26 september 2010 @ 16:20:
Zonder vooralsnog teveel op de inhoud in te gaan, ben ik op zoek naar argumenten waarom software ontwikkelen vandaag de dag productiever kan dan vroeger.

Een voor de hand liggende: programmeertalen evolueren. Kijk bijvoorbeeld naar .NET (of Java), daarin wordt een groot deel van het werk uit handen genomen door het framework, waardoor je je als programmeur niet meer bezig hoeft te houden met geheugenmanagement, UI coden, e.d.. Dat betekent dus dat je meer tijd hebt om aan het inhoudelijk deel van de applicatie / oplossing te werken. Daarnaast evolueren de IDE's waarmee de software wordt ontwikkeld ook, waarmee je ook weer productiever kan werken.

In oude artikelen wordt vaak gezegd dat software, in tegenstelling tot hardware, niet lineair schaalbaar is. Volgens mij klopt dat steeds minder, onder andere door de introductie van gemoduleerd, object georienteerd programmeren. Maar omdat ik financieel (in plaats van technisch) ben opgeleid ben ik hiervan niet zeker. Vandaar de vraag: is mijn aanname juist?

OO wordt door sommigen wel gezien als dé heilige graal, maar andere factoren zijn ook belangrijk (zoals ik hierboven al schrijf). Ik vraag me wel af hoe je er op komt om over dit onderwerp te willen schrijven, terwijl je geen technische achtergrond hebt?

[roy-t]

SH4D3H schreef op zondag 26 september 2010 @ 17:12:
[...]

Het ligt er ook een beetje aan wat je met 'vroeger' bedoelt. De eerste OO geschreven programma's zijn al 40 jaar oud en zeker na de introductie van C++ 30 jaar geleden werd het een stuk simpeler om in objecten te denken en ermee aan de slag te gaan. De echte, ehh, 'OOP omslag' is pas van de laatste 5(10?) jaren.

Tbh was het toen in talen zoals SmallTalk een stuk makkelijker om OO te programmeren, C++ was, vooral in het begin, maar een OO framework. Er werd een pre-compiler gebruikt om er C code van te maken en het ging daarna ook gewoon door de C compilter heen.

Leuk om te weten trouwens dat SmallTalk ook reflection had, iets wat ook niet meer weg te denken is in moderne programmeertalen. Ik denk trouwens dat op het vlak van reflection nog erg veel gewonnen kan worden, veel programmeurs negeren dit nog. Ook hadden de meeste SmallTalk implementaties een JITTER en werd er naar bytecode ipv machinecode gecompileerd. SmallTalk-80 doet voor C# en JAVA niet onder qua features zou je bijna zeggen.

[ Voor 24% gewijzigd door roy-t op 26-09-2010 17:42 ]

[Reveller]

Herko_ter_Horst schreef op zondag 26 september 2010 @ 17:09:
[...]

Wat voor schaalbaarheid bedoel je dan? Heb je het over de productiviteit (ontwikkelsnelheid vs fouten/maintenance) van het softwareontwikkelproces? Of over de performance en capaciteit van het eindproduct?

Ik bedoel schaalbaarheid in de zin dat de software niet herschreven hoeft te worden als er intensiever gebruik van wordt gemaakt. Als voorbeeld: ik hack in een paar uur een forum in elkaar, maar het kan best zijn dat de responsetijd zwaar achteruit gaat als er meer gebruikers komen (bijvoorbeeld omdat de SQL queries inefficient blijken). Hardware uitbreiden betekent meestal: 2x zoveel hardware, 2x zoveel concurrent users mogelijk. Maar vaak blijkt niet de hardware, maar de software het probleem (kijk bv. naar een rampproduct als OSCommerce, met soms wel 1000 (!) queries per pagina view). Ik vraag me af welke technieken er beschikbaar zijn om je code zo te structureren, dat het beter schaalbaar is - dus meer requests kan afhandelen zonder dat de performance exponentieel achteruit gaat. Ik hoop dat ik zo duidelijk ben

[djluc]

Vergroot OO programmeren de schaalbaarheid van software?

!=

Reveller schreef op zondag 26 september 2010 @ 16:20:
[...]
Zonder vooralsnog teveel op de inhoud in te gaan, ben ik op zoek naar argumenten waarom software ontwikkelen vandaag de dag productiever kan dan vroeger. In oude artikelen wordt vaak gezegd dat software, in tegenstelling tot hardware, niet lineair schaalbaar is.
[...]

Je hebt het aan de ene kant in je topictitel over schaalbaarheid, waar meestal mee bedoeld wordt: Hoe eenvoudig kan een stuk software meer gebruikers/bezoekers/whatever aan. In je topicstart heb je het over software ontwikkeling. Het lijkt me van essentieel belang om eerst duidelijk te maken waar het nu exact over gaat.

[edit]Ik zie je post zojuist verschijnen...

Als het daadwerkelijk om performance gaat dan is het interessant om eerst even te bedenken waar de meest logische bottlenecks zitten. Bijvoorbeeld bij een forum page request zou in basis dit kunnen zijn:

browser -> client -> ADSL -> server -> PHP -> MySQL -> PHP -> server -> ADSL -> client -> browser

Een deel is niet beïnvloedbaar en dus irrelevant. De meeste optimalisaties gebeuren in de database (aanleggen van indexen bijvoorbeeld) en in PHP code (minder queries aanvragen bijvoorbeeld. Die kan je het meest eenvoudig beïnvloeden.

Nu kom je op het meest interessante punt, afgezien van extremen zoals 1000 queries per pageview, kost het optimaliseren je een uurtarief developer. Een extra server kost ook iets maar in veel gevallen levert een performance optimalisatie maar een kleine verbetering op als de basis al een beetje fatsoenlijk in elkaar zit. Dus bespaar je een kleine hoeveelheid servercapaciteit waar je wel tijd in moet steken.

Onafhankelijk van het programmeren is het vaak dus een keuze van geld in plaats van techniek of er wel of niet geoptimaliseerd moet worden.

[ Voor 41% gewijzigd door djluc op 26-09-2010 17:55 . Reden: tegelijkertijd aan het schrijven ]

[FragFrog]

Reveller schreef op zondag 26 september 2010 @ 17:44:
Maar vaak blijkt niet de hardware, maar de software het probleem (kijk bv. naar een rampproduct als OSCommerce, met soms wel 1000 (!) queries per pagina view).

Dat is een vrij kenmerkende eigenschap juist van over-OOP-en zoals ik het zelf graag noem. Ik heb aardig wat interne softwareproducten gezien in de afgelopen jaren en juist de OOP projecten leveren mij vaak de taak op om de boel 'sneller' te krijgen. Dan zie je ORM systemen die functioneel wel goed werken, maar geen enkele vorm van lokaal datamodel gebruiken waardoor je pageviews krijgt met 500+ queries - juist omdat alles zo nodig een object moet zijn en elk object an sich weer geen donder kan zonder eerst al z'n relaties op te halen.

Ter illustratie: even geleden ben ik bezig geweest met een volledig OOP PHP framework. De belangrijkste eisen erachter zijn dat het simpel, intuitief en vooral snel moet zijn. Ik ben uiteindelijk twee dagen bezig geweest om een simpele pagina met comments even snel te krijgen als een enkele pagina op m'n blog die ik jaren geleden, zonder enige kennis van programmeren of OOP, volledig procedureel inelkaar geflanst heb.

Qua performance is OOP echt niet per definitie beter schaalbaar, eerder andersom.

[Gamebuster]

Ik programmeer OO omdat ik het gewoon prettiger vind werken. Code is overzichtelijker en logischer en je dwingt jezelf code te scheiden zodat je makkelijk aanpassingen kunt maken in bepaalde delen zonder dat andere delen ook aangepast moeten worden.

[Soultaker]

roy-t schreef op zondag 26 september 2010 @ 17:39:
Leuk om te weten trouwens dat SmallTalk ook reflection had, iets wat ook niet meer weg te denken is in moderne programmeertalen. Ik denk trouwens dat op het vlak van reflection nog erg veel gewonnen kan worden, veel programmeurs negeren dit nog.

Waar denk je dan aan? Ik vind persoonlijk reflectie een misfeature. Essentieel voor bepaalde toepassingen (RMI of serialisatie bijvoorbeeld) maar als bouwsteen voor OOP eerder schadelijk dan behulpzaam. Geen enkel gangbaar design pattern gebruikt reflectie (of noem een paar tegenvoorbeelden?)

Ook hadden de meeste SmallTalk implementaties een JITTER en werd er naar bytecode ipv machinecode gecompileerd. SmallTalk-80 doet voor C# en JAVA niet onder qua features zou je bijna zeggen.

De meeste?! In de jaren 80/90 (wat al laat is, want Smalltalk is ontwikkeld in de jaren 70) gebruikte geen enkele implementatie een JIT. Tegenwoordig is JIT-compilatie ook nog helemaal niet gebruikelijk.

Dat Java geïnspireerd is door Smalltalk (en C# weer door Java) is duidelijk als je de standaard class library eens doorneemt. Wat echter een fundamenteel verschil tussen Smalltalk en Java/C# is, is het verschil tussen dynamische en statische typering. Smalltalk is daarmee meer te vergelijken met Python of JavaScript dan met Java of C# naar mijn mening, vooral omdat in Java bijvoorbeeld bytes, integers, floats en classes geen objecten zijn.

[ Voor 13% gewijzigd door Soultaker op 26-09-2010 19:03 ]

[Herko_ter_Horst]

Reveller schreef op zondag 26 september 2010 @ 17:44:
[...]

Ik bedoel schaalbaarheid in de zin dat de software niet herschreven hoeft te worden als er intensiever gebruik van wordt gemaakt. Als voorbeeld: ik hack in een paar uur een forum in elkaar, maar het kan best zijn dat de responsetijd zwaar achteruit gaat als er meer gebruikers komen (bijvoorbeeld omdat de SQL queries inefficient blijken). Hardware uitbreiden betekent meestal: 2x zoveel hardware, 2x zoveel concurrent users mogelijk. Maar vaak blijkt niet de hardware, maar de software het probleem (kijk bv. naar een rampproduct als OSCommerce, met soms wel 1000 (!) queries per pagina view). Ik vraag me af welke technieken er beschikbaar zijn om je code zo te structureren, dat het beter schaalbaar is - dus meer requests kan afhandelen zonder dat de performance exponentieel achteruit gaat. Ik hoop dat ik zo duidelijk ben

Een hogere mate van abstractie leidt in de meeste gevallen niet tot een hogere performance/schaalbaarheid. Maar daarbij komt wel de afweging tussen de kosten van ontwikkeling en onderhoud vs. de kosten van hardware/systemen om de hoek kijken. De kans is namelijk groot dat een hoger abstractieniveau wel een hogere productiviteit en betere onderhoudbaarheid met zich mee brengt.

In de meeste gevallen zijn de kosten van ontwikkeling en in het bijzonder onderhoud vele malen groter dan de kosten van het uitbreiden/upgraden van hardware. Om het ORM voorbeeld te pakken: het is, ondanks mogelijke inefficientie, zeer waarschijnlijk goedkoper om een ORM framework van de plank te pakken (mits dat functioneel voldoet) en er zwaardere hardware tegenaan te gooien, dan om zelf een storagemechanisme te ontwikkelen, als de totale kosten worden bekeken over de levensduur van de applicatie.

Overigens is de vraag of een ORM framework van zichzelf inefficient is, niet zomaar te beantwoorden. Het kan in de genoemde voorbeelden ook heel goed liggen aan inefficient gebruik van het framework. Dat is uiteraard een risico van de abstractie: het is makkelijk functioneel correct te krijgen, maar dat wil nog niet zeggen dat het ook makkelijk efficient te krijgen is.

Mijns inziens is er geen enkel paradigma dat schaalbaarheid garandeert, dus ook OO niet. Het zal altijd een kwestie zijn van de zwakste schakel in de keten.

[DutchCommando]

De schaalbaarheid van veel architecturele oplossingen zit hem o.a. in de hoeveelheid state die requests (in het geval van websites en -services) delen. Op het niveau van een object bevat object-orientatie ook state in de vorm van de attributes die bij het object horen. Maar het object zelf kan transient (tijdelijk) zijn, door slechts aanwezig te zijn gedurende het afhandelen van een request. In dergelijke gevallen vormt object-orientatie geen belemmering voor het bereiken van schaalbaarheid.

In tegenstelling tot paradigma waarin een duidelijke scheiding bestaat tussen het modificeren van bepaalde shared state en het uitvoeren van pure functies, biedt object-orientatie geen extra hulp om deze schaalbaarheid te bereiken. Daarom zou ik niet durven te stellen dat OO programmeren de schaalbaarheid van software vergroot.

[ Voor 6% gewijzigd door DutchCommando op 26-09-2010 20:06 ]

[ACM]

Imho is een betere abstractie, mits goed gebruikt, wel in veel gevallen bruikbaar om schaalbaarheid van applicaties te vergroten. Denk bijvoorbeeld aan het vervangen van een onderdeel uit de datalaag die eerst in-memory elementen cached en waarbij de nieuwe dat op een cache-farm doet voor een betere cache hit ratio.

't Voordeel van abstractie (en dus bijvoorbeeld OO) is dat je dan (relatief) eenvoudig de nieuwe implementatie kunt inpluggen zonder dat de overige code hoeft te worden aangepast.

Herko_ter_Horst schreef op zondag 26 september 2010 @ 19:41:
In de meeste gevallen zijn de kosten van ontwikkeling en in het bijzonder onderhoud vele malen groter dan de kosten van het uitbreiden/upgraden van hardware. Om het ORM voorbeeld te pakken: het is, ondanks mogelijke inefficientie, zeer waarschijnlijk goedkoper om een ORM framework van de plank te pakken (mits dat functioneel voldoet) en er zwaardere hardware tegenaan te gooien, dan om zelf een storagemechanisme te ontwikkelen, als de totale kosten worden bekeken over de levensduur van de applicatie.

Als we het over schaalbaarheid hebben, dan is dat wel een gevaarlijk uitgangspunt. Je gaat er dan op voorhand eigenlijk al van uit dat je software wel schaalt naar snellere hardware... Maar dat is nou net een aspect dat wellicht helemaal niet waar is. Scale-out is zelden triviaal op grotere schaal op te zetten en scale-up heeft de vervelende neiging om steeds meer te kosten voor steeds minder extra performance. En bovendien levert scale-up vaak zat ook de vereiste van parallele verwerking van in je software op.

Schaalbaarheid betekent natuurlijk enerzijds dat je applicatie meer capaciteit behoort te krijgen op het moment dat er meer rekenkracht tegenaan gegooit wordt (bij voorkeur zowel in de breedte als in de hoogte). En anderzijds dat als je meer belasting hebt, dat dan de prestaties naar verhouding afnemen ipv steeds sneller afnemen.

Mijns inziens is er geen enkel paradigma dat schaalbaarheid garandeert, dus ook OO niet. Het zal altijd een kwestie zijn van de zwakste schakel in de keten.

Eens. Je zal in alle gevallen goed op moeten letten op wat je doet. Ik kan me zelfs niet voorstellen dat er uberhaupt software bestaat die met een kleine gebruikersschare begonnen is en naar een enorme hoeveelheid gebruikers gegroeid is zonder tussendoor herschreven te zijn.
In de praktijk is het maar afwachten of die beoogde belasting wel op je systeem komt (de meeste web start-ups worden niet "tweakers.net schaal" en dus al helemaal niet "web scale") en tegen de tijd dat die komt heb je toch al tig aspecten aangepast of zelfs herschreven ivm nieuwe features en het verhelpen van bugs.
Bij dat onderhoudstraject kan je dan ook de schaalbaarheid meenemen. In het begin zal dat dan vooral caching lagen toevoegen zijn en later wellicht ook het beter uit elkaar trekken van lagen naar losse servers of serverparken...

In een perfecte wereld zou je dat laatste dus triviaal kunnen doen door steeds een of enkele stukjes invulling van je abstractie te vervangen door nieuwe varianten die aansluiten bij je nieuwe schaal

[Matis]

Ik vind dat OOP wel degelijk de schaalbaarheid van software vergroot. Mede omdat door de komst van klassen en objecten, er mogelijkheid was voor het gebruiken van Design Patterns.

Op mijn werk maak ik (helaas) geen gebruik meer van OOP, maar ik denk dat je door de komst van OOP meet abstractie in de software kunt krijgen en derhalve eenvoudiger toepasbaar maakt. En daarom beter schaalbaar houdt.

[Herko_ter_Horst]

ACM schreef op zondag 26 september 2010 @ 20:55:
Imho is een betere abstractie, mits goed gebruikt, wel in veel gevallen bruikbaar om schaalbaarheid van applicaties te vergroten. Denk bijvoorbeeld aan het vervangen van een onderdeel uit de datalaag die eerst in-memory elementen cached en waarbij de nieuwe dat op een cache-farm doet voor een betere cache hit ratio.

't Voordeel van abstractie (en dus bijvoorbeeld OO) is dat je dan (relatief) eenvoudig de nieuwe implementatie kunt inpluggen zonder dat de overige code hoeft te worden aangepast.

Zeker. Maar de grotere schaalbaarheid op zich is dan niet het gevolg van OOP, alleen het makkelijk in kunnen bouwen is dat (onderhoudbaarheid). Je kunt natuurlijk ook zonder OOP caching inbouwen, maar zonder abstractie/interface zal dat een stuk meer moeite kosten. Abstractie op zich levert geen schaalbaarder systeem op, in de meeste gevallen kost het enige performance (die echter ruimschoots wordt terugverdiend in onderhoudbaarheid).

[...]

Als we het over schaalbaarheid hebben, dan is dat wel een gevaarlijk uitgangspunt. Je gaat er dan op voorhand eigenlijk al van uit dat je software wel schaalt naar snellere hardware... Maar dat is nou net een aspect dat wellicht helemaal niet waar is. Scale-out is zelden triviaal op grotere schaal op te zetten en scale-up heeft de vervelende neiging om steeds meer te kosten voor steeds minder extra performance. En bovendien levert scale-up vaak zat ook de vereiste van parallele verwerking van in je software op.

Wat ik bedoel te zeggen, is dat het laag houden van ontwikkel- en onderhoudskosten tegenwoordig belangrijker is dan de laatste druppel performance uit een systeem persen. Een brak systeem blijft natuurlijk een brak systeem

In een perfecte wereld zou je dat laatste dus triviaal kunnen doen door steeds een of enkele stukjes invulling van je abstractie te vervangen door nieuwe varianten die aansluiten bij je nieuwe schaal

Als je abstractie goed gekozen is, kan dat inderdaad. Maar dat vergt voor de meeste bedrijven/ontwikkelaars teveel toekomstvisie. En als je het niet goed kiest, zit het alleen maar in de weg. YAGNI.

[Gomez12]

Moeilijk, moeilijk. Qua snelheid / schaalbaarheid gaat er niets boven procedurele code.
OOP kost altijd performance (onder dezelfde omstandigheden).

OOP op zichzelf vind ik dan ook compleet nutteloos. Het is enkel de "complete" mindset eromheen ( design patterns / correcte abstracties etc etc ) die het nuttig maakt ( daarom maak ik kleine frutselprogs zo goed als altijd procedureel, die hebben geen mindset nodig. Die moeten 1 ding doen en dat moet goed en snel )

Een procedureel programma wil je eigenlijk niet opeens multiserver maken, dat is veelal een te erge crime.
Bij OOP-lessen wordt er gelijk geleerd om goed te abstraheren zodat je "gelijk" onderdelen van je code op een andere server kan onderbrengen.

In principe kan procedureel programmeren hetzelfde resultaat opleveren als OOP( enkel sneller ), enkel is niemand(?) die mindset aangeleerd. Terwijl de mindset dat alles vervangen moet kunnen worden ( en dus correcte abstracties moet hebben ) er bij OOP er al vanaf dag 0 ingestouwd worden.

[.oisyn]

Gomez12 schreef op maandag 27 september 2010 @ 00:43:
Moeilijk, moeilijk. Qua snelheid / schaalbaarheid gaat er niets boven procedurele code.
OOP kost altijd performance (onder dezelfde omstandigheden).

Sorry, maar dat slaat nergens op. Het is de abstractie die performance kost, niet OOP an sich. En een abstractielaag kun je in procedurele code ook maken.

[roy-t]

Soultaker schreef op zondag 26 september 2010 @ 18:47:
[...]

Waar denk je dan aan? Ik vind persoonlijk reflectie een misfeature. Essentieel voor bepaalde toepassingen (RMI of serialisatie bijvoorbeeld) maar als bouwsteen voor OOP eerder schadelijk dan behulpzaam. Geen enkel gangbaar design pattern gebruikt reflectie (of noem een paar tegenvoorbeelden?)


[...]

Design patterns:
http://msdn.microsoft.com/en-us/magazine/cc164170.aspx
http://www.vbdotnetheaven...ernUsingReflectionVB.aspx
Wikipedia: Visitor pattern (zie halverwege de details sectie)
http://www2.parc.com/csl/...ion96/docs/sobel/rop.html

Waar ik vooral reflection erg handig voor vind is als je 'editors' maakt. Stel dat je een soort 'powerpoint' maakt. Je maakt meerdere controls, deze controls moeten iets doen at runtime (zoals een plaatje laten zien), maar ook at design time wil je informatie over dat control, bijvoorbeeld wat voor opties de editor moet weergeven, dit kun je doen door voor elke control een extra class aan te maken (lelijk), maar je kunt ook de publieke fields/properties decoreren met attributen en via reflection deze achterhalen om te zien wat je in je editor moet weergeven.

Edit: maar misschien is het wel interessant om een appart "reflection discussie topic" aan te maken? Want ik vind echt dat dit underrated is.

[ Voor 7% gewijzigd door roy-t op 27-09-2010 10:16 ]

[Herko_ter_Horst]

Gomez12 schreef op maandag 27 september 2010 @ 00:43:
Moeilijk, moeilijk. Qua snelheid / schaalbaarheid gaat er niets boven procedurele code assembly.
OOP kost altijd performance (onder dezelfde omstandigheden).

There, fixed it for ya.

[Creepy]

Herko_ter_Horst: dan ga je er wel vanuit dat jij altijd slimmer bent dan een compiler. En dat geldt maar voor heel erg weinig mensen. Los daarvan is schaalbaarheid van code is wel even iets meer dan alleen een hele snelle routine.

[Verwijderd]

Ik programmeer alles in PHP / Python en heb dus niet veel met geheugen adressering te maken, en weet hier ook niet veel van.

Maar is het niet zo dat je met OOP & polymorfisch programmeren ook efficienter gebruik maakt van het geheugen?

Dat heb ik namelijk in een van mijn OOP boeken weleens voorbij zien komen.

[Haan]

roy-t schreef op maandag 27 september 2010 @ 09:52:
[...]

Edit: maar misschien is het wel interessant om een appart "reflection discussie topic" aan te maken? Want ik vind echt dat dit underrated is.

offtopic:
ik zou zeggen leef je uit! zo'n topic lijkt mij ook erg interessant

[ Voor 58% gewijzigd door Haan op 27-09-2010 11:28 ]

[Killemov]

Creepy schreef op maandag 27 september 2010 @ 11:10:
Herko_ter_Horst: dan ga je er wel vanuit dat jij altijd slimmer bent dan een compiler. En dat geldt maar voor heel erg weinig mensen. Los daarvan is schaalbaarheid van code is wel even iets meer dan alleen een hele snelle routine.

Nou ... de prestaties liggen voor 80% in de efficientie van een algoritme en 20% in de implementatie daarvan? Daarbij hoeft er geen correlatie te zijn tussen prestatie en schaalbaarheid.

Trouwens, slimmer dan een compiler zou nu nog wel kunnen ... maar sneller dan een runtime-optimizer? (JRE)

[Killemov]

Haan schreef op maandag 27 september 2010 @ 11:28:
[...]

offtopic:
ik zou zeggen leef je uit! zo'n topic lijkt mij ook erg interessant

Dan heb ik nog wel een mooie aankeiler: "Reflection kan handig zijn, maar je moet het niet gebruiken tenzij het echt niet anders kan."

[Cartman!]

Goed onderbouwd ook...

OO kan de schaalbaarheid denk ik wel verbeteren, je kunt immers veel makkelijker onderdelen lostrekken en refactoren naar een nieuwe backend of server toe.

[roy-t]

Haan schreef op maandag 27 september 2010 @ 11:28:
[...]

offtopic:
ik zou zeggen leef je uit! zo'n topic lijkt mij ook erg interessant

Ik zal even een modje schoppen

[Creepy]

En alsnog even een schopje door naar SEA.

[YopY]

Verwijderd schreef op maandag 27 september 2010 @ 11:20:
Ik programmeer alles in PHP / Python en heb dus niet veel met geheugen adressering te maken, en weet hier ook niet veel van.

Maar is het niet zo dat je met OOP & polymorfisch programmeren ook efficienter gebruik maakt van het geheugen?

Dat heb ik namelijk in een van mijn OOP boeken weleens voorbij zien komen.

Je kunt efficienter gebruik maken (met de nadruk op kunt), je variabelen kun je eenvoudiger in 'scope' beperken, waardoor ze korter in het geheugen zitten.

Aan de andere kant wordt er juist weer meer geheugen gebruikt, omdat een object nu eenmaal meer geheugen gebruikt dan een primitief datatype (er zit altijd wat overhead bij). Het initialiseren van een object kost ook extra processortijd.

Kan zo niet een voorbeeld bedenken van iets dat redelijk eenvoudig is en in zowel OO als procedureel geimplementeerd kan worden, overigens.

[djluc]

Wellicht is dit wel een echt meten = weten verhaal en bestaat er niet 1 duidelijke conclusie. Dat OOP programmeren overzichtelijker is e.d. dat weten we. Ook kan je vaak net even wat sneller ontwikkelen op basis van een OOP framework, zeker als dat bijvoorbeeld relaties e.d. meeneemt.

Of het een dan sneller is dan het ander zal specifiek verschillen per situatie. Een mooi OOP script wat RSS feeds ophaalt en importeert in een database kan stukken langzamer zijn als er allerlei OOP code extra uitgevoerd moet worden dan een stuk platte lineaire code wat hetzelfde doet.

Als je echter een paar duizend imports per dag doet dan boeit dat verschil waarschijnlijk helemaal niet maar de overzichtelijke code etc. wel. Dus ik verwacht dat dit topic geen echt antwoord gaat bieden.

Dit is trouwens een interessante site met allerlei real-life cases:
http://highscalability.com/

[ Voor 5% gewijzigd door djluc op 27-09-2010 13:53 ]

[roy-t]

[topickaap]Reflection, hier verder Reflection ondergewaardeerd of misfeature?[/topickaap]

[.oisyn]

Herko_ter_Horst schreef op maandag 27 september 2010 @ 09:56:
[...]


There, fixed it for ya.

Een assembler schrijven zorgt ervoor dat je programma sneller wordt?

Oooh, bedoel je assembly?

[djluc]

Wat je in veel situaties ziet waar heel veel dataverwerking plaatsvind en waar client snelheid van belang is: Batch processing.

Je hebt dan een wachtrij met allemaal taken om te verwerken. Die worden achter elkaar verwerkt op servers die alleen maar die wachtrij afwerken en daar dus geoptimaliseerd voor zijn. Dat uitbesteden kan echter zowel in OOP als lineair programmeren vrijwel niet zomaar omgezet worden. Dus ook daar zie ik geen relevantie tussen de manier van programmeren en de snelheid/portabiliteit.

[Verwijderd]

Ik denk persoonlijk dat de kracht van OO programmeren vooral ligt in de programmeur zelf (duh). Er zitten veel handige dingetjes in om zo gelaagd mogelijk en zo gestructureerd mogelijk een programma op te bouwen. Het is echter aan de programmeur zelf om hier al dan niet gebruik van te maken.
Ik denk dat een goede programmeur betere procedurele code schrijft, dan een slechte programmeur OO code schrijft. Maak je voor elk dingetje een aparte klasse, of ga je eerst generieke eigenschappen van verschillende componenten op een rijtje zetten zodat je een abstracte klasse kunt schrijven en kan gebruiken voor meerdere componenten?

Verwijderd schreef op maandag 27 september 2010 @ 11:20:
Ik programmeer alles in PHP / Python en heb dus niet veel met geheugen adressering te maken, en weet hier ook niet veel van.

Maar is het niet zo dat je met OOP & polymorfisch programmeren ook efficienter gebruik maakt van het geheugen?

Dat heb ik namelijk in een van mijn OOP boeken weleens voorbij zien komen.

Geen idee. Ik weet wel dat in PHP je bij voorkeur methodes statisch moet maken voor een betere snelheid. Althans, als we de volgende quote mogen geloven:

If a method can be static, declare it static. Speed improvement is by a factor of 4.

Bron.

Zelf gebruik ik eigenlijk zelden static methods, nu ik er zo over nadenk.

Hier nog wat meer interessant leesvoer: Static methods and performance.

[ Voor 4% gewijzigd door Verwijderd op 29-09-2010 21:46 ]

[.oisyn]

Ik ben het volledig eens met z'n stelling, alleen niet met z'n argumentatie. Waarom zou een method die niets met een instance doet niet static zijn? Het impliceert immers dat je 'm ook zonder instance aan kunt roepen. Door 'm niet static te maken kan dat ineens niet meer, terwijl het nergens op slaat. Feitelijk werkt het zelfs verwarrend.

Snelheid komt op de 2e plaats, maar het is al netter, wat het hele snelheidsargument derhalve teniet doet . Al is het artikel wel uit 2008.

Overigens is PHP nou niet echt het schoolvoorbeeld van OO.

[ Voor 23% gewijzigd door .oisyn op 29-09-2010 22:01 ]

[HuHu]

Verwijderd schreef op woensdag 29 september 2010 @ 21:46:

Geen idee. Ik weet wel dat in PHP je bij voorkeur methodes statisch moet maken voor een betere snelheid. Althans, als we de volgende quote mogen geloven:

[...]


Bron.

Zelf gebruik ik eigenlijk zelden static methods, nu ik er zo over nadenk.

Hier nog wat meer interessant leesvoer: Static methods and performance.

Jan 31, 2005, 14:10

Ik weet niet of dat nog relevant is.

[.oisyn]

Sterker nog, in de post van 2005 zegt ie "I did a test once". Oftewel, ten tijde van posten was het dus al een tijd geleden . Ben benieuwd wat de performance tegenwoordig is met die "late static binding" feature.

[ Voor 25% gewijzigd door .oisyn op 29-09-2010 22:02 ]

[Jory]

Verwijderd schreef op woensdag 29 september 2010 @ 21:46:
[...]
Bron.

Dat citaat uit jou bron, is iets wat de schrijver van dat artikel zelf ook citeert, en vervolgens tegenspreekt.

Daarnaast, als je methods static gaat maken omdat dat sneller is (en je die performance winst nodig hebt) dan heb je een ander probleem.

[chris]

Ik denk dat hier wel een belangrijk element mist: waarmee vergelijk je OOP? Ik heb veel (pure) functional programming gedaan, en dat vergroot de schaalbaarheid nog meer (omdat elementen nog makkelijker los te koppelen zijn). Ik moet ook zeggen dat het op een hoog niveau niet meer echt uit maakt welke taal je kiest: je kan overal software modulair in bouwen. Met de juiste abstracties (zoals HTTP / webservices) kan je prima schalen in iedere taal.

Ik denk dat de hoeveelheid state bijna direct samenhangt met de schaalbaarheid. Zodra componenten alleen weten wat ze écht nodig hebben kan je ze makkelijk loskoppelen en vervangen. Als componenten te veel weten dan wordt het steeds moeilijker om ze los te koppelen en individueel te schalen.

[Verwijderd]

Jory167 schreef op woensdag 29 september 2010 @ 22:03:
Daarnaast, als je methods static gaat maken omdat dat sneller is (en je die performance winst nodig hebt) dan heb je een ander probleem.

Exact. Of je wilt echt elke nanoseconde uit je programma persen, dat kan natuurlijk ook.

Zelf gebruik ik alleen statische methodes als het nodig is, of als ik zeker weet dat er nooit meerdere instances nodig heb van dat object. Dan is de "nette" manier om statische methodes/variabelen te gebruiken.
Het gebruik van een singleton object in dergelijke situaties wordt door sommigen niet beschouwd als een échte OO oplossing, terwijl de scope van statische functies/variabelen in (extended) classes weer heel anders werkt waardoor je allerlei rare work-arounds moet gaan vinden om ervoor te zorgen dat je statische methodes en variabelen ook kunt extenden. Al met al is static method inheritance in PHP één groot drama.

Maargoed.

[ Voor 10% gewijzigd door Verwijderd op 01-10-2010 12:45 ]

[djluc]

Dit gaat nu meer over mini optimalisaties, ook belangrijk, maar niet de basis van scalability, zitten hier geen mensen met ervaring daarin?

[H!GHGuY]

Het antwoord op de TS zijn vraag is volgens mij overduidelijk "NEE".

OO en scalability zijn 2 dingen die loodrecht op elkaar staan. Procedureel, functioneel, OO, ... zijn gewoon manieren waarop je je code opbouwt en organiseert. Scalability gaat over hoe je de beschikbare resources/hardware (optimaal) gebruikt.
Het gebruik van OO zal er niet magischerwijs voor zorgen dat je nu meer concurrent users kan bedienen of dat je programma plots sneller draait. Omgekeerd is OO geen noodzaak om scalable code te schrijven.

Zoals gezegd is OO een manier van organisatie van je code. Je abstraheert bepaalde concepten en deelt verantwoordelijkheden op tot individuele klassen. Het vergemakkelijkt scalability in de ontwikkelingsfase. Door interface en implementatie in de taal te scheiden vergemakkelijk je hergebruik en onderhoudbaarheid van code.
Wanneer we over performance praten, dan is het eigenlijk zelfs zo dat OO in het algemeen iets minder schaalt qua performance. De reden hierachter is dat een van de basisprincipes van het processor/geheugen-subsysteem minder benut worden: lokaliteit van data. Gerelateerde objecten (dus met referenties naar elkaar) hebben een snellere neiging om verspreid te zijn over het beschikbare geheugen.

Schaalbaarheid op zijn beurt gaat over het benutten van hardware. Dit gaat over aantal processor cores tot hoeveelheid geheugen of zelfs bandbreedte naar andere subsystemen of systemen. Voor geheugengebruik kan je bijvoorbeeld stellen dat caching technieken de hardware beter gaan benutten en dus schaalbaarder maken.
Voor bvb netwerk adapters, kun je stellen dat het gebruik van een groter maximum transmission unit (MTU) de beschibare bandbreedte efficienter en dus schaalbaarder gebruikt.
Voor processoren gaat dit voornamelijk over het grote magische woord concurrency. Je hebt verschillende manieren om aan concurrency te doen: bvb de verwerking van een dataset opsplitsen over meerdere cores, pipelining (elke core doet een specifiek deel van een algoritme), partitionering (elke core een andere set taken geven), versionering van data (bvb RCU, transactional memory), enz.

De 2 concepten zijn dus niet rechtstreeks gerelateerd. Concurrency begint meestel op architectuur niveau. Bij nieuwe programmatuur staan beide concepten zowat orthogonaal op elkaar. Voor een bestaande applicatie kan OO een factor in zijn die het concurrent maken makkelijker of moeilijker maakt afhankelijk van de structuur van je programma.

Trouwens is de bewering dat hardware lineair schaalt pertinent onwaar. Hardware kan slechts lineair schalen op voorwaarde dat _alle_ hardware in het systeem lineair meeschaalt. Het toevoegen van een 2de core op een processor zorgt bvb voor allerhande nieuwe bottlenecks zoals het coherent houden van caches.

[Gomez12]

djluc schreef op vrijdag 01 oktober 2010 @ 13:21:
Dit gaat nu meer over mini optimalisaties, ook belangrijk, maar niet de basis van scalability, zitten hier geen mensen met ervaring daarin?

Wil je echt over scalability gaan praten, dan heb je imho een echte uitgewerkte case nodig waarover je kan gaan praten.

Het is niet a of b, het kan a zijn afhankelijk van de vereisten, maar het kan ook b zijn als de vereisten anders zijn