[ALG] .NET: Geen Hungarian Coding meer! *sniff*

[Verwijderd]

De .NET library is opgezet met camelstyle vars (myFoo) en pascal style functions (FooBar()). Geen hungarian coding meer! Microsoft adviseert ook om camelstyle coding te gebruiken voor vars en Pascalstyle voor functies en constants.

Dit vind ik een verschrikking. Ik ben een van de zelfkastijders die een paar jaar terug hungarian coding heeft geadopteerd en er van is gaan houden, nu moet dat overboord! (Tuurlijk kun je doorbroddelen met je eigen style maar dat matcht dan niet met native taalelementen/library zaken).

Wat is er mis met m_siFoo; ? (membervariable van het type short int) Overal waar je die variabele gebruikt zie meteen wat voor type het is, code wordt inmens veel leesbaarder, nu moet men dit doen: myVar. Nou, wat voor type is dat? Moet je eerst de definitie opzoeken.. maar dat kost weer tijd.

Slechte zaak vind ik. Wat vinden jullie?

[D2k]

ff voor de n00bs (en voor mij )
WTF is hungarian coding?

[Verwijderd]

Op vrijdag 01 februari 2002 16:03 schreef D2k het volgende:
ff voor de n00bs (en voor mij )
WTF is hungarian coding?

Dat staat er toch bij Ik vond t ook wel duidelijk.

[Verwijderd]

Hungarian coding is de namingscheme, bedacht door een hongaar bij Microsoft, die een korte beschrijving van het type van de variabele vooraan de variabelenaam zet. Er zijn varianten opgemaakt overigens.

bv:

int iNummer;
char szName[10];

// global variable
int g_iFoo;

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/HungaNotat.asp

[Nielsz]

kamelenRulesz

[Rense Klinkenberg]

Op zich zou je als je aan het coden bent nog wel moeten weten welk type een var is.

Verder zie ik het verschil niet zo. Bij jouw manier moet je ook weten welk type een var heeft, omdat je anders de naam ervan niet eens kan weten, dus je moet dan ook nogsteeds dingen opzoeken.

[franklin]

hongaarse notatie ken ik wel en doorgaans programmeer ik ook wel zo... maar camel? perlstyle code ofzo? heb je niet wat linkjes? ik ben wel nieuwsgierig nu

[Verwijderd]

Dude, meesterlijk!!!
ik snapt er helemaal geen kloot van, maar ik ben dan ook echt een ONWIJZE n00b op dat gebied.
Ik wil het toch wel graag weten dus...

----
edit
----

oks, ik snap hem een heel klein beetje nu... tnx

[marcusk]

Op vrijdag 01 februari 2002 16:05 schreef Nielsz het volgende:
KamelenRulesz

kamelenRulesz bedoel je

zelf gebruik ik niet letters om het type aan te geven, maar wel m_ (member var) p_ (parameter) en g_ (global). en lokale variabelen zonder iets ervoor.

[Nielsz]

Op vrijdag 01 februari 2002 16:08 schreef franklin het volgende:
hongaarse notatie ken ik wel en doorgaans programmeer ik ook wel zo... maar camel? perlstyle code ofzo? heb je niet wat linkjes? ik ben wel nieuwsgierig nu

kamelenStartenElkOnderdeelVanEenFunctieMetEenNieuweHoofdLetterBehalveDeEersteThanxToMarcusk();

[whoami]

Hungarion notation heb ik eigenlijk al altijd overbodig gevonden. Wat voor nut heeft het nu eigenlijk om een prefix aan je variable-names te hangen die aangeeft om welk type het gaat? Een nummer, index of teller zal meestal wel een integer zijn, dus is het overbodig om er een i voor te zetten.
Als je goeie namen kiest voor je variables is het overbodig om hungarian te gaan gebruiken.

Wat wel handig kan zijn, is dat je een prefix aan uw variable hangt die de scope van die variable weergeeft.

Ik vind het een goed initiatief dat MS eindelijk van hun hungarian notation afstapt. (Was trouwens geintroduceerd door een hongaarse programmeur van MS)

[mulder]

Ja, ik heb dus het zelfde, policy hier is ook de camelshit, ben ook Hungarian gewend. Vind het minder duidelijk zo. Ach ja....

[Verwijderd]

Op vrijdag 01 februari 2002 16:11 schreef Nielsz het volgende:

[..]

kamelenStartenElkOnderdeelVanEenFunctieMetEenNieuweHoofdLetterBehalveDeEersteThanxToMarcusk();

inderdaadBehalveDeEerstePlusZeVermeldenGeenType(int javaStyleDus);

[whoami]

Het wil natuurlijk niet zeggen dat, omdat Microsoft zelf geen gebruik meer gaat maken van Hungarian en het ook afraad, dat jij er dan ook geen gebruik meer moet van maken.

[Mithrandir]

Op vrijdag 01 februari 2002 16:15 schreef whoami het volgende:
Het wil natuurlijk niet zeggen dat, omdat Microsoft zelf geen gebruik meer gaat maken van Hungarian en het ook afraad, dat jij er dan ook geen gebruik meer moet van maken.

Als jij in een project werkt werk je volgens regels...

[Verwijderd]

Maar waarom is microsoft omgeschakeld?

Ik begrijp wel dat je dezelfde stijl wilt gebruiken; dat doe ik ook met delphi; camelstyle dus

[Nielsz]

Ikzelf gebruik dus kamelenStyle. Verder als ik dingen hard define zet ik er meestal wel voor wat het is. Ik heb dus een queries.inc.php; waar ik dus alle queries in define =

QUERY_verderKamelenStyle



Maarja, PHP he

[whoami]

Op vrijdag 01 februari 2002 16:24 schreef DinoRaptor het volgende:

[..]

Als jij in een project werkt werk je volgens regels...

Idd, maar ga jij de codingstyle in een bestaand project gaan omgooien gewoon omdat MS nu zegt van geen hungarion meer te gebruiken?

Op vrijdag 01 februari 2002 16:24 schreef DiFool het volgende:
Maar waarom is microsoft omgeschakeld?

Ik begrijp wel dat je dezelfde stijl wilt gebruiken; dat doe ik ook met delphi; camelstyle dus

Omdat ze zelf ook inzagen dat die hungarian notatie geen steek hield... Misschien...

[Verwijderd]

*Lekker Belangrijk*

Kijk, mij maakt het niet uit waar ze voor kiezen, als ze het maar consequent aanhouden (waar MS nogal eens moeite mee heeft)

[Mithrandir]

Op vrijdag 01 februari 2002 16:30 schreef whoami het volgende:

[..]

Idd, maar ga jij de codingstyle in een bestaand project gaan omgooien gewoon omdat MS nu zegt van geen hungarion meer te gebruiken?
[..]

Omdat ze zelf ook inzagen dat die hungarian notatie geen steek hield... Misschien...

Niet middenin een project. Maar wel als je aan 'n nieuw project begint.

Verder gebruik ik altijd dingen_met_streepjes_onder, omdat dat veel lekkerder leest. (gelukkig hoef ik niet moeilijk te doen met Integers enzo, dat doet PHP wel voor me )

[Verwijderd]

DinoRaptor:Verder gebruik ik altijd dingen_met_streepjes_onder, omdat dat veel lekkerder leest.

Ik vind dus DingenMetStreepjesOnder veel makkelijker te lezen; maar het zal er wel aan liggen, wat je gewend bent

[mbravenboer]

