Archief - [ALG] hoe verder gaan

Jormungand · 2 nov 2005

Je bent vrij om die mening hierover te hebben uiteraard, ik persoonlijk ben het er niet mee eens.

Ikzelf werk aan een software systeem waaraan reeds meer dan 5 jaar gewerkt is, met een team. We spreken hier dan ook over honderd duizenden(!) regels code. Hierin zitten we ook met zogenaamde "legacy code" (C code, en ook nog ens slecht geschreven), en geloof mij, die code is dus echt niet herbruikbaar, zeer moeilijk te vatten en nog minder te onderhouden. Deze software heeft ook nog eens een levenscyclus van jaren en zal ook nog jaren vernieuwd worden. In mijn geval is het dus onmisbaar om goede designs te maken (for reuse and change) en OOP toe te passen. Wij als team hebben wel enorme voordelen door OOP te gebruiken. We hebben zeer flexibele designs, waarvan vele components effectief worden hergebruikt. Wij zijn ook geen team dat direct op de hype-kar van nieuwe technologieen zoals bv. .NET springt. We gebruiken voornamelijk gewoon C++, STL, COM, MFC en daarnaast eigen in-house frameworks. Zulke technologieen zijn er reeds jaren en zullen er nog jaren zijn. Het project waarover ik het heb is technologie dat is overgekocht van een ander bedrijf, waarvan ik de naam hier niet ga publiek maken. Wij hebben grote problemen juist door die legacy C-code. Het is juist die code die de software veel duurder maakt (vooral op lange termijn). We zijn dan ook volop bezig met refactoring van deze code in betere designs en met het integreren van ons in-house framework zodat ook dit software systeem, naar de user toe, onze gekende look 'n feel krijgt. Dit framework bestaat reeds 12 jaar (er zijn zelfs nog van die oude versies in the field) en er wordt vandaag nog steeds aan gewerkt.
Misschien snap je nu waarom ik het er helemaal niet mee eens ben. Het is onmogelijk om met bv. C dezelfde flexibiliteit te bekomen zonder grote(re) inspanningen te leveren die je ertoe dwingen om zelf gelijkaardige features te implementeren die je er bij C++ (of een OOP taal in't algemeen) er gratis en voor niets bij krijgt.
Meningsverschillen zuller er altijd zijn natuurlijk, ik vind het alleen jammer, voor jou, dat je OOP alleen mooi vind in theorie

azerty · 2 nov 2005

Begrijp me niet verkeerd hé, OOP kan in de praktijk wel werken en een goede ROI hebben. Het enige wat ik wou zeggen is dat je toch aan 't begin van elk project eerst de denkoefening moet maken, en niet zomaar direct OOP doen zomaar omdat iedereen 't doet.
M'n persoonlijke ervaring is dat op ongeveer 30% à 50% vd projecten die ik al heb meegemaakt met OOP, men een beter/sneller/goedkoper resultaat kon hebben dr 't gewoon te bouwen.

Unzip Attack · 2 nov 2005

ik zou me geen project meer kunnen voorstellen zonder OO, serieus zo legacy code is verschrikkelijk gewoon om u in te werken... Dat 30% tot 50% zogezegd zonder OOP kan is SERIEUS overdreven. In de praktijk is "inwerken in code" door nieuwe programmeurs in een project enzo OOK allemaal extra tijd en dus money.
Wat voor projecten zijn dat dan zoal die je zonder kan doen ?

fretn · 2 nov 2005

Unzip Attack zei:
ik zou me geen project meer kunnen voorstellen zonder OO, serieus zo legacy code is verschrikkelijk gewoon om u in te werken... Dat 30% tot 50% zogezegd zonder OOP kan is SERIEUS overdreven. In de praktijk is "inwerken in code" door nieuwe programmeurs in een project enzo OOK allemaal extra tijd en dus money.
Wat voor projecten zijn dat dan zoal die je zonder kan doen ?

(pseudocode)

Code:

class Camera
{
  float x;
  float y;
  
  void move_up(void)
  {
    this.x++;
  } 
}

var cam = new Camera
cam.move_up();

vs

Code:

typedef struct cam_s
{
  float x;
  float y;
}
cam_t;

cam_t cam;

void move_up( cam_t camera)
{
  camera.x++;
}

move_up(cam);

voor dergelijke dingen vind ik (maar dat is dan mijn mening natuurlijk) OO overbodig, waarom:

- de legacy versie is even herbruikbaar als de class-versie
- meerdere instanties nodig van uw camera, geen probleem in beide versies
- inheritance heb je niet nodig in dergelijk geval
- ...

zaken waar OO dan wel goed voor is, is bvb: een entity systeem in uw game-engine, je hebt een main class 'Entity' met de hoofd parameters en dan gaat ieder entity deze inheriten en zijn eigen specificaties toevoegen

maar aangezien tegenwoordig bijna alles OO is, kan het geen kwaad van te leren wat OO is

Jormungand · 2 nov 2005

Unzip Attack zei:
ik zou me geen project meer kunnen voorstellen zonder OO, serieus zo legacy code is verschrikkelijk gewoon om u in te werken... Dat 30% tot 50% zogezegd zonder OOP kan is SERIEUS overdreven. In de praktijk is "inwerken in code" door nieuwe programmeurs in een project enzo OOK allemaal extra tijd en dus money.
Wat voor projecten zijn dat dan zoal die je zonder kan doen ?

Vind ik dus ook.

@fretn
Jij vergeet gewoon een van de belangrijkste concepten die OO bieden. Namelijk encapsulation en information hiding. Dat zijn zeer belangrijke concepten.
Je non-OO versie van je voorbeeld heeft dit niet, maw jij als ontwerper van je camara "object" heeft geen controle meer omdat gewoon iedereen met x en y kan doen wat hij wil, ook dingen die fout zijn! En die foute dingen kunnen zeer subtiel zijn, en dus ook zeer moeilijk te detecteren/debuggen. Jou concept in de non-OO versie van een camera is veel minder gedefinieerd. Hoe kan jij nu garanderen dat jou camera concept correct zal werken, als iedereen ermee kan doen wat hij/zij wil?! Dan kan jij helemaal NIET. Laat staan om een invariant te garanderen!
Daarom ga ik eveneens niet met jou akkoord, helemaal niet zelfs, ik vind het onzin. De OO versie van de camera class heeft niets dan voordelen, het draait even snel als de C versie, het concept is zeer goed gedefinieerd en kan zijn eigen regels vastleggen (data private), initialisatie is gegarandeerd door constructors, moet ik nog verder gaan met de voordelen op te sommen (ik weet er nog een deel)? Ik kan helemaal geen nadeel vinden hoor. Misschien weet jij er wel, laat ze maar komen...

killgore · 2 nov 2005

Jormungand zei:
Vind ik dus ook.

@fretn
Jij vergeet gewoon een van de belangrijkste concepten die OO bieden. Namelijk encapsulation en information hiding. Dat zijn zeer belangrijke concepten.
Je non-OO versie van je voorbeeld heeft dit niet, maw jij als ontwerper van je camara "object" heeft geen controle meer omdat gewoon iedereen met x en y kan doen wat hij wil, ook dingen die fout zijn! En die foute dingen kunnen zeer subtiel zijn, en dus ook zeer moeilijk te detecteren/debuggen. Jou concept in de non-OO versie van een camera is veel minder gedefinieerd. Hoe kan jij nu garanderen dat jou camera concept correct zal werken, als iedereen ermee kan doen wat hij/zij wil?! Dan kan jij helemaal NIET. Laat staan om een invariant te garanderen!
Daarom ga is eveneens niet met jou akkoord, helemaal niet zelfs, ik vind het onzin. De OO versie van de camera class heeft niets dan voordelen, het draait even snel als de C versie, het concept is zeer goed gedefinieerd en kan zijn eigen regels vastleggen (data private), initalisatie is gegarandeerd door constructors, moet ik nog verder gaan met de voordelen op te sommen (ik weet er nog een deel)? Ik kan helemaal geen nadeel vinden hoor. Misschien weet jij er wel, laat ze maar komen...

je kan (uit gameprogging view) wel degelijk aan overerving doen. Stel dat jij extra camera's wil maken om naar textures te renderen. Je kan natuurlijk altijd de basisklasse gebruiken en alles juist instellen, je kan ook een afgeleide klasse maken die onmiddelijk alle functionaliteit in zich heeft zodat je de volgende keer maar even werkt hebt om weer zo een camera te maken

.
Het lijkt mssch stom vb hier, maar als ik iets programmeer is dat meestal met in het achterhoofd de gedachte dat ik dat wel eens zwaar zou kunnen uitbreiden en dan val je onverbiddelijk terug op OOP

.

Maar ik begrijp fretn's standpunt wel, beste om het op toe te passen is imho de webscripttaal PHP. Daar is onlangs OOP ook veel populairder geworden met als resultaat dat vele mensen bijna ALLES in OOP schrijven. De mensen hier die ooit al deftig in php gewerkt hebben zullen weten dat het in dit geval eerder gaat over tijdsverspilling & onnodige oop coding aangezien vele aspecten van een site gewoon uniek zijn voor de site & geen uitbreiding/veralgemening mogelijk is

. Ik heb het hier over 95% v/d gewone sites, als je met ingewikkelde portaalsites, cms-systemen, ... gaat beginnen zal een OOP aanpak veel nodiger worden, maar dit zijn al grotere en "algemenere" projecten.

Om jormungand aan te vullen, 1 v/de belangerijste zaken in mijn ogen van php is de dynamiek die het aan je code geeft. De mogelijkheid tot uitbreidingen en hergebruik, die bij het procedurale programmeren veel minder was

(ik zeg niet dat ze onmogelijk was he

).

wlibaers · 3 nov 2005

Jormungand zei:
Vind ik dus ook.

@fretn
Jij vergeet gewoon een van de belangrijkste concepten die OO bieden. Namelijk encapsulation en information hiding. Dat zijn zeer belangrijke concepten.

Niet noodzakelijk. De C++/Java variant van OOP, ja, niet in het algemeen.
http://www.paulgraham.com/reesoo.html
http://www.paulgraham.com/noop.html

Persoonlijk denk ik dat OOP vooral gunstig is voor GUI werk. Op andere gebieden is het iets minder duidelijk hoe voordelig het is/of het voordelig is. Zoals in bovenstaande links vermeld kan de omgeving waarin men werkt hier ook veel belang hebben.

C code kan trouwens ook zeer goed zijn,
http://www.cs.princeton.edu/software/cii/

azerty · 3 nov 2005

'K heb de indruk dat men hier denkt dat ik tegen OOP ben of vind dat OOP slecht is. Dat zal waarschijnlijk wel aan mij liggen dan...
Neen, het enigste wat ik wou overmaken is dat OOP niet ALTIJD DE oplossing is en men telkens opnieuw de overweging moet maken, want dat loont soms de moeite, zeker als je de volledige levenscyclus in 't oog houdt.

Het principe achter code-hiding (getters, setters, private, public,...) brengt soms op, maar neemt sowieso meer tijd om te proggen en maakt de leesbaarheid vd code moeilijker.
Het heeft z'n voor EN nadelen. 'K krijg de indruk dat je hier niet mag spreken over de nadelen van een populaire manier van denken... (zelfs al zijn er meestal meer voor dan nadelen)

Jormungand · 3 nov 2005

Niet noodzakelijk. De C++/Java variant van OOP, ja, niet in het algemeen.
http://www.paulgraham.com/reesoo.html
http://www.paulgraham.com/noop.html

Ik heb het ook niet over wannabee OO taaltjes. Wel over echte OO talen zoals C++, Java, C#, Smalltalk, etc. Neem vooral de 'goede' raad van Mr. Paul aan. Ik heb een poging gedaan om die man zijn teksten te lezen, ik ben gestopt omdat er gewoon zever in staat.

C code kan trouwens ook zeer goed zijn,

Heb ik ooit ergens geschreven of de indruk gegeven dat C per definitie slecht is? Heb ik nooit gezegd en zal ik ook nooit zeggen. Het probleem is dat de meeste C code SLECHT GESCHREVEN IS. En dit omdat C een structured programming taal is. Dit boek beschrijft inderdaad goede coding style, hier wordt gebruik gemaakt van de concepten die ik reeds eerder aanhaalde, namelijk encaptulation en data-hiding. Dit gebeurt door goed uitgedachte interfaces naar de buitenwereld toe, interne data blijft altijd intern en zal men het handle principe hanteren om deze data te kunnen manipuleren. Enkel zo kan je veilige software garanderen die jij als ontwikkelaar onder controle hebt en enkel zo bekomt men herbruikbare modules. Wordt nu even wakker, dit zijn nu juist die belangrijke concepten die OOP u probeert voor te knabbelen en zulk een stijl is ook makkelijker in OO talen omdat deze er nu juist voor ontworpen zijn. Jij spreekt voor een stuk jezelf tegen. C vind ik bv. goed voor een DLL interface te maken, daar gebruikt ik het ook nog voor. Maar intern in deze DLL is het een OO architecture. OOP laat je meer nadenken over de concepten in het probleem domein, en laat ook op een veel natuurlijkere wijze toe om deze te beschrijven.

Jormungand · 3 nov 2005

Neen, het enigste wat ik wou overmaken is dat OOP niet ALTIJD DE oplossing is en men telkens opnieuw de overweging moet maken, want dat loont soms de moeite, zeker als je de volledige levenscyclus in 't oog houdt.

Ik ben er zeker van dat jij ook wel nut ziet in OOP, maar met bovenstaande quote ben ik niet akkoord. Zelfs voor kleine projecten is OOP nuttig, OOP is imho altijd nuttig. In kleine projecten zijn er altijd stukken die misschien nog ergens anders hun nut kunnen bewijzen. Daarom, gebruik OOP en code for reuse and change.

Er zijn natuurlijk grenzen en ik ben de laatste om te beweren dat dit niet zo is. Met OO kan je heel ver gaan, en maar blijven designen. Dan verhoog je de complexiteit aanzienlijk, zonder veel nut. Dat is een feit. Maar hier moeten dingen worden afgewogen. Dit is nu juist het essentiele verschil tussen een goed, ervaren architect met eentje die minder ervaren is. Die met de ervaring heeft een soort van zesde zintuig opgebouwd om te kunnen voorspellen waar de herbruikbare dingen kunnen zijn en de dingen die hoogst waarschijnlijk zullen gaan veranderen in de toekomst.

Het principe achter code-hiding (getters, setters, private, public,...) brengt soms op, maar neemt sowieso meer tijd om te proggen en maakt de leesbaarheid vd code moeilijker.
Het heeft z'n voor EN nadelen. 'K krijg de indruk dat je hier niet mag spreken over de nadelen van een populaire manier van denken... (zelfs al zijn er meestal meer voor dan nadelen)

Ik weet niet hoe uw coding style is dan hoor maar voor mij wordt de code juist duidelijker. Ik vind het 'meer tijd om te proggen' argument totaal bullshit. Ik pleit voor duidelijke, leesbare, veilige en correcte code. En vooral die twee laatste zijn veel moeilijker te bekomen in een structured programming style om redenen die ik reeds aanhaalde in een andere post. De twee eerste zijn meestal ook ver zoek...

Je mag zeker de voor- en nadelen bespreken (en die nadelen zijn er ook), ik ga gewoon niet akkoord met de stellen dat OOP gewoon een 'populair' iets is en dat het niet voor ieder project geschikt is. Een class met een goed design schrijven is voor mij niet meer werk dan een C variant met bijbehorende functies ervan maken. De C variant heeft echter belangrijke nadelen tov. de OO variant, waarvan ik er al een deel heb beschreven in andere posts.

fretn · 3 nov 2005

Jormungand zei:
Vind ik dus ook.

@fretn
Jij vergeet gewoon een van de belangrijkste concepten die OO bieden. Namelijk encapsulation en information hiding. Dat zijn zeer belangrijke concepten.
Je non-OO versie van je voorbeeld heeft dit niet, maw jij als ontwerper van je camara "object" heeft geen controle meer omdat gewoon iedereen met x en y kan doen wat hij wil, ook dingen die fout zijn! En die foute dingen kunnen zeer subtiel zijn, en dus ook zeer moeilijk te detecteren/debuggen. Jou concept in de non-OO versie van een camera is veel minder gedefinieerd. Hoe kan jij nu garanderen dat jou camera concept correct zal werken, als iedereen ermee kan doen wat hij/zij wil?! Dan kan jij helemaal NIET. Laat staan om een invariant te garanderen!
Daarom ga ik eveneens niet met jou akkoord, helemaal niet zelfs, ik vind het onzin. De OO versie van de camera class heeft niets dan voordelen, het draait even snel als de C versie, het concept is zeer goed gedefinieerd en kan zijn eigen regels vastleggen (data private), initialisatie is gegarandeerd door constructors, moet ik nog verder gaan met de voordelen op te sommen (ik weet er nog een deel)? Ik kan helemaal geen nadeel vinden hoor. Misschien weet jij er wel, laat ze maar komen...

verklaar u nader ivm "verkeerd werken".

en in een niet OO versie kan je evengoed regels vastleggen ... initialisatie is niet gegarandeerd, maar als iemand anders weet dat hij die camera moet initialiseren en hij doet het niet ... zijn probleem imo

en ivm doen met x wat ik wil in de OO versie, je kan toch die class aan overerven en zo terug x gaan manipuleren ?

(en gebruik wat meer newlines want het is moeilijk om lezen zonder)

killgore: uw php voorbeeld is een veel beter voorbeeld dan m'n camera ding hier
ivm meerdere camera's defineeren, dit is perfect mogelijk zonder OO

disclaimer: het is meer dan vier jaar geleden dat ik echt in OO geprogged heb, dus ik ben veel van de termen en mogelijkheden vergeten maar in die vier jaar tijd heb ik nooit het gevoel gehad van, damn hiervoor MOET ik volgens OO principes programmeren

OO is volgens mij overroepen maar dit wil niet zeggen dat het slecht is, ik kan me gewoon niet vinden in die manier van denken

Jormungand · 3 nov 2005

en in een niet OO versie kan je evengoed regels vastleggen ... initialisatie is niet gegarandeerd, maar als iemand anders weet dat hij die camera moet initialiseren en hij doet het niet ... zijn probleem imo

Jij kan geen regels vastleggen omdat, in jou voorbeeld, x en y gewoon door eenderwie kunnen gemanipuleerd worden. Niets verhinderd de gebruiker om dit te doen.

Het argument 'als iemand anders weet dat hij die camera moet initialiseren en hij doet het niet ... zijn probleem' is gewoon bullshit. Kan jij van jezelf garanderen dat je het NOOIT zal vergeten te doen? Ik in ieder geval niet, ik ben maar een gewone sterveling die fouten maakt. Met zo een manier van denken zal je zeer veel lange debug sessies moeten ondergaan, en het is niet een kwestie van 'of' dat wel zou gebeuren, neen, meer van 'wanneer'. Gebeuren zal het.

Er is zoiets als defensief programmeren weet je wel, de hoogste prioriteit ligt hier bij leesbare en zo correct mogelijke code, code die het de gebruiker moeilijk maakt om iets verkeerd te doen. Dat is zeer belangrijk. Vergeet niet dat zulke code veel makkelijker te debuggen is, te testen, te onderhouden en te optimaliseren. Geoptimaliseerde code die zogezegd 'slim' geschreven is vanaf het begin, is juist veel moeilijker om correct te krijgen!

Jou mening is hetzelfde als zeggen "Ik bouw geen leuning aan mijn terras, op de 5de verdieping, om kosten te besparen. Die wie eraf valt wist op voorhand dat hij niet te dicht bij de rand moest komen, dus is het zijn probleem.". Dat is dus ook bullshit.

en ivm doen met x wat ik wil in de OO versie, je kan toch die class aan overerven en zo terug x gaan manipuleren ?

Dit bewijst dus dat je inderdaad niet zit te liegen in je 'disclaimer':
Data dat private is kan zelfs niet gemanipuleerd worden door classes die overerven.

Hoe moet ik jou mening over OOP nu serieus nemen als je nog niet eens deftig de basis ervan weet? Je hebt zojuist bewezen dat je amper iets van OOP afweet. Alle respect, maar hou dan aub op met tegen OOP te argumenteren.

maar in die vier jaar tijd heb ik nooit het gevoel gehad van, damn hiervoor MOET ik volgens OO principes programmeren

Nogal logisch! Je weet gewoon niet wat de echte voordelen en mogelijkheden ervan zijn (de basis is zelfs nogal verstoft), hoe kan je dan dat gevoel hebben?

dJeez · 3 nov 2005

killgore zei:
Maar ik begrijp fretn's standpunt wel, beste om het op toe te passen is imho de webscripttaal PHP. Daar is onlangs OOP ook veel populairder geworden met als resultaat dat vele mensen bijna ALLES in OOP schrijven. De mensen hier die ooit al deftig in php gewerkt hebben zullen weten dat het in dit geval eerder gaat over tijdsverspilling & onnodige oop coding aangezien vele aspecten van een site gewoon uniek zijn voor de site & geen uitbreiding/veralgemening mogelijk is . Ik heb het hier over 95% v/d gewone sites, als je met ingewikkelde portaalsites, cms-systemen, ... gaat beginnen zal een OOP aanpak veel nodiger worden, maar dit zijn al grotere en "algemenere" projecten.

Code re-use is een goede zaak, OOP zorgt ervoor dat dat net iets makkelijker is, en de ene guestbook is - buiten wat frulletjes hier of daar - echt wel zo goed als identiek aan de andere, dus perfect in een makkelijk herbruikbare klasse te steken.

Het probleem is nu net dat de meeste mensen PHP op een ondoordachte manier gebruiken en hun PHP code tussen de HTML meppen, met alle gevolgen vandien (onderhoud dergelijke rommel maar eens). Dat is ten dele wel zo gegroeid doordat er een gebrek was aan een degelijk OO model in PHP4, pas sedert PHP5 kan je eigenlijk van OO spreken.

De toekomst voor PHP ziet er alvast goed uit, met het aangekondigde Zend PHP Framework (dat deel zal uitmaken van het PHP Collaboration Project).

Maar is OO dan dè wonderoplossing? Uiteraard niet, er zal ook steeds nood zijn aan procedurele en niet-procedurele talen. Voor het programmeren van eenvoudige toestellen (zoals een simpele scanner) is een OO aanpak doorgaans totaal overkill (voorzover je er al iets met OO op kan doen) en kan je beter met de oude, getrouwe en geteste procedurele aanpak blijven werken. Niet elk toestel heeft nl. een JVM of .NET CF (of iets gelijkaardigs) aan boord

.

wlibaers · 4 nov 2005

Jormungand zei:
Ik heb het ook niet over wannabee OO taaltjes. Wel over echte OO talen zoals C++, Java, C#, Smalltalk, etc. Neem vooral de 'goede' raad van Mr. Paul aan. Ik heb een poging gedaan om die man zijn teksten te lezen, ik ben gestopt omdat er gewoon zever in staat.

In de eerste link stond een lijst met mogelijke eigenschappen die op een of andere manier verbonden zijn met OO talen. Jij kiest er gewoon een bepaalde subset uit om de naam "echte" OO eraan te geven. Dat is geen inhoudelijk argument, gewoon het in het leven roepen van een eigen definitie om alternatieven te kleineren. Dat die groep van talen in de industrie veruit de meest gebruikte OO talen zijn betekent niet dat het de enige "echte" OO talen zijn.

Of zoals in het artikel al stond:
Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser.

Wat die "zever" betreft: eenvoudig te verklaren door de achtergrond van Graham. De Lisp programmeerstijl is nu eenmaal verschillend van die in de meer gangbare talen, zeker als de Lisp macro's gebruikt worden. Dat kan er inderdaad voor zorgen dat bepaalde zaken onlogisch lijken als je ze zou toepassen op de populaire talen van het moment. Dit zou nog duidelijker zijn als je bijvoorbeeld met een fan van Prolog zou praten over programmeren.

Heb ik ooit ergens geschreven of de indruk gegeven dat C per definitie slecht is? Heb ik nooit gezegd en zal ik ook nooit zeggen. Het probleem is dat de meeste C code SLECHT GESCHREVEN IS. En dit omdat C een structured programming taal is.

Ligt dat niet eerder aan slechte programmeurs?

Dit boek beschrijft inderdaad goede coding style, hier wordt gebruik gemaakt van de concepten die ik reeds eerder aanhaalde, namelijk encaptulation en data-hiding. Dit gebeurt door goed uitgedachte interfaces naar de buitenwereld toe, interne data blijft altijd intern en zal men het handle principe hanteren om deze data te kunnen manipuleren. Enkel zo kan je veilige software garanderen die jij als ontwikkelaar onder controle hebt en enkel zo bekomt men herbruikbare modules. Wordt nu even wakker, dit zijn nu juist die belangrijke concepten die OOP u probeert voor te knabbelen en zulk een stijl is ook makkelijker in OO talen omdat deze er nu juist voor ontworpen zijn. Jij spreekt voor een stuk jezelf tegen.

Wat gewoon aantoont dat je geen "echte" OO taal nodig hebt om aan OO te doen. Ofwel dat de goede concepten die lang voor de OO-hype bekend waren gewoon gerecupereerd worden door OO-liefhebbers (doctrinair: alleen OO is goed. Als in een pre-OO taal iets goeds gedaan werd, dan is dat alleen maar omdat het eigenlijk al OO was). Hangt ervan af hoe je het wil bekijken.

Niet dat OO slecht zou zijn hoor, integendeel, men heeft inderdaad een paar bekende goede technieken rechtstreeks in de basisfunctionaliteir van enkele talen gestopt. Wat me stoort aan OOP is vooral het fanatisme van sommige aanhangers (hetzelfde probleem dat je, in nog extremere vorm, ook bij sommige aanhangers van specifieke talen ziet, zoals C# vs. Java of Common Lisp vs. Scheme).

C vind ik bv. goed voor een DLL interface te maken, daar gebruikt ik het ook nog voor. Maar intern in deze DLL is het een OO architecture. OOP laat je meer nadenken over de concepten in het probleem domein, en laat ook op een veel natuurlijkere wijze toe om deze te beschrijven.

Dat heeft meer te maken met incompatibiliteiten in de ABI van DLL's dan met eigenschappen van OO denk ik (omdat de binaire object layout van compiler tot compiler kon verschillen, terwijl men voor C al snel per architectuur conventies kreeg).

Wat die concepten betreft: soms wel, soms niet. Soms zijn de concepten best abstract wiskundig uit te drukken, wat dan kan leiden tot een bewijsbaar correct programma, wat misschien makkelijker in Fortran te schrijven is als een reeks arraybewerkingen dan in Java. Hangt ervan af met welke concepten je precies werkt.

fretn · 4 nov 2005

Jormungand zei:
Jij kan geen regels vastleggen omdat, in jou voorbeeld, x en y gewoon door eenderwie kunnen gemanipuleerd worden. Niets verhinderd de gebruiker om dit te doen.

ik dacht in de richting van

static int blub;

fuction set_blub(int value)
{
blub = value;
}

en als je blub wil manipuleren vanuit een andere file moet je die set_blub gaan gebruiken

maar dit gelijkt dan al verdacht veel op een class met een getter en een setter

Jormungand zei:
Het argument 'als iemand anders weet dat hij die camera moet initialiseren en hij doet het niet ... zijn probleem' is gewoon bullshit. Kan jij van jezelf garanderen dat je het NOOIT zal vergeten te doen? Ik in ieder geval niet, ik ben maar een gewone sterveling die fouten maakt. Met zo een manier van denken zal je zeer veel lange debug sessies moeten ondergaan, en het is niet een kwestie van 'of' dat wel zou gebeuren, neen, meer van 'wanneer'. Gebeuren zal het.

dat is waar

Jormungand zei:
Er is zoiets als defensief programmeren weet je wel, de hoogste prioriteit ligt hier bij leesbare en zo correct mogelijke code, code die het de gebruiker moeilijk maakt om iets verkeerd te doen. Dat is zeer belangrijk. Vergeet niet dat zulke code veel makkelijker te debuggen is, te testen, te onderhouden en te optimaliseren. Geoptimaliseerde code die zogezegd 'slim' geschreven is vanaf het begin, is juist veel moeilijker om correct te krijgen!

Jou mening is hetzelfde als zeggen "Ik bouw geen leuning aan mijn terras, op de 5de verdieping, om kosten te besparen. Die wie eraf valt wist op voorhand dat hij niet te dicht bij de rand moest komen, dus is het zijn probleem.". Dat is dus ook bullshit.

Dit bewijst dus dat je inderdaad niet zit te liegen in je 'disclaimer':
Data dat private is kan zelfs niet gemanipuleerd worden door classes die overerven.

Hoe moet ik jou mening over OOP nu serieus nemen als je nog niet eens deftig de basis ervan weet? Je hebt zojuist bewezen dat je amper iets van OOP afweet. Alle respect, maar hou dan aub op met tegen OOP te argumenteren.

Nogal logisch! Je weet gewoon niet wat de echte voordelen en mogelijkheden ervan zijn (de basis is zelfs nogal verstoft), hoe kan je dan dat gevoel hebben?

Gelijk heb je, ik zal als ik er de tijd voor heb mijn 'schoolboeken' over OO eens van onder het stof halen en m'n mening over OO herzien

mijn excuses voor eventuele (nieuwe) grijze haren

Jormungand · 4 nov 2005

Gelijk heb je, ik zal als ik er de tijd voor heb mijn 'schoolboeken' over OO eens van onder het stof halen en m'n mening over OO herzien

mijn excuses voor eventuele (nieuwe) grijze haren

Geen probleem hoor, ik ben blij dat je eindelijk tenminste open staat ervoor. Je zal zelf wel ontdekken dat er OOP beter is. Ik wil hiermee niet zeggen dat jij per definitie slechte code schrijft hoor, in OOP kan je nog betere code schrijven, op voorwaarde dat je OOP niet verkeerd toepast he!

fretn · 4 nov 2005

Jormungand zei:
Geen probleem hoor, ik ben blij dat je eindelijk tenminste open staat ervoor. Je zal zelf wel ontdekken dat er OOP beter is. Ik wil hiermee niet zeggen dat jij per definitie slechte code schrijft hoor, in OOP kan je nog betere code schrijven, op voorwaarde dat je OOP niet verkeerd toepast he!

ik sta voor alles open, men moet enkel me op een duidelijke manier kunnen aantonen waarom ik het evt zou gebruiken en waarom het beter is dan hetgeen ik nu gebruik

in school moesten we voor bepaalde dingen in OO werken terwijl ik toen vond (en nu nog altijd eigenlijk) dat ik dat evengoed in niet OO kon programmeren, geen enkele van de leraars zei dan ook ooit waarom de oplossing beter in OO was dan in niet OO

Jormungand · 4 nov 2005

In de eerste link stond een lijst met mogelijke eigenschappen die op een of andere manier verbonden zijn met OO talen. Jij kiest er gewoon een bepaalde subset uit om de naam "echte" OO eraan te geven. Dat is geen inhoudelijk argument, gewoon het in het leven roepen van een eigen definitie om alternatieven te kleineren. Dat die groep van talen in de industrie veruit de meest gebruikte OO talen zijn betekent niet dat het de enige "echte" OO talen zijn.

Er zijn wel degelijk duidelijk gedefinieerde regels waaraan een taal moet voldoen om als een OOP taal door het leven te kunnen gaan. De talen die ik opnoemde voldoen aan deze eisen met glans. Het is bv. niet zo dat indien een taal het concept van een class ondersteund, dat deze daarom ook aanzien kan worden als een echte volwaardige OOP taal.

Of zoals in het artikel al stond:
Because OO is a moving target, OO zealots will choose some subset of this menu by whim and then use it to try to convince you that you are a loser.

Bullshit. Ik heb hier nooit zitten zeggen dat niet-OO programmeurs per definitie slechts zijn, of sterker nog, losers zijn. De autheur van dat artikel moet nog volwassen worden.
Er kan inderdaad goede code in C (bv.) geschreven worden, maar die begint al heel sterk te lijken op het concept van classes, dus waarom toch blijven volharden en het uzelf moeilijker (blijven) maken?

Wat die "zever" betreft: eenvoudig te verklaren door de achtergrond van Graham. De Lisp programmeerstijl is nu eenmaal verschillend van die in de meer gangbare talen, zeker als de Lisp macro's gebruikt worden. Dat kan er inderdaad voor zorgen dat bepaalde zaken onlogisch lijken als je ze zou toepassen op de populaire talen van het moment. Dit zou nog duidelijker zijn als je bijvoorbeeld met een fan van Prolog zou praten over programmeren.

Populaire talen van het moment? C++ is een taal die er al van 1983 bestaat.
Begin dus niet te beweren dat die een populair taaltje van het moment is he. C++ is een volwassen taal, met zeer krachtige features. En tot op vandaag, met alle concurentie die ze krijgt van bv. Java, C# en zelfs VB.NET staat deze taal nog steeds zeer sterk. En ik wil hiermee ook niet zeggen dat die andere talen niet deugen (allee behalve VB dan

).

Ligt dat niet eerder aan slechte programmeurs?

Zie het gelijk je wil, het is gewoon een feit dat veel legacy C code een grote mesthoop is. En dit heeft vooral te maken met (1) de ervaring van de programmeur, (2) dat een structured programming language een andere denkwijze in gang zet, met vaak dit verschrikkelijke resultaat.

Wat gewoon aantoont dat je geen "echte" OO taal nodig hebt om aan OO te doen. Ofwel dat de goede concepten die lang voor de OO-hype bekend waren gewoon gerecupereerd worden door OO-liefhebbers (doctrinair: alleen OO is goed. Als in een pre-OO taal iets goeds gedaan werd, dan is dat alleen maar omdat het eigenlijk al OO was). Hangt ervan af hoe je het wil bekijken.

Dat is weer zo een argument dat nergens op trekt. Je vergeet polymophism, een zeer belangrijk concept in OOP. En ja dat kan je ook nabootsten in C als je dat wil, ik zeg het al maar in jou plaats, maar dan ben je het jezelf wel zeer moeilijk aan't maken. Dat noem ik dan pas 'tijd verspillen'.

Wat me stoort aan OOP is vooral het fanatisme van sommige aanhangers (hetzelfde probleem dat je, in nog extremere vorm, ook bij sommige aanhangers van specifieke talen ziet, zoals C# vs. Java of Common Lisp vs. Scheme).

Wat ik dus zeker van jou ook kan zeggen. Je wil basis OOP technieken toepassen in bv. C. (Jou woorden: "Wat gewoon aantoont dat je geen "echte" OO taal nodig hebt om aan OO te doen."). Maar je wil zeker niet dit doen met een echte OOP taal

. Dat noem ik nu eens koppig zijn en het uzelf moeilijk maken, of met jou woorden 'fanatisme'.

C vind ik bv. goed voor een DLL interface te maken, daar gebruikt ik het ook nog voor. Maar intern in deze DLL is het een OO architecture. OOP laat je meer nadenken over de concepten in het probleem domein, en laat ook op een veel natuurlijkere wijze toe om deze te beschrijven.

Klik om te vergroten...

Dat heeft meer te maken met incompatibiliteiten in de ABI van DLL's dan met eigenschappen van OO denk ik (omdat de binaire object layout van compiler tot compiler kon verschillen, terwijl men voor C al snel per architectuur conventies kreeg).

Neen, dat heeft alles te maken met name mangling (of name-decoration) van een funtctie door de compiler. Bij C is dit simpel en heeft dus ook vaste regels. DLL's gecompileerd met de ene compiler zijn dus compatible voor een andere compiler (op voorwaarde dat ze de C standaarden handhaven.). Bij C++ is het probleem veel moeilijker omdat C++ oa. function overloading kent en dergelijke (er zijn nog vele andere problemen zoals namespaces, etc, etc). Men kan hier dus niet zomaar een simpel standaard name mangling scheme vastleggen. Met als gevolg dat er geen standaard is, en compiler uitgevers eigen schemes hebben. Als nadeel heeft dit natuurlijk dat dll's met c++ linkage niet gebruikt kunnen worden met verschillende compilers, soms zelfs niet met verschillende versies van dezelfde uitgever. Daarom vind ik C nuttig om DLL interfaces te maken. Dan kan ik als ik een paar regels in acht neem deze zelfs voor iemand die VB gebruikt ter beschikking stellen. Er zijn wel technieken om het C++ probleem op te lossen en er is ook zo iets als COM DLL's. Die zijn binair standaard.

Wat die concepten betreft: soms wel, soms niet. Soms zijn de concepten best abstract wiskundig uit te drukken, wat dan kan leiden tot een bewijsbaar correct programma, wat misschien makkelijker in Fortran te schrijven is als een reeks arraybewerkingen dan in Java. Hangt ervan af met welke concepten je precies werkt.

Ik spreek dan van een algorithm, dat kan men inderdaad perfect op een wiskundige manier beschrijven, als jij dat al een 'programma' noemt dan begin ik mij af te vragen of jij wel al eens aan 'echte' software hebt gewerkt?

Jormungand · 4 nov 2005

fretn zei:
geen enkele van de leraars zei dan ook ooit waarom de oplossing beter in OO was dan in niet OO

Ik hoop dat ik voor een stukje, voor jou, die vraag heb kunnen beantwoorden...

fretn · 4 nov 2005

Jormungand zei:
Ik hoop dat ik voor een stukje, voor jou, die vraag heb kunnen beantwoorden...

daarom dat ik ook mijn mening eens ga herzien

Archief - [ALG] hoe verder gaan

Jormungand

Legacy Member

azerty

Legacy Member

Unzip Attack

Legacy Member

fretn

Legacy Member

Jormungand

Legacy Member

killgore

Legacy Member

wlibaers

Legacy Member

azerty

Legacy Member

Jormungand

Legacy Member

Jormungand

Legacy Member

fretn

Legacy Member

Jormungand

Legacy Member

dJeez

Legacy Member

wlibaers

Legacy Member

fretn

Legacy Member

Jormungand

Legacy Member

fretn

Legacy Member

Jormungand

Legacy Member

Jormungand

Legacy Member

fretn

Legacy Member