Fri, May 31, 2019 4:50:48 PM
If you write a method in Java (as you will soon learn how to do): <br/>
void doSomething(Shape shape) { <br/>
shape.erase(); <br/>
// ... <br/>
shape.draw(); <br/>
} <br/>
This method speaks to any Shape, so it is independent of the specific type of object that it�s <br/>
drawing and erasing. If some other part of the program uses the doSomething( ) method: <br/>
Circle circle = new Circle(); <br/>
Triangle triangle = new Triangle(); <br/>
Line line= new Line(); <br/>
doSomething(circle); <br/>
doSomething(triangle); <br/>
doSomething(line); <br/>
The calls to doSomething( ) automatically work correctly, regardless of the exact type of <br/>
the object. <br/>
This is a rather amazing trick. Consider the line: <br/>
doSomething(circle); <br/>
What�s happening here is that a Circle is being passed into a method that�s expecting a <br/>
Shape. Since a Circle is a Shape it can be treated as one by doSomething( ). That is, any <br/>
message that doSomething( ) can send to a Shape, a Circle can accept. So it is a <br/>
completely safe and logical thing to do. <br/>
We call this process of treating a derived type as though it were its base type upcasting. The <br/>
name cast is used in the sense of casting into a mold and the up comes from the way the <br/>
inheritance diagram is typically arranged, with the base type at the top and the derived <br/>
classes fanning out downward. Thus, casting to a base type is moving up the inheritance <br/>
diagram: �upcasting.� <br/>
<br/>
An object-oriented program contains some upcasting somewhere, because that�s how you <br/>
decouple yourself from knowing about the exact type you�re working with. Look at the code <br/>
in doSomething( ): <br/>
shape.erase(); <br/>
// ... <br/>
shape.draw(); <br/>
Introduction to Objects 27�<br/>
Notice that it doesn�t say, �If you�re a Circle, do this, if you�re a Square, do that, etc.� If you <br/>
write that kind of code, which checks for all the possible types that a Shape can actually be, <br/>
it�s messy and you need to change it every time you add a new kind of Shape. Here, you just <br/>
say, �You�re a shape, I know you can erase( ) and draw( ) yourself, do it, and take care of <br/>
the details correctly.� <br/>
What�s impressive about the code in doSomething( ) is that, somehow, the right thing <br/>
happens. Calling draw( ) for Circle causes different code to be executed than when calling <br/>
draw( ) for a Square or a Line, but when the draw( ) message is sent to an anonymous <br/>
Shape, the correct behavior occurs based on the actual type of the Shape. This is amazing <br/>
because, as mentioned earlier, when the Java compiler is compiling the code for <br/>
doSomething( ), it cannot know exactly what types it is dealing with. So ordinarily, you�d <br/>
expect it to end up calling the version of erase( ) and draw( ) for the base class Shape, and <br/>
not for the specific Circle, Square, or Line. And yet the right thing happens because of <br/>
polymorphism. The compiler and runtime system handle the details; all you need to know <br/>
right now is that it does happen, and more importantly, how to design with it. When you <br/>
send a message to an object, the object will do the right thing, even when upcasting is <br/>
involved. <br/>
The singly rooted hierarchy <br/>
One of the issues in OOP that has become especially prominent since the introduction of C++ <br/>
is whether all classes should ultimately be inherited from a single base class. In Java (as with <br/>
virtually all other OOP languages except for C++) the answer is yes, and the name of this <br/>
ultimate base class is simply Object. It turns out that the benefits of the singly rooted <br/>
hierarchy are many. <br/>
All objects in a singly rooted hierarchy have an interface in common, so they are all <br/>
ultimately the same fundamental type. The alternative (provided by C++) is that you don�t <br/>
know that everything is the same basic type. From a backward-compatibility standpoint this <br/>
fits the model of C better and can be thought of as less restrictive, but when you want to do <br/>
full-on objectoriented programming you must then build your own hierarchy to provide the <br/>
same convenience that�s built into other OOP languages. And in any new class library you <br/>
acquire, some other incompatible interface will be used. It requires effort (and possibly <br/>
multiple inheritance) to work the new interface into your design. Is the extra �flexibility� of <br/>
C++ worth it? If you need it�if you have a large investment in C�it�s quite valuable. If you�re <br/>
starting from scratch, other alternatives such as Java can often be more productive. <br/>
All objects in a singly rooted hierarchy can be guaranteed to have certain functionality. You <br/>
know you can perform certain basic operations on every object in your system. All objects can <br/>
easily be created on the heap, and argument passing is greatly simplified. <br/>
A singly rooted hierarchy makes it much easier to implement a garbage collector, which is <br/>
one of the fundamental improvements of Java over C++. And since information about the <br/>
type of an object is guaranteed to be in all objects, you�ll never end up with an object whose <br/>
type you cannot determine. This is especially important with system-level operations, such as <br/>
exception handling, and to allow greater flexibility in programming. <br/>
Containers <br/>
In general, you don�t know how many objects you�re going to need to solve a particular <br/>
problem, or how long they will last. You also don�t know how to store those objects. How can <br/>
you know how much space to create if that information isn�t known until run time? <br/>
28 Venkata Pilaka Venkata Pilaka <br/>
void doSomething(Shape shape) { <br/>
shape.erase(); <br/>
// ... <br/>
shape.draw(); <br/>
} <br/>
This method speaks to any Shape, so it is independent of the specific type of object that it�s <br/>
drawing and erasing. If some other part of the program uses the doSomething( ) method: <br/>
Circle circle = new Circle(); <br/>
Triangle triangle = new Triangle(); <br/>
Line line= new Line(); <br/>
doSomething(circle); <br/>
doSomething(triangle); <br/>
doSomething(line); <br/>
The calls to doSomething( ) automatically work correctly, regardless of the exact type of <br/>
the object. <br/>
This is a rather amazing trick. Consider the line: <br/>
doSomething(circle); <br/>
What�s happening here is that a Circle is being passed into a method that�s expecting a <br/>
Shape. Since a Circle is a Shape it can be treated as one by doSomething( ). That is, any <br/>
message that doSomething( ) can send to a Shape, a Circle can accept. So it is a <br/>
completely safe and logical thing to do. <br/>
We call this process of treating a derived type as though it were its base type upcasting. The <br/>
name cast is used in the sense of casting into a mold and the up comes from the way the <br/>
inheritance diagram is typically arranged, with the base type at the top and the derived <br/>
classes fanning out downward. Thus, casting to a base type is moving up the inheritance <br/>
diagram: �upcasting.� <br/>
<br/>
An object-oriented program contains some upcasting somewhere, because that�s how you <br/>
decouple yourself from knowing about the exact type you�re working with. Look at the code <br/>
in doSomething( ): <br/>
shape.erase(); <br/>
// ... <br/>
shape.draw(); <br/>
Introduction to Objects 27�<br/>
Notice that it doesn�t say, �If you�re a Circle, do this, if you�re a Square, do that, etc.� If you <br/>
write that kind of code, which checks for all the possible types that a Shape can actually be, <br/>
it�s messy and you need to change it every time you add a new kind of Shape. Here, you just <br/>
say, �You�re a shape, I know you can erase( ) and draw( ) yourself, do it, and take care of <br/>
the details correctly.� <br/>
What�s impressive about the code in doSomething( ) is that, somehow, the right thing <br/>
happens. Calling draw( ) for Circle causes different code to be executed than when calling <br/>
draw( ) for a Square or a Line, but when the draw( ) message is sent to an anonymous <br/>
Shape, the correct behavior occurs based on the actual type of the Shape. This is amazing <br/>
because, as mentioned earlier, when the Java compiler is compiling the code for <br/>
doSomething( ), it cannot know exactly what types it is dealing with. So ordinarily, you�d <br/>
expect it to end up calling the version of erase( ) and draw( ) for the base class Shape, and <br/>
not for the specific Circle, Square, or Line. And yet the right thing happens because of <br/>
polymorphism. The compiler and runtime system handle the details; all you need to know <br/>
right now is that it does happen, and more importantly, how to design with it. When you <br/>
send a message to an object, the object will do the right thing, even when upcasting is <br/>
involved. <br/>
The singly rooted hierarchy <br/>
One of the issues in OOP that has become especially prominent since the introduction of C++ <br/>
is whether all classes should ultimately be inherited from a single base class. In Java (as with <br/>
virtually all other OOP languages except for C++) the answer is yes, and the name of this <br/>
ultimate base class is simply Object. It turns out that the benefits of the singly rooted <br/>
hierarchy are many. <br/>
All objects in a singly rooted hierarchy have an interface in common, so they are all <br/>
ultimately the same fundamental type. The alternative (provided by C++) is that you don�t <br/>
know that everything is the same basic type. From a backward-compatibility standpoint this <br/>
fits the model of C better and can be thought of as less restrictive, but when you want to do <br/>
full-on objectoriented programming you must then build your own hierarchy to provide the <br/>
same convenience that�s built into other OOP languages. And in any new class library you <br/>
acquire, some other incompatible interface will be used. It requires effort (and possibly <br/>
multiple inheritance) to work the new interface into your design. Is the extra �flexibility� of <br/>
C++ worth it? If you need it�if you have a large investment in C�it�s quite valuable. If you�re <br/>
starting from scratch, other alternatives such as Java can often be more productive. <br/>
All objects in a singly rooted hierarchy can be guaranteed to have certain functionality. You <br/>
know you can perform certain basic operations on every object in your system. All objects can <br/>
easily be created on the heap, and argument passing is greatly simplified. <br/>
A singly rooted hierarchy makes it much easier to implement a garbage collector, which is <br/>
one of the fundamental improvements of Java over C++. And since information about the <br/>
type of an object is guaranteed to be in all objects, you�ll never end up with an object whose <br/>
type you cannot determine. This is especially important with system-level operations, such as <br/>
exception handling, and to allow greater flexibility in programming. <br/>
Containers <br/>
In general, you don�t know how many objects you�re going to need to solve a particular <br/>
problem, or how long they will last. You also don�t know how to store those objects. How can <br/>
you know how much space to create if that information isn�t known until run time? <br/>
28 Venkata Pilaka Venkata Pilaka <br/>
Comments
Post a Comment