DEV Community: Sujith

C# Intro to the Abstract classes

Sujith — Wed, 17 Jul 2019 08:50:50 +0000

What are Abstract classes?

Abstract classes are a combination of both a normal class (default class) and an Interface.

Abstract class as an Interface: Like an interface you're not allowed to have an instance of an abstract class anywhere and also you're allowed to create "declaration only" methods like the methods inside interfaces and can later demand the inheritor of the abstract class to write the definitions.

Abstract class as a normal class: Like normal classes, you're allowed to have member variables, methods with definition and all the other advantages which will be covered in this post.

Let's jump into an example to see how to create an abstract class.

Let's write a scenario where we put a human to sleep at night. We can easily pull this off by creating a function Sleep in a separate class, Writing a functionality in a separate class enables the class to be independent and most importantly it will be really easier to be used in more than a single recipient class.
So, we create the Sleep as an abstract class.( There is a reason behind using an abstract class instead of a normal class. We will explain that in a bit but before that let's just see how to create an abstract class first.)

Creating an abstract class

To make a class into an "abstract" class just put an abstract keyword right in front of the class keyword.

    public abstract class Sleep: MonoBehaviour
    {
      public bool sleep;
        public void GetSleep()
        {
          //the inherited organisms will sleep whence this method is called
          sleep = true;
        }

    }

The Sleep abstract class has a method named GetSleep() which switches the sleep boolean to true. Upon making the sleep to true it will put the instance of a class which inherits the Sleep class to sleep.(we will expand on the "the inherited organism will sleep" comment that has been written inside the sleep method after writing the rest of the structure required for a human to sleep).

Let's start writing the class that inherits the Sleep class.

As planned this inheriting class will be the class Human. Since we've already wrote the functionality for the sleep inside the Sleep class. Thus we will pretty much leave the whole human class empty and inherit the sleep functionality from the Sleep abstract class. One of the main reasons to inherit this behavior instead of just writing this as part of the Human class is that the Human class does not have to know what sleep is.

This is one of the main reasons an abstract class is called an abstract class.

The inherited class doesn't need to know the structure of the class that is inside the class that it inherits. It is just like an actual human, A human like you who wishes to sleep. You close your eyes and expect yourself to be put to sleep, but you as a conscious self have no control over the process of sleep, there is no "sleep" button in your head that puts you to sleep. For you, the entire concept of sleep is abstract. You know how sleep can be triggered but cannot directly put yourself to sleep.
The best thing you can do is to close your eyes and wait till your brain puts you to sleep. So like a human who doesn't need to know the internal structure of sleep, this Human class doesn't need to know the internal structure of a Sleep class and how it does the sleep process. For the Human class the internal structure of a Sleep class is abstract.

    public class Human : Sleep
    {

    }

Now the Human class is capable of sleeping whenever GetSleep() is called over any human subject, Let's do that in a class called Night. Because the night cycle is one of the pottential triggers for Humans or any living organisms to sleep.

public class Night : MonoBehaviour {
 private GameObject human;

    private void PutEverybodyToSleep()
    {
        Sleep sleep = human.GetComponent<Sleep>();

        if(sleep != null)
        {
            sleep.GetSleep();
        }
    }
}

Here we have a GameObject(An Unity centric object, It serves as just a reference that holds the class Human over it). Now we do a GetComponent to get an instance of the Sleep from the Human GameObject and if it actually has an instance of Sleep(we confirm it by doing a a null check) we call the GetSleep() method to put the human subject to sleep. Since the Human class directly inherits the Sleep the GetSleep method had become part of the Human class.
As you have seen the Human class has nothing written in it, All it did was inherit a Sleep class into it and all of sleep functionality came on to it for the Night class to call it.

I promised right through the read that I will answer the following two questions in no chronological order.

1) The comment of GetSleep() inside the sleep class saying, "the inherited organisms will sleep whence this method is called"
2) Why abstract intstead of a normal class ?

I will answer the first question first, The reason to say that the inherited organisms instead of an organism because we were only talking about a human at that point of time and this GetSleep() was not just built for humans. The GetSleep() method inside the Sleep class upon inheriting will be a generic method that puts any organism to sleep as "sleep" is a common behaviour for all living organisms. So we can just inherit this class on any class types that require sleep behavior.

