Abstract Classes

Abstract Classes

Today, we build on that notion by discussing Abstract classes, which represent abstract entities. Earlier this semester, we discussed classes, and how they represent single entities – persons, places or things.

But in 2013, a phone isn’t nearly descriptive enough. You need more details, like brand, features, color, etc. Suppose I need you to run an errand for me. I need you to go online and purchase a phone for me. If we were in 1915, that might be all the information you need. But what do I mean by abstract?

Similarly, suppose a friend and I are just returning from the zoo, and you’re interested in knowing what animals we saw. Once again, you’re not satisfied, because there is no such creature named mammal. And upon you asking, we respond, “Mammals”.

And I respond, “A muscle.” Once again, you’re still not satisfied, because there is no body part simply named muscle. And lastly, suppose I need you to be my workout partner tomorrow at the gym. And you respond, “Sure! Which body part will we be working out?”

What phone, mammal and muscle all have in common is that they’re not actual entities. They’re abstract entities. General ideas. Mammal generally means any creature that is warm-blooded, has a vertebrae, is hairy or furry, as well as other characteristics. And Muscle is generally any organ in the body that contracts to produce a movement. Phone generally means any device we use to communicate with someone far away.

Phone Mammal Iphone Android Lion Human Muscle Bicep Tricep From these abstract entities, actual entities can be derived. …But what relevance does this have to C++?

Suppose I am creating Animal.cpp, where multiple Animal objects interact with one another based on user input. I’ll need 4 different classes to start off with, each corresponding to an animal.

struct Puppy { string name; int age; void eating() { cout << “Eating Puppy Chow”; } void makeSound() { cout << “Woof woof!”; } };

struct Kitten { string name; int age; void eating() { cout << “Eating Gourmet Blend”; } void makeSound() { cout << “Meowww…”; } };

struct Cow { string name; int age; void eating() { cout << “Eating grass…”; } void makeSound() { cout << “Moooo…”; } };

struct Snake { string name; int age; void eating() { cout << “Eating mice”; } void makeSound() { cout << “Hssssss…”; } };

Not only that, but suppose I decide tomorrow to store more information, like animal breed and color – I’ll have to go to each class and make that same change. I’m a tad worn out though, because I’m rewriting much of the same code for each class I create. Fortunately, C++ offers a more convenient approach in the form of an abstract class.

struct Animal { // Abstract class string name; int age; void eating() { cout << “Eating”; } void makeSound() { cout << “Making sounds…”; } };

struct Puppy : public Animal { // Empty }; struct Kitten : public Animal { // Empty }; struct Cow : public Animal { // Empty }; struct Snake : public Animal { // Empty }; C++ recognizes this kind of need, and thus allows us to make functions virtual, which gives us the option of overriding the default definition in a subclass. With that taken care of, my next issue is me not wanting the eating() function to have the same output for every class, since each animal has their own preferred food. I can leave the struct empty (for now) because Puppy inherits all the variables and functions inside Animal.

struct Animal { … virtual void eating() { cout << “Eating”; } … }; The virtual keyword at the front indicates the function is virtual. Each subclass now has the option of either using the default definition or defining its own.

struct Puppy : public Animal { // Override void eating() { cout << “Eating Puppy Chow”; } }; struct Kitten : public Animal { // Override void eating() { cout << “Eating Gourmet Blend”; } }; struct Cow : public Animal { // Override void eating() { cout << “Eating grass…”; } }; struct Snake : public Animal { // Empty // We’ll keep the default definition };

Another example of a function we would want to make virtual (if it were declared inside Animal) is: virtual void walking() { cout << “Walking…”; } For the Snake, however, the default definition doesn’t make sense. So we would want to exercise the option to override it in this case. For Puppy, Kitten and Cow, the default definition is probably good enough.

struct Animal { … virtual void makeSound() = 0; … }; That all being said,sometimes we don’t want overriding the definition of a virtual function to be optional. Sometimes, we want it to be required. Functions that are requiredto be overridden are known as Pure Virtual Functions. The virtual keyword at the front and the ‘= 0’ symbol at the end indicates the function is pure virtual. Since this function is required to be overridden, it has no default definition.

struct Puppy : public Animal { … // Override void makeSound() { cout << “Woof woof!”; } }; struct Kitten : public Animal { … // Override void makeSound() { cout << “Meooowww…”; } }; struct Cow : public Animal { … // Override void makeSound() { cout << “Moooooo…”; } }; struct Snake : public Animal { …. // Override void makeSound() { cout << “Hssssss…”; } };

Another example of a function we would want to make • pure virtual is: • virtual void drawSelf() = 0; // Draw self using FLTK So in this case, it makes more sense to require each class derived from Animal to provide its own definition of how it should be drawn. In this case, no default definition would make sense because there is no default image of an animal (that I know of).

In summary, the job of Abstract Classes (such as the Animal class) is to store variables and functions that each of its subclasses will have in common. When it comes to functions, the default definition in our Abstract class may not always be specific enough. In those cases, we make the function virtual to give us the option of overriding it. At other times, we may not want a default definition. Sometimes, we will want every subclass to have its own definition, and in those cases, we make the function pure virtual. In closing, whenever you have multiple classes that fall under a similar category and share several traits, consider creating an abstract class. Once created, the only code needed inside the subclass will be the code specific to just that class.

Abstract Classes