Polymorphism is the third essential feature of an object-oriented programming language,after data abastraction and inheritance.
It provides another dimension of separation of interface from implementation, to decouple what from how. Polymorphism allows improved code organization and readability as well as the creation of extensible programs that can be "grown" not only during the original creation of the project, but also when new features are desired.
Polymorphism deals with decoupling in terms of types.
Polymorphism also called dynamic binding or late binding or run-time binding
Upcasting revisited
Forgetting the object type
The compiler can't know that this Instrument reference points to a Wind in the case and not a Brass or Stringed.
Method-call binding
Connecting a method call to a method body is called binding. When binding is performed before the program is run ( by the compiler and linker, if there is one), it's called early binding. C compilers have only early binding.
The solution is called late binding, which means that the binding occurs at run time, based on the type of object. Late binding is also called dynamic binding or runtime binding.
That is, the compiler still doesn't know the object type, but the method-call mechanism finds out and calls the correct method body. ( you can imagine that som sort of type information must be installed in the objects.
All method binding in Java uses late binding unless the method is static or final ( private methods are implicitly final). This means that ordinarily you don't need to make any decisions about whether late binding will occur--it happens automatically
only use finla as a design decision, and not as an attempt to improve performance.
Producing the right behavior
Extensibility
Polymorphism is an important technique for the programmer to "separate the things that change from the thins that stay the same."
Pitfall: "overriding" private methods
public class PrivateOverride {
private void f() {print("private f()");}
public static void main (String[] args) {
PrivateOverride po = new Derived();
po.f();
}
}
class Derived extends PrivateOverride {
public void f() { print("public f()");}
}
输出： private f()
Derived's f() in this case is a brand new method; it's not even overloaded,since the base-class version of f() isn't visible in Derived.
Pitfall: fields and static methods
only ordinary method calss can be polymorphic
For example, if you acces a field directly, that access will be resolved at compile time.
When a Sub object is upcast to a Super reference, any field accesses are resolved by compiler, and are thus not polymorphic. In this example, different storage is allocated for Super.field and Sub.field. Thus, Sub actually contains two fieldss called field: its own and the one that it gets from Super. Howerver, the Super version in not the default that is produced when refer to field in Sub; in order to get the Super field you must explicitly say super.field.
Although this seems like it could be a confusing issue, in practive it virtually never comes up. For one thing, you'll generally make all fields private and so you won't access them directly, but only as side effects of calling methods. In addition, you probably won/t give the same name to a base-class field and a derived-class field, because its confusing.
Constructors and polymorphism
Constructors are not polymorphic (they're actually static methods, but the static declaration is implicit).
Order of constructor calls
Inheritance and cleanup
If you do have cleanup issues, you must be diligent and create a dispose() method for you new class. And with inheritance, you must override dispose() in the derived class if you have any special cleanup that must happen as part of garbage collection. When you override dispose() in an inherited class, it's important to remember to call the base-class version of dispose(), since otherwise the base-class cleanup will no happen.
If one of the member objects is shared with one or more other objects, the problem becomes more complex and you cannot simply assume that you can call dispose(). In this case, reference counting may be necessary to keep track of the number of objects that are still accessing a shared object.
private int refcount = 0;
public void addRef() { refcount++;}
protectd void dispose(){
if ( -- refcount == 0){
// 具体的dispose
}
When you attach a shared object to your class, you must remember to call addRef(), but the dispose() method will keep track of the reference count and decide when to actually perform the cleanup. This technique requires extra diligence to use, but if you are sharing objects that require cleanup you don't have much choice.
Behavior of polymorphic methods inside constructors
class Glyph {
void draw() { print("Glyph.draw()"); }
Glyph() {
print("Glyph() before draw()");
draw();
print("Glyph() after draw()");
}
}
class RoundGlyph extends Glyph {
private int radius = 1;
RoundGlyph(int r) {
radius = r;
print("RoundGlyph.RoundGlyph(), radius = " + radius);
}
void draw() {
print("RoundGlyph.draw(), radius = " + radius);
}
}
public class PolyConstructors {
public static void main(String[] args) {
new RoundGlyph(5);
}
} /* Output:
Glyph() before draw()
RoundGlyph.draw(), radius = 0
Glyph() after draw()
RoundGlyph.RoundGlyph(), radius = 5
A good guideline for constructors is, "Do as little as possible to set the object into a good state, and if you can possibly avoid it, don't call any other methods in this class." The only safe methods to call inside a constructor are those that are final in the base class. ( This also applies to private methods, which are automatically final.)
Convariant return types
Java SE5 adds convariant return types, which means that an overridden method in a derived class can return a type derived from the type returned by the base-class method
Designing with inheritance
If you choose inheritance first when you're using an existing class to make a new class, things can become needlessly complicated.
A better approach is to choose composition first, especially when it's not obvious which one you should use.
A general guideline is " Use inheritance to express difference in behavior, and fields (composition) to express variations in state."
Substitution vs. extension
It would seem that the cleanest way to create an inheritance hierarchy is to take the "pure" approach. That is , only methods that have been established in the base class are overridden in the derived class.
All you need to do is upcast from the derived class and never look back to see what exact type of object you're dealing with. Everything is handled through polymorphism.
This too is a trap. Extending the interface is the perfect solution to a particular problem. This can be termed an "is-like-a" relationship.
Downcasting and runtime type information
At run time this cast is checked to ensure that it is in fact the type you think it is. If it isn't, you get a ClassCastException.
The act of checking types at run time is called runtime type identification (RTTI).
Summary