Before answering my second question I would like to remind you again that an abstract class is very similar to a normal class. Both are capable of handling a constructor, both are capable of creating local/global variables inside (just like the sleep boolean inside the Sleep class), both are capable of encapsulating(hiding data from children classes or other unrelated classes) both member variables and methods inside a class. The last and the most important similarity in both types of classes are, they are capable of handling virtual methods.

Wait! what are virtual methods?

Virtual methods are like any other method where they will have a method definition and will execute that definition upon calling that method. As an added advantage, If these methods are being inherited from a parent class these classes can be modified in the children's class by adding new definitions along with the existing definition or one can even over-write the entire definition provided by the parent class with a new set of definitions by using the "override" keyword.

Let's write a short virtual method inside our sleep class

To make any method a virtual method add the "virtual" keyword after an access specifier and before the return type of a method. Here in our example, there is a Dream method that generates a basic not so nightmarish, non-eccentric dream upon called by any of the children's class instance.

public abstract class Sleep : MonoBehaviour
    {
        public bool sleep;

        public void GetSleep()
        {
            //the inherited organisms will sleep whence this method is called
            sleep = true;
        }

        public virtual void Dream()
        {
            BasicDream();
        }

        private void BasicDream()
        {
            //A basic not so nightmarish, non-eccentric dream  
        }

    }
}

It is not mandatory for the children class to override the virtual method.

 public class Human : Sleep
    {
        public void GetSleep()
        {

        }

    }

This should not throw you any compile time or run time errors, but if you'd like to change the definition, You're given a free hand to do so. Let's assume that our human subject is suffering from some sort of sleep disorder and has a hard time sleeping. We cannot expect our subject to be having a pleasant dream during the course of his slumber. So we override the existing Dream method to give him a nightmare.

public class Human : Sleep
    {
        public void GetSleep()
        {

        }

        public override void Dream()
        {
            //bring him some ghosts, clowns and zombies to wreck his sleep
        }

    }

Now if you call the Dream() for an instance of a Human class, This human instead of having a non-nightmarish dream, he will see ghosts, clowns, and zombies in his dreams.
Here we have overridden the previous definition and changed it to give our human subject a taste of hell. But don't you feel like we have been too hard on our test subject? I definitely feel like it. So let's give him a normal non-nightmarish dream after all of that nightmare. As you know this "non-nightmarish dream" functionality is already part of the base Dream() method definition situated inside the parent class Sleep. Thus we do not have to rewrite it. To call the base definition inside an overridden method just use the keyword "base.MethodName()" (in our case it is base.Dream()) to use the base definition written inside the parent class.

        public override void Dream()
        {
            //bring him some ghosts, clowns and zombies to wreck his sleep
            base.Dream();
        }

The base class can be called inside an overridden method in no particular order. It can be either called before the overridden definitions or in-between the overridden definitions or even after the overridden definitions as we did above.

Now that you've learned virtual methods, we can now continue with answering the second question which is "Why abstract class instead of a normal class"?

As you could see normal classes and abstract classes are very similar and there is only one reason that should probably make you use an abstract class instead of a normal class. It is the need for an Interface like methods. In an Interface, methods are just declared and not defined. The ability to define these methods will be made mandatory for the classes that inherit the interface. The same way we can create such methods in abstract classes by preceding the method with the "abstract" keyword. Just add "abstract" keyword after an access specifier and before the return type of a method to make a method an abstract method.

We now use the same old Sleep class to create an abstract method called EstablishSleepTime(). As you could see that the sleep time can change in between species to species, every species should be able to establish their own definition of managing their sleep time.
Remember these abstract methods will not have definitions inside and the compiler will throw an error even if you try to give one.

public abstract class Sleep : MonoBehaviour
    {
        public bool sleep;

        public void GetSleep()
        {
            //the inherited organisms will sleep whence this method is called
            sleep = true;
        }

        public virtual void Dream()
        {
            BasicDream();
        }

        private void BasicDream()
        {
            //A basic non nightmar-ish, non eccentric dream  
        }

        public abstract void EstablishSleepTime();


    }
}

