[alg] design patterns, wie gebruikt ze.

[whoami]

Ik kan er ook niet veel over vertellen, maar het interesseert me wel.

* whoami denkt dat het tijd wordt om ook dat boek eens aan te schaffen.

[LuCarD]

Ik ben er sinds kort mee bezig (dank Nielsz ), en aangezien ik in een niet OO taal schrijf ( PHP ). Ben ik nog een beetje aan rond kijken en het zoeken naar een design pattern die bij mij en bij PHP past.

Mijn oog is nu gevallen op Singleton of Monostate.
Helaas zijn die specifiek geschreven voor OO talen.. Dus ik moet er af en toe een eigen draai aan geven...

whoami schreef op 09 augustus 2002 @ 13:25:
Ik kan er ook niet veel over vertellen, maar het interesseert me wel.

* whoami denkt dat het tijd wordt om ook dat boek eens aan te schaffen.

* LuCarD voelt een inkoop actie aan komen...

[Alarmnummer]

Hier zijn trouwens 2 interessante online boeken over design patterns:

http://www.mindview.net/Books/TIPatterns
Dit boek is nog niet klaar, maar het belooft een heel leuk stuk te worden, waarin hij toch een hele andere draai geeft aan de standaard aanpak van design patterns. (Taal = Java)

http://www.patterndepot.com/put/8/JavaPatterns.htm (Taal = Java)
Dit is wel een standaard beschrijving van de design patterns zoals in het GoF boek wordt beschreven. Het GoF boek is een van de 1e boeken waarin een bundeling staat van design patterns die voor een deel in de smalltalk community zijn ontwikkeld. Je kan stellen dat het GoF boek de bijbel op het gebied van design patterns is, alhoewel er ook hele interessante boeken zijn waarin andere patterns worden behandeld. Vanuit andere boeken wordt meestal ook naar het GoF boek verwezen, dus het is zeker geen miskoop.

Het maakt eigelijk niet zoveel uit voor welke taal een design patterns boek is geschreven. In het GoF boek wordt gebruik gemaakt van C++ voorbeelden en in de bovengenoemde links wordt gebruik gemaakt van Java. Als een taal maar goeie oo ondersteuning heeft, kan je de meeste design patterns wel toepassen zonder dat je vast zit in een bepaalde taal.

[drm]

* drm denkt dat LuCarD het model-view-controller (MVC) design pattern ook wel interessant vindt

da's wel redelijk toepasbaar in PHP

da's dan ook meteen het enige design pattern waar ik naar gekeken heb, en voor de rest ga ik hier denk ik alleen maar lezen

[Zoijar]

Ik gebruik ze intensief. Heb design patterns en pattern hatching gelezen, en verder veel artikellen uit tijdschriften/online-mags enzo. Vooral composite met (gewijzigde) visitor zie ik vaak naar voren komen.
Hoewel ik nu steeds vaker de "template" versies ga gebruiken van de GoF patterns, zoals bv Alexandrescu er veel heeft beschreven (functors, die templated visitor met dynamic cast, event dispatcher/handler)
Erg nuttig allemaal

edit:
oh en Singleton mag zeker niet ontbreken hier, toch wel een waar het meest over is geschreven

[PostbodeSiemen]

Heb met afstuderen wel gewerkt met Abstract Factory en Singletons.

Ben nu in mijn huidige (tijdelijke) werk een beetje aan het expirimenteren maar ik moet toegeven dat ik het vaak nog moeilijk vind om de juiste oplosing bij een probleem te zoeken.

Heb laatst een Log frameworkje gebaseerd op het observer/observable pattern gemaakt bij een applicatie zodat ik makkelijk overal vanuit mjin programma logberichten kan generen, en deze automatisch verwerkt worden door de juiste klassen.
( Heb me alleen niet helemaal goed gehouden aan het pattern ben ik bang. )

(hoop ook in een toekomstige baan er nog veel mee te maken te krijgen)

[MisterData]

Tjsa, ik programmeer al heel lang, maar voor wat ik doe denk ik dat design patterns niet echt nodig is. Maar ik wil er zeker eens naar kijken

[Alarmnummer]

drm schreef op 09 augustus 2002 @ 13:35:
* drm denkt dat LuCarD het model-view-controller (MVC) design pattern ook wel interessant vindt

Het voordeel aan het MVC design pattern is dat je een ontkoppeling krijgt tussen je model (je data en logica) en de visualisatie dmv een controller. Eigelijk zou ik geen systeem kunnen ontwerpen zonder deze ontkoppeling alhoewel ik nog wel iets zou kunnen maken wat niet aan het mvc voldoet. Ik denk dat de meeste programmeurs ook hun data structuren los van hun visualisatie ontwerpen.

da's wel redelijk toepasbaar in PHP

Ik ben niet echt thuis in mvc, maar ik weet dat ze geen interfaces hebben. Ik weet ook niet in hoeverre overerving bestaat of hogere orde functies (functies die een functie als argument mee kunnen krijgen). Maar op een of andere manier moet een callback structuur gemaakt worden waardoor dus die ontkoppeling plaats vind.

da's dan ook meteen het enige design pattern waar ik naar gekeken heb, en voor de rest ga ik hier denk ik alleen maar lezen

Als je serieus met design patterns bezig wilt is het misschien handiger om op een echte oo taal over te gaan zodat je ook gebruik kan maken van allerlei oo faciliteiten.

[Zoijar]

PostbodeSiemen schreef op 09 augustus 2002 @ 13:40:
( Heb me alleen niet helemaal goed gehouden aan het pattern ben ik bang. )

Dat hoeft ook niet altijd. Een pattern is een soort "framework voor een oplossing". Je mag er best van afwijken als je wilt, je hoeft soms zelfs niet eens alle classes te gebruiken.

[whoami]

Alarmnummer schreef op 09 augustus 2002 @ 13:44:
[...]
Als je serieus met design patterns bezig wilt is het misschien handiger om op een echte oo taal over te gaan zodat je ook gebruik kan maken van allerlei oo faciliteiten.

Deze reply van mij is wel een beetje off-topic.
Maar waarom zou hij gebruik moeten maken van een andere taal als PHP nu voor hem het geschiktst is voor zijn projecten?
Design patterns zijn een hulpmiddel en geen doel op zich.

[whoami]

MisterData schreef op 09 augustus 2002 @ 13:41:
Tjsa, ik programmeer al heel lang, maar voor wat ik doe denk ik dat design patterns niet echt nodig is. Maar ik wil er zeker eens naar kijken

Waarom denk je dat? Het kan toch altijd handiger/nuttiger zijn als je met software engineering bezig bent, en je maakt gebruik van OO - technologie, dat je er iets vanaf weet?

[Alarmnummer]

PostbodeSiemen schreef op 09 augustus 2002 @ 13:40:
Heb met afstuderen wel gewerkt met Abstract Factory en Singletons.

Ben nu in mijn huidige (tijdelijke) werk een beetje aan het expirimenteren maar ik moet toegeven dat ik het vaak nog moeilijk vind om de juiste oplosing bij een probleem te zoeken.

Heb laatst een Log frameworkje gebaseerd op het observer/observable pattern gemaakt bij een applicatie zodat ik makkelijk overal vanuit mjin programma logberichten kan generen, en deze automatisch verwerkt worden door de juiste klassen.
( Heb me alleen niet helemaal goed gehouden aan het pattern ben ik bang. )

(hoop ook in een toekomstige baan er nog veel mee te maken te krijgen)

Ik heb het GoF boek nu al een tijd in huis. In het begin kijk je hem eens door en dan denk je leuk en fijn, maar je ziet niet meteen waar je het kan inzetten in de praktijk. Ik probeer iedere week een handje vol design patterns door te kijken (voornamelijk opfrissen) en ik probeer veel te experimenteren. Ik heb nu wel een redelijk gevoel wanneer ik welk design pattern voor een bepaald probleem ga gebruiken. Als ik nu naar mijn code kijk dan ziet het er ook allemaal veel duidelijker uit, omdat je dus hele goeie namen aan je objecten kan geven.
:PersonDelegate, PersonProxy, IntRealAdapater etc etc.

Zoljar
Ik gebruik ze intensief. Heb design patterns en pattern hatching gelezen, en verder veel artikellen uit tijdschriften/online-mags enzo. Vooral composite met (gewijzigde) visitor zie ik vaak naar voren komen.
Hoewel ik nu steeds vaker de "template" versies ga gebruiken van de GoF patterns, zoals bv Alexandrescu er veel heeft beschreven (functors, die templated visitor met dynamic cast, event dispatcher/handler)
Erg nuttig allemaal

Dit klinkt erg interessant!

Ik ben zelf ook vrij veel bezig met visitors, en mbravenboer die kwam een keer aanzetten met visitor combinators (JJTraveler) en dan krijg je weer een volledig nieuwe visie op het visitor design pattern. Ik maak zelf meestal gebruik van guides.

VariableCollector col = new VariableCollector();
expressie.accepts(new DepthFirstGuide(col));

op deze manier kan ik de traversal ook nog een keer loskoppelen van de visitors en krijg je een nog eenvoudiger en duidelijker framework. Zie verder mijn signature hoe ik over visitors denk (eigelijk multi dispatch want een visitor is niets anders dan een manier om double dispatch te bewerkstelligen).

[PostbodeSiemen]

MVC ben ik nog vergeten, maar die is ook wel vrij standaard geworden denk ik.

Ben nu in Delphi aan het programmeren (en het is niet mijn taal ) en ik merk dat ik mij er bij delphi erg op moet focussen om Model en View gescheiden te houden. Het is in delphi zo makkelijk om alles aan je textvaken en knoppen te hangen.

Heb ik met Java een stuk minder last van, daar heb ik altijd het gevoel dat je min of meer gedwongen wordt om het goed te doen.

[CubicQ]

Ik ben er nog nooit mee in aanraking gekomen in m'n studie (inf aan de UT, geen SE afstudeerrichting), aan de ene kant verbaast me dat wel enigzins. Maar waarschijnlijk ben ik net een paar generaties te oud ('98).

Maar goed, ik heb een maandje of 2, 3 geleden Design Patterns van Gamma gekocht, maar nog geen tijd gehad om het te lezen, dus ik ben benieuwd

[Alarmnummer]

CubicQ schreef op 09 augustus 2002 @ 13:59:
I
Maar goed, ik heb een maandje of 2, 3 geleden Design Patterns van Gamma gekocht, maar nog geen tijd gehad om het te lezen, dus ik ben benieuwd

Schaam je diep

[D2k]

*steekt hand op*
heb geen flauw idee wat het zijn

[Alarmnummer]

Een voorbeeld voor d2k. Een singleton is een design pattern waarmee je kan garanderen dat er maar 1 object van in je systeem wordt aangemaakt en is meestal het 1e design pattern dat uitgelegd wordt omdat hij zo eenvoudig is. Hieronder die je een singleton EventQueue staan.

code:

public class EventQueue{

    private static EventQueue s_instance = null;

    public static EventQueue getInstance(){
        if(s_instance == null){
            s_instance = new EventQueue();
        }
        return s_instance;
    }

    private EventQueue(){   
        ... 
    }

    public add(Event e){
        ...
    }   

    ...
}