whoami: Hungarion notation heb ik eigenlijk al altijd overbodig gevonden. Wat voor nut heeft het nu eigenlijk om een prefix aan je variable-names te hangen die aangeeft om welk type het gaat? Een nummer, index of teller zal meestal wel een integer zijn, dus is het overbodig om er een i voor te zetten.
Als je goeie namen kiest voor je variables is het overbodig om hungarian te gaan gebruiken.

Wat wel handig kan zijn, is dat je een prefix aan uw variable hangt die de scope van die variable weergeeft.

Ik vind het een goed initiatief dat MS eindelijk van hun hungarian notation afstapt. (Was trouwens geintroduceerd door een hongaarse programmeur van MS)

Ik kan een verhaal gaan tikken, maar ik sluit me hier volledig bij aan .

Kort samengevat mijn mening:
- Type is vaak al af te leiden uit de naam van een variabele, de betekenis van de variabele dus.
- Het leest niet prettig: code moet je als het ware doorheen kunnen lezen. Deze type informatie vind ik onprettig obstakels.
- Als je het type aanpast moet je het overal gaan aanpassen.
Code gaat er in het algemeen 'vriendelijker' uit zien vind ik.

Uiteraard zijn dit allemaal gewoon meningen .

Die scope vind ik ook wel aardig: Ik gebruik zelf bijvoorbeeld een _ voor instantie variabelen om ze te onderscheiden van lokale variabelen en parameters.

Verder vind ik al die suffeHoofdLetters eigenlijk ook niet prettig om te lezen. Er is een taal die geen - operatie kent en daar kan je daarom heerlijk zonder-suffe-hoofdletters werken . Om een of andere reden vind ik dat weer wel prettig en suffe_underscores_niet. Don't ask .

[Verwijderd]

Op vrijdag 01 februari 2002 16:11 schreef whoami het volgende:
Hungarion notation heb ik eigenlijk al altijd overbodig gevonden. Wat voor nut heeft het nu eigenlijk om een prefix aan je variable-names te hangen die aangeeft om welk type het gaat? Een nummer, index of teller zal meestal wel een integer zijn, dus is het overbodig om er een i voor te zetten.
Als je goeie namen kiest voor je variables is het overbodig om hungarian te gaan gebruiken.

Wat wel handig kan zijn, is dat je een prefix aan uw variable hangt die de scope van die variable weergeeft.

Ik vind het een goed initiatief dat MS eindelijk van hun hungarian notation afstapt. (Was trouwens geintroduceerd door een hongaarse programmeur van MS)

Ik ben het er helemaal mee eens dat de scope van een variabele altijd in één oogopslag bekend moet zijn.

Als je het nut van hungarian coding (of een andere variant) niet inziet dan komt dat doordat... (vul hier een reden naar keuze in) ... . Als je een beetje flinke applicatie bouwt met daarin heel veel waarden die functioneel gezien erg op elkaar lijken maar die van verschillende gegevenstypen zijn, is het een verademing om ze onmiddelijk van elkaar te kunnen onderscheiden.

Ook als je wil voorkomen dat je tech-fouten om je oren krijgt vanwege gegevenstypen die niet overeenkomen in complexe statements is het veel makkelijker om niet elke keer bij de declaratie te hoeven kijken "wat was dat ook al weer?"

[mbravenboer]

IJskoud: Als je het nut van hungarian coding (of een andere variant) niet inziet dan komt dat doordat... (vul hier een reden naar keuze in) ... .

Sorry maar ik ga geen reden invullen . In een goed OO design is deze notatie gewoon vaak overbodig naar mijn mening.

Als je een beetje flinke applicatie bouwt met daarin heel veel waarden die functioneel gezien erg op elkaar lijken maar die van verschillende gegevenstypen zijn, is het een verademing om ze onmiddelijk van elkaar te kunnen onderscheiden.

Ik werk toch af en toe wel aan een flinke applicatie

code:

compile:
    [javac] Compiling 452 source files to <knip>

maar ik heb die verademing nog nooit nodig gehad. Goede code is eenvoudige code: kleine methoden, kleine klassen. Daarin is genoeg overzicht zodat deze notatie niet nodig is

Ook als je wil voorkomen dat je tech-fouten om je oren krijgt vanwege gegevenstypen die niet overeenkomen in complexe statements

Complexe statements zijn foute statements .

[ACM]

Op vrijdag 01 februari 2002 17:02 schreef mbravenboer het volgende:
Complexe statements zijn foute statements .

Sommige dingen "moeten" complex, of je nou allerlei methode aanroepen op rij plaatst en daarbinnen weer allerlei methode aanroepen... etc

Of dat je het in een paar grote doet. Complex blijft de code toch

Probeer bijvoorbeeld maar een encryptie/decryptie stuk code te maken dat ook echt duidelijk is (in perl kan het vaak in 1 regel, maar ik ken weinig mensen die het binnen 5 minuten begrijpen eigenlijk geen een)
Of je nou veel of weinig methoden en classes gebruikt, de code blijft complex

[mbravenboer]

ACM: Sommige dingen "moeten" complex, of je nou allerlei methode aanroepen op rij plaatst en daarbinnen weer allerlei methode aanroepen... etc

Mwah, het enige waarvoor ik wil toegeven dat complex blijft zijn echt ingewikkelde wiskundige berekeningen of bit-ge-etter.

In alle andere gevallen zou je moeten abstraheren en je code verdelen over meer klassen of interfaces. Geef mijn maar 1 voorbeeld zonder zware rekenkundige zooi wat volgens jou complex moet .

Abstraheren via interfaces en gescheiden componenten is het allerbelangrijkste in een goed programma en zeker in een OO ontwerp. Als je dit goed doet, heb je naar mijn mening dus geen hongaarse methode meer nodig .

Of je nou veel of weinig methoden en classes gebruikt, de code blijft complex

Mwah, je kunt complexiteit verspreiden zodat de lokale complexiteit laag is. Voor globale complexiteit heb je geen hongaarse methode nodig, voor lokale complexiteit wel. Lokale complexiteit zou je echter moeten vermijden. Vind ik .

[ACM]

Op vrijdag 01 februari 2002 17:24 schreef mbravenboer het volgende:
In alle andere gevallen zou je moeten abstraheren en je code verdelen over meer klassen of interfaces. Geef mijn maar 1 voorbeeld zonder zware rekenkundige zooi wat volgens jou complex moet .

Lekker is dat, wilde ik terwijl ik juist net _dat_ bedoelde

Allerlei prachtige matrix berekeningen, lineaire solvers (alhoewel de "niet lineaire solvers" nog ingewikkelder zijn ) etc etc etc.

Ze zijn wel met allerlei losse methoden te doen, maar worden er niet minder complex van, vooral de ingewikkelder wiskundige varianten...

Zo zijn er nog erg veel dingen die behoorlijk complex kunnen zijn.

De meeste applicaties (wanneer heb je het over 'de meeste', is dat 'waar je zelf mee werkt'?) hoeven idd niet complex te zijn en dan kan je inderdaad (en gelukkig) wel redelijk goed een aardige "methode en klasse" structuur voor elkaar krijgen

[dusty]

Op vrijdag 01 februari 2002 16:06 schreef freak007 het volgende:
Op zich zou je als je aan het coden bent nog wel moeten weten welk type een var is.

Verder zie ik het verschil niet zo. Bij jouw manier moet je ook weten welk type een var heeft, omdat je anders de naam ervan niet eens kan weten, dus je moet dan ook nogsteeds dingen opzoeken.

Ehh. ik zie dt jij nog nooit een echt groot project hebt gemaakt ?