And also remember that the abstract methods can only be written in an abstract class.

Whence this class is inherited, the inherited class (in our case the Human class) will have to establish the amount of he sleep any human should be getting.

Writing definitions for an abstract method can only be done by overriding the abstract method inside the inherited class just like overriding a virtual method inside an inherited class

    public class Human : Sleep
    {
        public void GetSleep()
        {

        }

        public override void Dream()
        {
            //bring him some ghosts, clowns and zombies to wreck his sleep
            base.Dream();
        }

        public override void EstablishSleepTime()
        {
            //get 8 hours of sleep for this human
        }
    }

Here inside the EstablishSleepTime() method we define the amount of time a human can sleep. Since this EstablishSleepTime() is made as an abstract method in the parent class this method is made as a mandatory class to be defined in the children's class.

This is the main reason why we use an abstract class instead of a normal class.

The other main use of an abstract class:
If you could see the abstract class Sleep you can witness that it is a very common behavior of every living thing. Even non-living things like computers sleep when they're tired. So this functionality can be inherited by any class that requires sleep. If you had written the sleep functionality inside every single class it would only be a duplicate of the same functionality inside every single class that requires sleep. Since abstract is capable of being a replacement of a normal class, We write this once in a class and we directly inherit it and use it anywhere like how we would do with a normal default class.

Conclusion

Abstract classes are a combination of both a normal class and an interface. A normal method cannot handle an abstract method and Interfaces are incapable of using constructors, encapsulation, member variables, and method definitions. But the abstract class is capable of doing what both of these classes cannot do. If your class structure demands for such a class to be inherited then you should use an abstract class.

C# Intro to the Interface

Sujith — Thu, 11 Jul 2019 02:11:58 +0000

Prelude

Just so you know I'm not an Interface wizard who knows every nook and cranny that exists with an interface. I am just gonna explain how one can effectively use an interface and make their day/code less cumbersome and a lot cleaner. Also, a few elements of the examples will have some unity keywords in it, But that will not bog you from learning the fundamental concept that I'm trying to explain. Without further ado, let's jump into the topic.

What is an Interface?

An interface is a base class with a bunch of method declarations with no definitions, This interface class cannot work on its own as all its methods are just declarations. It will expect some other class to inherit this interface and upon inheriting the interface will make it mandatory to the inherited class to define all the method declarations inside it. In essence, an interface tells a class about the methods it needs to have in order for the class to perform certain functions but the interface will not tell what the function does, It will expect the writer of that class to know it.
I hope this much is clear, let's continue with an example , A human will perform a function of eating without which a human will die. If the human were a class we interface the class human with an Interface IEat (People always precede Interface with an "I" so let us follow the same rule, It's not necessary but I'd advise everybody to follow the same). This IEat will only add a method to the class Human called Eat and this method will have a parameter called consummate amount. Remember this method or the parameter from the interface does not tell us how to eat or how much to eat. They will only tell these things to exist in class and later the writer of the class should specify how to eat the food and how much/what food to eat Human.

This is how the code for the above-mentioned functionality will look like

IEat.cs Interface

public interface IEat {

    void Eat(int consumateamount);
}

Human.cs

public class Human : IEat
{
    public void Eat(int consumateamount)
    {
        PutItInMouth(GetFood(consumateamount));
    }

    private Food GetFood(int consumateamount)
    {
        Food food = new Food();
        food.apple = consumateamount;
        food.meat = consumateamount;
        return food;
    }

    public void PutItInMouth(Food food)
    {
        //Human Eats
    }
 }

public class Food
{
    public int apple;
    public int meat;
}

So now let's see how we could use this Eat(int consumateamount) for a human test subject.

Let's consider that the human brain has a class called BrainSchedule, Inside the class we have each time cycle of a day as a method and inside every method we call the Eat(int consumateamount) method for an instance of a human subject. Here the amount of food consumed is determined by the time cycle method.

public class BrainSchedule : MonoBehaviour
{
    private Human myHuman;

