C# Setting manager design probleem

[lauwsa]

Hallo iedereen,

Ik heb even een design probleem in C#, misschien dat jullie hier even naar willen kijken? Ik denk namelijk dat ik helemaal fout aan het denken ben.

Bedoeling:
Ik ben iets aan het schrijven dat een taak maakt die een onbeperkt aantal taken kan bevatten. Hier bij moet support zijn voor vervolg taken.

Even een voorbeeld, er is een taak die vervult moet worden. Deze taak bevat 10 taken, taak 2 heeft een aantal subtaken. Als taak 2 klaar is moeten de subtaken van taak 2 uitgevoerd worden voordat hij met de rest door mag gaan. Deze subtaken kunnen weer subsubtaken bevatten, dit gaat zo oneindig door.

Mijn oplossing:
De taken zelf wil ik zo generiek mogelijk maken, ik wil namelijk verschillende types kunnen gebruiken aangezien je soms een string als data type wilt hebben en de andere keer een getal. Hier heb ik al een begin voor gemaakt met Generics. Een taak heeft dan een naam die de gebruiker kan opgeven en dan data opslag die aangeven hoe de taak uitgevoerd moet worden. Dus eigenlijk de opdracht. ( Dit word later uitgebreid in deze post )

De taken zelf wil ik dus ook support geven dat deze een lijst van andere taken kan houden. Zo kan ik deze oneindig uit berijden.

Paar problemen met een oplossing:
Een probleem hier bij is dat je van te voren moet opgeven wat voor type de lijst met taken moet gaan worden. Dit weet ik dus eigenlijk niet aangezien dit afhankelijk is hoe de user de taken gaat instellen. Een oplossing is natuurlijk om van deze lijst een lijst van object te maken, dan kan deze dus elk mogelijk type bevatten. In dit geval komt in deze lijst taken met een bepaald type.

Hier komt nog een probleem bij kijken, ik weet nooit wat voor type ik terug kan verwachten als ik een task uitlees, maar hier is natuurlijk ook een oplossing voor. Ik was aan het denken om een enum te maken met mogelijke “opties” die vervult kunnen worden. Er zijn namelijk maar een beperkt aantal soorten taken mogelijkheden.

Hoe werkt het
Op deze manier kan ik de juiste processing code voor elke taak aanroepen, de enum bepaalt namelijk wat de taak gaat verwerken. Hij weet dus zelf wat hij moet verwachten.

Bij laden in het werkgeheugen is het geen probleem dat je niet weet welk type je kan verwachten, je zet gewoon in het object wat je wilt en krijgt dit weer als object terug. De processing code lost dit aan de hand van de enum op.

Bij het exporteren moet ik er voor zorgen dat de taak zelf kijkt welk type het object is, deze moet het genen dan omvormen naar een string met als “notitie” er bij wat voor type het origineel is. De onderdelen die in de lijst met taken zit roep ik dan weer een export functie aan en dit zet ik dan in een soort van tekst base array.

Ik vind dat dit alles Generics een beetje "overbodig" maken, uiteindelijk ga je kijken welk type de data opslag van de taak heeft. Hier voor moet je voor elke mogelijkheid dan een export voor schrijven. Om eerlijk te zijn vind ik dit best wel zonden. Wat natuurlijk ook kan is dat alles geëxporteerd word als byte array. Maar dan kijk je nog steeds naar de type om er achter te komen hoeveel bytes je moet kopiëren. Dan moet ik wel uitzoeken hoe je dit het beste kan doen maar het is misschien wel een oplossing.

Mijn conclusie
Wat ik me hierbij afvraag is, is dit wel een goede manier om dit voor elkaar te krijgen? Vind het een beetje omslachtig en voelt eigenlijk ook niet echt goed. Hoe zouden jullie dit aanpakken?

Om even een duidelijker beeld te geven, zo zou ik dit zo in code type:

code:

public enum PosableTasks 
{
    AJob,
    AnotherJob
}

public class Task<TaskType>
{
    private string Name;
    private TaskType TaskData;
    private List<Object> TaskChildes;
    private PosableTasks KindOfTask;

    public Task(string Name)
    {
        this.Name = Name;
    }

    public string GetName()
    {
        return Name;
    }

    public void SetTaskData(TaskType TaskData)
    {
        this.TaskData = TaskData;
    }

    public TaskType GetTaskData()
    {
        return TaskData;
    }
    
    //Todo:
    //TaskChildes add/delete/edit/get
    //KindOfTask get
}

Edit:
Setting naar task hernoemt.

[ Voor 3% gewijzigd door lauwsa op 17-10-2012 11:03 ]

[CodeCaster]

Ik snap je concrete probleem niet helemaal en snap de relatie tussen de SettingsManager en je taken niet helemaal, maar dit lijkt te neigen naar een oplossing met een strategy pattern.

Laat al je taken een interface implementeren die een methode Execute() definieert. De concrete klasse zal deze Execute() dan implementeren.

Als je een taak ook een List<ITask> SubTasks geeft, kun je die in je Execute() recursief laten uitvoeren.

[lauwsa]

CodeCaster schreef op woensdag 17 oktober 2012 @ 10:54:
Ik snap je concrete probleem niet helemaal en snap de relatie tussen de SettingsManager en je taken niet helemaal, maar dit lijkt te neigen naar een oplossing met een strategy pattern.

Laat al je taken een interface implementeren die een methode Execute() definieert. De concrete klasse zal deze Execute() dan implementeren.

Als je een taak ook een List<ITask> SubTasks geeft, kun je die in je Execute() recursief laten uitvoeren.

Ik vond op de helft van de post in dit geval taken beter klinken dan setting. Dus ik had alles aangepast naar taken. Ik had alleen de code eerder getypt en hier ben ik alles vergeten te vervangen.

Maar dat is inderdaad een betere oplossing, dan zit je ook niet met het probleem dat je je oude code moet uit berijden om een mogelijkheid toe te voegen. Thanks!

[Hydra]

CodeCaster schreef op woensdag 17 oktober 2012 @ 10:54:
Ik snap je concrete probleem niet helemaal en snap de relatie tussen de SettingsManager en je taken niet helemaal, maar dit lijkt te neigen naar een oplossing met een strategy pattern.

Laat al je taken een interface implementeren die een methode Execute() definieert. De concrete klasse zal deze Execute() dan implementeren.

Als je een taak ook een List<ITask> SubTasks geeft, kun je die in je Execute() recursief laten uitvoeren.

Ik heb ongeveer exact hetzelfde gedaan voor een AI die ik als proefprojectje geschreven heb. M.i. is dit gewoon de beste (/enige juiste) aanpak.

[sig69]

Hydra schreef op woensdag 17 oktober 2012 @ 11:31:
[...]


Ik heb ongeveer exact hetzelfde gedaan voor een AI die ik als proefprojectje geschreven heb. M.i. is dit gewoon de beste (/enige juiste) aanpak.

zonder er heel lang over na te denken zou ik ook voor zoiets gaan.

oh ja, het is uitbreiden, niet uit berijden