door hungarian kan je zien WELKE type variabele het is EN waar die variabele voor wordt gebruikt. Bij het andere weet je alleen waar hij voor wordt gebruikt. (en niet welke type, dat moet je dan weer herinneren of opzoeken) terwijl je bij hungarian een i kan zien en meteen kan weten: Integer!

[Verwijderd]

Iets is complex wanneer je niet begrijpt wat er gebeurt. Wiskunde is voor velen complex, maar voor wiskundigen die er helemaal in thuis zijn is het gesneden koek.

Ik ben het er absoluut niet mee eens dat je maar op de variabelenaam moet afgaan wat voor type een variabele heeft.

voorbeeld: LoginID.
Numeriek? Alphanumeriek? Wie zal het zeggen.

iLoginID zegt me dat het een integer is. szLoginID zegt me dat het een string is (alphanumeriek dus).

Het is IMHO het probleem niet erkennen door te zeggen dat je dmv classes e.d. het gemakkelijker maakt om te achterhalen wat voor type een variabele heeft. Het is juist MOEILIJKER om te achterhalen wat voor type een variabele heeft!

bv:

code:

CMyClass  myObject;

myObject.var1 = 1;
myObject.var2 = 1.0f;

Ik moet nu de definitie erbij halen van CMyClass. Heb ik helemaal geen zin in. Tuurlijk moet je weten waar je mee bezig bent, maar het gaat juist vaak om zaken zoals ints vs floats, waarbij je een int verwacht, maar men een float gebruikt ivm optimalisatie van berekeningen. (of andersom!).

Code zoals hierboven levert dan problemen op. Code zoals hieronder is duidelijker:

code:

CMyClass omcMyObject;

omcMyObject.m_iVar1 = 1;
omcMyObject.m_fVar2 = 1.0f;

[mbravenboer]

dusty: Ehh. ik zie dt jij nog nooit een echt groot project hebt gemaakt ?

Zullen we proberen om niet steeds om te komen zetten met 'grote project' argumenten in de varianten 'jij maakte niet' of 'ik maak ze wel'?

Als je je argument moet maken door te zeggen dat jij ervaring hebt of de ander niet, vind ik dat eigenlijk een vrij zwak argument .

Het punt is dus: is het zinvol om overal direct het type van een variable te zien in de source code? Ik zeg dus nee: omdat je bij lokaal altijd genoeg overzicht moet kunnen hebben.

Een ander argument kan nog zijn dat een IDE dit zou kunnen bieden. Als jij wilt weten wat voor een type een variabele is, kan deze dat voor je uitzoeken. De type informatie in de Hongaarse notatie is dus duidelijk 'dubbelop'. Het is de vraag of dat handig is of niet . Ik vind dus van niet .

Otis: ik meende me trouwens te herrinneren dat je een andere coding style juist handig vond om eigen code van de standaard libraries te onderscheiden. Ben je van mening veranderd en zo ja: waarom?

[mbravenboer]

Otis: Ik ben het er absoluut niet mee eens dat je maar op de variabelenaam moet afgaan wat voor type een variabele heeft.

Ik zeg ook niet dat het onzinnige informatie is: tuurlijk is het handig om te weten wat voor type een variabele heeft. Dit treedt naar mijn mening vooral op bij geproggel met primitieven en niet zo zeer bij objecten. Daar voor zou informatie over een type dus handig zijn. Mijn punt is echter dat ik het in de variabele-naam niet prettig vind omdat het vervelende onderbrekingen in de leesbaarheid van je code tegenkomt. Uiteraard heb je hier minder tot geen last van als je een ervaren hongaarse notatie lezer bent.

Type informatie bij een variabele kan heel door een IDE geregeld worden... Daarom is het naar mijn smaak niet zinvol om deze notatie te gebruiken: ik heb het te zelden nodig en als ik het nodig zou hebben zou ik het liever niet steeds intikken.

Het is juist MOEILIJKER om te achterhalen wat voor type een variabele heeft!

Mwah, met het voorbeeld wat jij geeft wel, met mijn voorbeeld niet:

code:

public interface Model {
    void addChangeListener( ...)
    void removeChangeListener) ..)
}

public class Specie{
    List<Component> getComponents();
    void setComponents(List<Component> s)

    void addComponent(Component s);
    void removeComponent(Component s);
}

[mbravenboer]

Voor de gein heb ik het ff opgezocht:

Otis schreef hier: Voor je API kies je een bepaalde namingscheme. Op zich vind ik dan dat je voor je eigen code een andere scheme moet kiezen zodat je API calls en eigen code uit elkaar kan houden, maar dat is persoonlijk

Otis in dit topic: Dit vind ik een verschrikking. Ik ben een van de zelfkastijders die een paar jaar terug hungarian coding heeft geadopteerd en er van is gaan houden, nu moet dat overboord! (Tuurlijk kun je doorbroddelen met je eigen style maar dat matcht dan niet met native taalelementen/library zaken).

Volgens mij zit je ons dus gewoon uit te dagen en code jij gewoon lekker verder in hongaarse notatie .

Ik schrik btw van mijn eigen geheugen .

[MisterData]

Hmm heb zelf eigenlijk nooit echt nagedacht over hoe mijn variabelen moeten heten Ik gebruik gewoon de java-methode, dus dat met die kamelen

[mbravenboer]

MisterData: Hmm heb zelf eigenlijk nooit echt nagedacht over hoe mijn variabelen moeten heten

Dasniezo mooi .

[MisterData]

Dasniezo mooi

Neej mijn code ook niet echt

edit : En toen ging er iets fout met de quote tags

Hmmz en nu ontopic :

Ik vind het wel irritant als je moet overschakelen van Java naar .NET, dat dan alle variabele- en functienamen met een hoofdletter beginnen. In Java heb je bijvoorbeeld object.toString() , dat is in .NET dus al Object.ToString()

Dat is dus iedere keer weer een compiler fout Maarja, ik denk dat het gewoon een kwestie van wennen is

[Verwijderd]

Bravenboer: ik ben idd van mening veranderd. Ik zit nu dat C# boek door te werken (Programming C#, oReilly) en ik had het me niet zo gerealiseerd maar het is me wat te ingrijpend die namingscheme change, omdat de library van .NET toch wat te uitgebreid is, je hebt dus erg vaak code van .NET in je eigen code verweven, wat nergens op lijkt als je 2 namingschemes doorelkaar heen gebruikt. (Wanneer je een eigen API maakt en die gebruik je niet zo intens, dan is dat niet zo erg.)

[Verwijderd]

Maak gewoon niet zoveel gebruik van globale variabelen, dan kun je best het type onthouden.

En ik vind zo i/g_ voor de naam van een variabele nou ook niet echt denderend.

[mbravenboer]

Otis: je hebt dus erg vaak code van .NET in je eigen code verweven, wat nergens op lijkt als je 2 namingschemes doorelkaar heen gebruikt.

Kan ik me helemaal in vinden....

Had je dit topic trouwens gezien?
[topic=397875/1/25]
(MSXML promoten is niet echt mijn hobby dus ik had eigenlijk verwacht dat jij dat wel op je zou nemen ).

[mbravenboer]

MisterData: functienamen met een hoofdletter

Dat vind ik inderdaad ook zeer vervelend. Ik vind het eigenlijk een zeer onhandig, dus het is niet alleen een gewenning: Ik had pas een property met dezelfde naam als de klasse van die property. Allebei beginnen ze dus met een hoofdletter en dat ging niet zo goed .

[stylee]

Iemand trouwens wat meer informatie over de naming-scheme van WinForms controls/elementen? Heb me suf gezocht op google/msdn, maar ik weet zeker dat er ergens wel wat over moet staan.