Zoals je ziet is de constructor private dus niemand kan dit object aanmaken behalve de EventQueue zelf, en dat gebeurt met de getInstance methode. Als een EventQueue nodig is, dan kan je die als volgt aanspreken.

EventQueue.getInstance().add(new LeukEvent());

Deze singleton is ook nog eens lazy, want er wordt niet automatisch een eventqueue aangemaakt, dat gebeurt pas na aanroep van de getInstance methode.

[Bobco]

Gebruik ze met enige regelmaat. Singleton komt regelmatig voor, maar ook AbstractFactory is nog wel eens aanwezig. Ik heb net wat zitten klooien met Decorating Filter om een applicatie die in XML heeft staan op een simpele manier HTML output te laten genereren. Ik snapte toen ook opeens waarom een FilterChain zo'n goed idee is.

Een aanrader is trouwens ook het boek Bitter Java van Bruce Tate. Deze is als PDF op te halen bij JavaLobby. Het grappige aan dit boek is dat er nogal eens anti-patterns genoemd worden, patterns die juist duiden op een slechte implementatie. Tot mijn schande moest ik bekennen dat een paar van die anti-patterns mij heel erg bekend voorkwamen

[ Voor 0% gewijzigd door Bobco op 09-08-2002 14:21 . Reden: tags sluit je af met een ] ]

[TaXaN]

Ik studeer licentiaat informatica aan de KULeuven (België) en wij komen in het derde jaar (van de vier) in aanraking met software engineering technieken als UML en ook design patterns. Het vak is in feite een groepsproject met vier personen waarin je een spel implementeert. De bedoeling is dat je rigoreus de UML methodiek toepast en zoveel mogelijk gebruik maakt van design patterns. Jouw stokpaardje MVC komt alsdusdanig niet rechtstreeks aan bod maar zou toch een gevolg moeten zijn van het goed omgaan met UML en gebruik van design patterns. Het boek van Gamma wordt als referentie gebruikt.
In onze opleiding krijgen we er dus van vrij kortbij mee te maken en naar mijn mening op een goede manier: het meteen toepassen in een concreet project zou je duidelijk moeten maken wat goeds design patterns met zich mee brengen.

[drm]

Alarmnummer:
Het voordeel aan het MVC design pattern is dat je een ontkoppeling krijgt tussen je model (je data en logica) en de visualisatie dmv een controller. Eigelijk zou ik geen systeem kunnen ontwerpen zonder deze ontkoppeling alhoewel ik nog wel iets zou kunnen maken wat niet aan het mvc voldoet. Ik denk dat de meeste programmeurs ook hun data structuren los van hun visualisatie ontwerpen.

Daarom denk ik dat 't vooral het waarnemen waard is voor de PHP'ers onder ons, die 't e.e.a. nog wel eens door elkaar kunnen gooien

Ik ben niet echt thuis in mvc, maar ik weet dat ze geen interfaces hebben. Ik weet ook niet in hoeverre overerving bestaat of hogere orde functies (functies die een functie als argument mee kunnen krijgen). Maar op een of andere manier moet een callback structuur gemaakt worden waardoor dus die ontkoppeling plaats vind.

Niet thuis in PHP bedoel je? Je kunt een eind komen hoor, met MVC in PHP

Als je serieus met design patterns bezig wilt is het misschien handiger om op een echte oo taal over te gaan zodat je ook gebruik kan maken van allerlei oo faciliteiten.

Ik ben voor een PHPert redelijk goed op de hoogte van wat OO is, maar ja, je zal met me eens zijn dat 't voor een website niet echt 't meest nuttige is waar je je mee bezig zal houden in de ontwikkelsfeer. Hobbysfeer, ala

[Zoijar]

PHP mist gewoon een aantal dingen die je met de meeste patterns nodig hebt. En buiten dat zijn veel patterns ontworpen met het oog op strong type checking. Aangezien PHP helemaal geen type checking heeft kan je sommige dingen daar heel makkelijk (fout ) in doen.

Ik probeer in PHP wel OO te proggen, maar heb nog nooit echt patterns gebruikt zoals ik in C++ doe. Maar bij websites is vaak het enige "tricky" gebeuren om je data van je representatie te scheiden. Verder is het gewoon "dom" data ophalen uit je database imo.

[GraasGast]

Als reactie op de topicstarter:

Ik weet dus uberhaubt niet wat design patterns zijn.
Als ik even snel door de thread heen lees heb ik wel een beetje het idee dat het over re-usable code en applicatieontwerp gaat.
Aangezien ik daar de laatste tijd ook een beetje mee bezig ben ben ik wel geintereseerd in deze materie.

Omdat ik denk ik niet de enige ben: zou iemand eens uit de doeken kunnen doen wat design patterns nou precies zijn, hoe het werkt, voor/nadelen tov. alternatieven enz?

_{en ja, ik moet meer boeken gaan lezen}

[Alarmnummer]

Design patterns zijn eigelijk vaste technieken die je gebruikt die verder niet goed in een herbruikbare api vast te leggen zijn, in tegenstelling tot bv een button of een vector. Ik denk dat je hebt beste het 1e hoofdstuk van dit boek even kan doorlezen om een indruk te krijgen van design patterns. Hierin staat het veel beter verwoord dan ik het zou kunnen

[Zoijar]

Hmm ik bedenk me net ineens, als ik Amazon links post naar boeken, dus zeg maar om een aantal aanbevelingen te geven... telt dat hier dan als reclame (wat niet mag) ? Lijkt me niet toch? bv.

Design Patterns

Pattern Hatching

Modern C++ Design

[Alarmnummer]

Dan zijn dit ook aanraders:

Pattern-Oriented Software Architecture, Volume 1: A System of Patterns

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

en voor de java mensen is dit ook een erg goed boek:
Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition)
Dit boek gaat voornamelijk over concurrency control, maar daarbij wordt enorm veel gebruik gemaakt van design patterns. Dit is zeker geen miskoop, en ik heb begrepen dat dit 'het' boek is op gebied van concurrency control.

[Verwijderd]

Maar, als je zoals ik, kromme tenen krijgt van het op een functionele manier benaderen van data-oriented vraagstukken, dan zijn de meeste designpatterns not-done. Ik snap wel dat ze handig zijn als je geen kromme tenen krijgt van het toepassen van functionele benaderingen van data-oriented vraagstukken (dus dat je objecten maakt met functionaliteit die dus niet op een gedefinieerd stukje data werkt maar net zoals bij functionele oplossingen, op de invoer).

[Alarmnummer]

Niet alle design patterns zijn een functionele manier van benaderen Ik neem aan dat je ook wel eens een singleton gebruikt of een abstract factory of een iterator (jaja.. iterator is ook design pattern in het GoF boek)

En soms kan je bv met een visitor (dus een functionele aanpak) heel eenvoudig bepaalde functionaliteit gaan toevoegen. Stel dat je een expressie hebt, en je wilt daaruit alle variablen halen om in een lijst te zetten? Dan zul je bij ieder object in die expressie hierarchie een getAllVariables moeten implementeren en bij iedere implementatie zal je dus ook weer een traversal moeten schrijven. Dit leid tot een klont met code die vrij lastig te wijzigen is, die veel herhalingen bevat en op den duur stikt in de 'handige' methodes.

Maar kijk eens naar dit stukje code:

code:

public class VariableCollector extends ExpressionAdapter{
   private Set<Variable> _set = new HashSet<Variable>();

   public void visit(Variable var){
        _set.add(var);
   }

   public Set<Variable> getResult(){
        return _set;
   }
}

en je kan het aanroepen met:
VariableCollector col = new VariableCollector();
expression.accepts(new DepthFirstGuide(col));

Dit kan je dus onmogelijk voor elkaar krijgen op de 'klassieke' manier. Tevens is het niet ongebruikelijk om objecten in te delen in functionaliteit zodat je een bundeling krijg van bij elkaar horende functies ipv dat het verspreid ligt over je object hierarchie.

[ Voor 0% gewijzigd door Alarmnummer op 09-08-2002 16:05 . Reden: foutjes in code ]

[Verwijderd]

Ik doelde meer op het baseclass met functionaliteit vs (class met data + class met algemene functionaliteit). Ja die non-functionele aanpak gebruik ik ook inderdaad, die zijn zo triviaal Verder lenen sommige talen natuurlijk eerder voor een andere aanpak (bv talen met multiple inheritance) dan andere talen.

[DeGroninger2]

Verwijderd schreef op 09 augustus 2002 @ 15:32:
Maar, als je zoals ik, kromme tenen krijgt van het op een functionele manier benaderen van data-oriented vraagstukken, dan zijn de meeste designpatterns not-done. Ik snap wel dat ze handig zijn als je geen kromme tenen krijgt van het toepassen van functionele benaderingen van data-oriented vraagstukken (dus dat je objecten maakt met functionaliteit die dus niet op een gedefinieerd stukje data werkt maar net zoals bij functionele oplossingen, op de invoer).

Dit is geenszins de schuld van Design Patterns, maar van de gebruiker van een pattern. Design patterns geven je bouwstenen om de architectuur van je (OO) software product op te zetten. Je wilt bijvoorbeeld een library maken voor een 3D kernel (how original). Je eerste keuze is bijvoorbeeld OpenGL, maar je wilt eigenlijk in de toekomst ook nog andere systemen aankunnen. Je hoofdarchitectuur doe je op basis van (bijvoorbeeld) een AbstractFactory en voor je OpenGL maak je dus een specialisatie van deze Factory. Om het elegant te houden maak je een aantal Adapters om de interfaces van OpenGL te verbergen voor de argeloze gebruikers van jouw library.

Een persoonlijk waarneming met design patterns is:
Als je genoeg OO projecten hebt gedaan, veel geexperimenteerd met designs en architecturen, dan ken je de meeste Design Patterns al lang, maar je wist nog niet dat ze een naam hadden. Dus, zogeheten 'Aha'-Erlebnissen

[Alarmnummer]

En het voordeel is dat als je de naam weet, je er ook makkelijker met een collega over kan praten en meteen ziet wat een bepaald object doet. Daarnaast zijn ze meestal goed gedocumenteerd en weet je wat de zwakke en sterke punten zijn en kom je ook snel erachter wat de relatie is tussen bepaalde design patterns.

Eigelijk zijn design patterns hogere orde bouwstenen die geen basis onderdeel zijn van de taal zoals for lussen en arrays, maar ze zijn net zo onmisbaar en essentieel.

[Zoijar]

Verwijderd schreef op 09 augustus 2002 @ 15:32:
Ik snap wel dat ze handig zijn als je geen kromme tenen krijgt van het toepassen van functionele benaderingen van data-oriented vraagstukken (dus dat je objecten maakt met functionaliteit die dus niet op een gedefinieerd stukje data werkt maar net zoals bij functionele oplossingen, op de invoer).

Huh?

De klassieke opdeling van patterns in klasses is: Structural / Creational / Behavioral

Structural en creational zijn volgens mij behoorlijk "data oriented", waar behavioral voornamelijk functioneel is.

Wat is bij jou dan een data-oriented vraagstuk? Ik neem aan dat je dan ook een structuur over je data legt, en dan op alle stukjes data operaties uitvoert? Juist bij data-oriented problemen laat je toch steeds een nieuwe operatie uitvoeren op delen van data. Een soort van data pomp architectuur, SIMD machines bv. Daar zijn perfect toepasbare DP's voor.

