COMP 401 Prasun Dewan1 22. Delegation Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, say, Aspirin and Tylenol, have. Both are alternatives for fixing a problem – Tylenol and Aspirin a headache, and Inheritance and Delegation code duplication ‐ with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used. Constructs Gradually Falling Out of Favor Inheritance is a very attractive concept. It distinguishes an object‐oriented language from an object‐based one. An object‐based language supports only objects and classes, while an object‐oriented supports objects, classes, and inheritance. Object‐oriented languages have had much more impact than object‐based language because programming language inheritance corresponds to the real‐life concept of inheritance, which made it, for, many a “natural” solution for the code duplication problem. The point of this chapter is that it is easy to go overboard in the use of inheritance ‐‐ the history of object‐oriented libraries is replete with examples of its overuse. In particular, the Java 1.0 libraries were mostly inheritance based. After facing real problems with this approach, the Java designers decided to convert many of the inheritance‐based libraries to delegation‐based ones in Java 1.1. The history of computer science is also full of examples of constructs that have been embraced enthusiastically for a while and then fallen out of grace. If you have used Basic or FORTRAN, you know about the Go To statement, which allows a program to transfer jump to some arbitrary labeled location in the code. It tremendously increases the flexibility of a programmers, but also makes the code less structured, and hence, difficult to understand. Way back in 1968, Dijkstra, a very smart and far sighted computer scientist, wrote the seminal article “Go To Statement Considered Harmful.” This article did not have an immediate impact on computer science. However, gradually, people started moving from . 1  Copyright Prasun Dewan, 2009.Go To statements to more structured constructs such as loops. For example, Pascal, a language designed by another very smart computer scientist, Niklaus Wirth, supported Go To statements, even though Wirth recommended against its use. Java, a much more modern language, has taken the stop of not even supporting Go To statements. After rallying against Go To statements, computer scientists started attacking un‐encapsulated data types, which are essentially objects with public variables. Every textbook and professor will tell you never to create such variables. However, language designers have not been brave enough to remove such variables from languages. Another popular practice that is now frowned on is using classes to type variables. In languages with interfaces, as we have seen several times so far, using interfaces to type variables leads to more reusable code. Unfortunately, as we have seen in the design of Java libraries, the default, for many programmers today, is to still use classes as types, and convert to interface types when they face reusability problems. In all of these examples, the tension between practice and recommendations from purists arises because in the short run, the recommendations increase programmer effort, though in the long term, they reduce software costs. Inheritance is another construct that can, in the short term, reduce programmer effort, but in the long term, result in brittle code that must be re‐factored to accommodate changes. However, the argument against inheritance is much more subtle. The recommendation here is not ban it from programs, but us it only when it is appropriate to do so. Thus, this chapter could be titled “Indiscriminate use of inheritance considered harmful.” Inheritance vs. Delegation The big reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class. This reference allows it to delegate tasks to the reused class. Inheritance(IS-A)ÆCode ReusabilityÅDelegation (HAS-A)ÅJust as computer inheritance corresponds to the real‐world concept of inheritance, computer delegation corresponds to the real‐world concept of a worker delegating a task to another. The figure shows real‐world examples of these two concepts. Based on these examples, inheritance and delegation seem like unrelated concepts –like apples and oranges. In fact, they are closely related, as illustrated by the following example: A basketball player can inherit the skills to get a basket in a certain situation, or can pass to someone, that is, delegate to, someone who has the skills. Similarly, a class can inherit some functionality or delegate to a class that has the functionality, possibly through inheritance. This is all very abstract, so let us take an example to better understand and compare these two concepts. Inheriting vs. Delegating Observable Counter In the chapter on MVC, we started with a simple, unobservable, counter. We then presented an observable version of it. public class ACounter implements Counter {int counter = 0;public void add (int amount) {counter += amount;}public int getValue() {return counter;}}The observable counter class duplicates code in the regular counter class. Let us use this simple example to compare the inheritance and delegation approach to removing code duplication. By now, we know enough about inheritance to easily create the observable counter class as a subclass of the regular counter class. public class AnObservableCounter implements ObservableCounter {int counter = 0;ObserverHistory