Det är aldrig bara en artikel

När jag trodde att jag var färdig med Nonames artiklar, märkte jag att han hade bifogat ännu en med rubriken: "Man kan aldrig lära sig för mycket om klasser – ta en titt på det här." Artikeln följde sedan.

Articles on a terminal

Klassmodellering

Även om det är avgörande att veta vad en klass är, räcker det inte för att börja använda objektorienterad programmering. En viktig del som återstår att förstå är vilka klasser som ska skapas och när.

Föreställ dig att du ansvarar för ett förråd för Motståndsrörelsen där överlevande lagrar viktiga resurser som mat, vatten och verktyg. De överlevande förlitar sig på arbetardroider för att samla in dessa resurser. Uppgiften är att skapa en uppsättning klasser för att representera förrådet, resurserna i det och arbetardroiderna.

För att börja skapa klasserna behöver du först titta på substantiven i uppgiften. I vårt fall är dessa Storage, WorkerDroid och Resource. Dessa tre täcker alla aktörer i uppgiften.

Därefter kommer verben: vad ska aktörerna kunna göra? Arbetarna ska arbeta och leverera resurser; de kan lagra resurser i förrådet eller hämta dem därifrån. Resurser har egenskaper men kan inte egentligen utföra något särskilt, så de saknar specifika verb.

Den magiska stunden uppstår när du omvandlar substantiven till klasser och verben till deras metoder!

public class Resource
{
    public string Name;
    public int Quantity;

    public Resource(string name, int quantity)
    {
        Name = name;
        Quantity = quantity;
    }

    public void Print()
    {
        Console.WriteLine($"Resource: {Name}, Quantity: {Quantity}");
    }
}

public class DroidWorker
{
    public string Id;

    public DroidWorker(string id)
    {
        Id = id;
    }

    // Work() Method here

    public void Print()
    {
        Console.WriteLine($"Droid ID: {Id}, Capacity: 5");
    }
}

public class Storage
{
    private List<Resource> storedResources = new List<Resource>();

    public void AddResources(List<Resource> resources)
    {
        foreach (var resource in resources)
        {
            storedResources.Add(resource);
        }
    }

    public List<Resource> RetrieveAllResources()
    {
        var resourcesCopy = new List<Resource>();
        foreach (var resource in storedResources)
        {
            resourcesCopy.Add(resource);
        }

        storedResources.Clear();

        return resourcesCopy;
    }

    public void Print()
    {
        Console.WriteLine($"Storage Contents: {storedResources.Count}");
        foreach (var resource in storedResources)
        {
            resource.Print();
        }
    }
}

Vi lade till metoderna "Print" i klasserna för bekvämlighets skull. Ibland lägger man till metoder som inte finns i verkliga världen – till exempel kan en arbetare inte skriva ut sig själv – men i klassrepresentationen kan det fortfarande vara vettigt att ha en sådan metod. Det finns många regler som försöker avgöra vilka metoder som är okej att ha i en klass och vilka som bör undvikas, men ofta handlar det om sunt förnuft: metoderna bör vara relevanta för klassen, och den ska inte bli för stor. Om klassen blir för omfattande, dela upp den i flera klasser. Du kan läsa mer om detta i SOLID-principerna.

Nu när arbetaren är klar ska vi kombinera alla tre klasserna och använda dem i Main. Därefter kommer vi att titta på hur vi kan förbättra resurs­hanteringen i den tillhandahållna lösningen.