[Article] C# & design patterns.

[whoami]

Voor de mensen die bezig zijn met C# en design patterns (of geinteresseerd zijn), is dit misschien wel een interessant artikel:
Illustrated GOF Design Patterns in C# Part I: Creational

De patterns die in het GoTF boek besproken worden, worden hier mbv C# geimplementeerd.

[whoami]

Ik kix0r deze nog maar ff.

[Alarmnummer]

ieks... enumeratie types met integers

Maar verder leuk om die design patterns ook in c# te zien (alhoewel je c++ voorbeelden uit het gof boek ook wel kan begrijpen).

[edit]
daarnaast staat er in het gof boek ook uitleg en vooral de voors en tegens op een bepaald design pattern vind ik erg belangrijk.

[whoami]

Ja, tuurlijk. Maar altijd leuk om eens een implementatie in een andere taal te zien, gewoon omdat C# bepaalde dingen heeft die C++ niet heeft (interfaces bv).

Waar zie jij enum types met integers? In C++ stelt ieder enum type eigenlijk een integer voor.

[Alarmnummer]

Ik zie het bij die factory methode.

En verder is een enumeratie type niet hetzelfde als een integer. Dat de compiler er een leuk getal van maakt,. wil niet zeggen dat een enumeratie type gelijk is aan een integer type. Tenslotte is dit onzin:
enum fruit {appel,peer,banaan,...}
int x = appel + peer;

Als je gebruik maakt van een echt enumeratie type, dan kan je minder logische fouten krijgen.

[Alarmnummer]

Oja.. hij maakt verder ook nog gebruik van magic numbers in die methode

[Alarmnummer]

Ik vind het trouwens wel enorm naadje aan c++ dat je niet kan opdwingen dat een class geen methode definities mag hebben (alleen declaraties). BIj een interface is dit wel mogelijk (kan zelfs niet eens anders) en doordat je veel met interfaces werkt kan je proxy achtige stappen invoeren. Ik heb mezelf er al op betrapt dat ik toch ging implementeren bij zo`n class (lekker makkelijk), maar later zat ik van: ohh.. daar moet nog een proxy tussen.

[whoami]

Alarmnummer schreef op 07 november 2002 @ 15:35:
Ik vind het trouwens wel enorm naadje aan c++ dat je niet kan opdwingen dat een class geen methode definities mag hebben (alleen declaraties). BIj een interface is dit wel mogelijk (kan zelfs niet eens anders) en doordat je veel met interfaces werkt kan je proxy achtige stappen invoeren. Ik heb mezelf er al op betrapt dat ik toch ging implementeren bij zo`n class (lekker makkelijk), maar later zat ik van: ohh.. daar moet nog een proxy tussen.

Hmm. Kan toch wel? 't is al een tijdje geleden dat ik nog C++ gedaan heb, maar ik dacht dat C++ wel het keyword abstract kent voor classes?
Je kunt alleszins wel pure virtual functions (abstract dus) maken in C++

[Alarmnummer]

Ik doe inderdaad ook alles met virtuele functies, maar bij een interface kan je garanderen dat niemand loopt te implementeren, volgens mij kan je dat met c++ niet voor elkaar krijgen.

[Soultaker]

whoami schreef op 07 November 2002 @ 15:28:
Waar zie jij enum types met integers? In C++ stelt ieder enum type eigenlijk een integer voor.

Maar het is wel een apart type, in die zin, dat je niet de ene enum-variable voor de andere kan substitueren (ook al hebben ze dezelfde integer waarde).

Alarmnummer schreef op 07 November 2002 @ 15:35:
Ik vind het trouwens wel enorm naadje aan c++ dat je niet kan opdwingen dat een class geen methode definities mag hebben (alleen declaraties).

Hoe stel je je dat voor dan? Als je wil dat je klasse geen implementatie heeft, dan maak je je methoden toch pure virtual? Dan kan een afgeleide klasse ze wel alsnog implementeren, natuurlijk, maar het lijkt me ook niet zinnig om methoden te hebben die nooit geïmplementeert kunnen worden.

[whoami]

Hmmm... Idd. In VC++.NET heb je wel het __abstract keyword, maar dat kan enkel gebruikt worden in managed code.
In GNU C++ kan je met het keyword signature een volledig abstracte class definieren.

[whoami]

Soultaker schreef op 07 november 2002 @ 16:09:


Hoe stel je je dat voor dan? Als je wil dat je klasse geen implementatie heeft, dan maak je je methoden toch pure virtual? Dan kan een afgeleide klasse ze wel alsnog implementeren, natuurlijk, maar het lijkt me ook niet zinnig om methoden te hebben die nooit geïmplementeert kunnen worden.

