Inheritance

• Responding to shifting requiremnets with a new abstraction.

To define a new class by stating only the differences (in terms of features) between the new class and another class that we’ve already established.

The "is a" Nature of the Inheritance

Inheritance is often referred to as the “is a” relationship between two classes, because if a class B is derived from a class A, then B truly is a special case of A. Anything that we can say about a superclass must therefore also be true about all of its subclasses;

if there is something that can be said about a class A that can’t be said about a proposed subclass B, then B really isn’t a valid subclass of A.

The benefits of Inheritance

• Reduce code redundancy.
• Subclasses are much more specific thant they would without inheritance.
• We can reuse and extend code that has already been thoroughly tested without modify it.
• We can derive a new class from an existing class even if we do not own the source code for the latter.

The pbject class

public class Person {}
public class Student extends Person {}

Avoiding "Ripple Effects" in a class Hierarchy

Whenever possible, avoid adding features to non-leaf classes once they have been established in code form in an application, to avoid ripple effects throughout an inheritance hierarchy.

Rules for deriving classes

The don'ts

• We shouldn’t change the semantics—that is, the intention, or meaning—of a feature.
• We can’t physically eliminate features, nor should we effectively eliminate them by ignoring them.
• We shouldn’t attempt to change a method’s signature when we override it.

Private Features and Inheritance

protected accessibility is a sort of “middle ground” between private and public accessibility, in that protected features are inherited by/in scope within subclasses.

The best approach is to allow attribute to remain a private modifier in parent class, but to use the public accessible getAge/setAge methods that we inherit from the parent class to manipulate the value of an attribute.

Constructors and Inheritance

Constructors are not inherited

super(arguments);     // note that there is no "dot" involved 
    // when reusing CONSTRUCTOR code

If we explicitly call a superclass constructor from a subclass constructor using the super(...) syntax, the call must be the first statement in the subclass constructor—that is.

Replacing the Default Parameterless Constructor

If we don’t bother to define any explicit constructors for a particular class, Java will attempt to provide us with a default parameterless constructor for that class. What we’ve just seen is that when we invoke the default constructor for a derived class, the compiler will automatically try to invoke a parameterless constructor for each of the ancestor classes in the inheritance hierarchy in top-down fashion.

The implication is that if we derive a class B from class A, and write no explicit constructors for B, then the (default) parameterless constructor of B will automatically look for a parameterless constructor of A.

Multiple Inheritance

• Not supported in JAVA.
• Provided using interfaces