1. Csci 490 / Engr 596 Special Topics / Special Projects Software Design and Scala Programming Spring Semester 2010 Lecture Notes

2. Understanding Inheritance This set of slides is loosely based on chapter 8 of Timothy Budd's textbook Understanding Object-Oriented Programming with Java, Updated Edition (Addison-Wesley, 2000) Created: 14 August 2004, Revised for Scala 9-11 February 2010

3. Motivation for Inheritance Use inheritance to create new software structures from existing software units to:  improve productivity  enhance quality 1

4. Generality and Specialization in Software Development Conflict:  Specific projects usually require very specialized software  Reusability usually requires very general software Resolution?  Inheritance allows general software to be specialized for a project 2

5. Abstract Idea of Inheritance (is-a) 3 Material Object Non-Living Thing Rock Air Living Thing Plant Animal Reptile Mammal Human Being DentistRoy Shopkeeper Flo WriterJohn Cat Dog Platypus

6. Practical Meaning of Inheritance In programming languages, inheritance means  Data and behavior of parent class are part of child  Child class may include data and behavior not in parent With respect to the parent class, a child class is, in some sense  An extension – larger set of properties  A contraction – more specialized (restricted) objects 4

7. Idealized Image of Inheritance Consider  Subclass instances must possess all data areas of the parent  Subclass instances must implement all functionality of the parent Thus  Subclass instance should be indistinguishable from parent class instance—child can be substituted for parent 5

8. Principle of Substitutability If C is a subclass of P, instances of C can be substituted for instances of P in any situation with no observable effect. 6

9. Subclass and Subtype Subtype  Class that satisfies principle of substitutability Subclass  Something constructed using inheritance, whether or not it satisfies the principle of substitutability. The two concepts are independent  Not all subclasses are subtypes  Sometimes subtypes are constructed without being subclasses 7

10. Forms of Inheritance Specialization  Child class is a special case (subtype) of parent Specification  Parent class defines behavior implemented in the child, but not parent Construction  Parent class used only for its behavior -- child class is not subtype -- no is-a relationship to parent Generalization  Child class modifies or overrides some methods of parent, extends the behavior to more general kind of object Extension  Child class adds new functionality to parent, but does not change any inherited behavior Limitation  Child class limits some of the behavior of parent Variance  Child and parent class are variants of each other -- inheritance to allow code sharing -- arbitrary relationship Combination  Child class inherits features from more than one parent -- multiple inheritance 8

11. Forms of Inheritance Specialization Child class is a special case (subtype) of parent  Most common form of inheritance  Example: Professor is specialized form of Employee  Child may override behavior of parent to specialize  Child satisfies specification of parent in all relevant aspects  Preserves substitutability 9

12. Forms of Inheritance Specification behavior Parent class defines behavior implemented in the child, but not parent  Second next most common form of inheritance  Example: class StackInArray gives implementations for method signatures defined in abstract class Stack Java and Scala: StackInArray extends Stack  Example: class ArrayRankedSeq gives implementations for method signatures defined in Java interface or Scala trait RankedSequence Java: ArrayRankedSeq implements RankedSequence Scala: ArrayRankedSeq extends RankedSequence Scala: ArrayRankedSeq extends RankedSequence 10

13. Forms of Inheritance Specification (continued) behavior Parent class defines behavior implemented in the child, but not parent  …  Subclasses are realizations of incomplete abstract specification  Defines common interface for group of related classes  Preserves substitutability 10

14. Forms of Inheritance Construction Parent class used only for its behavior — child class is not subtype — no is-a relationship to parent  Sometimes used for convenience, but discouraged  Example: extending List class to develop Set, without "hiding" unneeded methods  Example: extending a byte-based I/O stream to a stream for handling other objects  Often violates substitutability  More common in dynamically typed languages (e.g., Smalltalk, Ruby) than in statically typed (e.g., Java, Scala)  Can sometimes use aggregation (composition) instead 11

15. Forms of Inheritance Generalization Child class modifies or overrides some methods of parent, extends the behavior to more general kind of object  Sometimes used for convenience (or necessity), but discouraged  Example: graphics Window generalized to ColorWindow (with background color)  Opposite of specialization—violates substitutability  Used when must build from fixed, difficult-to-modify set of classes  Where possible, invert class hierarchy or use aggregation 12

16. Forms of Inheritance Extension Child class adds new functionality to parent, but does not change any inherited behavior  Useful technique to give new behaviors to existing base class that cannot be modified  Example: StringSet extends Set, adding string-related methods (e.g, prefix search)  Preserves substitutability 13

17. Forms of Inheritance Limitation Child class limits some of the behavior of parent  Sometimes used for convenience, but strongly discouraged  Example: extends, replacing unneeded methods to give error messages  Example: Stack extends DoubleEndedQueue, replacing unneeded methods to give error messages  Violates substitutability  Used when must build from fixed, difficult-to-modify set of classes  Avoid when possible, perhaps use aggregation 14

18. Forms of Inheritance Variance Child and parent class are variants of each other—inheritance to allow code sharing— arbitrary relationship  Sometimes used for convenience, but discouraged  Example: graphics class extending to share similar control code  Example: graphics Tablet class extending Mouse to share similar control code  Violates substitutability  Better to define more general parent class like  Better to define more general parent class like PointingDevice 15

19. Forms of Inheritance Combination Child class inherits features from more than one parent—multiple inheritance  Example: might inherit from both and  Example: GraduateInstructor might inherit from both GraduateStudent and Faculty  Often difficult to understand and to implement language  Often use to "mix-in" specification of another role or protocol 16