[Zoijar]

Ik ga meestal als volgt te werk: Eerst bedenk ik me wat voor data ik ga processen en wat m'n objecten daarvoor worden. Dan zoek ik een toepasbaar DP om structuur op de data te leggen (Structural), stel bv Composite voor een parser. Daarna een manier om je al gevonden structuur op te bouwen (Creational) en bv AbstractFactory. Dan wil je operaties op je data gaan uitvoeren, en kies je een Behavioral pattern, bv Visitor.

Als ik nu m'n ontwerp aan een ander moet uitleggen kan ik dat globaal in een paar regels.

(bv. Een composite van functie boxes, die in de parser via een abstractfactory worden gecreerd, en de operaties erop doe ik via verschillende visitors, ordening wordt bepaald dmv iterators)

[Nielsz]

Leuk topic
Ik heb een tijdje geleden een boek aangeschaft. Alleen is alle code in C++ en Smalltalk, en dus niet al te duidelijk omdat ik een PHP nerd ben

[Alarmnummer]

Nielsz schreef op 09 augustus 2002 @ 16:45:
Leuk topic
Ik heb een tijdje geleden een boek aangeschaft. Alleen is alle code in C++ en Smalltalk, en dus niet al te duidelijk omdat ik een PHP nerd ben

Daarom is mijn advies ook dat je met een echt oo taal bezig moet gaan voordat je goed gebruik kan maken van de meeste design patterns omdat ze meestal wel redelijk geavanceerde (tov php) oo constructies gebruik maken.

[Nielsz]

Alarmnummer schreef op 09 augustus 2002 @ 16:47:
[...]
Daarom is mijn advies ook dat je met een echt oo taal bezig moet gaan voordat je goed gebruik kan maken van de meeste design patterns omdat ze meestal wel redelijk geavanceerde (tov php) oo constructies gebruik maken.

Ik hoopte vandaag m'n nieuwe pc binnen te hebben, maar nee
Daarop gaat natuurlijk een dualboot, en dan kan ik lekker in linux gaan java prutseren enzo

Dus ik ga overstappen

[Alarmnummer]

Java schijnt ook te draaien onder windows hoor

[Nielsz]

Alarmnummer schreef op 09 augustus 2002 @ 16:54:
Java schijnt ook te draaien onder windows hoor

Euh, jaar, maar toch

[LuCarD]

Nielsz schreef op 09 augustus 2002 @ 16:52:
[...]
Ik hoopte vandaag m'n nieuwe pc binnen te hebben, maar nee
Daarop gaat natuurlijk een dualboot, en dan kan ik lekker in linux gaan java prutseren enzo

Dus ik ga overstappen

VERRADER

Ik wacht met smart op de nieuwe php versie....

[Alarmnummer]

ontopic aub..

[Verwijderd]

Zoijar schreef op 09 augustus 2002 @ 15:57:
[...]
Huh?
De klassieke opdeling van patterns in klasses is: Structural / Creational / Behavioral
Structural en creational zijn volgens mij behoorlijk "data oriented", waar behavioral voornamelijk functioneel is.

Ik ken de termen niet, dus ik kan me er geen voorstelling van maken. Wat ik wel gezien heb bij veel designpatterns: OF ik gebruikte ze al OF ze zijn gericht op een re-usability mbt functionaliteit die toepasbaar is op meerdere typen, en daar wringt de schoen denk ik.

Wat is bij jou dan een data-oriented vraagstuk? Ik neem aan dat je dan ook een structuur over je data legt, en dan op alle stukjes data operaties uitvoert? Juist bij data-oriented problemen laat je toch steeds een nieuwe operatie uitvoeren op delen van data. Een soort van data pomp architectuur, SIMD machines bv. Daar zijn perfect toepasbare DP's voor.

Data oriented vraagstukken: daar waar de data centraal staat en je die modelleert en DAARNA de functionaliteit op die data. Dus niet de functionaliteit modelleren maar de data. Sommige designpatterns kun je prima gebruiken in dat soort omgevingen, andere totaal niet zoals de visitor varianten. Ik vind die, hoewel knap gevonden, niet werkbaar, omdat het voor mij een andere kijk op de programmatuur vereist die afwijkt van de data-oriented view die ik wil bereiken.

Daarom zie ik meer in bv baseclasses en dmv inheritance je classes voorzien van common code ipv het visitors pattern te gebruiken. Voor iedere benadering is iets te zeggen, het is maar net wat je ligt denk ik. Designpatterns zijn een hulpmiddel om tot een goed resultaat te komen. Dmv NIAM je data te modelleren en daaruit je classes te distilleren kan dat ook zijn, er zijn meer wegen die naar Rome leiden

[Verwijderd]

Ik heb MVC en het visitor design pattern gebruikt, natuurlijk gebruik ik ook java beans, factories en singletons. Dat GoF boek moet ik nog steeds kopen, lijkt me erg interessant

[ Voor 0% gewijzigd door Verwijderd op 09-08-2002 17:19 . Reden: Factories vergeten ]

[Alarmnummer]

Pas trouwens een beetje op met die singletons. Ik heb ze in het begin veel gebruikt, maar ik heb ik gebruik ze niet veel meer omdat je op die manier heel slecht meerdere processen naast elkaar kan draaien die hun eigen singletons gebruiken. Ik ben maar overgestapt op een soort enviroment die ik aan mijn objecten meegeef die gemeenschappelijke objecten op die manier kunnen aanspreken.

[LuCarD]

Toch stiekem een beetje offtopic maar goed....

Kijk hier eens OOP PHP...

http://www.php.net/source.php?url=/zend2_example.phps

[Verwijderd]

Alarmnummer schreef op 09 augustus 2002 @ 17:20:
Pas trouwens een beetje op met die singletons. Ik heb ze in het begin veel gebruikt, maar ik heb ik gebruik ze niet veel meer omdat je op die manier heel slecht meerdere processen naast elkaar kan draaien die hun eigen singletons gebruiken.

Zeker omdat ik veel webdevelopement doe probeer ik er ook langzamerhand van af te stappen, maar soms zijn ze wel erg handig

[Soultaker]

Naar mijn idee moet je een singleton alleen gebruiken als het object in kwestie uitsluitend functionaliteit biedt die niet afhankelijk is van de toevallige omgeving waar deze in verkeert. Het is erg verleidelijk om singletons te gebruiken als verkapte globale variabele. Als je het idee hebt dat je, in verband met parallelle executie bijvoorbeeld, je singleton toch liever in een omgevingsstructuur mee wilt geven, dan was je verkeerd bezig.

Het singleton patroon is namelijk niet een methode om alle objecten waarvan je er normaal gesproken maar 1 van hebt mee te benaderen, maar uitsluitend bedoeld voor die objecten, waar conceptueel gezien ook maar 1 van kan bestaan. Als je concludeert dat er gevallen zouden kunnen zijn, waarin meerdere instanties van een singleton object wenselijk zouden zijn, dan zou je dat object vanuit principieel perspectief nooit als singleton mogen uitvoeren.

[Alarmnummer]

Je hoeft met bv het visitor design pattern helemaal niet bang te zijn dat je niet data gericht kan ontwerpen. Het enigste wat een visitor anders maakt dan de normale aanpak is dat je object niet vervuild raak met allerlei 'handige' methodes. De objecten die blijven dus helemaal clean (dit kan je ook voor elkaar krijgen zoals je zelf al zei door in een aparte classe functionaliteit te plaatsen).

code:

public interface Expression{
    public void accepts(ExpressionVisitor v);
}

public class Variable implements Expression{

    private String _name;

    ..constructor

    ..getters

    ..toString

    public void accepts(ExpressionVisitor v){
        v.visit(this);
    }
}

public class PlusOperation implements Expression{

    private Expression _leftRoot;
    private Expression _rightRoot;
    
    ..constructor

    ..getters
        
    public void accepts(ExpressionVisitor v){
        v.visit(this);
    }

}

public class Operand implements Expression{
    private int _value;

    ..constructor

    ..getters

    public void accepts(ExpressionVisitor v){
        v.visit(this);
    }

}

Dit is een simpel voorbeeld van een data model. Zoals je zit is het afgezien van die accepts methode niet anders dan jij zou maken.

Nu komen een paar handige hulp classes:

code:

public interface ExpressionVIsitor{
    public void visit(Variable v);
    public void visit(PlusOperation p);
    public void visit(Operand o);
}

abstract public class ExpressionAdapter{
    public void visit(Variable v){visitDefault(v);}
    public void visit(PlusOperation p){visitDefault(p);}
    public void visit(Operand o){visitDefault(o)}
    public void visitDefault(Expression e){};
}

final public DepthFirstGuide implements ExpressionVisitor{
    private ExpressionVisitor _guest;
    
    ..constructor waarin de _guest ingesteld wordt.

    public void visit(Variable v){
        _guest.visit(v)
    }

    public void visit(PlusOperation p){
        p.getLeftRoot().accepts(this);
        p.getRightRoot().accepts(this);
        _guest.visit(p);
    }
    
    public void visit(Operand o){
        _guest.visit(o);
    }
}

En nu kan ik het voorbeeldje met die variable collector er weer bij pakken:

code:

public class VariableCollector extends ExpressionAdapter{
    private Set<Variable> _set = new HashSet<Variable>();
   
    public void visit(Variable var){         
        _set.add(var);    
    }    

    public Set<Variable> getResult(){
             return _set;    
    } 
}

En dit kan je als volgt aanroepen:
VariableCollector col = new VariableCollector();
expression.accepts(new DepthFirstGuide(col)):


En je kan zo een printer in elkaar zetten:

code:

public class ExpressionPrinter implements ExpressionVisitor
    public void visit(Variable v){
        System.out.println(v.getName());
    }
    
    public void visit(PlusOperation p){
        System.out.println(p.getOperatorName());
    }
    
    public void visit(Operand o){
        System.out.println(o.getValue());
    }

En je kan hem dan als volgt infix, prefix en postfix printen:

expression.accepts(new InfixGuide(ExpressionPrinter()));
expression.accepts(new PostfixGuide(ExpressionPrinter()));
expression.accepts(new PrefixGuide(ExpressionPrinter()));

Zoals je zit heb ik dus een hele lading functionaliteit toegegevoegd, maar alle expressie objecten zijn nog helemaal schoon. Daarnaast bezit afgezien van en guide ook niemand informatie over hoe over die structuur een traversal plaats moet vinden + kan je de traversal hergebruiken (dus minder redundante code in je systeem met alle voordelen van dien).

[ Voor 0% gewijzigd door Alarmnummer op 09-08-2002 18:04 . Reden: prog foutjes ]

[Alarmnummer]

Soultaker schreef op 09 augustus 2002 @ 17:40:
Naar mijn idee moet je een singleton alleen gebruiken als het object in kwestie uitsluitend functionaliteit biedt die niet afhankelijk is van de toevallige omgeving waar deze in verkeert. Het is erg verleidelijk om singletons te gebruiken als verkapte globale variabele. Als je het idee hebt dat je, in verband met parallelle executie bijvoorbeeld, je singleton toch liever in een omgevingsstructuur mee wilt geven, dan was je verkeerd bezig.

