[C#]Abstract field

[apNia]

Klein vraagje aan C# developers (kon zo snel geen C# algemeen topic vinden), kan je bij een abstract class nou een abstract field maken? Bijv:

code:

public abstract int LEVEL_WIDTH;

Het lijkt enkel via get/set te mogen, dus:

code:

public abstract int LEVEL_WIDTH{ get; }

[Voor 8% gewijzigd door apNia op 13-06-2011 14:49]

[JaWSnl]

apNia schreef op maandag 13 juni 2011 @ 14:49:
Klein vraagje aan C# developers (kon zo snel geen C# algemeen topic vinden), kan je bij een abstract class nou een abstract field maken? Bijv:

code:

public abstract int LEVEL_WIDTH;

Het lijkt enkel via get/set te mogen, dus:

code:

public abstract int LEVEL_WIDTH{ get; }

Lijkt me dat alleen de laatste mag. Abstract geeft aan dat datgene dat het modified nog niet 'compleet' is. En de eerste is af, hooguit wil je hem nog initializeren, waar de constructor voor gebruikt kan worden. Van msdn: "The abstract modifier can be used with classes, methods, properties, indexers, and events"

Maar eh... dit is niet de plek voor die vragen

[Voor 11% gewijzigd door JaWSnl op 13-06-2011 15:19]

[apNia]

JaWSnl - leek me zo'n simpele vraag, vond nieuw topic een beetje zonde
Is er een algemeen C# topic voor btw?

[Caelorum]

apNia schreef op maandag 13 juni 2011 @ 15:22:
JaWSnl - leek me zo'n simpele vraag, vond nieuw topic een beetje zonde
Is er een algemeen C# topic voor btw?

Nee, maar voornamelijk omdat dingen met een taal vaak makkelijk op te zoeken zijn in de documentatie. Zoals in dit geval op MSDN

[apNia]

Leeuwendeel van de Devschuur vragen is te vinden in de documentatie Caelorum. Ik zoek altijd voor ik een vraag op GoT post. Kon het niet vinden, daarom post ik het hier.

[Voor 17% gewijzigd door apNia op 13-06-2011 16:05]

[JaWSnl]

apNia schreef op maandag 13 juni 2011 @ 16:05:
Leeuwendeel van de Devschuur vragen is te vinden in de documentatie Caelorum. Ik zoek altijd voor ik een vraag op GoT post. Kon het niet vinden, daarom post ik het hier.

Dan moet je het toch nog eens proberen, want als je "C# abstract" invult op google zijn de eerste twee hits allebei MSDN met info

[apNia]

JaWSnl schreef op maandag 13 juni 2011 @ 16:09:
[...]


Dan moet je het toch nog eens proberen, want als je "C# abstract" invult op google zijn de eerste twee hits allebei MSDN met info

Ik heb geen algemene vraag over abstracte classes, het gaat mij er om waarom abstract fields als get/set properties moeten worden gedeclared. Ik kon dat niet vinden in de docs. Je vertelt me niks nieuws door te zeggen dat het wel te vinden is ergens.

[alwinuzz]

Waarom wil je een abstract field? Ik zie de meerwaarde er niet van in.

C#:

//base class:
public abstract int ClassId {get; }

//derived:
public overide int ClassId {get { return "Dit ben ik!"; } }

[Voor 51% gewijzigd door alwinuzz op 13-06-2011 16:27]

[apNia]

Stel ik heb abstract class Foo, en al zijn childclasses moeten een eigen id hebben. Dan wil je een abstract id hebben.

[DEiE]

apNia schreef op maandag 13 juni 2011 @ 16:15:
[...]

Ik heb geen algemene vraag over abstracte classes, het gaat mij er om waarom abstract fields als get/set properties moeten worden gedeclared. Ik kon dat niet vinden in de docs. Je vertelt me niks nieuws door te zeggen dat het wel te vinden is ergens.

Een abstract class is een class die nog niet 'af' is, je kan hierin aangeven dat functies wel in het object moeten zitten, maar in de subclasses worden geimplementeerd.
Velden kan je niet later implementeren, omdat het datahouders zijn, als je wilt dat het veld in de abstracte klasse aanwezig zijn, kan je ze er gewoon zonder abstract ervoor inzetten, wellicht protected als je het veld direct wilt benaderen vanuit de subklasse.
Properties zijn in de praktijk getters en setters, dus eigenlijk functies, vandaar dat je deze wel abstract mag defineren.

apNia schreef op maandag 13 juni 2011 @ 16:23:
Stel ik heb abstract class Foo, en al zijn childclasses moeten een eigen id hebben. Dan wil je een abstract id hebben.

Op het moment dat je de id opneemt in je abstracte klasse, wordt de waarde hiervan niet gedeeld onder de subklassen, gewoon als normale member in de abstracte klasse opnemen doet dus wat jij wilt .

[Voor 18% gewijzigd door DEiE op 13-06-2011 16:25]

[apNia]

Thanks DEiE
Ik was de zin die JaWSnl aankaartte tegengekomen ("The abstract modifier can be used with classes, methods, properties, indexers, and events") maar ik had in m'n hoofd een foute definitie van wat een property inhield. Daarom snapte ik 't niet. Helemaal duidelijk nu

edit:

DEiE schreef op maandag 13 juni 2011 @ 16:23:
Op het moment dat je de id opneemt in je abstracte klasse, wordt de waarde hiervan niet gedeeld onder de subklassen, gewoon als normale member in de abstracte klasse opnemen doet dus wat jij wilt .

Maar is dat niet een bad practice? Ik wil ze toch afdwingen een id te declareren? Als ik 't als protected member declareer dwing ik men niet af dit juist te implementeren toch?

[Voor 46% gewijzigd door apNia op 13-06-2011 16:28]

[alwinuzz]

apNia, met een "abstract property get" dwing je subclasses af om die property te implementeren (in jouw geval id). Of het "juist" geimplementeerd is volgens jouw standaard kan de compiler moeilijk weten...

edit: voor een voorbeeldje zie m'n edit van m'n vorige post

[Voor 15% gewijzigd door alwinuzz op 13-06-2011 16:32]

[apNia]

In mijn geval moet dat overal ja. Ik ben momenteel bezig met een tile based 2D game, elk met verschillende Levels. Level is abstract, en elke Level implementatie moet een width/height van de tileset gedeclareerd hebben. Zijn 2 abstracte properties (width/height) dan niet de juiste oplossing?

[alwinuzz]

Ja ik denk het wel (IMHO natuurlijk).
Eventueel kan je één abstract property van type Size doen o.i.d., ligt eraan of er al zo'n soort type bestaat in je game / framework. Size is dan een object met width en height properties.

[DEiE]

offtopic:
Is het wel nodig om voor elk level een aparte implementatie te maken? In structuur zijn wellicht alle levels hetzelfde, alleen met andere invulling. De data veranderd, maar de functionaliteit niet. Daarover nadenken kan je spelletje wellicht wat flexibeler maken, met betrekking tot het toevoegen van levels.

[Voor 10% gewijzigd door DEiE op 13-06-2011 17:06]

[roy-t]

apNia schreef op maandag 13 juni 2011 @ 16:36:
In mijn geval moet dat overal ja. Ik ben momenteel bezig met een tile based 2D game, elk met verschillende Levels. Level is abstract, en elke Level implementatie moet een width/height van de tileset gedeclareerd hebben. Zijn 2 abstracte properties (width/height) dan niet de juiste oplossing?

Nee volgens mij is dit niet de juiste oplossing, immers heeft elke level implementatie een width en height, dus tenzij je de manier waarop width en height berekend worden wilt veranderen kun je de Width en Height properties implementeren in de abstracte Level class. Verder eis je bijvoorbeeld dat de width en height in de constructor gezet worden (en fix je daar dat ze in een protected of private variabele komen).

Zoiets dus:

C#:

public abstract class Level
{ 
    public Level(int w, int h) { this.w = w; this.h = h; }
    private int w, h;
    public int Width { get { return w;} }
    public int Height {get {return h;} }
}

public class MyLevel : Level
{
      public MyLevel(Tile[,] tiles) 
         : base(tiles.GetBounds(0), tiles.GetBounds(1))
       { }
}

Dus ik vind dat je alleen methoden virtual moet declaren als je denkt dat de berekening erin anders gaat zijn, nooit als je alleen wilt eisen dat er iets gedaan wordt voor die methode gebruikt wordt (zoals breedte opslaan).


Edit: Verder heeft DEiE ook een goed punt dat levels over het algemeen alleen verschillen qua data. Maar dat kan in sommige gevallen anders zijn.

[Voor 4% gewijzigd door roy-t op 13-06-2011 17:13]

[alwinuzz]

Wat is er mis met

code:

public override int Width { get { return 300; } }

Scheelt een hoop gedoe in de contructor, KISS

Over class per level: het ligt eraan of het alleen data is of dat er ook gedrag in het level zit, zoals AI en level-specifieke gebeurtenissen. Voor level-specifieke code lijkt een subclass per level helemaal niet zo'n gek idee.

[roy-t]

alwinuzz schreef op maandag 13 juni 2011 @ 17:19:
Wat is er mis met

code:

public override int Width { get { return 300; } }

Scheelt een hoop gedoe in de contructor, KISS

Over class per level: het ligt eraan of het alleen data is of dat er ook gedrag in het level zit, zoals AI en level-specifieke gebeurtenissen. Voor level-specifieke code lijkt een subclass per level helemaal niet zo'n gek idee.

Dat is mis omdat meerdere instanties van dezelfde level class andere breedtes en hoogtes kunnen hebben . Voor elk level in je game een apparte class schrijven is nou niet echt KISS .

[apNia]

roy - als het in de constructor gaat komt het bijvoorbeeld in Game waar m'n FooLevel geinstanced wordt. Dan zou ik in Game aankaarten hoe hoog/breed mijn level wordt, en dat lijkt mij niet de juiste locatie. De hoogte/breedte van een level hoort in de class zelf gedefinieerd te zijn.

[roy-t]

Het licht natuurlijk deels aan je design, maar een breedte en hoogte hardcoden in een level class voor een tile based game lijkt me imho gewoon niet de bedoeling. Verder zul je een level toch moeten vullen met tiles, dus zul je altijd weten hoe breed en hoog een level is op het moment dat je een level instantieerd. Als dat niet zo is, hoe komt een level dan aan zijn inhoud als dat niet via de constructor gaat?

[apNia]

Alle overeenkomstige tiles (randen van het level bijv) worden gevuld in de abstract class. Level karakteristieke dingen inderdaad in de constructor. Ik snap alleen niet waarom het dan slecht is width/height in die specifieke class te hebben.

(btw: is het inmiddels misschien handig een mod te vragen het af te splitsen naar een topic?)

[roy-t]

afsplitsen is misschien handig

Zover ik jou begrijp zou je letterlijk in MyLevel de code

code:

public int Width { get { return 256;}}

schrijven, dan zou je een nieuwe class moeten schrijven voor een ander level, dat is wel heel erg limiterend.

Natuurlijk moet je niet alles uber dynamisch maken, maar de meeste tile based games hebben levels van verschillende grotes, dus vandaar dat ik er op kwam om het zo te doen. Als je bijvoorbeeld altijd wil dat de levels een rand hebben van 1 dik met 'onbreekbare stenen' (denk bomberman) dan kan de abstracte Level class dat niet doen zonder te weten van de breedte en hoogte (ok hij zou het kunnen afleiden uit de Tile[,] array, maar dan zou de abstract class het gewoon implementeren als get{return tileArray.GetBounds(0);})

Dus door op deze manier de kennis aan de abstract class te geven hoef je veel code niet te herschrijven en kun je veel voorkomende code alvast in methodes in je abstracte class schrijven zodat je deze niet hoeft te dupliceren.

[apNia]

Dat is idd hoe ik het in de subclasses implementeer. Maar hij weet de breedte/hoogte omdat hij gewoon naar width/height kan refereren vanuit de abstracte class. Volgens mij bedoelen we alletwee hetzelfde

edit: voor de duidelijkheid, alles wordt rekenkundig gevuld, het is niet dat ik zeg "plaats FooTile op positie 10,1" in m'n abstract.

[Voor 24% gewijzigd door apNia op 13-06-2011 17:46]

[alwinuzz]

Ja volgens mij ook, maar de één vindt subclass per level wel een goed idee en de ander niet (roy-t?)

[roy-t]

exact

Het verschil per level is een data iets, niet een code iets, dus moet je er ook geen andere code voor gebruiken maar andere data in gooien.

[apNia]

Gezien m'n levels rekenkundig gevuld worden lijkt het me handig daar wel losse classes van te maken (ik werk niet met een Mappy achtige tileset maker). Vind ik ook handig als ik met de is modifier werk

[roy-t]

Invullen van een level is maar een klein stukje van wat ik me bij een level voorstel, en gebeurt waarschijnlijk door tiles in de level instantie te gooien, je maakt dan een tile generator per algoritme, gooit wat parameters in dat algoritme, die gooit een serie tiles er uit en die gooi je dan in je level instantie.

Hoe het makkelijker is om met de is modifier te werken als we het over levels hebben snap ik niet. Er is immers maar altijd 1 actief level, en alle operaties op dat level voor je uit door de interface van de abstracte class te gebruiken (verschil in gedrag zit in de overloads van de virtuele methodes in de child classes). Als je een switch of serie ifs gaat gebruiken om te checken wat voor soort level je hebt en aan de hand daarvan verschillende code uitvoert, dan is je code niet bepaald OO vrees ik.

(Nogmaals ik heb makkelijk praten vanaf hier, ik weet je probleem/implementatie tot zo ver niet, maar ik heb wel het idee dat er iets niet helemaal lekker gaat).

Edit: mijn volgende reactie zal wat langer duren, even eten, maar ik vind het altijd leuk om over game design te praten .

[Voor 5% gewijzigd door roy-t op 13-06-2011 17:58]

[Rutix]

Ik wil niet te veel lopen zeuren maar dit gaat wel erg ver naar helpdesken. Maak alsjeblieft een nieuwe topic hiervoor.

[apNia]

Ehhrr de is operator sloeg ook op m'n Square classes die de tileset vullen, daar moest de zin tussen dat ik gek ben op dingen in classes op te delen
Er is inderdaad altijd maar 1 level

Rutix - heb al lang en breed een topicreport aangevraagd

[roy-t]

@Rutix, ik heb al een modje gevraagd om het af te splitsen

[Rutix]

Fair enough Maakt mij niet zoveel uit hoor vind het ook wel interessant maar ik denk voordat er problemen komen

[alwinuzz]

Mods zijn ook aan het eten?

Ik ben wel benieuwd waarom je de is operator gebruikt; type casting is veel minder nodig juist met OOP en abstract classes / interfaces.

[apNia]

code:

for(int i = 0; i < squares.Length; i++) {
 if(squares[i] is IWalkable){ ... }
}

[roy-t]

apNia schreef op maandag 13 juni 2011 @ 18:12:

code:

for(int i = 0; i < squares.Length; i++) {
 if(squares[i] is IWalkable){ ... }
}

Hier zie ik twee dingen mee.

1. Het is geen level, en ik dacht dat je daar op doelde.
2. Wat voor functionaliteit zou een IWalkable interface implementatie toevoegen, waarom niet gewoon een boolean toevoegen in de tile struct? (Of een enum)

[Woy]

apNia schreef op maandag 13 juni 2011 @ 15:22:
JaWSnl - leek me zo'n simpele vraag, vond nieuw topic een beetje zonde
Is er een algemeen C# topic voor btw?

Nee dat is zeker niet zonde, want dan kan eventueel iemand anders het antwoord ook nog vinden. Tevens is het dan meteen duidelijk dat de normale regels voor een topic ook gelden.

Ik doe dit topic even dicht voor overleg wat we hier precies mee willen. Want een dergelijk vraag past op zich wel in PRG, echter verwachten we dan wel een wat uitgebreidere topic start. Dat is ook exact de reden dat we geen korte vraagjes in de coffee corner toestaan, want dan zouden de normale regels niet meer echt nuttig zijn.

Edit:
Dit topic blijft dicht, mocht je er toch over verder willen discussiëren dan kun je een nieuw topic openen, maar die moet natuurlijk wel aan het beleid voldoen.

[Voor 9% gewijzigd door Woy op 14-06-2011 09:13]