Alarmnummer bedoelt dat je niet kan garanderen dat er niemand anders een niet pure virtual function aan die base class toevoegd.
Maar ook met het keyword abstract ervoor oid kan je dat niet. Dat keyword is makkelijk te deleten. (Zelfs met een interface garandeer je dat niet -> interface wijzigen in class). (Dan heb je - in Java en C# - wel de kans dat de compiler zal lopen klagen over multiple inheritance).

[Alarmnummer]

Het probleem zit hem dus in duidelijkheid. Ik wil mezelf graag helpen om mijn code beter te begrijpen. Als ik een interface zie, dan weet ik gewoon dat er geen implementaties zijn, maar bij een class kan ik dat niet zien. Ik zal dan iedere methode bij langs moeten om te kijken of er niet per ongeluk een implementatie is. En verder kan je aan een class ook members toevoegen, en dat kan je bij een interface ook niet.

[whoami]

Alarmnummer schreef op 07 november 2002 @ 16:20:
Het probleem zit hem dus in duidelijkheid. Ik wil mezelf graag helpen om mijn code beter te begrijpen. Als ik een interface zie, dan weet ik gewoon dat er geen implementaties zijn, maar bij een class kan ik dat niet zien. Ik zal dan iedere methode bij langs moeten om te kijken of er niet per ongeluk een implementatie is. En verder kan je aan een class ook members toevoegen, en dat kan je bij een interface ook niet.

commentaar toevoegen.

[Alarmnummer]

#define INTERFACE class

maarja.. dan heb je nog geen garantie

[Verwijderd]

Ik vind het altijd vreemd als iemand een taal "naadje" vindt omdat hij meer kan dan de voorkeurstaal van de persoon in kwestie.

Het is natuurlijk vij absurd om te argumenteren dat iemand methods gaat toevoegen aan een abstract baseclass, terwijl dat argument net zo goed opgaat voor een interface. Overigens kun je in C++ prima aangeven dat een method niet geimplementeerd is:

C++:

class Base {
public:
    virtual ~Base() {}
    virtual void do_something() = 0;
};

Knap als jij er nu in slaagt toch Base::do_something() te implementeren.

[Alarmnummer]

Ik vind het altijd vreemd als iemand een taal "naadje" vindt omdat hij meer kan dan de voorkeurstaal van de persoon in kwestie.

Ik keur ook niet alles af van c++ En verder hou ik ook van zeiken, maar dat wisten jullie al wel

Het is natuurlijk vij absurd om te argumenteren dat iemand methods gaat toevoegen aan een abstract baseclass, terwijl dat argument net zo goed opgaat voor een interface. Overigens kun je in C++ prima aangeven dat een method niet geimplementeerd is:

Maar je kan het niet in 1 keer voor alle methodes garanderen. Ik wou dus je in c++ ook interfaces had die eigelijk niets anders zijn dan een class, maar met de volgende beperkingen:
-iedere methode is virtual
-geen members

[farlane]

Verwijderd schreef op 07 November 2002 @ 16:50:
Knap als jij er nu in slaagt toch Base::do_something() te implementeren.

C++:

class VirtualOrNot
{
public:
    VirtualOrNot(){};
    virtual ~VirtualOrNot(){};

    virtual bool isImplemented()=0
    {
        return true;
    };
};

class DerivedFromVirtualOrNot : public VirtualOrNot
{
public:
    DerivedFromVirtualOrNot(){};
    ~DerivedFromVirtualOrNot(){};

    bool isImplemented()
    {
        return VirtualOrNot::isImplemented();
    }
};

int main()
{


    DerivedFromVirtualOrNot obj;

    std::cout<<obj.isImplemented()<<std::endl;
    std::cin.get();
    return 0;

}      

[Soultaker]

farlane schreef op 07 november 2002 @ 20:31:
<knip code>

Heel knap hoor! En nu dat VirtualOrNot::notImplemented aanroepen zoals mietje zei en niet DerivedFromVirtualOrNot::notImplemented.

C++:

DerivedFromVirtualOrNot object;
object.VirtualOrNot::notImplemented(); /* run-time exception; pure virtual method called.*/

[.oisyn]

farlane schreef op 07 November 2002 @ 20:31:
[...]

C++:

    virtual bool isImplemented()=0
    {
        return true;
    };

dit is geen standaard C++

[Scare360]

leesvoer voor in de queue

[Verwijderd]

.oisyn schreef op 07 November 2002 @ 21:06:
[...]
dit is geen standaard C++

Nee, maar pure virtuals definen mag best hoor:

ISO-IEC 14882-1998 h 10.4 p 2
A pure virtual function need be defined only if explicitely called with the qualified-id syntax (5.1).

[farlane]

Soultaker schreef op 07 November 2002 @ 20:48:
[...]

Heel knap hoor! En nu dat VirtualOrNot::notImplemented aanroepen zoals mietje zei en niet DerivedFromVirtualOrNot::notImplemented.

C++:

DerivedFromVirtualOrNot object;
object.VirtualOrNot::notImplemented(); /* run-time exception; pure virtual method called.*/

Daar ging het toch niet om ? De vraag was, implementeer een pure virtual functie in een abstracte klasse. Dat is wat ik heb gedaan.

( Overigens weet ik niet echt hoe ik je 'Heel knap hoor!' moet opvatten. Komt een beetje gek over namelijk.

Dit is geen Standaard C++

C++:

class VirtualOrNot
{

public:

    VirtualOrNot( ){ };
    virtual ~VirtualOrNot( ) { };

    virtual string isImplemented( ) = 0;
};

string VirtualOrNot::isImplemented( )
{
    return string("Yep !");
};

Dit dan ?