Some Inheritance Issues in Java

1. Some Inheritance Issues in Java

2. Inheritance • protected members in Java are visible to the package as well as to subclasses • Java: public, private, protected, (default) • C++: public, private, protected

3. Inheritance • We have already mentioned the name collision resolution differences • Java: shadow variable names, override method names. • C++: shadow all names unless it is a virtual method name. Use dynamic binding only if the object is a pointer or a reference.

4. Final • In Java, inheritance can be stopped by declaring the class as “final” • Can be used for efficiency: (is this done?) • methods of a final class can be made inline • Safety • there can be no overriding of a method of a class since the users cannot subclass.

5. Casting • (as-in-C++) Casting is used to change the type of a name for compilation purposes. • primitive casts: int-> float, .. • when meaningful • non-primitive • inheritance hierarchy (downward only)

6. Downward Casts • Should only be used to get at a unique method of a derived class when dealing with an ancestor type or interface. • IS NEVER SAFE due to dynamic binding. • Should be tested or handled with an exception whenever done. • (unfortunately rarely is)

7. How this mess • Single rooted inheritance is a way to avoid templates in container classes. • Example: Vector class defined to hold Objects. • Since everything is an Object we can put any class in a vector instance.

8. Vector of Strings • How do we know a vector of strings holds only strings….we don’t unless we create a StringVector subclass and protect the I/O • Even then, the implementation of the subclass will require a downward cast to return a string.

9. Lazy programmers • Don’t create the safer StringVector class • rarely protect what they get from a retrieval Object x = v.elementAt(i) if ( x instanceOf String) String s = (String) x; • or try { String s = (String)x; } catch (ClassCastException e) {...

10. Abstract classes • Convenient to provide most of the methodology of a class but leave a required unique method to the subclass. (Actually a class an be abstract if it has NO abstract methods)

11. void * • references to Objects are similar to the C++ void * except that they are guaranteed to reference objects of the class Object

12. Adam | Eve • The class Object’s methods are inherited by all classes. a.equals(b) compares whether the references are the same, not values b=a.clone() gives a shallow copy. finalize() is called by the garbage collector. • these are sometimes overridden in a subclass

13. Cain & Able • Subclasses should provide a toString() method that gives a string describing objects. • If an object has such a method, the string concatenation operation will call this method • System.out.println(“ ” + earth); //standard trick for • System.out.println(earth.toString()); //6 less keystrokes

14. Inheritance and Arrays • Arrays are not container classes - but can act like them • // Object[] w = new int[10]; is not OK • Object x = new int[10]; //is OK • Object[] y = new Employee[3]; • Object z = y; • Object[] p = y; // better

15. Wrappers • Wrappers are a common design pattern to migrate a non-object into the OO world. • Most of the Java primitive types have a JDK wrapper e.g. Integer for int • Note however….no methods of these classes support state change (i.e. immutable objects)

16. CORBA wrappers • CORBA had to support in out parameters in its port to java • Pulled this off with wrappers that have a public data member

17. Example import org.omg.CORBA.*; import java.io.*; public class TestIt { static void increment(IntHolder x) { x.value++; } static public void main(String[] arg) { IntHolder a = new IntHolder(3); increment(a); System.out.println(a.value); }}

18. Design rules • The super class contains all common features. • The mechanism is for the “is-a” relationships among objects • Use polymorphism when using inheritance (a C++ rule) • Try to avoid inheritance except for interface design.