Het singleton patroon is namelijk niet een methode om alle objecten waarvan je er normaal gesproken maar 1 van hebt mee te benaderen, maar uitsluitend bedoeld voor die objecten, waar conceptueel gezien ook maar 1 van kan bestaan. Als je concludeert dat er gevallen zouden kunnen zijn, waarin meerdere instanties van een singleton object wenselijk zouden zijn, dan zou je dat object vanuit principieel perspectief nooit als singleton mogen uitvoeren.

leuk verhaal. Maar als je vanuit een proces gaat redeneren dan is er conceptueel ook maar 1 object voor dat proces aanwezig. En veel dingen worden in het begin ook als een single proces systeem opgezet, en dan geld dus dat er maar 1 object aanwezig is, en ontstaan er grote problemen doordat je op meerdere processen overgaat (met allemaal hun eigen 'singleton'). Het is dus maar net hoe je er tegen aankijkt.

[Zoijar]

Soultaker schreef op 09 augustus 2002 @ 17:40:
Als je concludeert dat er gevallen zouden kunnen zijn, waarin meerdere instanties van een singleton object wenselijk zouden zijn, dan zou je dat object vanuit principieel perspectief nooit als singleton mogen uitvoeren.

Singelton pattern geeft je juist de mogelijkheid om later over te stappen op meerdere instanties dan 1. Daar wordt veel moeite voor gedaan. Een display adapter is een goed voorbeeld, je begint als singelton, en later heb je een multi-monitor situatie. Dan kan je gewoon overstappen.

Alarmnummer schreef op 09 augustus 2002 @ 17:20:
Pas trouwens een beetje op met die singletons. Ik heb ze in het begin veel gebruikt, maar ik heb ik gebruik ze niet veel meer omdat je op die manier heel slecht meerdere processen naast elkaar kan draaien die hun eigen singletons gebruiken.

Het kan wel, bv. "double checked locking" wordt gebruikt bij singelton voor thread safety.

Singelton is een van de lastigste patterns, je kan het op heeeeel veel manieren doen en je moet met heeeel veel rekening houden. Vooral destruction is een gevoelig onderwerp. Stel je hebt twee singletons, ErrorLog en Display, en wanneer Display destroyed wordt komt er een error die je in error log wilt schrijven. Maar bestaat errorlog dan nog wel? Dat weet je niet, wat de volgorde van destructie van statics staat niet vast.

[Alarmnummer]

Zoijar schreef op 09 augustus 2002 @ 17:51:
[...]
Singelton pattern geeft je juist de mogelijkheid om later over te stappen op meerdere instanties dan 1. Daar wordt veel moeite voor gedaan. Een display adapter is een goed voorbeeld, je begint als singelton, en later heb je een multi-monitor situatie. Dan kan je gewoon overstappen.

Ik werk op dit met een environment die ik meegeef omdat ik vrij veel objecten bij elkaar wil bundelen die bij elkaar horen. Maar ik zal eens gaan kijken naar een n instance singleton.

Het kan wel, bv. "double checked locking" wordt gebruikt bij singelton voor thread safety.

Ik bedoelt dat je ook echt een singleton per proces gaat krijgen. Zoals bv een ProcesManager, hiervan heeft ieder proces zijn eigen.

[Zoijar]

Alarmnummer schreef op 09 augustus 2002 @ 17:55:
Ik bedoelt dat je ook echt een singleton per proces gaat krijgen. Zoals bv een ProcesManager, hiervan heeft ieder proces zijn eigen.

Hmm ik kan het er niet uit opmaken, wil je nou juist wel dat dit zo is (1 instantie per process) of niet?

In principe is het geen probleem, elk process heeft bv zijn eigen printer singelton, en die regelt access naar een shared resource, bv mbv spooling.

Je kan ook een client/server achtig iets opzetten, waar er slechts 1 process is dat een printer singelton instantieert, en die ondersteund dan RPC (remote procedure call) oid.

[Alarmnummer]

Zoijar schreef op 09 augustus 2002 @ 18:07:
[...]

Hmm ik kan het er niet uit opmaken, wil je nou juist wel dat dit zo is (1 instantie per process) of niet?

Ik zag ook later dat het nogal onduidelijk was, maar ik bedoel echt een per proces singleton.

In principe is het geen probleem, elk process heeft bv zijn eigen printer singelton, en die regelt access naar een shared resource, bv mbv spooling.

Je kan ook een client/server achtig iets opzetten, waar er slechts 1 process is dat een printer singelton instantieert, en die ondersteund dan RPC (remote procedure call) oid.

Maar op welke manier maakt een proces duidelijk aan een singleton bak (zitten dus meerdere singletons in) welke hij moet hebben?

[Soultaker]

