In the last OOPsie entry we looked into the basics behind object-oriented programming (OOP) and learned quite a bit about classes, objects, and inheritance. The big question that defined inheritance was: 'How can we reuse code to give a handful of objects similar details?' The example we used was a series of cars, all of which shared similar details like having 4 wheels and being able to start up. And, while we customized the color of the Ferrari car class using 2 objects, both performed the same. Upon starting up and honking the horn they both sounded the same. This time around we'll append to our question that defines inheritance: 'How can we reuse code to give a handful of objects similar details while keeping their individuality?'
Individuality
First, before we continue, we should define individuality in the context of this article. Surprisingly, I'm not referring to your awkward years in high school when I mention individuality. There are two types of individuality we need to look at, class individuality and object individuality. In this context, class individuality will refer to different classes (remember classes are like blueprints) that have their own unique features. Even though 2 classes inherit from a base class, there's a great chance they inherit in order to provide their own unique details (in fact, this always should be the case) even though they both have similiar functionality. For the simple reason that it makes little to no sense to inherit from a base class only to provide the same functionality, we will assume every class mentioned herein is somehow unique and promotes the idea of class individuality.
On the other hand, object individuality will refer to differences between objects. For instance, if we had two House objects and each was painted differently, each house would have object individuality.
Quick side note: The Ferrari objects mentioned in the last OOPsie were NOT class individualistic but were object individualistic. The two Ferrari car objects had different color data stored but the Ferrari class had no unique functionality compared to Car (which it inherited from).
Is-A Relationships
Remember from last OOPsie, we said inheritance provides a sub class with a is-a relationship to the parent. For example, a Ferrari is-a Car (this is how we modelled our classes). However, notice that every Car is not a Ferrari. This is an extremely fundamental piece to the abstract idea of inheritance and I should have mentioned it in the first article, but as we'll see, this one-way relationship will be a big focus in a later portion of this article.
While on the topic of relationships, especially when it comes to this article, let's take a very brief glance at object relationships and equality. With objects, since we are instantiating (creating) objects off a blueprint, we could end up with multiple objects with all the same properties. Like we learned last article, we can customize our object by passing in arguments to a constructor. So, if we create a two green Ferrari's, we can assume they are equal because they share the same properties (even though they are, in fact, two actually seperate entities and are stored in seperate memory locations). In this case, the two Ferrari's are individualistic against all other objects that don't share all the same properties (such as a Red or Yellow Ferrari) but are not individualistic compared to each other and can be considered equal.
Function Overriding with Inheritance
One of the awesome key features we haven't discussed regarding to inheritance thusfar has been the concept of function overriding (sometimes referred to as a virtual function). Function overriding allows subclasses (classes that inherit from another class) to define it's own implementation of a function defined in the base class. This will come in much more useful later when we get into Polymorphism, but lets look at an example using a screen cap from Dead Rising 2.
Comments
Post a Comment