In VB was ik gewend om bijvoorbeeld textboxes txtEdit, listboxes lstBla, etc te nomen. Wordt het aangeraden om hiermee door te gaan of hebben de heren-ontwerpers bij Microsoft wat anders op het oog?

[Verwijderd]

Op vrijdag 01 februari 2002 20:25 schreef stylee het volgende:
Iemand trouwens wat meer informatie over de naming-scheme van WinForms controls/elementen? Heb me suf gezocht op google/msdn, maar ik weet zeker dat er ergens wel wat over moet staan.

In VB was ik gewend om bijvoorbeeld textboxes txtEdit, listboxes lstBla, etc te nomen. Wordt het aangeraden om hiermee door te gaan of hebben de heren-ontwerpers bij Microsoft wat anders op het oog?

Dat gaat om controls op een form, da's iets anders. Daarvoor wordt meestal de "VB coding standard" gebruikt, txtEdit, lstBla...

[Verwijderd]

Op vrijdag 01 februari 2002 19:10 schreef mbravenboer het volgende:
Had je dit topic trouwens gezien?
[topic=397875/1/25]
(MSXML promoten is niet echt mijn hobby dus ik had eigenlijk verwacht dat jij dat wel op je zou nemen ).

Nee, dat is een appotjewijd topic, die mijd ik

[Verwijderd]

Ik zat net in de MSDN te bladeren en daar kwam ik nog gewoo artikels tegen over VB.Net met daarin Hungarian notatie! zie hier. De developers @ MS zijn blijkbaar dus zelf ook niet zo overtuigd over wat ze nou moeten doen.

[Tomatrix]

Toen ik c++ programmeerde heb ik meteen de hungarian notation gebruikt. Heb dit nog een tijdje volgehouden toen ik overstapte op java. Maar ja, op een gegeven moment zie je in dat dit volkomen onleesbare code oplevert.

Zowiezo ben ik van mening dat wanneer een klasse meer dan, pak 'm beet, 5 member variabelen heeft, je design verkeerd is en je eigenlijk een nieuwe klasse had moeten maken. Voor die paar variabelen is best wel te onthouden welk type ze hebben, zeker omdat de getter en setter methodes dit via hun return type volkomen duidelijk maken.
Daarom gebruik in Java voor klasse variabelen altijd de this.{vul maar in} constructie, die paar tellertjes die je verder hebt zijn toch wel duidelijk.

Kort samengevat, hungarian is bij een goed design nergens voor nodig.

[whoami]

Op zondag 03 februari 2002 01:43 schreef Tomatrix het volgende:

Zowiezo ben ik van mening dat wanneer een klasse meer dan, pak 'm beet, 5 member variabelen heeft, je design verkeerd is en je eigenlijk een nieuwe klasse had moeten maken.

Komaan zeg, dit is toch een beetje overdreven niet? Wat heeft het aantal member var's in een class nu te maken met het feit of uw design nu al of niet verkeerd is?
Stel, je hebt een class persoon; dan kun je toch al gauw meer dan 5 member var's hebben hoor.

[Tomatrix]

Wat ik bedoel te zeggen is dat wanneer je een hele kluwen member variabelen hebt, je misschien helper klassen moet gaan toevoegen om die variabelen op een zinnige manier te bundelen. Al was het alleen maar om de leesbaarheid/overzichtelijkheid van je code te verbeteren.

[mbravenboer]

Tomatrix: je misschien helper klassen moet gaan toevoegen om die variabelen op een zinnige manier te bundelen.

Idd, daar kan ik me wel in vinden. Eventueel kan je natuurlijk ook kiezen voor een inheritance oplossing door een hogere abstractie te introduceren met wat members erin, maar hier moet je wel mee uitkijken. In ieder geval moet je liever niet alleen op basis van gemeenschappelijke data abstracties invoeren...

[Verwijderd]

Op zondag 03 februari 2002 11:20 schreef Tomatrix het volgende:
Wat ik bedoel te zeggen is dat wanneer je een hele kluwen member variabelen hebt, je misschien helper klassen moet gaan toevoegen om die variabelen op een zinnige manier te bundelen. Al was het alleen maar om de leesbaarheid/overzichtelijkheid van je code te verbeteren.

Dat is freubelen zonder theoretische basis. Je classes ontwerp je met een methode, en aangezien we hier praten over blokken data, is het handig daar een normaliserende modelleringstechniek voor te gebruiken zoals NIAM. De tabellen (oftewel classes) die daaruit rollen kun je dan wel doormidden gaan knippen maar dat is onzin.

Ik ben het er ook niet mee eens dat helperclasses de leesbaarheid van je code verhogen. Is dezelfde discussie die gevoerd wordt door veelal mensen die niet dagelijks software schrijven: "Als een functie langer is dan 1 scherm moet je hem opdelen". Allemaal leuk en aardig, maar ik kan je verschillende voorbeelden geven van functies die langer zijn dan 10 pagina's en waarbij je bij opdeling een veelvoud aan pagina's krijgt met subfuncties (die ook weer opgedeeld moeten worden etc) met alle complexiteit van parameter/data passing van dien.

Dit volgt uit het feit dat je je af moet vragen waarom je in die functie bent. Bv: "ExecuteCommand" in een script/inputfile based/driven applicatie. Dat kan een complexe routine worden, of beter: een lange repeterende routine. Als ik daar een kerstboom aan functies ONDER hang, bv 3 niveaus diep, en ik besluit in zo'n leaf dat de executie kan stoppen, is het voor de lezer dan logisch dat men stopt met 'ExecuteCommand' ? Nee, men stopt met de leaf functie. Opdelen van functies is goed, maar wel op basis van een theorie: welke blokken logica zijn te onderscheiden en is het verstandig daar een apart blokje van te maken zodat het kan worden hergebruikt, of anders: is het verstandig het op te delen in een apart blokje logica want het moet opereren als een black box? Niet gaan snoeien omdat een functie toevalling 105 regels bevat.

Idem dito met het lukraak introduceren van classes. (nog erger eigenlijk.). Zonder theoretische onderbouwing uberhaupt classes gaan bakken is onzinnig. Wat je dan steevast ziet is dat men op basis van FUNCTIONALITEIT de classes gaat opdelen. Maar dat is ONNOZEL! OO is niet gebaseerd op functionaliteitgroepering! Het is gebaseerd op het groeperen van data met daarbij behorende functionaliteit, maar die functionaliteit is _ondergeschikt_ aan de relatie van de data tot elkaar. (je zou kunnen zeggen: de dataconstructie(s) bepalen de functionaliteit die in de classes wordt geimplementeerd). Ook een van de redenen waarom ik het keyword 'static' een grotere doodzonde vindt in een puur OO design dan het keyword 'goto'.

Gaan lopen zagen in je classtree omdat de hoeveelheid members van een class groter is dan een zeker getal is dan ook niet goed te praten. Je KUNT niet aantonen met welk theoretisch model dat je class-tree die na het zagen is ontstaan het gevolg is van wijzigingen in het model, want je gebruikt het gehele model niet: je bent handmatig wijzigingen aan het aanbrengen: de 1e stap op weg naar een buggend, niet te onderhouden resultaat.

[Verwijderd]

Op zondag 03 februari 2002 11:25 schreef mbravenboer het volgende:
[..]
Idd, daar kan ik me wel in vinden. Eventueel kan je natuurlijk ook kiezen voor een inheritance oplossing door een hogere abstractie te introduceren met wat members erin, maar hier moet je wel mee uitkijken. In ieder geval moet je liever niet alleen op basis van gemeenschappelijke data abstracties invoeren...

