[C#]Beginner, waarom zou je abstract classes gebruiken? *

[daanmsvl]

Ben weer een goede 50 pagina's verder met het C# boek en we zijn aangekomen bij abstract classes. Met een abstract class maak je alleen een signature en geen implementation, zo leert ook Internet mij.

C#:

public abstract class Car
{
  public abstract void StartEngine ();

  public abstract void StopEngine ();
}

en dat zou je dan later kunnen toepassen middels inheritance:

C#:

class Volvo : Car
{
  public override void StopEngine ()
  {
    // Some code
  }

   public override void StartEngine()
   {
     // Some Code
   }
}

Nu mijn vragen want ik geloof dat ik de theorie wel begrijp?
- Waarom zou je dit willen? Ik bedoel, wat is hiervan het voordeel? Ik heb er niet echt een praktijk gevoel bij. M.a.w. wat heb je aan een abstract?
- Kan je ook een static hebben in een abstract (public static void SomeFunction)??

Uiteraard ook wat rondgezocht op het internet maar ik kan nergens echt vinden WAAROM je een abstract zou willen hebben.

[R4NCOR]

Om een en ander 'af te dwingen'. Je weet in het door jouw gegeven voorbeeld nu dat Volvo's een startEngine() en stopEngine() methode hebben. Stel je hebt ook Mercedes, Volkswagen en Fiat classes opdezelfde manier, dan zou je ze door mekaar kunnen gebruiken in een verzameling Cars bijvoorbeeld

Een Volvo, Mercedes en Fiat zijn allemaal een Car, maar een Car zelf is niets - daarom is die abstract.

[denyos]

In een abstracte classe mag je ook al complete implementaties van functies maken. Wat je dus kan doen is een universele functie voor je auto's, zoals je zelf al zegt moet iedere auto kunnen starten en stoppen. Wanneer dit voor iedere auto nog ook nog eens het zelfde werkt kan je die methodes dus 1 keer aanmaken, vervolgens lijd je je Volvo dus af en je Car en kan die dus direct starten en stoppen.

Zoals jij het nu in je voorbeeld hebt staan werkt het met Interfaces, dat zijn beschrijvingen van methodes die ook daadwerkelijk geinplementeerd MOETEN worden.


//edit: Toch is sneller leren typen....Wat R4NCOR zegt dus.

[ Voor 5% gewijzigd door denyos op 23-03-2008 11:38 ]

[daanmsvl]

Zou je dat ooit in eigen code gebruiken of alleen in een assembly die je released naar een 3rd party? Of gebruik je dit ook om ervoor te zorgen dat bepaalde classen er altijd op een bepaalde manier uitzien??

Overigens: Wat nou als ik hem niet abstract maak maar virtual? Dan kan je nog steeds overrides krijgen, wat is dan het verschil?

[daanmsvl]

denyos schreef op zondag 23 maart 2008 @ 11:38:
In een abstracte classe mag je ook al complete implementaties van functies maken. Wat je dus kan doen is een universele functie voor je auto's, zoals je zelf al zegt moet iedere auto kunnen starten en stoppen.

Dat snap ik niet. Kan je daar een kort voorbeeldje van tonen? Ik dacht nl juist dat je bij abstract geen implementaties had.

[PainkillA]

tja vind het zelf ook wat vaag. maar het enige wat ik mij kan voorstellen is dat je dan altijd een soort zekerheid heb dat bepaalde methodes zijn ingebakken in bepaalde classen. Maar verder ben ik ook wel benieuwd hiernaar.

[R4NCOR]

daanmsvl schreef op zondag 23 maart 2008 @ 11:38:
Zou je dat ooit in eigen code gebruiken of alleen in een assembly die je released naar een 3rd party? Of gebruik je dit ook om ervoor te zorgen dat bepaalde classen er altijd op een bepaalde manier uitzien??

Overigens: Wat nou als ik hem niet abstract maak maar virtual? Dan kan je nog steeds overrides krijgen, wat is dan het verschil?

In een van de projectjes die we bij ons op school gedaan hebben, hebben we een simpel strategyspelletje gemaakt. In dat spel zitten wat soldaatjes, een lichte tank, een medium tank, een grote tank en een vrachtwagen met raketinstallatie. Dit zijn allemaal units die jij als speler kunt besturen. Deze werden allemaal bijgehouden in een verzameling die het type Unit bewaard. Units hebben allemaal bepaalde methodes om hem te verplaatsen, te laten aanvallen, etc.

Een Unit zelf is echter niets en is daarom niet instantieerbaar. Maar op deze manier kan ik wel al m'm verschillende units in 1 verzameling gebruiken en allemaal als Unit object aanspreken en bepaalde opdrachten geven.

Het verschil met gewone inheritance is inderdaad alleen dat in dit geval de baseclass niet te instantieren is. En dat is wat je wil omdat je aan zo'n object niets hebt

[SH4D3H]

Wat hij zegt dus ^^

[ Voor 94% gewijzigd door SH4D3H op 23-03-2008 11:48 ]

[daanmsvl]

R4NCOR schreef op zondag 23 maart 2008 @ 11:44:
[...]

Het verschil met gewone inheritance is inderdaad alleen dat in dit geval de baseclass niet te instantieren is. En dat is wat je wil omdat je aan zo'n object niets hebt

Klinkt helder, dus:

C#:

Car c = new Car ();

Zou een compiler error moeten opleveren?

//edit:
Stom dat kon ik dus zelf checken:
Cannot create an instance of the abstract class 'Car'.

Idd, compiler error.

[ Voor 13% gewijzigd door daanmsvl op 23-03-2008 11:48 . Reden: Compiler error ]

[Cloud]

daanmsvl schreef op zondag 23 maart 2008 @ 11:38:
Zou je dat ooit in eigen code gebruiken of alleen in een assembly die je released naar een 3rd party? Of gebruik je dit ook om ervoor te zorgen dat bepaalde classen er altijd op een bepaalde manier uitzien??

Overigens: Wat nou als ik hem niet abstract maak maar virtual? Dan kan je nog steeds overrides krijgen, wat is dan het verschil?

Tuurlijk kun je dit in je eigen code gebruiken, R4NCOR zegt al waarom:

Stel je hebt ook Mercedes, Volkswagen en Fiat classes opdezelfde manier, dan zou je ze door mekaar kunnen gebruiken in een verzameling Cars bijvoorbeeld

Daar is het o.a. heel nuttig voor.

Wat betreft het gebruik van virtual, zou ik toch echt even de documentatie van virtual en abstract erbij pakken. Daar staat het allemaal heel duidelijk in vermeld.

daanmsvl schreef op zondag 23 maart 2008 @ 11:40:
Dat snap ik niet. Kan je daar een kort voorbeeldje van tonen? Ik dacht nl juist dat je bij abstract geen implementaties had.

Een abstracte methode heeft inderdaad geen implementatie. Die moet ingevuld worden door de klasse die ervan erft. Een abstracte klasse echter, kan prima implementatie hebben, echter kan nooit geïnstantieerd worden. Zie ook Abstract Classes.

daanmsvl schreef op zondag 23 maart 2008 @ 11:48:
Klinkt helder, dus:

C#:

Car c = new Car ();

Zou een compiler error moeten opleveren?

Ja.

[Victor]

PainkillA schreef op zondag 23 maart 2008 @ 11:41:
tja vind het zelf ook wat vaag. maar het enige wat ik mij kan voorstellen is dat je dan altijd een soort zekerheid heb dat bepaalde methodes zijn ingebakken in bepaalde classen. Maar verder ben ik ook wel benieuwd hiernaar.

Exact. Zoals R4NCOR al zegt, het idee erachter is dat je een absolute basis hebt waar je van uit kan gaan. Om maar even bij de auto's te blijven. Stel ik heb een class ValetParking met de methode getCar. Aan die methode wil ik een afgeleide van Car doorgeven, bijvoorbeeld een Audi. In je methode getCar is het niet interessant wat die Audi allemaal kan, maar je wil wel weten dat je de basisfunctionaliteit tot je beschikking hebt. Zoals bijvoorbeeld het starten van de motor. Aangezien de Audi als afgeleide van Car verplicht is al deze basisfunctionaliteit te implementeren, kun je er op rekenen dat startEngine niet in een gigantische exception eindigt

edit:
En inmiddels heeft half GoT dit ook al gezegd

[ Voor 3% gewijzigd door Victor op 23-03-2008 11:50 ]

[denyos]

daanmsvl schreef op zondag 23 maart 2008 @ 11:40:
[...]

Dat snap ik niet. Kan je daar een kort voorbeeldje van tonen? Ik dacht nl juist dat je bij abstract geen implementaties had.

Okay, dit kan beetje onduidelijk worden....
Ik heb zelf in een eigen projectje (knowledge base) de volgende objecten

Artikel en Persoon.

Beide objecten moeten zichzelf kunnen opslaan en ophalen vanuit de database. Daarom laat ik deze objecten afleiden van een abstracte klasse. In deze abstracte klasse heb ik vervolgens de methode Save, GetById en Delete.

In de implementerende klasse heb ik staan welke stored procedure bij deze methode horen.
Zo hoort bij het object Persoon de storedprocedure GetPersoonById en bij Artikel GetArtikelById.

Zo weet de abstracte klasse welke storedprocedure hij moet gebruiken en heb ik de rest volledig dynamisch kunnen houden. Als ik nu een nieuw object aanmaak, en ik laat hem van mijn abstracte klasse afleiden, heeft hij dus direct de methodes Save, Delete en GetById.


EDIT: Ik heb het hier idnerdaad over een abstracte classe! Deze kan wel een eigen implementatie hebben zoals Wolkje al terecht opmerkte.

[ Voor 6% gewijzigd door denyos op 23-03-2008 11:54 ]

[daanmsvl]

denyos schreef op zondag 23 maart 2008 @ 11:52:
[...]

Okay, dit kan beetje onduidelijk worden....
Ik heb zelf in een eigen projectje (knowledge base) de volgende objecten

Artikel en Persoon.

Beide objecten moeten zichzelf kunnen opslaan en ophalen vanuit de database. Daarom laat ik deze objecten afleiden van een abstracte klasse. In deze abstracte klasse heb ik vervolgens de methode Save, GetById en Delete.
[...]

Heb jij dan in de abstracte classe alleen een interface staan of ook de implementatie van Save, GetById en Delete? Als je ook een implementatie hebt staan dan ben ik benieuwd hoe dit eruit ziet. Ik ben nl nog steeds in de overtuiging dat bij abstract je dus alleen een interface hebt (en dus geen implementatie, of gooi ik dingen nu gigantisch door elkaar?)

[Snake]

Heb niet het ganse topic gelezen.


Maar voor een beginner is het niet gemakkelijk, omdat ge niet met grotere klassen werken, en grotere projecten. Ook voor uzelf is het niet zo belangrijk, omdat ge zelf weet dat ge er geen object van wilt laten instantieren.

Wel kan het handig zijn voor klassen die methodes overerven van de superklasse, waarvan een aantal abstract zijn (die ge dus zelf moet bepalen). Daarvoor kan ook een Interface handig zijn.

[martijnve]

Even samenvattend:
Volgens mij kun je je vraag in 2'en opdelen.

1. Waarom zou ik alle automerk-klasses van een classe afleiden?
Hierdoor kun je dus functies/methodes maken die op alle automerk-klasses werken (wat als ze niet allemaal van een parent zijn afgeleid nagenoeg onmogelijk is!!!) en je kunt bijv mercedesen en audi's bij elkaar in een array bewaren.

2. Warom zou ik de classe parent abstract maken en geen gewone klasse?
Dit is om je tegen jezelf (of je collega's of klanten in een groter project) te beschermen, aangezien alle auto's altijd van een bepaald merk zijn wil je dus nooit een generieke auto aanmaken, temeer omdat de klasse car niet alle methodes (correct) geimplementeerd hoeft te hebben, denk bijv aan de methode SchakelAlarmUit() oid die is per merk(/type) anders en kan in een evt niet abstracte car klasse alleen als SchakelAlarmUit() {
return;
}
worden "geimplementeerd"

[denyos]

daanmsvl schreef op zondag 23 maart 2008 @ 11:57:
[...]

Heb jij dan in de abstracte classe alleen een interface staan of ook de implementatie van Save, GetById en Delete? Als je ook een implementatie hebt staan dan ben ik benieuwd hoe dit eruit ziet. Ik ben nl nog steeds in de overtuiging dat bij abstract je dus alleen een interface hebt (en dus geen implementatie, of gooi ik dingen nu gigantisch door elkaar?)

Ik heb de implementatie dus ook in de abstracte classe staan inderdaad, anders had ik beter een Interface kunnen gebruiken. Om hier niet een mega lap code neer te plempen heb ik hieronder even alleen de Delete() methode binnen een abstracte classe gezet:

C#:

 public abstract class SingleBase
    {
        public void Delete()
        {
            string methodType = "delete";  //Aan de hand van de methodType wordt bepaald welke storedprocedure uit een collectie nodig is.
            OpenDatabaseConnection();
            SqlCommand cmd = new SqlCommand(StoredProcedures.Get(methodType), _connection);
            cmd.CommandType = CommandType.StoredProcedure;

            ArrayList parameters = new ArrayList();
            parameters = getCommandParameters(methodType);
            foreach (SqlParameter sqlParameter in parameters)
            {
                cmd.Parameters.Add(sqlParameter);
            }
            cmd.ExecuteNonQuery();
            cmd.Dispose();
        }
}

Deze functie komt uit een veel grotere classe, en een groter geheel waardoor niet alles duidelijk zal zijn.

[Snake]

martijnve schreef op zondag 23 maart 2008 @ 12:04:
Even samenvattend:
Volgens mij kun je je vraag in 2'en opdelen.

1. Waarom zou ik alle automerk-klasses van een classe afleiden?
Hierdoor kun je dus functies/methodes maken die op alle automerk-klasses werken (wat als ze niet allemaal van een parent zijn afgeleid nagenoeg onmogelijk is!!!) en je kunt bijv mercedesen en audi's bij elkaar in een array bewaren.

Jap

2. Warom zou ik de classe parent abstract maken en geen gewone klasse?
Dit is om je tegen jezelf (of je collega's of klanten in een groter project) te beschermen, aangezien alle auto's altijd van een bepaald merk zijn wil je dus nooit een generieke auto aanmaken, temeer omdat de klasse car niet alle methodes (correct) geimplementeerd hoeft te hebben, denk bijv aan de methode SchakelAlarmUit() oid die is per merk(/type) anders en kan in een evt niet abstracte car klasse alleen als SchakelAlarmUit() {
return;
}
worden "geimplementeerd"

Die return mag niet.

ge schrijft het zo:

C#:

public abstract class Car
{ 
   /* u methodes */
   public abstract void SchakelAlarmUit(); //GEEN body!
}

[daanmsvl]

@ martijnve: Dank voor de duidelijke samenvatting ik denk datik dat nu begrijp

@ denyos: Ik ga even samenvatten hoe het er nu voor mij uitziet: Het valt me op dat Delete () bij jouw geen abstract is. Dus, in een abstract kan je een combinatie van abstracts en, zeg maar, normale functies / methods / etc maken. Wil je alleen maar een "blue print" zonder implementatie whatsoever dan moet je een interface gebruiken. Zeg ik dat correct?

[Cloud]

daanmsvl schreef op zondag 23 maart 2008 @ 12:09:
Wil je alleen maar een "blue print" zonder implementatie whatsoever dan moet je een interface gebruiken. Zeg ik dat correct?

Dat zeg je correct Met een interface forceer je de implementatie van de methoden in je interface.

[daanmsvl]

Snake schreef op zondag 23 maart 2008 @ 12:06:
[...]
Jap

[...]
Die return mag niet.

ge schrijft het zo:

C#:

public abstract class Car
{ 
   /* u methodes */
   public abstract void SchakelAlarmUit(); //GEEN body!
}

Ik denk dat martijnve het object bedoelde en niet de klasse definitie, dan mag het toch wel?

C#:

class Audi : Car
{
  public void SchakelAlarmUit ()
  {
    return;
  }
}

[daanmsvl]

wolkje schreef op zondag 23 maart 2008 @ 12:11:
[...]

Dat zeg je correct Met een interface forceer je de implementatie van de methoden in je interface.

yay! Oke vraag beantwoord, de puzzelstukjes vallen in elkaar. Ik ga weer verder lezen, jullie horen het wel weer als ik vast loop.

[Soultaker]

daanmsvl schreef op zondag 23 maart 2008 @ 11:33:
Waarom zou je dit willen?

Ben je bekend met polymorfisme? Ik vermoed van niet, anders zou je deze vraag waarschijnlijk niet stellen. Toch is het raar dat het in de hele thread niet genoemd wordt. Het nut van een abstracte klasse wordt vrij snel duidelijk als je een voorbeeld ziet waarin die abstracte klasse gebruikt wordt.

In het algemeen houdt polymorfisme in dat je verschillende typen objecten kunt gebruiken (bijvoorbeeld als argument naar een functie) die een gemeenschappelijke interface hebben. In C# betekent dat dat ze een gemeenschappelijke superclass hebben of een gemeenschappelijke interface implementeren. Een simpel voorbeeld met de autos zou zijn:

C#:

void restartCar(Volvo v) {
  v.StopEngine();
  v.StartEngine();
}

Je ziet nu al het probleem dat restartCar een instantie van klasse Volvo als argument verwacht. Dat is natuulijk niet handig als je een heleboel verschillende klassen van auto's hebt. Je zou dan deze functie opnieuw kunnen implementeren voor elke klasse, maar dat is een hoop gedoe en eigenlijk nergens voor nodig.

Je zou dan kunnen bedenken dat alle klassen impliciet subklassen van Object zijn, en het zo proberen op te lossen:

C#:

void restartCar(Object o) {
  o.StopEngine();
  o.StartEngine();
}

Elke soort auto kun je nu meegeven als argument. Probleem opgelost! Helaas compileert het niet, want een Object heeft een methodes om de motor te starten of te stoppen. Logisch ook, want een heleboel andere objecten die géén auto's zijn, kun je ook als argument geven.

Om dit op te lossen kun je dus gebruik maken van een abstracte superklasse, die aangeeft dat een auto (Car) methodes heeft om de motor te starten en stoppen (StartEngine, StopEngine) en dat type kun je weer in dezelfde functie gebruiken:

C#:

void restartCar(Car c) {
  c.StopEngine();
  c.StartEngine();
}

Dit compileert prima, omdat de methoden gedefinieert zijn behorende bij de klasse Car. Alle auto's die je aan zo'n functie wil meegeven moeten nu wel van Car afgeleid zijn en moeten verplicht de bijbehorende methodes implementeren.

Ik hoop dat het nut van de abstracte klasse nu wel duidelijk is: je gebruikt ze om gemeenschappelijk gedrag van klassen te kunnen beschrijven, zonder dat je dat gedrag direct hoeft te implementeren (want de motor starten gaat voor elke auto anders). Wat dat betreft is een abstracte klasse goed te vergelijken met een interface (hoewel er ook een aantal verschillen zijn).

[daanmsvl]

@ soultaker: Dank voor het heldere verhaal, het maakt e.e.a. voor mij heel duidelijk. Goeie uitleg.

[whoami]

Tja, waarom maak je gebruik van abstracte classes:
Om het geen wat gemeenschappelijk is , te implementeren, en hetgeen dat 'varieert' te implementeren in een concrete subclass.

Ik maak regelmatig gebruik van abstracte classes, zowel om binnen m'n eigen code (of binnen 't werk) te gebruiken, als voor 3rd parties.

Wat dat betreft is een abstracte klasse goed te vergelijken met een interface (hoewel er ook een aantal verschillen zijn).

Niet helemaal mee akkoord; met een interface leg je enkel een 'contract' vast wat een bepaalde class die die interface implementeert, moet hebben qua publieke methods & properties.
In een abstracte class kan je ook al (gemeenschappelijke) functionaliteit kwijt, en leg je ook al vast waar een abstract method moet opgeroepen worden.

Als ik een abstract class maak, dan ga ik in veel gevallen echter ook een interface maken, en die abstract class implementeert die interface dan

[TaraWij]

De doelen van polymorfisme zijn het leesbaar maken van broncode en het voorkomen dat de programmeur steeds documentatie moet naslaan voor het vinden van de juiste identifier.

Door het gebruik van consequente naamgeving en argumenten is het voor de lezer van de broncode mogelijk deze te begrijpen zonder dat bij elke aanroep documentatie geraadpleegd hoeft te worden, of nog erger, dat de code iets anders doet dan deze suggereert.

Een vuistregel is dat de programmeur door het gokken van de naam een trefkans van 90% heeft. Alleen in die laatste 10% moet de programmeur opnieuw gokken of de documentatie naslaan. Ook voor de argumenten van een operatie geldt een dergelijk percentage.

Bron: Wikipedia

Verder kan je hiermee nog leuke dingen doen, stel je schrijft een simulatie om met auto's te toeteren...

Je zal de auto's die van een verschillende type (mercedes, ford, ...) toevoegen aan een array. Nu loop jij die array af en je wilt dat elke auto toetert, maar niet alle toeters zijn hetzelfde, dus zal er automatisch voor je bepaald worden welke toeter hij moet gebruiken. (Bij een Mercedes auto doet hij dan de toeter van de Mercedes die je in de Mercedes klasse hebt gespecifieerd)

De array van auto's zijn dus van het type Car, maar jij voegt er auto's aan toe van verschillende types. (Zolang die uitgebreid zijn op Car is dit mogelijk)

code:

Mercedes mercedes = new Mercedes();
Ford ford = new Ford();

Car car[2];
car[0] = mercedes;
car[1] = ford;

for (int i = 0; i < 2; ++i)
  car[i].Toeter();

Hiervoor wordt polymorfisme (abstract) dus vaak gebruikt.

[ Voor 6% gewijzigd door TaraWij op 23-03-2008 21:09 ]

[Anoniem: 183983]

Abstracte classen gebruik je voor polyformisme. Dat wil eigenlijk zeggen dat het je niet zoveel uitmaakt wat de -specifieke- classen allemaal kunnen, maar dat je uit wilt kunnen gaan van een bepaalde basis.

Bij ons op het werk gaat het om producten die we verkopen. Wat voor producten? Dat maakt niet uit. Maar die producten moeten wel allemaal bepaalde gemeenschappelijke eigenschappen en gedragingen hebben. En dat kun je afdwingen door een abstracte class.

Voorbeeld:

abstracte class product moet:
- kunnen vertellen wat de totaalprijs is (voor de klant)
- moet boekbaar zijn.

we hebben op dit moment 3 producten: Car, Hotel en Flight.
De abstracte class product heeft dan TotalPrice en de methode Book(). De afgeleide classen Car, Hotel en Flight zijn verplicht om die TotalPrice en Book() te implementeren, en ze moeten zelf maar uitzoeken HOE ze dat doen.

Het voordeel van een abstracte class is ook dat je eventuele toekomstige nieuwe afgeleide classen op dezelfde manier kan aanspreken in je code. Dus in dit geval weet je dat je voor een denkbeeldig toekomstig product ook de totaalprijs kan opvragen en dat je dat product kunt gaan boeken. Dus mochten we nog anderen producten in de software gaan ondersteunen, dan hoeven we de stukken code die al overweg kunnen met de abstracte class product niet meer aan te passen.

Zoek voor je eigen lol ook eens de discussies op internet op of je nou een abstracte class moet gebruiken, of juist interfaces

[Snake]

Een interface is een volledig abstracte klasse. Met het verschil dat een klasse meerdere interfaces kan implementen, maar maar 1 klasse kan erven.

[Soultaker]

Trouwens, ik vind de Nederlandse versie van Wikipedia dramatisch slecht als het aankomt op wiskunde en informatica. Ik zou dus daar niet direct uit quoten.

Neem zo'n uitspraak:

De doelen van polymorfisme zijn het leesbaar maken van broncode en het voorkomen dat de programmeur steeds documentatie moet naslaan voor het vinden van de juiste identifier.

Dat raakt kant noch wal. Dan kun je beter de rest van de pagina ook negeren.

[SH4D3H]

Soultaker schreef op zondag 23 maart 2008 @ 22:09:
Dat raakt kant noch wal. Dan kun je beter de rest van de pagina ook negeren.

Wikipedia kan door iedereen aangepast worden.
Als jij je kennis dan met de rest van Nederland deelt, lezen 'wij' wel de juiste info

[JeroenTheStig]

Ik raad de TS aan om het boek Head First Design Patterns te lezen. Dit boek laat op een speelse manier zien hoe onder andere abstract classes, interfaces, polymorphisme enz wordt gebruikt bij vaak toegepaste patronen: de design patterns. Hierdoor zul je ook snel begrijpen wat het nut is van o.a. abstract classes.

[daanmsvl]

Boktor schreef op maandag 24 maart 2008 @ 15:06:
Ik raad de TS aan om het boek Head First Design Patterns te lezen. Dit boek laat op een speelse manier zien hoe onder andere abstract classes, interfaces, polymorphisme enz wordt gebruikt bij vaak toegepaste patronen: de design patterns. Hierdoor zul je ook snel begrijpen wat het nut is van o.a. abstract classes.

Dit boek dan maar bestelt, ziet er goed uit en het heeft hoge ratings

[Down]

daanmsvl schreef op maandag 24 maart 2008 @ 21:34:
[...]

Dit boek dan maar bestelt, ziet er goed uit en het heeft hoge ratings

Ik vond het zelf een nuttig en makkelijk te lezen boek. Naast de werking van bepaalde dingen wordt je ook de toepassing duidelijk, zonder die toepassing is het soms moeilijk het nut van iets te begrijpen.

[Anoniem: 183983]

Head First Design Patterns ligt hier ook op de plank. Wat mij betreft een echte aanrader. Je wordt meegenomen met een aantal refactoring slagen.
Zeker ervaren programmeurs zullen een 'erha-erlebnis' hebben.

"
What is the most constant factor of software?
-CHANGE
"

[pkuppens]

wolkje schreef op zondag 23 maart 2008 @ 11:48:
[...]

Tuurlijk kun je dit in je eigen code gebruiken, R4NCOR zegt al waarom:


[...]

Daar is het o.a. heel nuttig voor.

Wat betreft het gebruik van virtual, zou ik toch echt even de documentatie van virtual en abstract erbij pakken. Daar staat het allemaal heel duidelijk in vermeld.

[...]

Een abstracte methode heeft inderdaad geen implementatie. Die moet ingevuld worden door de klasse die ervan erft. Een abstracte klasse echter, kan prima implementatie hebben, echter kan nooit geïnstantieerd worden. Zie ook Abstract Classes.

[...]

Ja.

toon volledige bericht

daanmsvl schreef op zondag 23 maart 2008 @ 11:48:
[...]

Klinkt helder, dus:

C#:

Car c = new Car ();

Zou een compiler error moeten opleveren?

//edit:
Stom dat kon ik dus zelf checken:
Cannot create an instance of the abstract class 'Car'.

Idd, compiler error.

Dit is de abstracte klasse. Wat verder van belang is, bij abstracte methoden, is dat als een derived klasse 'vergeet' een abstracte methode te implementeren, dat dit ook een compile error geeft.

C#:

class CrappyCar : Car
{
  // waar is de StartEngine???
  public override void StopEngine ()
  {
    // Some code
  }
}

Ongetest, uit een ver geheugen, en ik ben ook geen expert.

[Anoniem: 183983]

De 'gewone' methodes van de base-class Car worden natuurlijk ook ge-erft.

C#:

public abstract class Car
{
    public abstract string Name
    {
        get;
    }

    public void MakeNoise()
    {
       Console.Out.WriteLine("VROEM");
    }
}


public class Volvo : Car
{
    public override string Name
    {
        get
        {
             return "Volvo";
        }
    }
}

Ook de Volvo-instantie heeft de MakeNoise() implementatie. Die zal voor alle auto's hetzelfde zijn.

[Michali]

Een class is vaak abstract om het Template Method pattern toe te passen. Misschien wel interessant om dat eens uit te zoeken en ook gelijk op de nadelen te letten.