Hmm, ik vind nog steeds dat een object dat alleen 'praktisch' en niet conceptueel singleton is, niet de naam 'singleton' mag krijgen. Misschien denken Gamma e.a. er anders over, maar ik ben erg eigenwijs. (Heb 't boek ook niet hier, om daar wat zinnigers over te melden).

Wat betreft double checked locking; ik las laatst (was dat nou hier?) dat dat in Java helaas niet werkt (zoals je zou verwachten). Nog steeds een beetje mee oppassen dus.

[Zoijar]

Hmmm waarom zou dat niet werken dan? Zolang je een echte mutex hebt...

[Alarmnummer]

Soultaker schreef op 09 augustus 2002 @ 19:47:
Hmm, ik vind nog steeds dat een object dat alleen 'praktisch' en niet conceptueel singleton is, niet de naam 'singleton' mag krijgen. Misschien denken Gamma e.a. er anders over, maar ik ben erg eigenwijs. (Heb 't boek ook niet hier, om daar wat zinnigers over te melden).

Het zit hem dus puur in het feit hoe je er tegen aankijkt. Als je bijvoorbeeld een eventQueue ziet voor AWT dan zou je deze perfect Singleton kunnen maken, aangezien voor de hele applicatie 1 eventqueue nodig is. Maar stel nu dat je 2 applicaties naast elkaar wil draaien dan hebben ze ook hun eigen eventQueue nodig. (En even niet dwars liggen dat ze hem kunnen delen we nemen gewoon even aan dat dit niet kan). Dus op 1 moment is iets echt singleton, maar later is het dus niet meer het enigste object.

Het probleem bij veelvuldig singleton gebruik is dat je soms je systee slecht kan ombouwen tot een systeem waar je dus meerdere gescheiden processen naast elkaar hebt.

[Soultaker]

Zoijar schreef op 09 augustus 2002 @ 20:12:
Hmmm waarom zou dat niet werken dan? Zolang je een echte mutex hebt...

Ik kan helaas het artikel (stond ergens op internet) niet meer vinden, maar het kwam er op neer dat de 'logische' implementatie niet werkte:

code:

if(!instance)
    synchronized
    {
        if(!instance)
            instance = new Singleton;
    };

De reden was geloof ik, dat volgens de specificatie van de Java memory manager, het in theorie voor zou kunnen komen dat er al een geldig geheugenadres geassigned wordt aan 'instance' voordat deze volledig geinitialiseerd is.

Dit kwam dan doordat de Java specificatie stelt dat threads lokaal geheugen mogen bijhouden dat pas gesynchroniseerd hoeft te worden met het 'globale' geheugen op het moment dat een monitor verlaten wordt. Aangezien de eerste check buiten een monitor plaatsvindt, kan ik me voorstellen dat op dat punt slechts een deel van het thread-lokale geheugen (met daarin dus zowel een pointer als een object) gesynchroniseerd zou kunnen zijn. Als de pointer er net wel staat maar de implementatie niet, gaat er wat mis.

De conclusie van het artikel was dat het controleren op gedeeld geheugen echt uitsluitend binnen een monitor mag gebeuren omdat dit soort hacks bijna maar net niet helemaal werken. Omdat Java portable is, kun je in feite geen aannamen doen over de manier van geheugen management, behalve voor zover die in de Java specificatie zijn vastgelegd.

Pin me echter niet op deze uitleg vast; ik heb het niet verzonnen. Voor details moet je bij de specificatie van de Java memory manager zijn.

[Alarmnummer]

Waarom zo moeilijk doen? Je kan gewoon dit doen.

code:

public synchronized EventQueue getInstance(){
    if(s_instance == null){
         s_instance = new EventQueue();
    }
    return s_instance;
}

http://www.javaworld.com/...4-1999/jw-04-toolbox.html

Het enigste probleem aan deze aanpak is dat je iedere statische methode gaat locken, maar zo lang je die niet hebt is er niets aan de hand. Daarnaast heb je natuurlijk altijd wat overhead omdat je na de 1e keer locken (dus het object aanmaken) die lock verder niet meer nodig bent.

[Zoijar]

Soultaker schreef op 09 augustus 2002 @ 20:31:

De reden was geloof ik, dat volgens de specificatie van de Java memory manager, het in theorie voor zou kunnen komen dat er al een geldig geheugenadres geassigned wordt aan 'instance' voordat deze volledig geinitialiseerd is.

Ahhh...ja, zoiets staat me ook bij. C++ had volgens mij een zelfde probleem met optimizing compilers en memory management. De oplossing daar was om de instance pointer als "volatile" te declareren..maaaaar, dat was dan weer implementatie afhankelijk. Waarschijnlijk wel portable, maar niet 100% gegarandeerd. Lijkt erg op jouw verhaal over Java. Zal het nog is opzoeken...race condities zuigen

[Zoijar]

Alarmnummer schreef op 09 augustus 2002 @ 20:49:

Daarnaast heb je natuurlijk altijd wat overhead omdat je na de 1e keer locken (dus het object aanmaken) die lock verder niet meer nodig bent.

Dat was precies de rede om zo moeilijk te doen ja Bij elke access moet je een lock aquire-en. Locks hebben vaak veel overhead omdat het system calls zijn, en zorgen voor een context switch etc.

[Alarmnummer]

Locks zijn tegenwoordig vrij goedkoop. Het snelheidsverschil tussen een Vector en ArrayList zijn vrij klein. Je zou eventueel ook kunnen kiezen voor een eager singleton, dan ben je helemaal van dat geklungel af.

Trouwend dit stuk gaat dus over wat SoulTaker vertelde.

[Soultaker]

Alarmnummer schreef op 09 augustus 2002 @ 21:22:
Je zou eventueel ook kunnen kiezen voor een eager singleton, dan ben je helemaal van dat geklungel af.

Dat is, denk ik, in de meeste gevallen een goede optie. Meestal is er een goede reden voor het bestaan van dat singleton object en is het niet aannemelijk dat hij gedurende de executie niet gebruikt gaat worden. Als je 'm vroeger of later toch gaat gebruiken, dan kun je 'm net zo goed meteen initialiseren. Die overweging hangt natuurlijk af van de feitelijke duur van de initialisatie en het soort applicatie (een servertoepassing mag doorgaans langer initialiseren dan een gebruikersapplicatie).

Trouwens dit stuk gaat dus over wat Soultaker vertelde.

Ah, je hebt het gevonden! Niet hetzelfde artikel als ik gelezen had, maar wel hetzelfde verhaal.

Voor de masochisten in deze thread:
http://www.cs.umd.edu/~pu...odel/DCL-performance.html
Een aantal benchmarks van Doug Lea voor verschillende singleton initialisatiemethoden in Java.

[SG]

Design Pattern is Software Designe Re-Use omdat globaal mensen vaak met gelijke oplossingen komen voor dezelfde problemen en dus steeds het design wiel opnieuw ontwikkellen wat dus met design patterns enigzins vermeden kan worden, hierdoor kan de time to market weer wat verkort worden.

Dus vergelijkbaar met code reuse maar dan op software design niveau.

Dat is wat ik er zover van begrepen heb.

[Alarmnummer]

En een bijkomend voordeel is dat je er nu ook makkelijker met anderen over kan praten omdat ze dus een naam hebben. Verder zijn ze door meerdere mensen getest en dus zijn de voor en nadelen ook bekend.

[edit]
Doordat er een naam aan zit, kan je vaak die naam ook gebruiken in je object:
PersoonDelegate, ExpressionVisitor. Hierdoor wordt je code ook een stuk duidelijker.

[Verwijderd]

Woei! De bibliotheek bleek de Nederlands vertaling () van het GoF (of liever GvV ) boek te hebben, ik ben benieuwd

[Bobco]

Verwijderd schreef op 10 augustus 2002 @ 19:13:
Woei! De bibliotheek bleek de Nederlands vertaling () van het GoF (of liever GvV ) boek te hebben, ik ben benieuwd

Die vertaling heb ik ook, en ik moet zeggen dat het niet echt een geweldige vertaling is. het klopt allemaal wel, maar dit soort boeken leest, ook al omdat er zo ontzettend veel geralteerde documentatie in het Engels is, toch makkelijk in het Engels, IMHO.

[Verwijderd]

/me moet met het schaamrood op de kaken bekennen dat hij nog nooit in de praktijk bewust heeft gewerkt met design patterns, en ook de theorie slechts zeer beperkt onder de knie heeft

... maar dat gaat veranderen. Ik ben nu net bezig met .Net, en wordt daardoor meer dan ooit gedwongen OO te denken / werken / ontwerpen / etc dan ooit tevoren. Na mijn vakantie ga ik het GoF boek eens lezen (Nederlandse versie, bakken geodkoper, de Engelse termen pak ik vanzelf wel op).

Ik ben gisteren wel even aan de hand van dit topic eens wat gaan lezen, en kwam onder andere deze pagina tegen, met een grote verzameling zinvolle gegevens over patterns (niet alleen design patterns, maar bijv. ook analysis patterns):
http://www.enteract.com/~bradapp/docs/patterns-intro.html

Enjoy

[Alarmnummer]

Ik heb het heel snel even wat door gekeken, en het ziet er heel aardig uit. Er staat zelfs iets over anti patterns

[Alarmnummer]

*kick*

om de discussie nog maar even aan de gang te houden

[SG]

Ik ben vooral geinterreseerd in game programming met C++ en kwam in de
Game architekture & Design boek ook voor het eerst design pattern tegen.
Wat ik zeer interresant vind.
En nu zijn ze bezig met 'n boek voor Game design patterns daar zit ik op te wachten maar helaas hebben ze wat publisher problemen.

snik snik.

of is die al uit?

Ps die GoF NL heb ik ook maar vind ik te algemeen voor mijn interresse.

[Alarmnummer]

Design patterns zijn vrij ruim in te zetten, en ik snap niet dat je algemene oo design patterns niet kan toepassen binnen gamedesign. Heb je het boek verder goed doorgekeken of heb je er maar even aan geroken?

[SG]

Game design is een specifiek probleem domein waar 'n aanzienlijk deel van toepassing op is maar niet alles.

En heb het ook over de voorbeelden. zoals verwacht niet overwegend game releated maar das geen probleem want dat is de doelgroep niet van dat boek maar dat is game design patterns wel.
Aangezien Game Architekture & Design er maar oppervlakkig op in gaat om het onderd de aandacht te brengen.

Ben eigenlijk ook opzoek naar 'n goed C++ praktisch Design pattern boek voor MSvC++
Met in de gedachte van Game design dus meer met game voorbeeld.

[Alarmnummer]

Het zijn aanvullende technieken. Dus jij kan mij niet wijsmaken dat GoF te algemeen is voor jouw interesse omdat als je geinteresseerd bent in enige serieuze vorm van oo programmeren en je bent gebonden aan een c++/java/c#/delphi oo programmeer omgeving, dan kan je gewoon niet onder het GoF boek uit.

Ik ben op dit moment bezig in Nice een typeSysteem te maken, en ik pas hier ook volop design patterns toe uit GoF boek en verder in ieder domein waar ik bezig ben maak ik gebruik van deze patterns (en andere). Ik hoef alleen geen visitors meer te maken omdat multimethods/multidispatch onderdeel is van de taal

[Delphi32]

Alarmnummer schreef op 12 augustus 2002 @ 23:00:
Ik hoef alleen geen visitors meer te maken omdat multimethods/multidispatch
onderdeel is van de taal

Ben benieuwd wat

code:

SELECT COUNT(*) FROM GoTForum 
WHERE user = 'Alarmnummer' 
AND replytext LIKE '*multimethods/multidispatch*'

zou opleveren

Ik zie je die termen zo vaak gebruiken, kun je eens uitleggen wat je ermee bedoelt? Ik kan me er (nog) geen voorstelling van maken.

[Soultaker]

Het komt eigenlijk neer op method overloading, waarbij at run-time uitgezocht wordt welke methode uitgevoerd wordt: dit gebeurd dus niet alleen op basis van functienaam (single dispatch) maar ook op basis van de argumenten (multiple dispatch).

Daarbij vind ik de termen multidispatch en multimethods een beetje misplaatst, omdat ze suggereren dat een methode meerdere keren wordt uitgevoerd ofzo. Er wordt niets nieuws ingevoerd, met de uitzondering dat het traditioneel at compile time selecteren van methoden nu at run time kan gebeuren.

Een voorbeeldje staat wel op de nice website:
http://nice.sourceforge.net/visitor.html

Hoewel ik het een elegante manier van programmeren vind, vind ik het jammer dat er eigenlijk geen efficiente implementatie van het concept mogelijk is, juist omdat de selectie dynamisch plaats moet vinden.

[Verwijderd]

Overigens wil ik nog wel een discussiepunt in de strijd werpen, dat meer met (OO) ontwerpen in het algemeen dan met Design Patterns specifiek te maken heeft.

Het lijkt er vaak op dat mensen ontzettend streven naar een optimale oplossing voor alles. Ze willen 1 keer iets designen en daar moet vervolgens alles mee kunnen. Realiteit is echter dat het niet zo is. Zo kleeft aan ieder design zijn beperkingen, en dat is met design patterns natuurlijk net zo goed zo.

Als je dus eenmaal een objectmodel hebt voor een bestaande set functionaliteit, en die functionaliteit verandert, kan dat hele grote impact hebben, zelfs dusdanig dat het hele objectmodel op de schop moet. Dat betekent niet dat het eerste design fout was, maar dat het alleen niet past bij je nieuwe functionele eisen.

Ooit eens gelezen in een stukje over design patterns: Kies altijd eenvoud over generieke oplossingen.

/me vraagt zich af of hij ogen opent of slechts open deuren intrapt met zijn statements

[Soultaker]

Verwijderd schreef op 13 augustus 2002 @ 00:50:
Het lijkt er vaak op dat mensen ontzettend streven naar een optimale oplossing voor alles. Ze willen 1 keer iets designen en daar moet vervolgens alles mee kunnen. Realiteit is echter dat het niet zo is. Zo kleeft aan ieder design zijn beperkingen, en dat is met design patterns natuurlijk net zo goed zo.

Dat is waar, los van het gebruik van design patterns. Maar als je met wat extra moeite nu een hoop problemen van later kan voorkomen, dan is het de moeite waard om nu wat extra tijd te investeren. Als alles 'op de schop' moet is dat erg duur. Liever voorkomen dan genezen dus.

Ooit eens gelezen in een stukje over design patterns: Kies altijd eenvoud over generieke oplossingen.

Dat is ook een erg goed uitgangspunt. De truc is om een ontwerp zo specifiek mogelijk te maken, gebruikmakend van algemene principes. Als je een ontwerp maakt, wat mogelijkheden heeft die je niet nodig hebt, ben je verkeerd bezig. Daar staat echter tegenover dat je ontwerp wel op de toekomst gebouwd moet zijn en het dus mogelijk moet zijn om kleine wijzigingen door te voeren zonder dat het bestaande deel van het ontwerp daardoor onbruikbaar wordt.

Naar mijn ervaring is het ontwerpen van te generieke oplossingen en ontzettend goede manier om je code onnodig complex, moeilijk te testen en praktisch moeilijk bruikbaar te maken.

Waar je dus naar moet streven, is een ontwerp maken dat de essentie van je probleemstelling omvat en waarin entiteiten uit je probleem corresponderen met entiteiten in je ontwerp. De ervaring leert dat dit soort ontwerp goed uit te breiden, aan te passen en her te gebruiken is, in tegenstelling tot een mogelijk ontwerp dat ook prima kan voldoen aan de oorspronkelijke eisen, maar niet daarnaar gemodelleert is.

/me vraagt zich af of hij ogen opent of slechts open deuren intrapt met zijn statements

Ik herken je standpunten wel; mijn ogen waren dus niet helemaal gesloten voor de punten die je onder de aandacht bracht. Dat kan geen kwaad lijkt me, want dat zal vast niet voor iedereen gelden.

[Verwijderd]

Soultaker schreef op 13 augustus 2002 @ 01:05:
[...]

Dat is waar, los van het gebruik van design patterns. Maar als je met wat extra moeite nu een hoop problemen van later kan voorkomen, dan is het de moeite waard om nu wat extra tijd te investeren. Als alles 'op de schop' moet is dat erg duur. Liever voorkomen dan genezen dus.

/me lacht
Het probleem is dat je heel vaak niet weet waar de toekomst toe leidt. Dat geldt helemaal als je dus custom software voor klanten schrijft, want willen in zeker 50% van de gevallen zo'n paar dagen voor de eerste deel-oplevering aan de fundamenten van je software gaan toornen. Been there, done that, wanted to kick the client, was held back by project manager ...

Als je echter software maakt om die onder licentie te gaan verkopen heb je meestal een langere termijn visie voor functionele eisen en wensen, dus komt dat minder vaak en minder extreem voor.

[...]

De truc is om een ontwerp zo specifiek mogelijk te maken, gebruikmakend van algemene principes. Als je een ontwerp maakt, wat mogelijkheden heeft die je niet nodig hebt, ben je verkeerd bezig. Daar staat echter tegenover dat je ontwerp wel op de toekomst gebouwd moet zijn en het dus mogelijk moet zijn om kleine wijzigingen door te voeren zonder dat het bestaande deel van het ontwerp daardoor onbruikbaar wordt.

En deze koorddans tussen specifiek en generiek, pragmatisme en theoretiseren, is misschien wel een van de meest complexe dingen tijdens het maken van een technisch ontwerp.

[Alarmnummer]

Delphi32 schreef op 13 augustus 2002 @ 00:38:
[...]

Ben benieuwd wat

code:

SELECT COUNT(*) FROM GoTForum 
WHERE user = 'Alarmnummer' 
AND replytext LIKE '*multimethods/multidispatch*'

zou opleveren

Ik zie je die termen zo vaak gebruiken, kun je eens uitleggen wat je ermee bedoelt? Ik kan me er (nog) geen voorstelling van maken.

Als je een methode m hebt bij een object a en die heeft argumenten b en c.

code:

class A{
    void m(B b, C c){}
}

Dan zou je hier ook een functie van mogen maken alhoewel dat vanuit oo perspectief vreemd overkomt:
void m(A a, B b, C c){}
Dit is exact hetzelfde alleen een andere manier van schrijven. (Denk hier even goed over na, dit is erg belangrijk).

Stel nu dat A abstract is

code:

abstract class A{
    abstract void  m(B b, C c);
}

en je hebt de volgende 2 kinderen:

code:

class A1 extends A{
    void public m(B b, C c){System.out.println("A1");}
}

class A2 extends A{
    void public m(B b, C c)(System.out.println("A2");)
}

Dan heb je dus 2 methode implementaties:
void m(A1 a, B b, C c){System.out.println("A1");}
void m(A2 a, B b, C c){System.out.println("A2");}

Stel nu dat ik functie m ga aanroepen:
m(new A1(),new B(),new C())
Dan krijg je op je scherm te zien 'A1' omdat de juiste methode wordt gekozen op basis van het 1e argument. De selectie van de methode implementatie vind dus plaats op het 1e argument, en daarom heet dat ook wel single dispatch. Bij een multidispatch methode kan dit over meerdere argumenten plaats vinden, en dat zal ik hieronder even uitlegen.

Stel dat B ook 2 subclasses heeft, B1 en B2 en B is verder abstract. Dan zou ik bij A1 en A2 het volgende kunnen doen:

code:

class A1 extends A{
    void public m(B1 b, C c){System.out.println("A1,B1");}
    void public m(B2 b, C c){System.out.println("A1,B2");}
}

class A2 extends A{
    void public m(B1 b, C c)(System.out.println("A2,B1");)
    void public m(B2 b, C c)(System.out.println("A2,B2");)
}

En ik roep het nu als volgt aan:
m(new A1(),new B2(),new C());

Dan krijg je op je scherm te zien 'A1,B2', omdat je nu de juiste methode hebt gekozen op basis van 2 argumenten (double dispatch).

In het functionele programmeren is het vrij gebruikelijk om op deze manier te werken. Hieronder laat ik een stukje pseudo code zien hoe je types zou kunnen checken in een functionele prog taal:

code:

boolean isSubTypeOf(subType Type, superType Type);

isSubTypeOf(IntType subType ,IntType superType) = true; //een int is een subtype van int

isSubTypeOf(Type subType ,IntType superType) = false; //ieder ander type is geen subtype van een int

isSubTypeOf(RealType subType ,RealType superType) = true;//real is subtype van real

isSubTypeOf(IntType subType ,RealType superType) = true; //int is subtype van real

isSubTypeOf(Type subType ,Type superType)= false;
//ieder ander type van een real (afgezien van int en real dus) is geen subtype.

...

Wat je je hier ziet is dus pattern matching en dat is een uitermate krachtig middel in functionele programmeertalen. Mbv multidispatch heb je dus ook een redelijke versie van pattern matching tot je beschikking. En zoals je ziet heb je dus nu voor alles classes deze functie gedefinieerd in 1 keer en daarom is het ook veel overzichtelijker dan dat je hem over je hele class hierarchie gaat verspreiden. In nice kan je dit allemaal doen met multimethodes. Dit bied je de mogelijkheid om methodes te definieeren buiten objecten, maar je kan ze wel normaal aanroepen: intType.isSubTypeOf(realType), dus je houdt je oo notatie.

Over het algemeen wordt een double dispatch gesimuleerd mbv het visitor design pattern, en zie mijn signature hoe ik daar over denk Maar als je vanuit de taal zelf multi dispatch ondersteuning hebt, dan kan je gewoon veel mooiere code schrijven. En verder kan je met het visitor design pattern er voor zorgen dat je in 1 'class' alles afhandelende methodes hebt mbt een bepaald stuk functionaliteit en dat is dus ook iets wat je met een multimethod kan oplossen.

Ik hoop dat je er iets van hebt begrepen

[Alarmnummer]

Verwijderd schreef op 13 augustus 2002 @ 00:50:
Overigens wil ik nog wel een discussiepunt in de strijd werpen, dat meer met (OO) ontwerpen in het algemeen dan met Design Patterns specifiek te maken heeft.

Het lijkt er vaak op dat mensen ontzettend streven naar een optimale oplossing voor alles. Ze willen 1 keer iets designen en daar moet vervolgens alles mee kunnen. Realiteit is echter dat het niet zo is. Zo kleeft aan ieder design zijn beperkingen, en dat is met design patterns natuurlijk net zo goed zo.

Als je dus eenmaal een objectmodel hebt voor een bestaande set functionaliteit, en die functionaliteit verandert, kan dat hele grote impact hebben, zelfs dusdanig dat het hele objectmodel op de schop moet. Dat betekent niet dat het eerste design fout was, maar dat het alleen niet past bij je nieuwe functionele eisen.

Ooit eens gelezen in een stukje over design patterns: Kies altijd eenvoud over generieke oplossingen.

/me vraagt zich af of hij ogen opent of slechts open deuren intrapt met zijn statements

Ik denk dat je een paar open deuren intrapt

Ik streef niet naar continue reuse door de meest generieke aanpak als daardoor het minder duidelijk is, en daar streven design patterns ook niet naar. Design patterns zijn juist vast gebruikte oplossingen die niet gebundeld kunnen worden in een generieke api.

Jij maakt ook gebruik van design patterns, maar je weet de naam er niet echt voor. De kans bestaat dat je dezelfde manier van aanpak 20 keer doet en iedere keer een beetje anders. En daarnaast is het ook superlastig om met je collega`s over te praten. Met design patterns heb je dus manieren van aanpak met een duidelijke naam en duidelijke voor en nadelen waar je veel handiger mee leert te programmeren.

[Alarmnummer]

Soultaker schreef op 13 augustus 2002 @ 00:49:
Het komt eigenlijk neer op method overloading, waarbij at run-time uitgezocht wordt welke methode uitgevoerd wordt: dit gebeurd dus niet alleen op basis van functienaam (single dispatch) maar ook op basis van de argumenten (multiple dispatch).

foei foei keuze op methode naam is geen single dispatch. Keuze op alleen het 1e argument is single dispatch. Kijk maar eens naar mijn reply.

Daarbij vind ik de termen multidispatch en multimethods een beetje misplaatst, omdat ze suggereren dat een methode meerdere keren wordt uitgevoerd ofzo. Er wordt niets nieuws ingevoerd, met de uitzondering dat het traditioneel at compile time selecteren van methoden nu at run time kan gebeuren.

Ik vind de naam multimethod ook een beetje vreemd, maar misschien dat het een combi is tussen method en multi dispatch. Ik denk dat het iets voor de hand liggender is dan jouw verklaring.

Hoewel ik het een elegante manier van programmeren vind, vind ik het jammer dat er eigenlijk geen efficiente implementatie van het concept mogelijk is, juist omdat de selectie dynamisch plaats moet vinden.

Functioneel programmeren is meestal ook niet de meest efficiente aanpak, maar weerhoud jou dat ervan om het te gebruiken? (voor de juiste problemen natuurlijk). En trouwens java is static multi dispatch dus alleen als je het dynamisch wilt doen gaat het wat tijd kosten

[Soultaker]

Alarmnummer schreef op 13 augustus 2002 @ 01:44:
foei foei keuze op methode naam is geen single dispatch. Keuze op alleen het 1e argument is single dispatch. Kijk maar eens naar mijn reply.

Je hebt helemaal gelijk. Ik weet ook niet hoe ik er bij kwam om die onzin uit te kramen; ik had 't eigenlijk wel geweten. Het is ook al laat.

[Alarmnummer]

Soultaker schreef op 13 augustus 2002 @ 02:05:
[...]

Je hebt helemaal gelijk. Ik weet ook niet hoe ik er bij kwam om die onzin uit te kramen; ik had 't eigenlijk wel geweten. Het is ook al laat.

Het is ook een beetje verneukeratief omdat het 1e argument van een method dus het object is waar je de methode op aanroept en je die eigelijk vergeet. Het is je vergeven

Trouwens ik raad je echt aan om eens iets met nice te gaan maken. Ik zet op dit moment mijn ide`s (codeguide en idea) volledig aan de kant om gebruik te maken van Nice. Ik heb een dosprompt(ant), editplus en explorer en ik wil niet anders meer

Nice = Fantastisch. En er komen nog een hele lading features bij terwijl ik nog maar een klein gedeelte heb toegepast.

[Verwijderd]

Alarmnummer schreef op 13 augustus 2002 @ 02:07:
Trouwens ik raad je echt aan om eens iets met nice te gaan maken. Ik zet op dit moment mijn ide`s (codeguide en idea) volledig aan de kant om gebruik te maken van Nice. Ik heb een dosprompt(ant), editplus en explorer en ik wil niet anders meer

Nice = Fantastisch. En er komen nog een hele lading features bij terwijl ik nog maar een klein gedeelte heb toegepast.

Ik dacht dat je net weer aan C++ begonnen was
C++ heeft alles wat Nice heeft, en meer (prove me wrong ).

[.oisyn]

C++ heeft geen multidispatch

[Verwijderd]

.oisyn schreef op 13 augustus 2002 @ 04:03:
C++ heeft geen multidispatch

Jij hebt duidelijk hoofdstuk 11 uit Alexandrescu's Modern C++ Design niet gelezen .

Ik ben er zelf ook nog druk mee bezig, maar de volgende Nice code:

code:

class Visitor
{
  public void visit (Base e); 

  visit (e@Base) { /* ... */ }
  visit (e@DerivedA) { /* ... */ }
  visit (e@DerivedB) { /* ... */ }
}

zou je met wat generieke support code in C++ kunnen schrijven als:

code:

struct Visitor
{
  void Visit (Base & e) { Dispatcher<Base, DerivedA, DerivedB>::go(e, this); }

  void visit (Base & e) { /* ... */ }
  void visit (DerivedA & e) { /* ... */ }
  void visit (DerivedB & e){ /* ... */ }
};

Het enige 'nadeel' ten opzichte van de Nice methode is dat je even een dispatcher moet aanroepen met een lijstje typen die je wil opvangen.

Voor informatie over hoe de Dispatcher etc. werkt moet ik je helaas naar het genoemde boek verwijzen, het is simpelweg teveel stof om hier even samen te vatten.

Ik ben zelf momenteel bezig aan een nog betere dispatcher die op zo veel parameters moet kunnen gaan dispatchen als de compiler parameters aankan .

[Verwijderd]

Verwijderd schreef op 13 augustus 2002 @ 04:46:
Ik ben zelf momenteel bezig aan een nog betere dispatcher die op zo veel parameters moet kunnen gaan dispatchen als de compiler parameters aankan .

Hij's op een paar kleine details na af, alleen krijgt Borland er nu ICE's van .

Echt verschrikkelijk om, ondanks dat de code valid is (Comeau), niet zelf van het resultaat te kunnen genieten .

Mijn dispatcher bevat nu precies dezelfde functionaliteit als de Nice multi-methods: dispatch op alle parameters.

[Alarmnummer]

Verwijderd schreef op 13 augustus 2002 @ 04:46:
[...]
Jij hebt duidelijk hoofdstuk 11 uit Alexandrescu's Modern C++ Design niet gelezen .

Ik ben er zelf ook nog druk mee bezig, maar de volgende Nice code:[code]class Visitor
...
Ik ben zelf momenteel bezig aan een nog betere dispatcher die op zo veel parameters moet kunnen gaan dispatchen als de compiler parameters aankan .

Wat hier staat is een visitor, en dit is niets anders dan een gesimuleerde manier voor double (niet eens multi) dispatch. Dus met jouw voorbeeld heb je niet aangetoont dat c++ multidispatch heeft (zelfs niet mbv simulatie).

Trouwens iedereen kan wel een multidispatch support class schrijven (gebeurd dus onder de grond bij nice) maar het is makkelijker als je vanuit de taal ondersteuning hebt.

En verder kan je bij Nice ook buiten een class een methode toevoegen (zelfs als deze niet direct bij de class is gedefinieerd), ik geloof ook niet dat dit kan bij c++.

En verder gaat het juist om die native support vanuit de taal en niet meer te hoeven werken met al die kunstgrepen die je code obfuscaten.

[Soultaker]

Alarmnummer schreef op 13 augustus 2002 @ 07:34:
En verder kan je bij Nice ook buiten een class een methode toevoegen (zelfs als deze niet direct bij de class is gedefinieerd), ik geloof ook niet dat dit kan bij c++.

Door de aanwezigheid van globale functies en multiple implementation inheritance is dat ook niet nodig. In principe is het idee van objectgeorienteerd programmeren juist dat je al functionaliteit groepeert in klassen. Het is vanuit dat oogpunt niet logisch of zinnig om toe te staan dat methoden van een klasse buiten die klasse gedefinieerd kunnen worden.

Als je bepaalde functionaliteit wilt toevoegen aan een C++ klasse, heb je twee opties: ofwel je maakt een derived (template) class, die de gewenste methode toevoegt, ofwel je definieert een globale functie die zowel een object van de gewenste klasse als eventuele argumenten accepteert. Beperking van beide methoden is wel dat ze alleen van de publieke (of hooguit protected) interface van de klasse gebruik kunnen maken.

Zoals je misschien wel weet ondertussen, ben ik een voorstander van statische type checking. Ik vind het dus wel prettig dat een klasse eenmaal gecompileerd is, deze later niet meer uitgebreid kan worden.

[Alarmnummer]

Soultaker schreef op 13 augustus 2002 @ 14:30:
[...]
In principe is het idee van objectgeorienteerd programmeren juist dat je al functionaliteit groepeert in klassen. Het is vanuit dat oogpunt niet logisch of zinnig om toe te staan dat methoden van een klasse buiten die klasse gedefinieerd kunnen worden.

Dit ben ik niet helemaal met je eens. Als je leert oo proggen dan leer je inderdaad om alles netjes in 1 object te stoppen, zowel data als methodes over die data. Je bent nu relevante dingen bij elkaar aan het bundelen.

Maar moet deze aanpak zo strict worden toegepast binnen oo? Als je toch bezig bent om relevante zaken bij elkaar te bundelen, dan zou je ook functionaliteit kunnen bundelen. Bill Venners heeft al een aantal leuke stukken op javaworld gezet en een van zijn stukken op zijn eigen site die me wel aanspreekt is Guideline 2. See objects as bundles of behavior, not bundles of data En ik ben het eigelijk met hem eens. Je moet functionaliteit bij elkaar bundelen zodat je een goed overzicht krijgt ipv dat alle code over meerdere classes verspreid is.

Verder denk ik ook niet dat je halstarrig aan bepaalde paradigma`s moet vasthouden. Ieder paradigma heeft zijn eigen sterke en zwakke punten, en je moet gewoon de juiste kiezen voor een probleem. En daarbij vind ik het niet erg om een functioneel paradigma (multimethods) te combineren met het object georienteerde paradigma.

Over het algemeen kun je dus veel dingen beter uitdrukken mbv een functionele taal, maar je kan er geen applicatie in schrijven omdat het op sommige punten te beperkt is. Daarom vind ik nice dus ook zo mooi, omdat ik ook kan als ik imperatief moet en functioneel kan als ik functioneel wil. Ik zie het eerder als een verrijking dan als een overtreding.

Als je bepaalde functionaliteit wilt toevoegen aan een C++ klasse, heb je twee opties: ofwel je maakt een derived (template) class, die de gewenste methode toevoegt, ofwel je definieert een globale functie die zowel een object van de gewenste klasse als eventuele argumenten accepteert. Beperking van beide methoden is wel dat ze alleen van de publieke (of hooguit protected) interface van de klasse gebruik kunnen maken.

Je kan met java ook wel met een statische class functioniteit toevoegen aan een bepaald object, zie bv de Collection class. Maar kan je het dan ook op de 'oo' manier aanspreken in c++?

dus persoon.doeIets()

en doeIets is buiten persoon gedefinieerd. In Nice kan dit namelijk wel.

[.oisyn]

Verwijderd schreef op 13 augustus 2002 @ 04:46:
[...]
Jij hebt duidelijk hoofdstuk 11 uit Alexandrescu's Modern C++ Design niet gelezen .

Ik bedoel dat C++ als taal het niet in zich heeft
In C kun je ook OO simuleren, maar dat maakt C nog geen OO taal

[Soultaker]

Alarmnummer schreef op 13 augustus 2002 @ 14:50:
Maar moet deze aanpak zo strict worden toegepast binnen oo? Als je toch bezig bent om relevante zaken bij elkaar te bundelen, dan zou je ook functionaliteit kunnen bundelen.

'Bundelen' betekent wat mij betreft dan ook op dezelfde plek definieren.

Je moet functionaliteit bij elkaar bundelen zodat je een goed overzicht krijgt ipv dat alle code over meerdere classes verspreid is.

Uiteraard, maar globale functies in C++ worden juist vaak gebruikt wanneer gedrag niet duidelijk bij de ene of andere klasse past. Een praktijkvoorbeeld is een output stream (ostream), die een '<<' operator heeft om er data in te stoppen. Die methode zelf is overloaded om chars, ints, strings, floats, etc. te kunnen verwerken.

Wanneer ik echter een nieuwe datastructuur verzin, noem 'm X, dan wil ik misschien ook wel dat ik die datastructuur in een output stream kan stoppen. In C++ is het nu niet mogelijk om de methode aan de ostream toe te voegen, maar WEL om de '<<' operator te overloaden, zodat ik mijn datastructuur kan invoeren in termen van bestaande defintiies van de '<<' operator. Het zou niet logisch zijn om deze methode aan de ostream klasse toe te voegen, aangezien deze hierdoor onnodig veel bindingen met andere klassen krijgt. Er zijn normaliter tientallen typen die in een output stream gestopt kunnen worden en de code voor de implementatie daarvan hoort uiteraard niet in de ostream klasse thuis, omdat deze afhankelijk is van de implementatie van de specifieke datastructuur die wordt uitgevoerd.

De enige correcte oplossing is dan om de '<<' operator globaal te overloaden en te implementeren bij mijn nieuwe datastructuur X. Zoiets dus:

code:

class X
{
        friend ostream& operator<<(ostream &str, const X &data);
        int a, b;
public:
        X(int a, int b) : a(a), b(b) { };
};

ostream &operator<<(ostream &str, const X &data)
{
        str << data.a << " " << data.b;
}

Ik vind dit een mooie oplossing, omdat het duidelijk uitdrukt dat de << operator bij zowel de ostream klasse als bij de X klasse hoort. In een taal die dit soort constructies niet ondersteund, ben je verplicht een keuze te maken: bij welke klasse hoort de << operator? Duidelijk niet bij de ostream, maar onderbrengen bij de X klasse is ook niet mogelijk, aangezien het dan niet mogelijk is om X objecten net zo in een ostream te stoppen als basic types.

Ik wil hiermee niet betogen dat een pure OO oplossing niet goed zou zijn, maar het is niet reeel om te denken dat het in alle situaties de enige of beste oplossing is.

Verder denk ik ook niet dat je halstarrig aan bepaalde paradigma`s moet vasthouden. Ieder paradigma heeft zijn eigen sterke en zwakke punten, en je moet gewoon de juiste kiezen voor een probleem. En daarbij vind ik het niet erg om een functioneel paradigma (multimethods) te combineren met het object georienteerde paradigma.

Helemaal mee eens en dat komt eigenlijk overeen met wat ik hierboven betoog.

Over het algemeen kun je dus veel dingen beter uitdrukken mbv een functionele taal, maar je kan er geen applicatie in schrijven omdat het op sommige punten te beperkt is. Daarom vind ik nice dus ook zo mooi, omdat ik ook kan als ik oo moet en functioneel kan als ik functioneel wil. Ik zie het eerder als een verrijking dan als een overtreding.

En wat dat betreft vind ik C++ ook erg mooi, aangezien me toegestaan wordt om op een imperatieve wijze te werken waar dat in Java en Nice nice niet mogelijk is.

Het mooie van een taal als Java is dat alles eenvoudig is en het aantal concepten beperkt. Hierdoor is de taal redelijk goed te begrijpen en eenvoudig te leren. Wanneer je echter heel veel gaat programmeren en dus de moeite kunt besteden aan het doorgronde van een complexe programmeertaal, zul je uiteindelijk blij zijn dat je niet vast zit aan een enkel paradigma maar juist de meest geschikte werkwijze kunt kiezen bij het oplossen van elk probleem. Maar dat zij jij al.

[whoami]

* whoami heeft vandaag het GoF boek aangeschaft.
_{Tot zover deze niet-tot-de-discussie-bijdragende post}

[Verwijderd]

Alarmnummer schreef op 13 augustus 2002 @ 07:34:
Dus met jouw voorbeeld heb je niet aangetoont dat c++ multidispatch heeft (zelfs niet mbv simulatie).

Met m'n verse multi-dispatcher kan dit:

code:

struct A { virtual ~A() {} };  struct B : A {};
struct C { virtual ~C() {} };  struct D : C {};
struct E { virtual ~E () {} };  struct F : E {};

struct S
{
  void operator() (A &, C &, E &) { std::cout << "a, c, e\n"; }
  void operator() (A &, C &, F &) { std::cout << "a, c, f\n"; }
  void operator() (A &, D &, E &) { std::cout << "a, d, e\n"; }
  void operator() (A &, D &, F &) { std::cout << "a, d, f\n"; }
  void operator() (B &, C &, E &) { std::cout << "b, c, e\n"; }
  void operator() (B &, C &, F &) { std::cout << "b, c, f\n"; }
  void operator() (B &, D &, E &) { std::cout << "b, d, e\n"; }
  void operator() (B &, D &, F &) { std::cout << "b, d, f\n"; }
};

void g (A & a, C & c, E & e)
{
  S s;

  Dispatcher<MakeList<MakeList<B, A, A>::type,
                      MakeList<D, C, C>::type,
                      MakeList<F, E, E>::type>::type, void>::dispatch(s, &a, &c, &e);
}

int main ()
{
  B b; D d; F f;
  g (b, d, f); // output: b, d, f
}

Trouwens iedereen kan wel een multidispatch support class schrijven (gebeurd dus onder de grond bij nice) maar het is makkelijker als je vanuit de taal ondersteuning hebt.

Mwuah, is een kwestie van smaak. Ik vind het terecht dat een dergelijke feature niet built-in in C++ zit. Het is namelijk niks anders dan voor iedere parameter een aantal dynamic_cast's proberen, en dit is dan ook redelijk eenvoudig te automatiseren (zie mijn voorbeeld). (En over de analogie met 'in C kan je ook OO proggen': ik vind deze feature niet built-in-waardig, OO wel.)

En verder kan je bij Nice ook buiten een class een methode toevoegen (zelfs als deze niet direct bij de class is gedefinieerd), ik geloof ook niet dat dit kan bij c++.

Zie replies Soultaker, ik vind het kunnen aanroepen van extern toegevoegde 'methods' met de normale method aanroep syntax absoluut geen 'waardige' feature. C++ heeft het overigens niet, daar heb je helemaal gelijk in.

En verder gaat het juist om die native support vanuit de taal en niet meer te hoeven werken met al die kunstgrepen die je code obfuscaten.

Again, kwestie van smaak . (In het voorbeeld hierboven vind ik het zowieso al ontzettend meevallen.)

[Soultaker]

whoami schreef op 13 augustus 2002 @ 19:31:
* whoami heeft vandaag het GoF boek aangeschaft.
_{Tot zover deze niet-tot-de-discussie-bijdragende post}

Ban! Off-topic geneuzel kunnen we niet tolereren!

_{Oh, shit...}

[Alarmnummer]

Verwijderd schreef op 13 augustus 2002 @ 19:38:
[...]
Mwuah, is een kwestie van smaak. Ik vind het terecht dat een dergelijke feature niet built-in in C++ zit. Het is namelijk niks anders dan voor iedere parameter een aantal dynamic_cast's proberen, en dit is dan ook redelijk eenvoudig te automatiseren (zie mijn voorbeeld).

Er zijn wel meer constructies te schrijven op een andere manier maar ze zijn toegevoegd aan de taal omdat ze een bepaalde betekenis hebben, zoals multidispatch dat ook heeft. Daarom vind ik het dus een uitstekend argument om het op te nemen in de taal.

En hou er rekening mee dat niet iedere taalfeature zo groot hoeft te zijn als bv oo, als het maar een bepaalde betekenis kan uitdrukken dan kan het naar mijn mening opgenomen worden (dit is nog redelijk onder voorbehoud, opnemen moet natuurlijk wel met beleid gaan).

(En over de analogie met 'in C kan je ook OO proggen': ik vind deze feature niet built-in-waardig, OO wel.)

Dat heb ik ook niet gezegd. Dat is hetzelfde als je zegt dat je in asm functioneel kan programmeren

Zie replies Soultaker, ik vind het kunnen aanroepen van extern toegevoegde 'methods' met de normale method aanroep syntax absoluut geen 'waardige' feature. C++ heeft het overigens niet, daar heb je helemaal gelijk in.

Je zou het kunnen aanroepen als een functie, of als een methode. Aangezien er weinig verschil is tussen een functie en een methode vind ik dat je in wezen ieder functie op deze manier zou mogen schrijven voor het 1e argument.

Wat nice doet is dus het verschil tussen een methode en een functie weghalen en gewoon 2 willekeurige notaties hanteren terwijl java en c++ 2 notaties afhankelijk van de plek waar je de methode/functie hebt gedeclareerd.

Je kan zeggen dat een mehode in oo aan een object zit, en een functie niet en daarom dat argument is ingevoerd. Maar als je er goed naar kijkt, dan zie je dat er geen verschil bestaat dus waarom dan nog een verschil in syntax? Bij nice krijg je tenminste nog de mogelijkheid om te kiezen terwijl je dit in java en c++ niet kan.

Again, kwestie van smaak . (In het voorbeeld hierboven vind ik het zowieso al ontzettend meevallen.)

Ik dus niet. Je moet vrij veel code schrijven tov de afhandelende code. Ok, ik weet dat het geen complexe source is als je weet hoe het werkt, maar waarom zo moeilijk doen als dit gewoon een feature is in een taal? Ik werk zelf al een tijd met visitors en je moet altijd bij de visitable classes een accepts methode maken, en da nog een keer een visitor interface. Dit is vrij onnodig werk, en het is een design pattern: een tekort koming in de taal die opgelost moet worden mbv een construtie. Waarom nog design pattern als je het als feature in de taal kan krijgen.

Wat me trouwens wel opvalt is dat c++ programmeurs erg vast hangen aan hun taal. Op zich is dat niet erg, maar het wel erg belangrijk om je te realiseren dat er ook andere aanpakken kunnen zijn. Ik weet niet in hoeverre jij je ook verdiept in andere talen/paradigma`s, maar het is wel belangrijk dat je verder kijkt dan je c++ neus lang is.

[Verwijderd]

Alarmnummer schreef op 13 augustus 2002 @ 20:17:
Dat heb ik ook niet gezegd. Dat is hetzelfde als je zegt dat je in asm functioneel kan programmeren

Dat was even terzijde voor .oisyn :

.oisyn schreef op 13 augustus 2002 @ 15:13:
In C kun je ook OO simuleren, maar dat maakt C nog geen OO taal

Alarmnummer [vervolg]:
Wat me trouwens wel opvalt is dat c++ programmeurs erg vast hangen aan hun taal.

Hmm, hoe verklaar je dat?

Op zich is dat niet erg, maar het wel erg belangrijk om je te realiseren dat er ook andere aanpakken kunnen zijn. Ik weet niet in hoeverre jij je ook verdiept in andere talen/paradigma`s, maar het is wel belangrijk dat je verder kijkt dan je c++ neus lang is.

Ik probeer wel af en toe wat nieuws, alleen heb ik simpelweg nog geen taal gevonden die beter bij mij past dan C++ (voor applicaties e.d., scripts is een andere zaak (Ruby )). Wat betreft Java: onlangs vertelde ik je nog uitgebreid wat ik (persoonlijk!) van Java vs. C++ vind.

Wat betreft functioneel programmeren: ongeveer anderhalve maand geleden ben ik een discussietopic begonnen over het hoe en waarom van functioneel programmeren, en mijn problemen met het waarderen van dat paradigma.

Andere paradigma's zijn vaak hardstikke schattig en verfrissend, maar ze worden niet voor niks door vrijwel niemand gebruikt .

[Alarmnummer]

Verwijderd schreef op 13 augustus 2002 @ 21:28:

Hmm, hoe verklaar je dat?

Hmmzz.. ik denk een typisch c++ antwoord

Het is erg belangrijk dat je ook met andere talen in aanraking komt. Misschien zijn ze niet altijd praktisch inzetbaar maar de concepten maken je wel dingen duidelijk die je eventueel kan toepassen binnen c++.

Andere paradigma's zijn vaak hardstikke schattig en verfrissend, maar ze worden niet voor niks door vrijwel niemand gebruikt .

Ik vond AOP wel verfrissend en praktisch toepasbaar, en Nice zijn combinatie van functioneel met oo paradigma geeft me de mogelijkheid om functioneel te programmeren binnen oo. En dat vind ik persoonlijk erg opwindend *it`ers raken van de gekste dingen opgewonden*

Maar wat voor opleiding doe je? Als het goed is kom je op zowel met de HTS als met de Uni met verschillende paradigma`s in aanraking.

Maar zullen we weer proberen om on topic te komen?

[Verwijderd]

Alarmnummer schreef op 13 augustus 2002 @ 21:38:
Maar wat voor opleiding doe je? Als het goed is kom je op zowel met de HTS als met de Uni met verschillende paradigma`s in aanraking.

Over enkele weken begin ik aan het tweede semester van het eerste jaar HBO Informatica. Ik ben eventueel van plan om meteen na dit eerste propedeusejaar in februari over te stappen op een universiteit, maar daarvoor moet ik wel even de laatste drie jaar vwo wiskunde in een half jaartje inhalen .

Dit aankomende semester wordt bij ons als ik het mij goed herinner C geintroduceert .

_{Edit: Jaja, eerst zelf een offtopic vraag stellen, en dan terwijl ik een reply zit te tikken snel even erbij editen dat we ontopic dienen te blijven .}

[Zoijar]

Alarmnummer schreef op 13 augustus 2002 @ 21:38:
*it`ers raken van de gekste dingen opgewonden*

Ikke van mn accountje op dit juweeltje hier En op de een of andere vage rede van standaard C++ Hmm anyway...deze post had een rede behalve die vette bak te showen, maar ben het vergeten

Ohja, over paradigms, dit is wel een grappig boekje. Worden veel talen kort theoretisch in besproken.

[Soultaker]

Alarmnummer schreef op 13 augustus 2002 @ 20:17:
Wat me trouwens wel opvalt is dat c++ programmeurs erg vast hangen aan hun taal. Op zich is dat niet erg, maar het wel erg belangrijk om je te realiseren dat er ook andere aanpakken kunnen zijn. Ik weet niet in hoeverre jij je ook verdiept in andere talen/paradigma`s, maar het is wel belangrijk dat je verder kijkt dan je c++ neus lang is.

Dat vind ik een beetje een domme uitspraak, zeker nu ik al zo lang met je discussieer en je toch zou moeten weten dat het niet opgaat. Ik heb met een verscheidenheid aan talen gewerkt. Natuurlijk verschilt de mate van beheersing van de verschillende talen, maar ik durf wel te beweren dat ik met verschillende programmeerparadigma's ervaring heb. Misschien was je uitspraak voornamelijk op Sneechy toegespitst, maar dan had je die wel wat minder algemeen mogen formuleren.

De reden dat C++ vrijwel altijd weer genoemd wordt, is dat het een erg utigebreide en veelzijdige taal is. Veel van de kenmerken van andere talen vind je er in terug en als door de industrie geaccepteerde taal is het dan ook een erg geschikte taal om als referentiekader vanuit te gaan.

[Alarmnummer]

Soultaker schreef op 14 augustus 2002 @ 01:02:
Dat vind ik een beetje een domme uitspraak

Ojee, meteen een domme uitspraak ook nog

zeker nu ik al zo lang met je discussieer en je toch zou moeten weten dat het niet opgaat. Ik heb met een verscheidenheid aan talen gewerkt. Natuurlijk verschilt de mate van beheersing van de verschillende talen, maar ik durf wel te beweren dat ik met verschillende programmeerparadigma's ervaring heb.

Je voelt je wel een beetje aangesproken

Misschien was je uitspraak voornamelijk op Sneechy toegespitst, maar dan had je die wel wat minder algemeen mogen formuleren.

Het was meer gericht op c++ programmeurs in het algemeen en vooral vaak hun blinde overtuiging dat hun taal alles is en de rest kut is. Als je toch veel met andere paradigma`s bezig bent geweest dan kan je zelf bedenken dat het niet voor jou van toepassing is, maar meer voor het gros c++ programmeurs.

Daarom vind ik mijn uitspraak ook niet 'dom' zoals jij het zo netjes weet uit te drukken, maar eerder algemeen. Dit had jezelf ook wel een beetje kunnen bedenken.

De reden dat C++ vrijwel altijd weer genoemd wordt, is dat het een erg utigebreide en veelzijdige taal is. Veel van de kenmerken van andere talen vind je er in terug en als door de industrie geaccepteerde taal is het dan ook een erg geschikte taal om als referentiekader vanuit te gaan.

Dat weten we intussen wel