[ALG] OO Programmeren in procedurerele taal

[NMe]

Modbreak:

Topic is afgesplitst van Wat kan ik het beste leren

whoami schreef op zaterdag 19 maart 2005 @ 19:09:
Dat is een beetje kwatsch, want in C programmeer je procedureel, en in C++ kan je OO programmeren en in Java programmeer je OO.

Dat is ook een beetje kwatsch ben ik bang. In C kun je prima volgens OO-principes programmeren door gebruik van structs, en wanneer je je spul insuleert is het zelfs mogelijk om delen van je code private te maken. Het is waar dat je niet volledig OO kan werken, en het in het beste geval alleen OO benadert, maar in veel gevallen voldoet het prima. Aan de andere kant kun je in C++ ook weer puur procedureel programmeren. Java is dan weer een ander verhaal aangezien je daar altijd OO bezig bent.

whoami schreef op zaterdag 19 maart 2005 @ 20:00:
Dat is zo als je Delphi op de VB manier gebruikt ja. Echter, je kan Delphi ook op die manier gebruiken waarmee je toch op een betere manier gaat software gaan ontwikkelen.

Klik-en-sleep-werk voldoet voor veel programma's prima. Als ik mijn GUI via de IDE van Delphi in mekaar sleep, dan wil dat nog niet zeggen dat ik niet op een goeie manier software ontwikkel. Het kan een vervelend onderdeel van het programmeren wel een stuk makkelijker en prettiger maken, en daar zit de kracht van de IDE van Delphi.

[ Voor 35% gewijzigd door gorgi_19 op 30-03-2005 01:42 ]

[whoami]

-NMe- schreef op zaterdag 19 maart 2005 @ 21:05:
[...]

Dat is ook een beetje kwatsch ben ik bang. In C kun je prima volgens OO-principes programmeren door gebruik van structs, en wanneer je je spul insuleert is het zelfs mogelijk om delen van je code private te maken. Het is waar dat je niet volledig OO kan werken, en het in het beste geval alleen OO benadert

