Inheritance vs. polymorphism
Hi All,
I'm trying to learn more about inheritance and polymorphism, and also, combining the two. I wrote this program in hopes that I could understand it better. I made two classes (a milk truck and a UPS truck class) that both inherit from a truck class. It's working pretty well, but I have one last function that determins if the truck can go at the required speed. That function is a virtual function, but I don't know how to make it work. Code:
#include <iostream> Code:
truck *anotherUPS = new cls_ups_truck; thanks for any help! |
Quote:
Code:
truck *atruck = new cls_ups_truck; |
You're so close to making it work!
First, you have a dup-itis problem that has nothing to do with polymorphism; it simply makes your program work incorrectly as it is. Near the end of your code, when you're processing the UPS info, you do this: Code:
if (milk_truck.can_i_go_that_fast()) Code:
if (ups.can_i_go_that_fast()) Now. On to polymorphism. I modified your original program to use polymorphism by making the following changes.
Here's the code. It works. Code:
#include <iostream> |
I do not really think that creating a "blob" is the best way of achieving what the OP is after and to be blunt is very bad design. With a little re-factoring it could be made much better and not exit the application. The following:
Code:
virtual int milkGal() = 0; Code:
virtual int const& load()const = 0; Code:
class Truk |
It might help to consider that inheritance and polymorphism are really two sides .. but opposite sides .. of the same coin.
Inheritance tries to exploit the cases where "X is just the same as Y except..." Meanwhile, polymorphism tries to exploit, "Y is just the same as X, except..." Uh huh, "X and Y are reversed .. that's the only difference between the two .." but what a difference it is! In each case, what you're shooting for is the same goal: economy of code. There is, in each case, a "common set of code" that lies at the intersection between "X" and "Y," and in either case you are trying to exploit that commonality. But the two cases will never be equal because in one case you are exploiting the union between the two sets and in the other case you are exploiting the difference. P.S. Such an incredibly deep distinction, occurring as it is at such a late hour of the evening (in this part of the planet, anyhow) is definitely best-appreciated under the influence of good beer. ;) In fact, under such influences it is positively brilliant... |
thanks everyone for all the replies! wjevans_7d1@yahoo.co, thanks for catching that error with the use of the wrong object (milk instead of ups). dmail, you're right, i dont want to use "bulk" code as you called it. and i realize that i can categorize the contents of both trucks as "load" but what happens when an example comes around that doesn't allow something that simple?
i guess i'm also still very confused about the syntax of polymorphism. i thought i understood it, but now i'm thinking otherwise. can someone give me a definition of virtual and = 0 at the end of the functions. i guess i just used them b/c they didn't provide an error in the end. thanks again for everyone's help! |
If a class method is defined as virtual then the compiler will build a virtual lookup table. What this means is that when the program runs the code will need to visit the lookup table to decide which of the methods to actually call. Is is the truck version of the method, the cls_milk_truck version or the cls_ups_truck version. It decides which one by looking at the actual class of the object. Let's just assume that the actual object is a cls_farmyard_milk_truck then it will look up the virtual table for the version to use, since this class doesn't have a can_i_go_that_fast() it will then look at the parent class, in this case the cls_milk_truck, which does and so that version will be called.
Next comes the =0, this is associated with virtual functions and in C++ they are called pure virtual functions. A pure virtual function differ from virtual functions in that they don't have a definition (source code). Because they have not been defined they can't be called, and what is more it means that an object of that class can't be instantiated, the class is referred to as an abstract class and child classes would need to provide the code for this method if object of the child classes are to be created. However, a pointer to an abstract class can be declared, it must be instantiated to a concrete class, such as: truck * myVehicle; myVehicle = new cls_milk_truck(); Finally virtual functions can be called statically, that is it is possible to tell the compiler that under these circumstances call this version of the virtual function. For example the can_i_go_that_fast() of the cls_farmyard_milk_truck could be written to ensure that farmyard milk trucks are half the speed of their road running cousins, as follows: Code:
bool cls_farmyard_milk_truck::can_i_go_that_fast() |
Thanks graemef! That helped out a lot!
|
All times are GMT -5. The time now is 07:43 PM. |