    private void Morning()
    {
        myHuman.Eat(2);
    }
    private void Noon()
    {
        myHuman.Eat(4);
    }
    private void Evening()
    {
        myHuman.Eat(1);
    }
    private void Night()
    {
        myHuman.Eat(2);
    }
}

As you could see the BrainSchedule class assumes that the Human class has an eat method inside it and calls that method at different cycles of the day to keep the human well nourished.

We've just learned what an Interface is, But this is not the best application of it.

Thus we have a make-believe scenario here where Interface could be used at it's best.

Let's say we are maintaining a zoo, and this zoo has a variety of animals. Each animal will have its own base class. We as the zookeepers our main job here is to feed them. Even though each animal has its own unique food preference we can segregate them based on their food habits into three different categories.Herbivores, Carnivores and Omnivores

Writing the feeding system

We will have a common class called Feeding System which allocates the amount of food and feeds it to the respective animals based on the category. The important point to be noted here is each category will have different subcategories. For example, Herbivores eat foods ranging from hay to fruits. Some animals like Koala will eat the only eucalyptus. According to our design, the feeding system will only segregate foods based on the main categories, If Koala does not want to eat berries and only eat eucalyptus then it is up to the Koala to ignore the berries and consume eucalyptus, and will not be spoon-fed by the feeding system. (This in the real life would be a very irresponsible feeding system but for the sake of learning the Interface we are gonna bear with it).

Let's define what sort of foods these categories gonna have

[System.Serializable] //Just so I could view this over the inspector
public class HerbivoreFood
{
    public int hay;
    public int strawberry;
    public int eucalyptus;
}

[System.Serializable]
public class CarnivoreFood
{
    public int salmon;
    public int steak;
    public int lamb;
}

[System.Serializable]
public class OmnivoreFood
{
    public CarnivoreFood carnivoreFood;
    public HerbivoreFood herbivoreFood;
}

Let's create three interfaces based on the three different categories, Each of this category based interfaces will impose one method that takes in the food type of its category type. For example, Iherbivore interface should have an EatGreens method that takes HerbivoreFood instance as an argument. The code sample is provided below

public interface IHerbivore
{

    void EatGreens(HerbivoreFood herbivoreFood);

}

public interface ICarnivore
{
    void EatMeat(CarnivoreFood carnivoreFood);
}

public interface IOmnivore
{
    void EatGreensAndMeat(OmnivoreFood omnivoreFood);
}

And let's create a base class for every animal in the zoo and we will make each animal inherit an interface that suits with their food habits. For example, If an animal likes berries, It will have access to those berries only if the feeding system recognizes that animal is an herbivore and sends it herbivore based food. For the feeding system to recognize a given animal is herbivore or not we need to inherit the base class of an animal from the IHerbivore interface. (If the animal only wants to eat meat then it should inherit from the ICarnivore interface or else if it wants both then it should inherit from the IOmnivore interface.) The code for the base classes are given below.

public class Koala : MonoBehaviour, IHerbivore
{
    private int stomach;


    public void EatGreens(HerbivoreFood herbivoreFood)
    {
        EatEucalyptus(herbivoreFood.eucalyptus);
    }

    private void EatEucalyptus(int eucalyptus)
    {
        stomach += eucalyptus;
    }
}

As mentioned earlier due to Koala's inheritance from the IHerbivore class, It will be sent with all of the Herbivore based food but if you look properly at the class you'll realize that after receiving all of the herbivore based food it eats only what it wants to eat which is the eucalyptus and leaves the rest.

public class Panther : MonoBehaviour, ICarnivore
{
    private int stomach;

    public void EatMeat(CarnivoreFood carnivoreFood)
    {
        EatSteak(carnivoreFood.steak);
    }

    private void EatSteak(int steak)
    {
        stomach += steak; 
    }
}

Same way the panther eats only the steak even if it has access to lamb inside the CarnivoreFood Class.

public class Bear : MonoBehaviour,IOmnivore
{
    private int stomach;

    public void EatGreensAndMeat(OmnivoreFood omnivoreFood)
    {
        EatBerries(omnivoreFood.herbivoreFood.strawberry);
        EatFish(omnivoreFood.carnivoreFood.salmon);

    }