Dan werk je niet volgens het OO principe; om OO te kunnen werken, moet je minstens kunnen 'abstraheren', moet je kunnen inheriten, en moet je, dmv eenzelfde method signature aan te roepen, een verschillende functionaliteit kunnen tewerkstelligen ('polymorphisme).

maar in veel gevallen voldoet het prima.

Ik ben bang van niet. Zoals ik al gezegd heb, is OO wel meer dan wat data die bij elkaar hoort in een 'container' gooien, en dan bepaalde data te gaan encapsuleren.

Aan de andere kant kun je in C++ ook weer puur procedureel programmeren.

Dat had ik ook al gezegd.

Klik-en-sleep-werk voldoet voor veel programma's prima. Als ik mijn GUI via de IDE van Delphi in mekaar sleep, dan wil dat nog niet zeggen dat ik niet op een goeie manier software ontwikkel.

Ik heb het ook daar niet over; je zou moeten gek zijn als je -in Delphi, of in ieder andere IDE waar je die functionaliteit tot je beschikking hebt- je GUI niet dmv drag "n drop in elkaar sleept.
Ik had het echter over het 'aaneen lijmen van de componenten' dmv drag 'n drop, hier en daar wat properties instellen, hier en daar een lijntje code schrijven in één of andere event-handler, en hoppa.
Op die manier ben je niet bezig met programmeren.

[ Voor 26% gewijzigd door whoami op 19-03-2005 21:17 ]

[Erkens]

whoami schreef op zaterdag 19 maart 2005 @ 21:15:
Dan werk je niet volgens het OO principe; om OO te kunnen werken, moet je minstens kunnen 'abstraheren', moet je kunnen inheriten, en moet je, dmv eenzelfde method signature aan te roepen, een verschillende functionaliteit kunnen tewerkstelligen ('polymorphisme).

is dat verplicht om object georienteerd te kunnen werken?

als ik een object (struct) "kast" hebt, dan ben ik enkel geinteresseerd in wat ik er mee kan (zooi in opbergen) niet dat ik er eventueel extra planken in kan maken, of af kan sluiten voor anderen.

[whoami]

Erkens schreef op zaterdag 19 maart 2005 @ 21:26:
[...]

is dat verplicht om object georienteerd te kunnen werken?

Inheritance, encapsulation, abstraction en polymorphisme zijn de pijlers van OO.
Het is juist inheritance en polymorphisme die de kracht zijn van OO.

Het is niet omdat je een struct (of record) kunt maken, dat je daarom OO bezig bent. Als dat het geval zou zijn, dan zou je in VB6 ook OO kunnen werken.

als ik een object (struct) "kast" hebt, dan ben ik enkel geinteresseerd in wat ik er mee kan (zooi in opbergen) niet dat ik er eventueel extra planken in kan maken, of af kan sluiten voor anderen.

Tja, en de kracht van OO is dus dat je bv een class 'Boekenkast', 'Kleerkast', 'andereKast' hebt, en dat die classes allemaal eenzelfde method 'BergOp(object)' hebben, en dat je dus die method gewoon kunt aanroepen op ieder type kast, en dat die kast dan zelf wel bepaalt hoe dat object moet opgeborgen worden.

[NMe]

whoami schreef op zaterdag 19 maart 2005 @ 21:15:
Ik heb het ook daar niet over; je zou moeten gek zijn als je -in Delphi, of in ieder andere IDE waar je die functionaliteit tot je beschikking hebt- je GUI niet dmv drag "n drop in elkaar sleept.
Ik had het echter over het 'aaneen lijmen van de componenten' dmv drag 'n drop, hier en daar wat properties instellen, hier en daar een lijntje code schrijven in één of andere event-handler, en hoppa.
Op die manier ben je niet bezig met programmeren.

Ik zal niet op de eerste helft van je post ingaan, dat heeft Erkens al voor me gedaan. Hier wil ik wel even op reageren: ik kan me geen enkel programma indenken dat zo makkelijk in elkaar steekt, althans, niet iets waar iemand in het bedrijfsleven interesse in zou hebben, simpele voorbeelden als Notepad daargelaten. Ik ben het dan ook met je eens dat datgeen wat je noemt geen programmeren is, maar wanneer je die acties combineert in een inhoudelijk programma, dan is het dat wel degelijk, IMHO. Wanneer wat klik-en-sleep dat resultaat levert dat je nodig hebt, dan zul je nogal gek zijn als je dat gaat programmeren in code.

[whoami]

-NMe- schreef op zaterdag 19 maart 2005 @ 21:40:
[...]

Ik zal niet op de eerste helft van je post ingaan, dat heeft Erkens al voor me gedaan.

Tja, Erkens zijn post raakte imo dan ook niet echt de essentie.
Ik kan me niet voorstellen dat je, als je al enigszins serieus iets met OO gedaan hebt, zegt dat je in C ook OO kunt programmeren.
Veel mensen zien OO gewoon als 'data die bij elkaar hoort groeperen'. OO is wel meer dat dan dat.
Om even een simpel voorbeeld te geven, kan jij in C 2 simpele types maken, die afgeleid zijn van het type Werknemer (waarbij Werknemer een abstract type is); die 2 types die jij moet maken zijn 'Bediende' en 'Arbeider'.
Het loon van een bediende wordt op een andere manier berekend dan het loon van een arbeider.
Echter, ik heb bv een bedrijf waar ik 3 bedienden en 8 arbeiders tewerkstel. Ik wil één lijst hebben, waarop het loon staat van iedere werknemer.
Hoe ga je dat in C op een OO manier aanpakken ?

ik kan me geen enkel programma indenken dat zo makkelijk in elkaar steekt, althans, niet iets waar iemand in het bedrijfsleven interesse in zou hebben,

Ik denk - ik weet vrijwel zeker - dat er genoeg programma's bestaan die zo ontwikkelt zijn. Een wirwar van geklungel, dat leidt tot onbeheersbare code.

Wanneer wat klik-en-sleep dat resultaat levert dat je nodig hebt, dan zul je nogal gek zijn als je dat gaat programmeren in code.

En hoe zit het met de onderhoudbaarheid ? Aanpasbaarheid ? Uitbreidbaarheid ?

[ Voor 3% gewijzigd door whoami op 19-03-2005 21:54 ]

[NMe]

whoami schreef op zaterdag 19 maart 2005 @ 21:53:
Hoe ga je dat in C op een OO manier aanpakken ?

Zoals ik in mijn eerste post al zei: echt OO kan niet, maar je kan het benaderen. In het geval van inheritance en abstractie zul je dus wrapper functies moeten gebruiken. Dit doet echter niets onder voor de bewering die ik in mijn eerste post maakte: je kan volgens OO-principes werken. Dat je dat implementatiegewijs anders aanpakt, dat weet ik maar al te goed. Dat echt OOP veel fijner werkt, dat weet ik ook maar al te goed. Ik beweerde alleen dat een groot deel van de dingen die met OO mogelijk zijn, ook te simuleren zijn in procedurele talen.

Ik denk - ik weet vrijwel zeker - dat er genoeg programma's bestaan die zo ontwikkelt zijn. Een wirwar van geklungel, dat leidt tot onbeheersbare code.

En hoe zit het met de onderhoudbaarheid ? Aanpasbaarheid ? Uitbreidbaarheid ?

Ik zie het probleem hier niet echt...waarom zou een programma dat, waar mogelijk, door middel van klikken in elkaar is gezet, niet onderhoudbaar, aanpasbaar of uitbreidbaar zijn? Wanneer alles goed is gedocumenteerd, is er geen probleem.

[whoami]

-NMe- schreef op zaterdag 19 maart 2005 @ 22:17:
[...]

Zoals ik in mijn eerste post al zei: echt OO kan niet, maar je kan het benaderen. In het geval van inheritance en abstractie zul je dus wrapper functies moeten gebruiken. [

Dit doet echter niets onder voor de bewering die ik in mijn eerste post maakte: je kan volgens OO-principes werken. Dat je dat implementatiegewijs anders aanpakt, dat weet ik maar al te goed. Dat echt OOP veel fijner werkt, dat weet ik ook maar al te goed. Ik beweerde alleen dat een groot deel van de dingen die met OO mogelijk zijn, ook te simuleren zijn in procedurele talen.

Ben je OO bezig als je gewoon maar dingen gaat groeperen ?
Wat voor nut heeft het, als je dergelijke dingen met procedurele talen gaat gaan simuleren ? Waarom zou je dat dan uberhaupt willen simuleren ? Op die manier maak je je programma alleen maar ingewikkelder dan eenvoudiger.

Trouwens, wat heeft dat dan te maken met m'n initiele post waarop je reageerde ? Dat zou dan willen zeggen, als je de lijn doortrekt, dat je dan in C++ op dezelfde manier 'Object Oriented' gaat werken, zoals je dat zou gedaan hebben in C ?

Ik zie het probleem hier niet echt...waarom zou een programma dat, waar mogelijk, door middel van klikken in elkaar is gezet, niet onderhoudbaar, aanpasbaar of uitbreidbaar zijn? Wanneer alles goed is gedocumenteerd, is er geen probleem.

Jij hebt waarschijnlijk nog nooit zo'n programma -al is het goed gedocumenteerd- van xxxxxxx lijnen onder ogen gezien en moeten aanpassen/uitbreiden.

[NMe]

whoami schreef op zaterdag 19 maart 2005 @ 22:24:
Ben je OO bezig als je gewoon maar dingen gaat groeperen ?
Wat voor nut heeft het, als je dergelijke dingen met procedurele talen gaat gaan simuleren ? Waarom zou je dat dan uberhaupt willen simuleren ? Op die manier maak je je programma alleen maar ingewikkelder dan eenvoudiger.

Voor jezelf: ja. Voor iemand die je "objecten" later gaat toepassen in een programma echter niet. Die roept gewoon wat functies aan, en het werkt. Met die insteek programmeer je iets dergelijks. Hoe dat intern in elkaar zit met "inheritance" (struct-in-struct), dat maakt verder niet uit, daar heb je dan die wrapper functies voor.
Wat voor nut het heeft? Je benadert OO; je hebt dus een bepaalde manier van denken nodig om het te gebruiken. Verder is je code op deze manier beter geordend. Hoe dan ook, ik schrijf zelf niet graag dit soort code, maar in de Linux-wereld wordt het vaak toegepast. Misschien is er een Linux-programmeur die zijn licht hier eens over wil laten schijnen?

Trouwens, wat heeft dat dan te maken met m'n initiele post waarop je reageerde ? Dat zou dan willen zeggen, als je de lijn doortrekt, dat je dan in C++ op dezelfde manier 'Object Oriented' gaat werken, zoals je dat zou gedaan hebben in C ?

Nu ik het zo teruglees, kan ik me voorstellen dat die post zo overkomt. Ik doelde er echter alleen op te zeggen dat je een beetje zwart-wit tegen de zaak aankeek. Jouw post kwam over als "in C programmeer procedureel, C++ is hybride en Java is OO", terwijl de manier van programmeren juist de denkwijze bepaalt. Of het toepassen van OO-design in een procedurele taal wenselijk is laat ik maar in het midden, maar het wordt wel degelijk toegepast.

Jij hebt waarschijnlijk nog nooit zo'n programma -al is het goed gedocumenteerd- van xxxxxxx lijnen onder ogen gezien en moeten aanpassen/uitbreiden.

Jawel. Het beste voorbeeld dat ik heb was niet echt een geweldig groot programma, maar klein zou ik het ook niet willen noemen. Een vriend van me programmeert in Delphi een client voor een MUD, waar ik dan ook een deel van heb moeten schrijven. De code was ongedocumenteerd, maar an sich vrij duidelijk, mede ook door de namen van variabelen en objecten die gebruikt werden. Naamgeving en documentatie zijn wat dat betreft erg belangrijke dingen waar op gelet moet worden i.v.m. uitbreidbaarheid IMHO.

Aan de andere kant heb ik dan wel weer code gezien als het volgende:

Delphi:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
begin
  Button2.Enabled := false;
  Edit4.Text := 'blaat';
  Laadprocedure
end

Met naamgevingen als Button2 en Edit4 kom je er inderdaad lastig uit, heb ik toen gemerkt.

[whoami]

Weet je, ik heb helemaal geen zin meer in dit geneuzel.
Straks ga je me nog vertellen dat een kip een zoogdier is.

Over dat Delphi programmeren: ik heb ook niet gezegd dat je in Delphi zowiezo onbegrijpelijke code schrijft; ik zeg gewoon dat je het beter niet op de VB manier gebruikt.
Als je alles achter event-listeners gaat raggen, dan heb je gewoon een ononderhoudbare brei en ga je gegarandeerd bepaalde logica gaan dupliceren.

[Verwijderd]

Ik ben het met -NMe- eens. Een object-georiënteerde taal is niet vereist voor het maken van object-georiënteerde programma's. Alles wat je nodig hebt kun je prima 'nabouwen' met constructies uit procedurele talen, zelfs inheritance en polymorphisme. Dat kan ik zelfs bewijzen:

Elke taal die niet machinetaal is, moet (in één of meer stappen) vertaald worden naar machinetaal voordat hij uitgevoerd kan worden. Machinetaal is niet object-georiënteerd. Dat betekent dat alle object-georiënteerde talen na een N aantal vertaalslagen vertaald worden in een taal die niet object-georiënteerd is. Op dat niveau moeten alle OO constructies vertaald worden naar andere constructies in de niet object-georiënteerde taal. Er bestaat dus een taal die OO kan simuleren, en deze taal is procedureel.

En dan iets wat niet bij het bewijs hoort: grofweg zijn alle procedurele talen equivalent (niet helemaal waar, om OO te simuleren heb je wel degelijk iets als pointers nodig, dus BASIC valt af), dus ook in jouw favoriete taal kun je dit doen.

Voor de TS: Ik zou denk ik een taal zonder garbage collector kiezen om in te beginnen. Python is een heel erg mooie taal, en ik kan je hem van harte aanraden, maar als je begint te leren in Python/Java/C# en is de overstap naar een gecompileerde taal zonder garbage collection veel groter dan andersom, en kan nogal wat problemen opleveren omdat je je bezig moet houden met dingen die je niet gewend bent (geheugenbeheer dus).

[Alarmnummer]

Verwijderd schreef op zondag 20 maart 2005 @ 14:33:
Ik ben het met -NMe- eens. Een object-georiënteerde taal is niet vereist voor het maken van object-georiënteerde programma's. Alles wat je nodig hebt kun je prima 'nabouwen' met constructies uit procedurele talen, zelfs inheritance en polymorphisme. Dat kan ik zelfs bewijzen:

Elke taal die niet machinetaal is, moet (in één of meer stappen) vertaald worden naar machinetaal voordat hij uitgevoerd kan worden. Machinetaal is niet object-georiënteerd. Dat betekent dat alle object-georiënteerde talen na een N aantal vertaalslagen vertaald worden in een taal die niet object-georiënteerd is. Op dat niveau moeten alle OO constructies vertaald worden naar andere constructies in de niet object-georiënteerde taal. Er bestaat dus een taal die OO kan simuleren, en deze taal is procedureel.

Sorry maar dit is ronduit dikke onzin. Het kan zijn dat op het allerlaagste nivo geen onderscheid te maken is, maar dat is totaal irrelevant. Als jij object georienteerd wilt programmeren heb je vanuit de taal die features gewoon nodig... niks simuleren... Dit is dus wat er mis is met GoT..

Zometeen ga je me nog vertellen dat Prolog procedureel is en c declaratief..

[ Voor 6% gewijzigd door Alarmnummer op 20-03-2005 15:21 ]

[Verwijderd]

Alarmnummer schreef op zondag 20 maart 2005 @ 15:19:
[...]
Sorry maar dit is ronduit dikke onzin.

Wat dan? (Toegegeven, mijn bewijs was niet heel strak -- als je wilt wil ik het wel overnieuw proberen)

Het kan zijn dat op het allerlaagste nivo geen onderscheid te maken is, maar dat is totaal irrelevant.

Neen. Het punt is dat er een onderscheid is tussen de taal die je gebruikt en het paradigma dat je gebruikt. Die twee dingen zijn niet zomaar uitwisselbaar en het éne volgt niet automatisch uit het andere. Dat er een sterk verband kan bestaan zal ik verder niet ontkennen.

Als jij object georienteerd wilt programmeren heb je vanuit de taal die features gewoon nodig... niks simuleren...

Dat ben ik met je eens. Je wordt er niet vrolijk van om polymorphisme zelf te moeten maken. Het punt is dat het kán.

Dit is dus wat er mis is met GoT..

Ik denk dat je altijd spanningen krijgt als je "pragmatische programmeurs" met "theoretische programmeurs" mengt. En niet te vergeten een flinke dosis beginnende programmeurs die helemaal in de war raken van de tegenstrijdige meningen die rondgestrooid worden .

Zometeen ga je me nog vertellen dat Prolog procedureel is en c declaratief..

Moet je nu echt je toevlucht nemen tot sarcasme om een punt te maken? Dat wijst een beetje op een gebrek aan argumenten.

[SG]

Verwijderd schreef op zondag 20 maart 2005 @ 14:33:
Ik ben het met -NMe- eens. Een object-georiënteerde taal is niet vereist voor het maken van object-georiënteerde programma's. Alles wat je nodig hebt kun je prima 'nabouwen' met constructies uit procedurele talen, zelfs inheritance en polymorphisme. Dat kan ik zelfs bewijzen:

Ik zelf ben het meer met whoami eens.
C is totaal niet OO C++ ondersteund wat OO.
Java en C# zijn OO talen.
Tuurlijk kan je OO wrapping doen met C en ook C++ maar dat kost tijd en ik zie dat meer als work around extra werk dus.
Insuleren van C++objecten is leuk en aardig maar je bent meer iets aan het aanpassen om implementatie te laten voldoen aan een OO design.
Dit extra werk heeft een echte OO taal geen last van.

Ik zelf heb het book van UML naar C++ en daar schrik je toch wel van ja het is mogelijk maar geef mij maar 'n echte OO taal om die rompslomp te mijden.

Dit houd in dat als je een groot software OO project goed maintanable wilt hebben je de C++ implementatie moet aanpassen om aan het OO design te voldoen.
Een OO taal heeft daar juist geen last van.
In mijn ogen is een OO taal pas een OO taal als je een OO design 1 op 1 kan implementeren dus dat een Code Object of class ook 1 op 1 voldoet aan OO design. dus geen OO aanpassingen nodig voor consistentie tussen OO design en implementatie design.

Als je C of C++ gaat toepassen als OO taal, door het aantepassen aan true OO ben je eigenlijk grof gezien MS werk aan het doen wat tot C# leide.
Die tijd van die benodigde aanpassingen moet je bij je project tijd bijtellen en ook de kosten of van je deadline aftrekken en budged.
Zonde van tijd en geld.

Elke taal die niet machinetaal is, moet (in één of meer stappen) vertaald worden naar machinetaal voordat hij uitgevoerd kan worden. Machinetaal is niet object-georiënteerd. Dat betekent dat alle object-georiënteerde talen na een N aantal vertaalslagen vertaald worden in een taal die niet object-georiënteerd is. Op dat niveau moeten alle OO constructies vertaald worden naar andere constructies in de niet object-georiënteerde taal. Er bestaat dus een taal die OO kan simuleren, en deze taal is procedureel.

Je mist een heel belangrijk punt van true OO en elke stap naar een hogere orde taal vanaf machine taal en dat is time to markt. De reden dat men ASM niet meer gebruikt om een complete app mee te maken is tijd. aangezien dit 'n paar orde terug is kan je dit zo zien 'n app in C# die in één jaar er uitgeklopt is en opgeleverd kan worden heb je met asm 10 jaar nodig of is gewoon niet te doen ivm compexiteit.
Verschil tussen C++ OO en C#/java OO is een heel stuk kleiner maar nog steed relevant en voor grote projecten zeker belangrijk.

En dan iets wat niet bij het bewijs hoort: grofweg zijn alle procedurele talen equivalent (niet helemaal waar, om OO te simuleren heb je wel degelijk iets als pointers nodig, dus BASIC valt af), dus ook in jouw favoriete taal kun je dit doen.

Het kan, maar als je echt OO wil doen kan je beter een OO taal pakken dan een te simuleren want je bent dan veel tijd bezig met het simuleren van iets dat je bij de ander as_is al krijgt je kan je dan meer focusen op de applicatie logica.

[MrBucket]

SuperG schreef op zondag 20 maart 2005 @ 16:47:
[...]

Ik zelf ben het meer met whoami eens.
C is totaal niet OO C++ ondersteund wat OO.
Java en C# zijn OO talen.
Tuurlijk kan je OO wrapping doen met C en ook C++ maar dat kost tijd en ik zie dat meer als work around extra werk dus.
Insuleren van C++objecten is leuk en aardig maar je bent meer iets aan het aanpassen om implementatie te laten voldoen aan een OO design.
Dit extra werk heeft een echte OO taal geen last van.

Ik zelf heb het book van UML naar C++ en daar schrik je toch wel van ja het is mogelijk maar geef mij maar 'n echte OO taal om die rompslomp te mijden.

Waarom is C++ niet 'echt' OO, en wat bedoel je met "insuleren van objecten"?

Heeft iemand trouwens al gemerkt dat de TS alleen de openingspost heeft gemaakt, en voor de rest (volgens mij) is afgehaakt?

[Alarmnummer]

Verwijderd schreef op zondag 20 maart 2005 @ 16:30:
[...]

Wat dan? (Toegegeven, mijn bewijs was niet heel strak -- als je wilt wil ik het wel overnieuw proberen)

Het gaat niet om het bewijs dat je met een paradigma een ander paradigma kunt simuleren *moppelt iets over Turing compleet*. In de praktijk komt het erop neer dat je veel extra werk hebt en dat het vaak onplezierig aanvoelt. In java werk ik regelmatig met strategies maar in sommige gevallen zou ik liever een hogere orde functie hebben. In prolog ben ik soms allerlei 'procedurele' operatoren aan het implementeren om dat de standaard operatoren in Prolog mij niet op een prettige manier kunnen laten werken. Maar het eindresultaat is dat je vaak lelijke oplossingen hebt.. en daar gaat het om... hoe werkt het in de praktijk...

Dat ben ik met je eens. Je wordt er niet vrolijk van om polymorphisme zelf te moeten maken. Het punt is dat het kán.

Je kunt met een suikerklontjes ook een toren bouwen... maar niemand die dat gaat doen.. Jij geeft 'advies' die de topicstarter op het verkeerde been kan zetten. Als jij dit had gezegd in een topic waar iedereen goed thuis was in alle talen en paradigma`s.. prachtig.. maar dit is niet de goeie plek voor dit soort commentaar.

Ik denk dat je altijd spanningen krijgt als je "pragmatische programmeurs" met "theoretische programmeurs" mengt. En niet te vergeten een flinke dosis beginnende programmeurs die helemaal in de war raken van de tegenstrijdige meningen die rondgestrooid worden .

Precies.. en dat stoort mij dus aan GoT. Mensen geven te graag antwoord zonder rekening te houden met de gevolgen.

Moet je nu echt je toevlucht nemen tot sarcasme om een punt te maken? Dat wijst een beetje op een gebrek aan argumenten.

Ik laat je alleen zien dat jouw punt net zo slecht is als die van mij. Ik zet jouw opmerking in perspectief.

[ Voor 7% gewijzigd door Alarmnummer op 20-03-2005 17:17 ]

[Alarmnummer]

SuperG schreef op zondag 20 maart 2005 @ 16:47:
[...]

Ik zelf ben het meer met whoami eens.
C is totaal niet OO C++ ondersteund wat OO.

Nee.. C++ is net zo OO als Java of als C#. C++ is ook net zo procedureel als C. Je kunt C++ zien als een taal die 2 paradigma`s tegelijk ondersteunt. Dat maakt C++ niet minder een OO taal dan Java/C#. En het maakt C++ ook niet minder een procedurele taal dan C/Pascal.

[Verwijderd]

Eigenlijk hoef ik niet verder te reageren want, om in de onsterfelijke woorden van Balkenende te spreken, "we zijn het erover eens dat we het oneens zijn". Maar blijkbaar is mijn inbreng uit context gevallen en daar wil ik toch nog wel even op ingaan.

Alarmnummer schreef op zondag 20 maart 2005 @ 17:06:
[...]
Je kunt met een suikerklontjes ook een toren bouwen... maar niemand die dat gaat doen.. Jij geeft 'advies' die de topicstarter op het verkeerde been kan zetten.

Ho. Die opmerkingen waren nooit bedoeld als advies voor de topicstarter. Ik wou mezelf gewoon mengen in de lopende discussie (die we ook al vaker hebben gehad... hmmm, idee [1]). Misschien was het niet duidelijk genoeg, maar zoals je kunt zien stond in mijn oorspronkelijke post ook een paragraaf die uitdrukkelijk gemarkeerd was als wel bedoeld voor de TS, met gewoon praktisch advies en geen theoretisch gezwatel.

Als jij dit had gezegd in een topic waar iedereen goed thuis was in alle talen en paradigma`s.. prachtig.. maar dit is niet de goeie plek voor dit soort commentaar.

Hmm. Okee. Zie ook [1].

Precies.. en dat stoort mij dus aan GoT.

Ach. Zelf vind ik het wel mooi dat je meningen van allerlei verschillende perspectieven hoort. Al bestaat het nadeel dat sommige threads in een oeverloze discussie kunnen verzanden. Ik vind dat in elk geval zelf de interessantste threads, want de andere zijn van het type "Hoe doe ik dit in PHP" of "Mijn query werkt niet, help", met nihile discussiewaarde. Misschien is het een idee om een apart programmeerdiscussieforum in het leven te roepen?

[...]
Ik laat je alleen zien dat jouw punt net zo slecht is als die van mij. Ik zet jouw opmerking in perspectief.

Dat waardeer ik, want ik heb ook tegengas nodig als ik oeverloos begin te oreren. Maar ik zou het op prijs stellen als je het in perspectief plaatsen de volgende keer niet zou doen met

Alarmnummer schreef op zondag 20 maart 2005 @ 15:19:
(...) dit is ronduit dikke onzin.

^{_________ end of post ____________}

[1] Ik heb net een ideetje gekregen. Er zijn een paar onderwerpen die regelmatig ellenlange discussies uitlokken. Zo noem ik daar, Wel of niet OO in webpagina's?, String interpolation in PHP en nu weer Paradigma's en talen, en er zijn er vast wel meer te vinden waar ik zo even niet opkom. Is het geen plan om een aparte website te maken, waar iedereen over elk onderwerp zijn zegje kan doen (niet in threadvorm, want dan krijg je weer veel te veel pagina's om door te lezen, maar in essayvorm). Deze site kan dan gebruikt worden als referentie voor ieders mening over het onderwerp in kwestie, en we kunnen de (grotendeels vruchteloze) discussies uit het forum houden.

[NMe]

Alarmnummer schreef op zondag 20 maart 2005 @ 17:06:
Je kunt met een suikerklontjes ook een toren bouwen... maar niemand die dat gaat doen..

Niemand gaat inderdaad een toren bouwen van suikerklontjes. Maar, zoals ik al eerder zei, OO-design principes worden wel degelijk geïmplementeerd in procedurele talen. Zoals ik ook al eerder zei: het wordt in Linux verdomd vaak toegepast. De reden dat ze daar niet gewoon C++ gebruiken, is volgens mij dat het veel trager compileert.

Jij geeft 'advies' die de topicstarter op het verkeerde been kan zetten. Als jij dit had gezegd in een topic waar iedereen goed thuis was in alle talen en paradigma`s.. prachtig.. maar dit is niet de goeie plek voor dit soort commentaar.

Om te beginnen ben ik die discussie begonnen, niet OneOfBorg, dus val mij liever aan dan hem. Verder: er wordt van de mensen in dit forum verwacht dat ze een bepaald niveau hebben. Wanneer dit topic niet op deze discussie was uitgelopen, dan was het allang gesloten geweest, omdat het niveau niet hoog genoeg is. Ik ben het met je eens dat dit topic echter niet de goeie plaats is voor deze discussie, en daarom heb ik vanmiddag al een afsplitsing van dit topic gevraagd via een TR. Ik wacht nog op een modje die voorbij komt en dat leest.

Precies.. en dat stoort mij dus aan GoT. Mensen geven te graag antwoord zonder rekening te houden met de gevolgen.

Die gevolgen behoren in een forum als dit, waar iedereen een zeker niveau heeft, niet meer te zijn dan een aanzet tot nadenken. Niet meer, niet minder. Ik wil niet dat mensen zomaar dingen die ik roep voor waar aannemen, sterker nog, ik ben blij als mensen mijn punt onderuit proberen te halen, zoals whoami deed, en nu jij. Dat is het hele punt van een discussie: iedereen kan ervan leren. Zomaar dingen voor waar aannemen is echter nooit goed.

[NMe]

whoami schreef op zondag 20 maart 2005 @ 21:43:
In C# heb je geen pointers , en in Java ook niet. Echter, beiden zijn OO.

Feitelijk gezien hebben alle talen intern pointers, hoe wil je anders een string maken? Of gewoon een variabele in het algemeen? Ik ben bang dat dat al het zwakke punt van OOB's redenatie is, maar ik sta wel achter de rest van zijn verhaal.

[Verwijderd]

whoami schreef op zondag 20 maart 2005 @ 21:43:
In C# heb je geen pointers , en in Java ook niet. Echter, beiden zijn OO.

Eh, ja.

En wat dan nog?

Als je probeert het ongelijk van mijn bewering aan te tonen zul je toch met steekhoudende voorbeelden moeten komen.

Ik zei, om OO te simuleren heb je pointers nodig. Als je al in een OO omgeving zit hoef je niet te simuleren, en heb je dus geen pointers nodig.

_{Hoewel referenties intern nog steeds pointers zijn natuurlijk, je mag er alleen niet meer mee rekenen.}

edit:
Aaahhh, ik denk dat ik zie waar het probleem ligt: doordat ik zei dat je dit in BASIC niet zou kunnen doen denk jij dat ik VB bedoel. Mijn fout voor de onduidelijkheid, ik had het over klassiek BASIC van vrûûger.

-NMe- schreef op zondag 20 maart 2005 @ 21:51:
[...]
Feitelijk gezien hebben alle talen intern pointers

Natuurlijk, omdat alle gegevens opgeslagen worden in het geheugen, wat geindexeerd wordt met, juist, pointers. Maar eigenlijk is dat een implementatiedetail, en je hoeft dat niet altijd terug te zien in de taal.

[ Voor 88% gewijzigd door Verwijderd op 20-03-2005 22:01 ]

[whoami]

Verwijderd schreef op zondag 20 maart 2005 @ 21:53:
[...]


Eh, ja.

En wat dan nog?

Jij die zegt dat je pointers nodig hebt in een OO taal, en dat BASIC daarom geen OO taal is; echter VB.NET is dan wel weer OO.

[ Voor 18% gewijzigd door whoami op 20-03-2005 21:55 ]

[Daos]

whoami schreef op zondag 20 maart 2005 @ 21:43:
[...]

In C# heb je geen pointers , en in Java ook niet. Echter, beiden zijn OO.

Bij elk object en array werk je met pointers. Je ziet ze misschien niet, maar je heb er wel last van. Bijvoorbeeld als je een object of array meegeeft als argument bij een functieaanroep. Als je in de functie in je array of object gaat klussen, dan ziet de aanroeper dat ook.

Ander goed voorbeeld is inderdaad met strings.

Java:

char a = 'a';
char b = 'a';
// geeft waar
boolean x = a == b;

String a = "a";
String b = "a";
// geeft onwaar
boolean y = a == b;

Veel beginners snappen niet waarom de vergelijking van bv Strings niet goed gaat. In het tweede geval zijn a en b pointers naar een String-object. In a en b staat een ander adres en daarom geeft de == onwaar terug.

In C zie je dat veel duidelijker. C is dus een goede basis om mee te beginnen.

C:

char a = 'a';
char b = 'a';
// geeft waar
int x = a == b;

char *a = "a";
char *b = "a";
// geeft onwaar
int y = a == b;
// geeft waar (kijkt alleen naar eerste character)
int z = *a == *b;

Maar wat bedoeld wordt is als je OO in bv C wilt maken, dan heb je pointers nodig.
bijvoorbeeld
in Java:

Java:

class A{
  int i = 5;

  void m_A(int i) {
    this.i = i;
  }

  public static void main(String[] args) {
    A x = new A();
 
    system.out.println("i = " + x.i);

    x.m(3);
    system.out.println("i = " + x.i);
  }
}

wordt in C:

C:

typedef struct {
  int i;
} Class_A;

void m_A(Class_A *this, int i) {
  this->i = i;
}

int main() {
    Class_A x = {5};

    printf("i = %d\n", x.i);

    m_A(&x, 3);
    printf("i = %d\n", x.i);
}

[ Voor 32% gewijzigd door Daos op 20-03-2005 22:52 . Reden: Stukje met strings toegevoegd ]

[.oisyn]

Alarmnummer schreef op zondag 20 maart 2005 @ 15:19:
[...]

Sorry maar dit is ronduit dikke onzin. Het kan zijn dat op het allerlaagste nivo geen onderscheid te maken is, maar dat is totaal irrelevant. Als jij object georienteerd wilt programmeren heb je vanuit de taal die features gewoon nodig... niks simuleren...

Een applicatie kun je van de grond af ontwerpen met behulp van het OO paradigima. Daar komt geen regel code aan te pas, en op welke manier je die code vervolgens inklopt in je favoriete programmeertaal heeft daar geen zak mee te maken. Ik zal de laatste zijn die beweert dat OO in C "handig" is, feit blijft dat het kan en zelfs best goed kan.

Dit is dus wat er mis is met GoT..

Of met jezelf? Start anders een eigen forum (en aangezien ik de eindverantwoordelijke ben over de devschuur: mijn welgemeende excuses dat niet iedereen het met jou eens is, ik zal eens in de crew gooien om iedereen te bannen die het niet met jou eens is ).

.edit: oh, verdere posts lees ik waarschijnlijk niet meer aangezien ik morgenochtend naar California vertrek voor m'n werk, ben zaterdag weer terug. Just so you know

[ Voor 10% gewijzigd door .oisyn op 21-03-2005 18:08 ]

[Phyxion]

.oisyn schreef op maandag 21 maart 2005 @ 18:05:
[...]


Een applicatie kun je van de grond af ontwerpen met behulp van het OO paradigima. Daar komt geen regel code aan te pas, en op welke manier je die code vervolgens inklopt in je favoriete programmeertaal heeft daar geen zak mee te maken. Ik zal de laatste zijn die beweert dat OO in C "handig" is, feit blijft dat het kan en zelfs best goed kan.


[...]


Of met jezelf? Start anders een eigen forum (en aangezien ik de eindverantwoordelijke ben over de devschuur: mijn welgemeende excuses dat niet iedereen het met jou eens is, ik zal eens in de crew gooien om iedereen te bannen die het niet met jou eens is ).

.edit: oh, verdere posts lees ik waarschijnlijk niet meer aangezien ik morgenochtend naar California vertrek voor m'n werk, ben zaterdag weer terug. Just so you know

California

Iig, om toch even een inbreng hieraan te geven, zelf ben ik begonnen bij Java. En ik ben nu nog steeds bij Java Om hiermee te beginnen lijkt mij goed, er zijn veel boeken en informatie over te vinden

offtopic:
Ben benieuwd of de TS dit allemaal nog leest, nooit een reply...

[gorgi_19]

Modbreak:

Dit topic is een afsplitsing van Wat kan ik het beste leren

[NMe]

* NMe geeft gorgi_19 de grootste appel die hij ooit gezien heeft.

---

.oisyn schreef op maandag 21 maart 2005 @ 18:05:
Een applicatie kun je van de grond af ontwerpen met behulp van het OO paradigima. Daar komt geen regel code aan te pas, en op welke manier je die code vervolgens inklopt in je favoriete programmeertaal heeft daar geen zak mee te maken. Ik zal de laatste zijn die beweert dat OO in C "handig" is, feit blijft dat het kan en zelfs best goed kan.

Precies, en dat is waar ik naartoe wil. De ontwerpen die schuilgaan achter het objectgeoriënteerd programmeren zijn in een dergelijke mate toe te passen, dat het in principe in elke taal mogelijk is. Polymorphisme en abstracte "classes" zijn misschien lastig te maken, maar het is mogelijk. In C kun je bijvoorbeeld een struct maken voor de abstracte "class", en deze als member opnemen in een andere struct. Verder kun je, als je goed insuleert, zelfs zo werken dat niemand die dependancies te zien krijgt, en dat alles intern verborgen ligt.

Het werkt, zoals ik al eerder heb gezegd, en zoals .oisyn hierboven ook al vermeld heeft, niet optimaal, maar de principes zijn eenvoudig, en als je ze eenmaal hebt geleerd zijn ze heel makkelijk toe te passen. Voor een project waaraan ik nu werk is het ideaal. Hierin is objectgeoriënteerd programmeren echt een grote pré, omdat het alles gewoon veel makkelijker te modelleren en implementeren maakt, maar de omgeving waarin we moeten werken is Keil uVision 2.0 (programmeren voor microcontrollers), een omgeving waarin alleen C-code geprogrammerd kan worden. "Nep-OO" was echt een uitkomst. Ik zal het, als ik het kan vermijden, echt niet vrijwillig gebruiken, maar het kan gewoon een handig principe zijn.

[vinnux]

OO is een concept een denkwijze geen programeertaal.Net zoals UML een notatiewijze is een geen methode.
Uiteindelijk, zoals reeds gezegd, wordt alles omgezet naar 0en en 1en en het daarbijbehorrende geklooi met registers etc.
In elke programmeertaal is het dus mogelijk om op OO wijze te programeren.
Natuurlijk dwingt een taal als C niet af dat je in andersman geheugen kan klooien, maar dat betekent niet dat je niet volgens de principes van OO kunt programeren!
Als ik mij als programeur aan de OO regels houd kan ik in elke taal OO programeren, of deze taal dat nu afdwingt of niet.

[Verwijderd]

-NMe- schreef op woensdag 30 maart 2005 @ 02:00:
[...]
In C kun je bijvoorbeeld een struct maken voor de abstracte "class", en deze als member opnemen in een andere struct.
[...]

Zo doe je dat ook in C++:

C++:

typedef interface struct;

De eerste keer dat ik 't zag was ik shocked .

[NMe]

Verwijderd schreef op woensdag 30 maart 2005 @ 16:00:
Zo doe je dat ook in C++:

C++:

typedef interface struct;

De eerste keer dat ik 't zag was ik shocked .

Waarom? Dingen als dit worden ook vaak gedaan:

C:

typedef UINT unsigned;
typedef WORD short;

Enz. (Van die laatste ben ik niet zeker. )