Inheritance is a robust solution to obtain code reuse, however it isn’t all the time the perfect device for the job. Used inappropriately, inheritance results in fragile software program. It’s protected to make use of inheritance inside a bundle, the place the subclass and the superclass implementations are below the management of the identical programmers. Additionally it is protected to make use of inheritance when extending lessons particularly designed and documented for extension.
Inheriting from bizarre concrete lessons throughout bundle boundaries, nonetheless, is harmful.
By the best way, this text makes use of the phrase inheritance to imply implementation inheritance (when one class extends one other). The issues mentioned on this article don’t apply to interface inheritance (when a category implements an interface or when one interface extends one other).
In contrast to methodology invocation, inheritance violates encapsulation.
In different phrases, a subclass relies on the implementation particulars of its superclass for its correct perform. The superclass’s implementation could change from launch to launch, and if it does, the subclass could break, regardless that its code has not been touched. As a consequence, a subclass should evolve in tandem with its superclass, except the superclass’s authors have designed and documented it particularly for the aim of being prolonged.
To make this concrete, let’s suppose you’ve a program that makes use of a HashSet. To tune the efficiency of this system, you might want to question the HashSet to find out what number of components have been added because it was created (to not be confused with its present dimension, which matches down when a component is eliminated). To offer this performance, you write a HashSet variant that retains depend of the variety of tried ingredient insertions and exports an accessor for this depend. The HashSet class incorporates two strategies able to including components, add and addAll, so that you override each strategies, as follows:
// Damaged – Inappropriate use of inheritance!
public class InstrumentedHashSet<E> extends HashSet<E> {
// The variety of tried ingredient insertions
personal int addCount = 0;
public InstrumentedHashSet() {
}
public InstrumentedHashSet(int initCap, float loadFactor) {
tremendous(initCap, loadFactor);
}
@Override public boolean add(E e) {
addCount++;
return tremendous.add(e);
}
@Override public boolean addAll(Assortment<? extends E> c) {
addCount += c.dimension();
return tremendous.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
This class appears cheap, but it surely doesn’t work. Suppose you create an occasion and add three components utilizing the addAll methodology. (By the way, observe that you simply create an inventory utilizing the static manufacturing facility methodology Record.of, which was added in Java 9; when you’re utilizing an earlier launch, use Arrays.asList as an alternative.)
InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(Record.of(“Snap”, “Crackle”, “Pop”));
You’ll anticipate the getAddCount methodology to return 3 at this level, but it surely returns 6. What went fallacious? Internally, the HashSet addAll methodology is carried out on high of its add methodology, though HashSet, fairly fairly, doesn’t doc this implementation element. The addAll methodology in InstrumentedHashSet added three to addCount after which invoked the HashSet addAll implementation utilizing tremendous.addAll. This in flip invoked the add methodology, as overridden in InstrumentedHashSet, as soon as for every ingredient. Every of those three invocations added yet another to addCount, for a complete improve of six: Every ingredient added with the addAll methodology is counted twice.
You might repair the subclass by eliminating its override of the addAll methodology. Whereas the ensuing class would work, it might rely for its correct perform on the truth that the HashSet addAll methodology is carried out on high of its add methodology. This self-use is an implementation element that isn’t assured to carry in all implementations of the Java platform and is topic to alter from launch to launch. Subsequently, the ensuing InstrumentedHashSet class can be fragile.
It will be barely higher to override the addAll methodology to iterate over the required assortment, calling the add methodology as soon as for every ingredient. This might assure the proper outcome whether or not or not the HashSet addAll methodology had been carried out atop its add methodology as a result of the HashSet addAll implementation would now not be invoked. This system, nonetheless, doesn’t clear up all the issues. It quantities to reimplementing superclass strategies that will or could not end in self-use, which is troublesome, time-consuming, error-prone, and should cut back efficiency. Moreover, it isn’t all the time potential as a result of some strategies can’t be carried out with out entry to non-public fields which are inaccessible to the subclass.
A associated reason behind fragility in subclasses is that their superclass can purchase new strategies in subsequent releases. Suppose a program relies upon for its safety on the truth that all components inserted into some assortment fulfill some predicate. This may be assured by subclassing the gathering and overriding every methodology able to including a component to make sure that the predicate is happy earlier than including the ingredient.
This works effective till a brand new methodology able to inserting a component is added to the superclass in a subsequent launch. As soon as this occurs, it turns into potential so as to add an “unlawful” ingredient merely by invoking the brand new methodology, which isn’t overridden within the subclass. This isn’t a purely theoretical drawback. A number of safety holes of this nature needed to be mounted when Hashtable and Vector had been retrofitted to take part within the Collections framework.
Each of those issues stem from overriding strategies. You would possibly assume that it’s protected to increase a category when you merely add new strategies and chorus from overriding current strategies. Whereas this type of extension is way safer, it isn’t with out danger. If the superclass acquires a brand new methodology in a subsequent launch and also you gave the subclass a technique with the identical signature and a unique return sort, your subclass will now not compile.
If you happen to’ve given the subclass a technique with the identical signature and return sort as the brand new superclass methodology, then you definitely’re overriding it, so that you’re topic to the issues described earlier. Moreover, it’s uncertain that your methodology will fulfill the contract of the brand new superclass methodology as a result of that contract had not but been written once you wrote the subclass methodology.
Fixing the issue
Fortunately, there’s a solution to keep away from all the issues described above. As a substitute of extending an current class, give your new class a personal discipline that references an occasion of the present class. This design is known as composition as a result of the present class turns into a element of the brand new one.
Every occasion methodology within the new class invokes the corresponding methodology on the contained occasion of the present class and returns the outcomes. This is called forwarding, and the strategies within the new class are often called forwarding strategies. The ensuing class shall be rock stable and don’t have any dependencies on the implementation particulars of the present class. Even including new strategies to the present class could have no influence on the brand new class.
To make this concrete, under is a alternative for InstrumentedHashSet that makes use of the composition-and-forwarding strategy. Observe that the implementation is damaged into two items: the category itself and a reusable forwarding class, which incorporates all of the forwarding strategies and nothing else.
// Wrapper class – makes use of composition rather than inheritance
public class InstrumentedSet<E> extends ForwardingSet<E> {
personal int addCount = 0;
public InstrumentedSet(Set<E> s) {
tremendous(s);
}
@Override public boolean add(E e) {
addCount++;
return tremendous.add(e);
}
@Override public boolean addAll(Assortment<? extends E> c) {
addCount += c.dimension();
return tremendous.addAll(c);
}
public int getAddCount() {
return addCount;
}
}
// Reusable forwarding class
public class ForwardingSet<E> implements Set<E> {
personal closing Set<E> s;
public ForwardingSet(Set<E> s) { this.s = s; }
public void clear() { s.clear(); }
public boolean incorporates(Object o) { return s.incorporates(o); }
public boolean isEmpty() { return s.isEmpty(); }
public int dimension() { return s.dimension(); }
public Iterator<E> iterator() { return s.iterator(); }
public boolean add(E e) { return s.add(e); }
public boolean take away(Object o) { return s.take away(o); }
public boolean containsAll(Assortment<?> c) { return s.containsAll(c); }
public boolean addAll(Assortment<? extends E> c) { return s.addAll(c); }
public boolean removeAll(Assortment<?> c) { return s.removeAll(c); }
public boolean retainAll(Assortment<?> c) { return s.retainAll(c); }
public Object[] toArray() { return s.toArray(); }
public <T> T[] toArray(T[] a) { return s.toArray(a); }
@Override public boolean equals(Object o) { return s.equals(o); }
@Override public int hashCode() { return s.hashCode(); }
@Override public String toString() { return s.toString(); }
}
The design of the InstrumentedSet class is enabled by the existence of the Set interface, which captures the performance of the HashSet class. Apart from being sturdy, this design is extraordinarily versatile. The InstrumentedSet class implements the Set interface and has a single constructor whose argument can also be of sort Set.
In essence, the InstrumentedSet class transforms one Set into one other, including the instrumentation performance. In contrast to the inheritance-based strategy, which works just for a single concrete class and requires a separate constructor for every supported constructor within the superclass, the wrapper class can be utilized to instrument any Set implementation and can work with any preexisting constructor.
Set<On the spot> instances = new InstrumentedSet<>(new TreeSet<>(cmp));
Set<E> s = new InstrumentedSet<>(new HashSet<>(INIT_CAPACITY));
The InstrumentedSet class may even be used to briefly instrument a set occasion that has already been used with out instrumentation, as follows:
static void stroll(Set<Canine> canines) {
InstrumentedSet<Canine> iDogs = new InstrumentedSet<>(canines);
… // Inside this methodology use iDogs as an alternative of canines
}
The InstrumentedSet class is called a wrapper class as a result of every InstrumentedSet occasion incorporates (or “wraps”) one other Set occasion. That is also referred to as the Decorator sample as a result of the InstrumentedSet class “decorates” a set by including instrumentation. Typically the mix of composition and forwarding is loosely known as delegation. Technically it’s not delegation except the wrapper object passes itself to the wrapped object.
The disadvantages of wrapper lessons are few. One caveat is that wrapper lessons should not fitted to use in callback frameworks, whereby objects move self-references to different objects for subsequent invocations (“callbacks”). As a result of a wrapped object doesn’t know of its wrapper, it passes a reference to itself (this) and callbacks elude the wrapper. This is called the SELF drawback. Some folks fear concerning the efficiency influence of forwarding methodology invocations or the reminiscence footprint influence of wrapper objects. Neither end up to have a lot influence in follow. It’s tedious to jot down forwarding strategies, however you need to write the reusable forwarding class for every interface solely as soon as, and forwarding lessons could also be supplied for you. For instance, Google’s Guava core libraries for Java gives forwarding lessons for all the assortment interfaces.
Subtypes of superclasses
Inheritance is suitable solely in circumstances the place the subclass actually is a subtype of the superclass. In different phrases, a category B ought to prolong a category A provided that an “is-a” relationship exists between the 2 lessons. In case you are tempted to have a category B prolong a category A, ask your self this query: Is each B actually an A? If you happen to can’t honestly reply sure to this query, B mustn’t prolong A. If the reply isn’t any, it’s usually the case that B ought to comprise a personal occasion of A and expose a unique API. In different phrases, A isn’t a necessary a part of B; it’s merely a element of its implementation.
(There are a selection of violations of this precept within the Java platform libraries. For instance, a stack isn’t a vector, so Stack mustn’t prolong Vector. Equally, a property record isn’t a hash desk, so Properties mustn’t prolong Hashtable. In each circumstances, composition would have been preferable.)
If you happen to use inheritance the place composition is suitable, you needlessly expose implementation particulars. The ensuing API ties you to the unique implementation, without end limiting the efficiency of your class. Extra severely, by exposing the internals you let shoppers entry them straight. On the very least, it could actually result in complicated semantics.
For instance, if p refers to a Properties occasion, then p.getProperty(key) could yield completely different outcomes than p.get(key): The previous methodology takes defaults under consideration, whereas the latter methodology, which is inherited from Hashtable, doesn’t. Most severely, the shopper could possibly corrupt invariants of the subclass by modifying the superclass straight.
Within the case of Properties, the Java designers supposed that solely strings be allowed as keys and values, however direct entry to the underlying Hashtable permits this invariant to be violated. As soon as violated, it’s now not potential to make use of different components of the Properties API (corresponding to load and retailer). By the point this drawback was found, it was too late to appropriate it as a result of shoppers trusted using nonstring keys and values.
Supply: oracle.com