    private void EatBerries(int berries)
    {
        stomach += berries;
    }

    private void EatFish(int salmon)
    {
        stomach += salmon;

    }
}

And bear as usual being an omnivore eats both berries and salmon.

Now let's write the feeding system

The Feeding system should first have access to all the animals in the zoo, So we have all the animals inside the allZooAnimals array which is the type of a GameObject. (It is a Unity specific type don't pay much attention to it, just consider it as a common reference type). So far we have three animals scripts made so we will have three animals in the array and each animal GameObject will have one of the three animal scripts attached to them. As we have all of our animals now we create objects for each food type and initialize it inside the Start() method. After that, we call the FeedAllAnimals() method, which will recognize the type of each animal script attached to each GameObject in the array and call the appropriate method and pass the appropriate food type based on its category.

public class FeedingSystem : MonoBehaviour
{

    public GameObject[] allZooAnimals;

    [SerializeField]private HerbivoreFood herbivoreFood;
    [SerializeField]private CarnivoreFood carnivoreFood;
    [SerializeField]private OmnivoreFood omnivoreFood;


    private void Start()
    {
        ///Get food ready
        herbivoreFood = new HerbivoreFood();
        herbivoreFood.hay = 50;
        herbivoreFood.eucalyptus = 50;
        herbivoreFood.strawberry = 100;


        carnivoreFood = new CarnivoreFood();
        carnivoreFood.steak = 60;
        carnivoreFood.salmon = 100;
        carnivoreFood.lamb = 100;

       omnivoreFood = new OmnivoreFood();
        omnivoreFood.herbivoreFood = herbivoreFood;
        omnivoreFood.carnivoreFood = carnivoreFood;

        FeedAllAnimals();
    }


    private void FeedAllAnimals()
    {
        for (int i = 0; i < allZooAnimals.Length; i++)
        {

            IHerbivore herbivore = allZooAnimals[i].GetComponent<IHerbivore>();

            if (herbivore != null)
            {
                herbivore.EatGreens(herbivoreFood);
            }

            ICarnivore carnivore = allZooAnimals[i].GetComponent<ICarnivore>();

            if (carnivore != null)
            {
                carnivore.EatMeat(carnivoreFood);
            }

            IOmnivore omnivore = allZooAnimals[i].GetComponent<IOmnivore>();

            if (omnivore != null)
            {
                omnivore.EatGreensAndMeat(omnivoreFood);
            }
        }
    }
}

The GetComponent inside the FeedAllAnimals() method will get the instance of the animal as the type of the interface, We do this and not the base class of the animals because, the base class might have a hell lot functionalities which the feeding class does not need to know about, By accessing the instance as an interface we know that these methods inside the interface will compulsorily be written inside the class that inherits it, so we can pass the data with confidence also we use this to type check what sort of food that particular instance of the animal eats without having to know anything about that animal apart from its food habit just through the interface.

If you're buying a new animal to the zoo, Fret not! Just add an interface based on their diet to the animal and they will be ready to be fed, For example, see this Tiger and Zebra.

public class Tiger : MonoBehaviour, ICarnivore
{
    private int stomach;

    public void EatMeat(CarnivoreFood carnivoreFood)
    {
        EatLamb(carnivoreFood.lamb);
    }

    private void EatLamb(int lamb)
    {
        stomach += lamb;
    }
}

public class Zebra : MonoBehaviour, IHerbivore
{

    private int stomach;

    public void EatGreens(HerbivoreFood herbivoreFood)
    {
        EatHay(herbivoreFood.hay);
        EatBerries(herbivoreFood.strawberry);
    }


    private void EatHay(int hay)
    {
        stomach += hay;
    }

    private void EatBerries(int berries)
    {
        stomach += berries;
    }

}

So this marks the end of this tutorial or whatever you call this is, According to me this is the best use of an interface I've seen so far. Maybe there is more to the interface than meets the eye, if you know that is the case lets discuss it in the comments section below.

P.S This is like the first blog that I've ever written in my entire life so if you see places where I could improve both in writing and programming please do let me know, Thanks XOXO