Learning to Code — Part 9b: Inheritance & Polymorphism

OK, so here we go, new stuff!

ABSTRACT CLASSES

We’re going to talk about something called Abstract Classes, but the SoloLearn app first reviews what we just went through, polymorphism. It states that it’s:

Used when you have different derived classes with the same method, which has different implementations in each class. This behavior is achieved through virtual methods that are overridden in the derived classes.

In other words, where a base class has methods that are inherited by a derived class, you can have a method in the derived class overwrite a method of the same name from the base class.

They state that in some cases, there’s no need for the virtual method (i.e. the method that will be overwritten/doing the overwriting) to have a separate definition within the base class. Basically, you can have the method from within the derived class do the defining. This is specified with the abstract keyword. It’s also essential to know that you cannot instantiate objects of a class that contains an abstract method. So, our code would look like this:

abstract class Shape {
     public abstract void Draw();
}

The explanation within the app has me somewhat confused. It says:

As you can see, the Draw method is abstract and thus has no body. You do not even need the curly brackets; just end the statement with a semicolon. The Shape class itself must be declared abstract because it contains an abstract method.

The app then goes on to say:

Members marked as abstract, or included in an abstract class, must be implemented by classes that derive from the abstract class.

Here are my questions:

• The abstract Draw method above doesn’t appear to do anything, so what’s the point of it?
• …must be implemented by classes that derive from the abstract class. Does that mean that the abstract class is a base class?

Oh, Google??

First, looking on the site called Guru99, in a post called C# Abstract Classes Tutorial with Example, I see the sentence…

…An abstract class is used to define what is known as a base class.

So that answers my second question: yes, an abstract class is a base class. The post goes on to give the example of an abstract class called Animal within which is a method called Description, that they refer to as a generic method. Specifically, however, they mention that there’s nothing known about the Animal class, such as, whether it’s a dog or a cat.

Just as before, if we have derived classes called Dog and Cat, and want to instantiate a Dog object, when doing so, it inherits from the Animal base class, but cannot change the definition of the Description method. Instead, it has to define it’s own method called Dog-Description. Here’s the code:

abstract class Tutorial {
     public virtual abstract void Set();
}
public class Guru99Tutorial : Tutorial {
     protected int TutorialID;
     protected string TutorialName;
     public void SetTutorial(int pID, string pName) {
          TutorialID = pID;
          TutorialName = pName;
     }
     public String GetTutorial() {
          return TutorialName
     }
}

I understand how it works: the class called Guru99Tutorial is the derived class that inherits from the base class called Tutorial. Since Tutorial is an abstract class, the method called Set cannot change the definition of the Set method. Therefore, it has its own setting method called SetTutorial.

But, in what situation is this needed?

I moved on to the next section within the SoloLearn app, and the first few sentences began to clear things up:

An abstract class is intended to be a base class for other classes. It acts like a template for it’s derived classes. Now, having the abstract class, E can derive the other classes and define the own Draw() methods:

Looking at the code they show (which I’ll show in a moment), I’d ask this question, is the abstract, base class simply “telling” the programmer that the derived classes must contain all of the abstract methods listed within it?

Below the code within the app, it says:

A non-abstract class derived from an abstract class must include actual implementations of all inherited abstract methods and accessors.

That sounds like the answer to my question is, yes. Here’s the code from the app:

abstract class Shape {
     public abstract void Draw();
}
class Circle : Shape {
     public override void Draw() {
          Console.WriteLine(“Circle Draw”);
     }
}
class Rectangle : Shape {
     public override void Draw() {
          Console.WriteLine(“Rect Draw”);
     }
}
class Program {
     static void Main(string[] args) {
          Shape c = new Circle();
          c.Draw(); }
}

When executed, a new Circle object, of type Shape, called c is instantiated. Then, the Draw method of the new Circle object called c is executed. This jumps up to the class called Circle (which inherits from the abstract class called Shape, which requires that any derived class define a method called Draw), and executes the method called Draw, which prints the string Circle Draw to the screen.