Je moet uberhaupt niet gaan knoeien in het resultaat van je modelleringsproces. Zie het als een database ontwerper die via NIAM/ORM een E/R model genereert en dat in de database invoert, en in de database nog vrolijk wat velden gaat toevoegen, 2 tabellen gaat samenvoegen etc. No can do.

Inheritance kan alleen 'correct' worden genoemd wanneer er een relatie bestaat (semantisch, op basis van de data, niet op basis van functionaliteit!) tussen de base class en de class die gebaseerd is op die baseclass. Ga je maar wat schuiven met data of erger: functionaliteit, dan ben je eigenlijk niet goed bezig: waar is je theoretische model dat als basis diende voor de opdeling van de data zoals je die had/hebt? Als je dat model hebt, waarom wijzig je niet eerst DAAR de relaties en kijk je DAN wat voor effect dat heeft op je model!! Wellicht levert dat andere classes op dan je dacht.

[mbravenboer]

Otis: Dat is freubelen zonder theoretische basis.

Ach, design is zeer regelmatig freubelen zonder theoretische basis. Dat is ook exact hetgene wat het zo'n geschikt onderwerp voor discussies maakt .

Ik ben het er ook niet mee eens dat helperclasses de leesbaarheid van je code verhogen.

Het ligt eraan waarom je die helperclasses hebt geintroduceerd. Het is inderdaad te kort door de bocht om te zeggen "m'n klasse is te groot, laat ik maar gaan knippen". Dat schiet natuurlijk niet op. Wanneer schiet het wel op? Als je in een klasse (die nog eens groot hoeft te zijn) data ontdekt die eigenlijk op zich zelf staat (en dus niet afhankelijk is van de rest van de data in de klasse.

Delegatie is dan een aardige oplossing. Voor dit proces kan je bijvoorbeeld de refactorings "Extract Class" in combinatie met "Replace Inheritance with Delegation" gebruiken.

Wanneer zijn er dan concrete signalen dat je dit zou moeten doen?
1. Als een klasse meerdere rollen gaat vervullen en daardoor te veel verantwoordelijkheden krijgt.
2. Als je voelt dat je veel subclasses gaat maken die kleine delen van het gedrag in deze rollen gaan aanpassen.

Als je op deze manier een extractie kan doen, kan je zeer goede resultaten bereiken: (1) als je extractie echt een aparte rol is kan je deze rol wellicht gebruiken op andere plaatsen in je programma. (2) als het gedrag van de rol aangepast moet worden in verschillende varianten hoef je alleen maar je rol te specialiseren.

Waarom is dat laatste een voordeel? Stel dat een grote klasse rol x en rol y heeft. Als je rol x wilt aanpassen of specialiseren ga je wellicht een subklasse van x maken die dit doet. Als je rol y wilt aanpassen ga je weer een subklasse maken die dit doet. Als je echter de aangepast rollen x en y wilt combineren zit je in de penarie: je hebt twee aparte subklasse die die beide aanpassingen hebben geimplementeerd. Deze kan je dus niet combineren! Als je de rollen nu extract in een andere klasse, kan dit dus wel.

Conclusie: niet lukraak gaan extracten, maar wees gewaarschuwd als een klasse steeds uitgebreid moet worden. Vervult hij nog wel steeds 1 rol?

Idem dito met het lukraak introduceren van classes. (nog erger eigenlijk.). Zonder theoretische onderbouwing uberhaupt classes gaan bakken is onzinnig.

Inderdaad niet lukraak dus .

Wat je dan steevast ziet is dat men op basis van FUNCTIONALITEIT de classes gaat opdelen. Maar dat is ONNOZEL! OO is niet gebaseerd op functionaliteitgroepering!

code:

<?human-reader-warning
     description="Otis komt op dreef en is dan 
     soms niet zo subtiel en relativerend meer ;) "?>

Haha , dat kan jij wel vinden, maar ik niet . OO is oorspronkelijk wellicht ontstaan uit het combineren van data en functionaliteit bij deze data, maar ik denk dat de boeken van mensen als Erich Gamma, Martin Fowler en Kent Beck een interessante kant op gaan: in een interessant en duidelijk OO design gaat het om het verdelen van verantwoordelijkheden en rollen.

Het is gebaseerd op het groeperen van data met daarbij behorende functionaliteit, maar die functionaliteit is _ondergeschikt_ aan de relatie van de data tot elkaar.

Dat is inderdaad de oorsprong van OO geweest, maar dat wil niet zeggen dat in de OO alles om het het groeperen van data zou moeten gaan. Ik schrijf bijvoorbeeld vrachten klassen die helemaal geen data bevatten en toch (in ieder geval naar mijn mening) aardig goed ontworpen zijn. Overigens komt dit soms ook een beetje voort uit ervaringen met andere paradigma's.

Ook een van de redenen waarom ik het keyword 'static' een grotere doodzonde vindt in een puur OO design dan het keyword 'goto'.

Je moet dat inderdaad met mate gebruiken, maar zoals met alle slechte dingen zijn er af en toe ook positieve aspecten . Denk bijvoorbeeld aan Singletons of type-safe enums.

Ook ontkom je niet aan static methoden als je een bestaande klasse wilt uitbreiden met een nieuwe methode (Introduce Foreign Method), maar de source van deze klasse niet kunt aanpassen. Het is dan altijd nog beter om een static methode te gebruiken ipv overal dezelfde functionaliteit opnieuw implementeren.

[mbravenboer]

Otis: Je moet uberhaupt niet gaan knoeien in het resultaat van je modelleringsproces. Zie het als een database ontwerper die via NIAM/ORM een E/R model genereert en dat in de database invoert, en in de database nog vrolijk wat velden gaat toevoegen, 2 tabellen gaat samenvoegen etc. No can do.

Mwah, het resultaat van een modelleringsproces gaat over het algemeen alleen over data georienteerde klassen. Ik geef inderdaad toe dat (als je een modelleringsproces gebruikt) je in een normale productie omgeving de beslissingen dan beter aan het modelleringsproces van je keuze over kan laten (waarom gebruik je die anders).

Ik denk echter niet dat je je volledig applicatie via zo'n modelleringsproces op moet gaan zetten. Ik heb het dan vooral over library-ontwerp en implementaties die nodig zijn om een betere view op je platform te creeeren (in feite uiteraard ook een library).