20. Forms of Inheritance Combination (continued) Child class inherits features from more than one parent—multiple inheritance  …  C++ has multiple inheritance via subclassing, with some semantic difficulties  Java has single inheritance via subclassing (extends), but multiple inheritance for specification via interface implementations (implements)  Scala has single inheritance via subclassing and multiple “mix-in” inheritance of “stackable” traits (avoiding semantic issues of C++) 16

21. Inheritance and Assertions Suppose C is a subtype of P   P and C have interface invariants I and IC, respectively   meth() is a public method of P with precondition Q and postcondition R   meth() in C has precondition QC and postcondition RC Subtype C should not violate I, Q, and R   IC implies I – may strengthen invariant – extend interface and data   Q implies QC – may weaken precondition – expand valid inputs   RC implies R -- may strengthen postcondition – restrict valid outputs Abstract preconditions can enable controlled "strengthening" of precondition   Consider BoundedStack inheriting from an unbounded Stack class   Give method push() a "not full" precondition – always true in Stack   Refine "not full" in subclass BoundedStack to be true or false 17

22. Inheritance and Assertions Interface invariants meth() Pre- condition Post- condition P (Parent) IQR C (Child) ICQCRC IC=>IQ=>QCRC=>R strengthenweakenstrengthen 18

23. Trees versus Forests Two common views of class hierarchies Tree  All classes are part of single class hierarchy  Advantage: root's functionality inherited by all objects – all have basic functionality  Disadvantage: tight coupling of classes, large libraries for an application  Languages: Java's classes, Scala’s classes, Smalltalk, Objective C, Delphi Object Pascal Forest  Classes only placed in hierarchies if they have a relationship – many small hierarchies.  Advantage: smaller libraries of classes for application, less coupling possible  Disadvantage: no shared functionality among all objects  Languages: Java's interfaces, Scala’s traits, C++, Apple Object Pascal 19

24. Tree versus Forest A B C D EFG Tree 20

25. Trees versus Forests Forest A B C D EFG X Y Z 21

26. Inheritance in Java Tree-structured class hierarchy (with primitive data types not in hierarchy) Forest-structured interface hierarchy Modifiers for classes/interfaces Access modifiers for class/interface features 22

27. Inheritance in Java Tree-structured Class Hierarchy Root class is java.lang.Object Other classes extend exactly one other class   default is Object Declaration uses keyword extends after class name 23 Object Material_Object Non_living_ThingLiving_Thing ……

28. Inheritance in Java Forest-structured Interface Hierarchy interface defines an interface specification implements after class name to promise implementation of interface – inheritance for specification An interface extends zero or more other interfaces A class implements zero or more interfaces public interface Queue { // signatures of public methods // Queues must provide } public class QueueAsLinkedList implements Queue { // includes implementations // of the Queue methods // of the Queue methods} 24

29. Inheritance in Java Visibility Modifiers for Class/Interface Features public features accessible from anywhere in program private features accessible from inside class only Default-access (i.e., "friendly") features accessible from inside the current Java package protected features accessible in package or inside any child class 26

30. Inheritance in Java public abstract class Stack { // extends Object by default // data definitions plus signatures and // data definitions plus signatures and // possibly implementations of methods // possibly implementations of methods} public class StackInArray extends Stack { // extended features plus overridden implementations } public interface Queue { // signatures of public methods Queues must provide } public class QueueAsLinkedList implements Queue { // includes implementations of the Queue methods } 27

31. Facilities of Root Class Object Minimum functionality for all objects include equals(Object obj) is obj the same as receiver? toString() converts the object to a string value hashCode() return a default hashcode for the object getClass() return an identifier for the class of the object First three above are often overridden in classes. 28

32. Inheritance in Scala Tree-structured class hierarchy (with primitives in hierarchy) Classes that extend one class and “mix-in” zero or more traits Modifiers for classes/traits (slightly different from Java) Access modifiers for class/interface features (slightly different from Java) 22

33. Inheritance in Scala Tree-structured Class Hierarchy Root class is Any Primitive value types extend AnyVal All reference object types extend AnyRef (java.lang.Object) Scala reference objects also mix-in trait ScalaObject Scala traits extend AnyRef 23 Any AnyVal AnyRef Java primitive values Scala classes also have marker trait ScalaObject Java classes

34. Inheritance in Scala trait Philosphical { //method signatures, perhaps implementations //method signatures, perhaps implementations // perhaps data attributes // perhaps data attributes} class Frog extends Philosphical {... } trait HasLegs {... } class Animal class Frog extends Animal with Philosphical with HasLegs { … } 27

35. Inheritance in Scala Visibility Modifiers for Class/Trait Features private features accessible from inside class only (like Java except for inner classes) protected features accessible only from subclasses (more restricted than Java) No access modifier means “public” access features accessible from anywhere private[X] and protected[X] provide qualified access “up to X ” – gives capabilities like object private, package protected, etc. 26

36. Facilities of Root Classes Any and AnyRef … Look in the API documentation 28

37. Benefits of Inheritance Software reusability (among projects) Code sharing (within a project) Increased reliability (resulting from reuse and sharing of well-tested code) Consistency of interface (among related objects) Rapid prototyping (quickly assemble from pre- existing components) Polymorphism and frameworks (high-level reusable components) Information hiding 29

38. Costs of Inheritance Execution speed Program size Message-passing overhead Program complexity 30

39. Acknowledgement 31 The development of the original Java-based slides was supported by a grant from Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE).” The development of the original Java-based slides was supported by a grant from Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE).” Students who helped with slides—Jian Li, Yi Liu, Pallavi Tadepalli, etc.