OK, this now makes sense to me. It’s a way of ensuring that derived classes include specific methods (from a base class). That was a bit tough, but I think I’ve got it now.

INTERFACES

An interface is also an abstract class, but it contains only abstract members, and is declared with the interface keyword, like this:

public interface IShape {
     void Draw();
}

Since all members of an interface are abstract by default, an “efficiency” here is that you don’t actually need to enter the abstract keyword. It’s also important to know that all members of an interface are public, so no other access modifiers can be applied to them. Notice also that the name of the method has an “I” at the beginning. This is a common practice by programmers. Also, while they can contain properties and methods, the cannot contain fields (variables).

A requirement of implementing an interface is that, at the same time, it must define all of its methods. This was a little confusing to me and, while the next sentence, in my opinion, didn’t immediately and clearly explain the point, I was able to infer what it meant:

The term implementing an interface is used (opposed to the term “inheriting from”) to describe the process of creating a class based on an interface.

While the code above is the actual interface, the following is the process of implementing the interface:

class Circle : IShape {
     public void Draw() {
          Console.WriteLine(“Circle Draw”)
     }
}

So the “requirement” in the code above occurs when the method called Draw is defined (just as it is in the interface itself). As the app states:

The class implementing the interface must define how to accomplish the behaviors.

It’s also important to note that you do not need to use the override keyword when implementing the interface. The question that should be coming up now is, why use an interface instead of an abstract class? This goes back a few articles ago where I mentioned that a derived class cannot inherit from more than one base class. They can, however, inherit from more than one interface. The syntax for inheriting from multiple interfaces is:

Class A : IShape, IAnimal, etc.

NESTED CLASSES

There are only two, short sections left within Inheritance & Polymorphism, so we’re going to finish it up. A nested class is simply when a class is a member of another class, like this:

class Car {
     string name;
     public Car(string nm) {
          name = nm;
          Motor m = new Motor();
     }
     public class Motor {
          //some code
     }
}

In the code above, the Motor class is nested within the Car class. Not only can it be used just like any other members within the class, it can have the same access modifiers as other members (i.e. public, private, protected, etc.). The way the SoloLearn app goes on to explain it really makes it clear:

A car, which has its own attributes (color, brand, etc.) contains a motor, which as a separate objects, has its own attributes (volume, horsepower, etc.).

NAMESPACES

And finally, namespaces, as we defined in Part 2:

A namespace is a scope. It is container, or space, for things with names. It is a way of grouping those named things (presumably in a meaningful way) so the names don’t collide with other named things. Being the containing scope for named things is a namespace’s primary purpose. Namespaces are just fences around named things so that you can say “I’m talking about the Fido behind THAT fence” or “I think the thing I need is behind THAT fence.”

So, the code would look like this:

namespace SoloLearn {
     class Program {
          static void Main(string[] args) {
          }
     }
}

We also stated that at the beginning of your code, before the namespace declaration, you use the using keyword along with the libraries you intend to use with your program. So, in the following example…

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

The code above loads those 5 libraries into memory. For example, if we didn’t use that first line (using System) and tried to use the Console class (i.e. Console.WriteLine(“Hi”);), it wouldn’t work. If, for some reason, you didn’t want to use the using keyword to preload the library, but still wanted to use the Console class, you’d have to spell that out in-line:

System.Console.WriteLine(“Hi”);

System is one example of a .NET Framework namespace.

OK, so that’s it for Inheritance & Polymorphism. Next up will be Structs, Enums, Exceptions and Files. We’re definitely getting close to the end, and I’m starting to get excited to move onto the Revit API.

As usual, please let me know if there’s anything I got wrong, or need to explain further. Also, here’s a link to Learning to Code — Part 9a: Inheritance & Polymorphism.

Web: BIMuzer.com

Twitter: @BIMuzer

LinkedIn: Scott Rosenbloom