Bovendien is een modelleringsproces natuurlijk helemaal niet handig als je op een experimentele (jakkie vies woord he? manier met OO-design bezig wilt zijn.

Inheritance kan alleen 'correct' worden genoemd wanneer er een relatie bestaat (semantisch, op basis van de data, niet op basis van functionaliteit!) tussen de base class en de class die gebaseerd is op die baseclass.

Mwah, daar ben ik het maar gedeeltelijk mee eens. Jij denkt heel erg richting data-georienteerde delen van OO design. Zoals je in m'n vorige post hebt kunnen lezen vind ik dat dus niet het volledige beeld.

Ik omschreef mijn opmerking trouwens niet helemaal duidelijk: Ik bedoelde te zeggen dat je inheritance niet moet gebruiken voor het groeperen van data als:
1. De data niet dezelfde betekenis heeft en dus een onduidelijke rol vervult.
2. Als je bij de data in feite geen functionaliteit kunt opnemen.

waar is je theoretische model dat als basis diende voor de opdeling van de data zoals je die had/hebt?

Niet alles draait dus om data. Als je het over data hebt wil ik je wel gelijk geven.

[mbravenboer]

* mbravenboer vond dit net een leuke discussie worden .

[Verwijderd]

Op zondag 03 februari 2002 17:24 schreef mbravenboer het volgende:
* mbravenboer vond dit net een leuke discussie worden .

Je moet gewoon die complete boekwerk replies van je is wat meer verdelen over meerdere replies, dan krijg je misschien nog wat vaker antwoord

[mbravenboer]

Gordijnstok: Je moet gewoon die complete boekwerk replies van je is wat meer verdelen over meerdere replies, dan krijg je misschien nog wat vaker antwoord

Hum, misschien nog geeneens zo'n gek idee .
Bedankt voor de schop in ieder geval .

* mbravenboer doet gewoon z'n best om duidelijk te zeggen wat hij bedoelt .

[Tomatrix]

Op zondag 03 februari 2002 11:45 schreef Otis het volgende:

ik kan je verschillende voorbeelden geven van functies die langer zijn dan 10 pagina's

...ik begin nieuwsgierig te worden, post 's wat zou ik zeggen

[Verwijderd]

Op zondag 03 februari 2002 21:34 schreef mbravenboer het volgende:

* mbravenboer doet gewoon z'n best om duidelijk te zeggen wat hij bedoelt .

Volgens mij wordt dat door iedereen hier ook ten zeerste gewaardeerd

/me reserveerd alvast deel I van de verzamelde replies van mbravenboer

[Verwijderd]

Op maandag 04 februari 2002 08:37 schreef Tomatrix het volgende:

[..]

...ik begin nieuwsgierig te worden, post 's wat zou ik zeggen

haha Ik wil niet dat mbravenboer dit topic meteen dicht gaat gooien ivm een gigapost van mij Ik heb in DemoGL een functie zitten die ik bewust niet heb opgeknipt. Die functie loopt van regel 261 tot regel 1648. Dat is een GIGA lang stuk. Het is echter 1 grote switch, het executeert timeline eventobjects. De executie zit daar niet eens in. Om een timeline event te executeren doet hij normaliter dit:

code:

case CT_SETEAXENV:
{
    iResult=m_gpSoundSystem->SetEAXEnv(pTLE->GetCommandParamInt(0), pTLE->GetCommandParamFloat(1),
                    pTLE->GetCommandParamFloat(2),pTLE->GetCommandParamFloat(3));
    if(iResult==SYS_NOK)
    {
        sError.Format("Error in command %d;_SOUNDSYSTEM;SETEAXENV;%d;%f;%f;%f;. Couldn't set EAX parameters",
                pTLE->GetTimeSpot(),pTLE->GetCommandParamInt(0), pTLE->GetCommandParamFloat(1),
                    pTLE->GetCommandParamFloat(2),pTLE->GetCommandParamFloat(3));
        LogFeedback(&sError[0],true,"ExecuteTimeLine:_SS:CT_SETEAXENV",false);
        break;
    }
    sToLog.Format("On %d ms.: _SS: EAX overall parameters set.",
            (long)(m_gpDemoDat->GetfElapsedTimeInSecs()*1000.0f));
    LogFeedback(&sToLog[0],true,"DoExecuteTimeLine:_SS:CT_SETEAXENV",true);
};break;

Veel overhead code dus, die repeterend is. Die zou korter kunnen worden opgeschreven maar je ontkomt er niet aan, dat je toch veel regels overhoudt. Het opdelen levert alleen maar complexiteit op.

Idem met veel messagehandlers. Die zijn vaak ook honderden regels lang. Je kunt daar dan wel allerlei subroutines voor gaan verzinnen maar dat is ook lastig voor de lezer, die moet telkens heen en weer springen tussen functies. Als die lezer dan ook nog eens een IDE gebruikt die geen codedatabases ondersteunt zoek je je helemaal lens.

Opknippen op basis van logische blokken, ala. Opknippen op basis van 'het is te lang, dus knippen' is juist problemen veroorzaken ipv ze oplossen.

[Verwijderd]

De andere reply was idem als deze, dus ik reageer hier maar even op. Bravenboer: lees eens een boek over OO!

Op zondag 03 februari 2002 12:36 schreef mbravenboer het volgende:
Mwah, het resultaat van een modelleringsproces gaat over het algemeen alleen over data georienteerde klassen. Ik geef inderdaad toe dat (als je een modelleringsproces gebruikt) je in een normale productie omgeving de beslissingen dan beter aan het modelleringsproces van je keuze over kan laten (waarom gebruik je die anders).

Precies.

Ik denk echter niet dat je je volledig applicatie via zo'n modelleringsproces op moet gaan zetten. Ik heb het dan vooral over library-ontwerp en implementaties die nodig zijn om een betere view op je platform te creeeren (in feite uiteraard ook een library).

*cough*
WAT zeg je daar? Je moet je applicatie niet totaal via modelleringstechnieken opzetten? Je moet dus met de hand ergens iets tussenknoeien? Dat lijkt me ERG fout.

Het woord 'library' is de denkfout. Je moet niet gaan zeggen: "Ik wil een mathlibrary maken, en dan ben ik niet datafocussed bezig maar functionfocussed, DUS is OO niet altijd datafocussed", maar je moet dan zeggen: "Voor een mathlibrary is OO niet de juiste ontwikkelmethode, dus kies je niet OO als ontwikkelmethode". Library als een library van classes, ala, maar dan nog is de binding van de classes een relatie die ligt op het datavlak, niet op het functionele vlak.

Een mathlibrary voor matrices bv is in een OO taal niet een lijst functies op een matrix, maar een matrix class met daarin de matrixdata met daarop functies en een setje operators. De basis is de data, de matrix. NIET de wiskundige logica daarop. Ga ik een library van classes maken op wiskundige data, dan MOET ik dat modelleren. Hoe anders weet je wat je wilt gaan bouwen?

Bovendien is een modelleringsproces natuurlijk helemaal niet handig als je op een experimentele (jakkie vies woord he? manier met OO-design bezig wilt zijn.

Knoeiprojecties hebben geen design. Daar had ik het dan ook niet over

[..]
Mwah, daar ben ik het maar gedeeltelijk mee eens. Jij denkt heel erg richting data-georienteerde delen van OO design. Zoals je in m'n vorige post hebt kunnen lezen vind ik dat dus niet het volledige beeld.

Het IS het enige beeld wat correct is imho: OO is datageorienteerd software development. De basis is je data, daarOMHEEN bouw je je code. Zodra je op een punt komt dat je functioneel bezig bent en niet OO, dan moet je geen OO kiezen als ontwikkelmethode maar moet je een methode gebaseerd op procedurele talen kiezen. Je kunt dmv is-a relaties tussen de data je objects in een hierarchie plaatsen, maar that's it. Zie het als de subtype hierarchierelaties in NIAM/ORM. Exact daarmee kun je je object relaties al definieren. Zodra je gaat focussen op "als ik een class maak met dat setje functies dan kan ik daar mooi classes van afleiden die die class extenden", dan moet je een library maken met die functies in C en verder ophouden met dat in OO te gaan doen, want je gebruikt de methode dan verkeerd.

Ik omschreef mijn opmerking trouwens niet helemaal duidelijk: Ik bedoelde te zeggen dat je inheritance niet moet gebruiken voor het groeperen van data als:
1. De data niet dezelfde betekenis heeft en dus een onduidelijke rol vervult.
2. Als je bij de data in feite geen functionaliteit kunt opnemen.

Dus, wanneer er geen specialisatie plaatsvind dmv is-a relaties of in NIAM/ORM termen: dat er geen subtype relaties te definieren zijn.

[..]
Niet alles draait dus om data. Als je het over data hebt wil ik je wel gelijk geven.

Geef me 1 voorbeeld waarmee je duidelijk maakt dat je classtree gebaseerd is op louter functionaliteit ipv data, plus dat OO de juiste weg was om dit zo te bouwen.

Je moet NOOIT vergeten dat OO _een_ manier is om software te maken, niet _de_ manier. Als je niet datafocussed bezig bent, moet je niet OO gebruiken. Een van de redenen ook waarom Operating systems steevast niet in een OO taal gebouwd worden maar in een procedurele taal: men modelleert het systeem rondom functionaliteit, niet rondom data. De lagen DAAROP zijn juist wel gemodelleerd rondom data en niet rondom functionaliteit. Vandaar dat die juist vaak wel worden gebouwd in dataoriented talen.

[mbravenboer]

Bravenboer: lees eens een boek over OO!

Hum, ik heb inderdaad nog een boek van Cardelli in de kast staan wat ik nog steeds niet helemaal gelezen heb. Bedankt voor de tip .

Het woord 'library' is de denkfout. Je moet niet gaan zeggen: "Ik wil een mathlibrary maken, en dan ben ik niet datafocussed bezig maar functionfocussed, DUS is OO niet altijd datafocussed", maar je moet dan zeggen: "Voor een mathlibrary is OO niet de juiste ontwikkelmethode, dus kies je niet OO als ontwikkelmethode".

Mwah, allereerst had ik het niet over een math-library en zelfs geeneens over de vraag of een library functioneel of data-georienteerd is. Dit stuk ging over het toepassen van een modelleringsproces. Modelleringsprocessen zijn heel leuk, maar niet voor alle projecten. Library-design kan een van die projecten zijn naar mijn mening. Ook experimentele projecten (en nee: ik doel niet op knoeiprojecten) zijn per definitie ongeschikt voor ontwikkeling via een gedetaileerd en strak modelleringsproces. Wellicht is dit echter niet zo'n goed argument omdat jij vooral praat vanuit een pure productie gedachte (als ik mij niet vergis). Ik doe dat over het algemeen niet en daar kunnen wat verschillende meningen uitkomen, die eigenlijk helemaal niet conflicterend zijn: we praten vanuit een andere situatie en met het oog op andere toepassingen.

Wat zal jij trouwens een hekel hebben aan eXtreme Programming en de hele scene daar om heen .

Knoeiprojecties hebben geen design. Daar had ik het dan ook niet over

Ach, wat jij knoeien noemt moet je uiteraard zelf weten .

Het IS het enige beeld wat correct is imho: OO is datageorienteerd software development. De basis is je data, daarOMHEEN bouw je je code.

Mwah, dat vind ik een wat beperkte kijk op OO. OO is uiteraard ontstaan uit exact deze gedachte, wat echter niet betekend dat je niet op een fraaie manier voor kleine delen van je applicatie een andere draai aan OO kunt geven. Ik zal dadelijk wat voorbeelden geven.

Zodra je op een punt komt dat je functioneel bezig bent en niet OO, dan moet je geen OO kiezen als ontwikkelmethode maar moet je een methode gebaseerd op procedurele talen kiezen.

. Voor veel van de punten waar ik het over heb zou ik dan dus zeker niet een procedurele aanpak kiezen, maar goed: zo dadelijk wat voorbeelden.

Zodra je gaat focussen op "als ik een class maak met dat setje functies dan kan ik daar mooi classes van afleiden die die class extenden", dan moet je een library maken met die functies in C en verder ophouden met dat in OO te gaan doen, want je gebruikt de methode dan verkeerd.

Daar ben ik het niet mee eens (verwonderlijk he? ). Je kunt OO op een zeer fraaie manier ook gebruiken om te varieren in functionaliteit. Ik denk liever in termen van rollen van klassen. Een klasse vervult in een design een bepaalde rol.

Een simpel voorbeeldje waarin jouw stukje dus typisch wel van toepassing is in de OO: stel dat je in een klasse een bepaalde functionaliteit moet implementeren. Een algoritme wat een probleem oplost. Je kunt dit keihard in je klasse gaan zetten, maar als je het vermoeden hebt dat er meerdere oplossingen voor dit probleem zijn kan je beter een interface definieren die deze rol vervult. Je kunt deze interface nu op verschillende manieren implementeren. De client (de klasse waar het algoritme in zou moeten komen) kan nu werken op een abstractie van het algoritme zonder een concrete implementatie te kunnen. Het algoritme kan dus varieren onafhankelijk van deze klasse.

Dit voorbeeldje vind ik uit eigen ervaring een zeer succesvolle design-techniek en er komt toch echt niets data-georienteerds in voor. Toch kan het door de polymorphisme van OO zeer fraai geimplementeerd worden.

Dit voorbeeld is trouwens het Strategy pattern wat beschreven staat in het boek "Design Patterns, Elements of Reusable Object-Oriented Software", Erich Gamma etc.

Geef me 1 voorbeeld waarmee je duidelijk maakt dat je classtree gebaseerd is op louter functionaliteit ipv data, plus dat OO de juiste weg was om dit zo te bouwen.

Ik heb net een klein voorbeeldje gegeven: het Strategy pattern, wat ik in de praktijk zeer veel gebruik (vaak onbewust: ik moest zelfs de naam opzoeken). Hiermee scheidt je een algoritme dus een in aparte rol. Je kunt algoritmen op verschillende manier implementeren en je gebruikt polymorphisme om met het algoritme te werken.

Een ander voorbeeld, wat je zeer succesvol kunt combineren met het Strategy pattern is de Template Method waarbij je delen van een algoritme van een operatie over laat aan sub-classes. In combinatie met het delegatie voordeel van het Strategy pattern kan dan een zeer fraaie klasse structuur opleveren zonder ook maar 1 data element.

Het Visitor pattern is een ander interessant pattern wat zeer veel gebruikt wordt in programma-transformatie toepassingen. Hiermee scheidt je de operatie van een data-structuur op een functionele manier. Het grote nadeel van het definieren van een operatie over een grote klasse-structuur is dat je operatie verspreidt staat over alle klassen. Met het Visitor pattern kan je dit voorkomen en bovendien biedt het daarnaast nog vele andere interessante mogelijkheden. Je zou kunnen zeggen dat het Visitor pattern een work-around is en dus niet OO-style, maar daar zou ik het niet mee eens zijn: met het Visitor pattern profiteer je nog steeds volop van polymorhisme, inheritance, overloading en allerlei andere interessante aspecten van OO.

In feite kan ik alle behavioral patterns wel op gaan noemen.

Overigens kan ik je ook veel praktijk voorbeelden geven die deze patterns toepassen. Renderers in Swing zijn bijvoorbeeld een typische toepassing van het Strategy pattern. Hetzelfde geldt voor een Comparator bij het sorteren van een lijst. Heeft een Comparator data? Nee! Heeft een Comparator een duidelijk rol? Ja! Met behulp van een Comparator kan je een sorterings-algoritme generiek en op verschillende manieren gebruik voor eenzelfde data-type. Succesvol design vind ik dat. Een ander succesvol systeem: SAX. Heb je wel eens ContentHandlers aan elkaar gebreid zonder dat er data in die ContentHandlers zit? Heerlijk! .

Je moet NOOIT vergeten dat OO _een_ manier is om software te maken, niet _de_ manier.

Alweer zo'n goede tip . Nu we toch bezig zijn met tips uitdelen: bezoek je even de laatste twee links van mijn signature? . Gelukkig heb ik meer dan genoeg ervaring in niet-OO en zelfs niet-imperatieve talen, zodat ik kan inzien dat je inderdaad volkomen gelijk hebt.

Als je niet datafocussed bezig bent, moet je niet OO gebruiken.

Tja, ik hoop dus dat ik in dit vrij lange verhaal aangetoond heb dat dat niet hoeft te zijn, of je in ieder geval aan het denken heb gezet en wellicht zelfs nieuwsgierig gemaakt naar de boeken die ik noemde .

Een van de redenen ook waarom Operating systems steevast niet in een OO taal gebouwd worden maar in een procedurele taal: men modelleert het systeem rondom functionaliteit, niet rondom data.

Ach, tja: je hebt mij ook niet horen beweren dat jij nu maar alles wat functionaliteit is moet gaan implementeren in een OO-taal. Ik heb alleen aangegeven dat je wel degelijk op een fraaie manier functionaliteit kunt implementeren waarbij je abstraheert van de data georienteerde aanpak. Overigens zijn de voorbeelden die jij noemt ook wel zeer typisch. Math libraries zijn bekende problemen, een operating system heeft ook vele problemen waardoor een OO-aanpak voor grote delen van dit systeem ongeschikt is.

[mbravenboer]

Hum, tis weer een beetje lang geworden . Ik hoop dat het toch boeiend is . Het is in ieder geval geen klassieke welles-nietes-moddergooi discussie .

[Verwijderd]

Dit is veel te lang Je wilt gewoon zeggen dat jij vindt dat OO meer is dan alleen dataoriented bezigzijn. Zie je, dat kan gewoon in 1 zinnetje

Oh, en dat je dmv het 'misbruiken' van gevolgen van een OO methodiek (polymorphism, algo's opdelen in subclasses) probeert duidelijk te maken dat je bewering, alhier boven samengevat tot 1 zinnetje, kracht bij te zetten. Echter, ik vind dat dus foutief gebruik van een methodiek. Net zoals dat 1e C# voorbeeld wat ik ooit zag:

code:

public class calc
{
      public int add(int i, int j)
      {
          return i+j;
      }
}

(oid, er kunnen syntaxfouten in zitten)
Waarbij men onbedoeld aantoonde dat het hybride karakter van C++, zowel procedureel als dataoriented, een betere methodiek is om software te maken waarbij je het de developer en de lezer makkelijker maakt de code te begrijpen.

[mbravenboer]

Otis: Je wilt gewoon zeggen dat jij vindt dat OO meer is dan alleen dataoriented bezigzijn. Zie je, dat kan gewoon in 1 zinnetje

Pfff, doe ik zo mijn best om het goed te behandelen .

Echter, ik vind dat dus foutief gebruik van een methodiek.

Tja, das een mening en dat mag je helemaal zelf weten . Ik vind deze aanpak zeer prettig werken en ik vind OO er tot zijn recht komen. Dat er best-sellers over geschreven zijn zoals dat Design Patterns boek en bijvoorbeeld "Refactoring" van Martin Fowler lijkt mij een bewijs dat ik niet de enige ben die er zo over denkt .

Net zoals dat 1e C# voorbeeld wat ik ooit zag

Tja, das natuurlijk ook wel een zeer onzinnig voorbeeld .

Dit is absoluut geen voorbeeld van de aanpak die in nastreef. Daar zijn wel elegante en interessante voorbeelden van te vinden.

Overigens vind ik eigenlijk zelfs het sterk data-georienteerde design absoluut niet spannend. Bij het spelen met products, customers, bicycles en cars, komt OO naar mijn mening juist niet volledig tot zijn recht .

[whoami]

Op dinsdag 05 februari 2002 09:23 schreef Otis het volgende:
Waarbij men onbedoeld aantoonde dat het hybride karakter van C++, zowel procedureel als dataoriented, een betere methodiek is om software te maken waarbij je het de developer en de lezer makkelijker maakt de code te begrijpen.

Ik kan mij hier heel goed in vinden. Sterker nog, ik sluit me volledig aan bij dat standpunt. Waarom niet 'the best of both worlds' combineren?
Soms vind ik het een beetje overkill om alles OO te gaan implementeren en is procedural dan meer geschikt.

Dan zou dit probleem ook meteen van de baan zijn...

[marcusk]

Op dinsdag 05 februari 2002 19:37 schreef whoami het volgende:
Dan zou dit probleem ook meteen van de baan zijn...

Hoezo dat? Das toch alleen een kwestie van syntax ? Ik bedoel, het zou op zich heel goed bij java kunnen, maar de ontwerpers van de taal hebben daar niet voor gekozen. IIRC is er een zelfs een taal die naar java-bytecode compileert en dit ondersteunt (ik weet alleen niet meer welke)

[whoami]

Op dinsdag 05 februari 2002 19:45 schreef marcusk het volgende:

Hoezo dat? Das toch alleen een kwestie van syntax ? Ik bedoel, het zou op zich heel goed bij java kunnen, maar de ontwerpers van de taal hebben daar niet voor gekozen. IIRC is er een zelfs een taal die naar java-bytecode compileert en dit ondersteunt (ik weet alleen niet meer welke)

Jach, idd. Een beetje voorbarig van mezelf, dat voorbeeld.

[.oisyn]

Op vrijdag 01 februari 2002 22:17 schreef Otis het volgende:

[..]

Nee, dat is een appotjewijd topic, die mijd ik

hahaha

Verder vind ik het een beetje een nutteloze discussie... iedereen heeft z'n eigen smaak en z'n eigen redenen om die stijl te gebruiken. Persoonlijk vind ik die woestijnbeestenmet2bultenstijl ook wel lekkerder lezen, maar ja, wie ben ik

[mbravenboer]

OiSyN: Verder vind ik het een beetje een nutteloze discussie... Persoonlijk vind ik die woestijnbeestenmet2bultenstijl ook wel lekkerder lezen

Daar ging de discussie op het laatst niet echt meer over hoor .

[.oisyn]

heej je denkt toch niet dat ik de hele topic met al z'n nutteloze gebral door ga lezen he

[mbravenboer]

OiSyN: heej je denkt toch niet dat ik de hele topic met al z'n nutteloze gebral door ga lezen he

Zo'n vermoeden had ik al .

en bedankt trouwens .

[dusty]

Op vrijdag 01 februari 2002 18:13 schreef mbravenboer het volgende:
[..]
Als je je argument moet maken door te zeggen dat jij ervaring hebt of de ander niet, vind ik dat eigenlijk een vrij zwak argument .

Ik doelde eigenlijk op Freak007's commentaar dat je alle vars zou moeten kennen en weten wat het is, echter (zoals jij wel weet) ben je bij een groot project vaak met meerdere mensen bezig, en dan wordt het onmogelijk om meteen te weten welke var voor precies wat stond,

Het is dubbelop om hungarian code te gebruiken, echter werkt het wel prima als geheugensteuntje wat voor variabele het was. Dit is helemaal het geval als je 3 projecten hebt die simulaan werken, en waar je per dag kans hebt om aan het andere project te moeten werken.

[dusty]

Op vrijdag 01 februari 2002 18:30 schreef mbravenboer het volgende:
[..]
Ik schrik btw van mijn eigen geheugen .

Geen nood, verdwijnt vanzelf

[dusty]

Op zondag 03 februari 2002 11:45 schreef Otis het volgende:
[..]
Is dezelfde discussie die gevoerd wordt door veelal mensen die niet dagelijks software schrijven: "Als een functie langer is dan 1 scherm moet je hem opdelen".
[..]

Grotere scherm kopen