Introduction to Object Oriented / Functional Programming 9. Object-Oriented Software Development COMP4001 CSE UNSW Sydney Lecturer: John Potter

Transcription

1 Introduction to Object Oriented / Functional Programming 9 Object-Oriented Software Development COMP4001 CSE UNSW Sydney Lecturer: John Potter

2 Lecture Outline object equality design patterns composite interpreter visitor extensibility COMP4001 CSE UNSW Sydney 2

3 Object Equality most OO languages allow user-defined object equality and hashcodes Java, hence Scala, have specific rules that programmers must follow 1. if two objects are equal then they must have the same hashcode the converse is not possible in general, but the probability of two unequal objects having the same hashcodes should be small 2. equality == must be an equivalence relation reflexive: identical objects must be equal symmetric: if x == y then y == x transitive: if x == y and y == z then x == z COMP4001 CSE UNSW Sydney 3

4 Java: object equality & hashcode x == y tests object identity not overridable also usable on primitive types x.equals(y) is equality defined in runtime class of x equals relies on dynamic binding default equals is defined in class Object to be same as == equals applied to null yields a NullPointerException x.equals(null) is usually taken to be false System.identityHashCode(x) provides hashcode based on object identity of x COMP4001 CSE UNSW Sydney 4

5 Scala: object equality & hashcode x == y tests for Any equality for AnyVal objects, same as Java primitive type == for AnyRef objects, almost equivalent to x.equals(y) in Java except can test for nulls as well x == y tests for nulls then calls x.equals(y) final def == (that: Any): Boolean = if (null eq this) {null eq that else {this equals that cannot override == directly instead override the equals method x eq y is Scala's test for object identity not overridable not directly used much COMP4001 CSE UNSW Sydney 5

6 equals is usually faulty! ECOOP 2007 paper studied many Java programs most implementations of equals in Java are faulty!! I recommend reading the first 2 sections of the paper: Common errors wrong signature provides overloading instead of overriding failing to override hashcode when overriding equals defining equals in terms of mutable fields this can make sense, but limits valid uses of objects such objects cannot be used in equality/hash based searching cannot be used as elements of Sets or as keys in Maps equality in Scala's mutable collections does depend on mutable content failing to implement equals as an equivalence relation COMP4001 CSE UNSW Sydney 6

7 Wrong Signature for equals The equals method below is overloaded and wrong! class Point(val x: Int, val y: Int) { // wrong: does not override equals def equals(other: Point) = this.x == other.x && this.y == other.y COMP4001 CSE UNSW Sydney 7

8 Overriding equals We can combine overloaded and overridden versions: note use of override keyword makes difference between overriding and overloading clearer in Scala recommend always annotation in Java class Point(val x: Int, val y: Int) { // better equals, but still faulty for subclasses override def equals(other: Any) = other match { case that: Point => this equals that case _ => false def equals(that: Point) = this.x == that.x && this.y == that.y COMP4001 CSE UNSW Sydney 8

9 Asymmetric equals consider an extension to the Point class class ColoredPoint(x: Int, y: Int, val color: Color.Value) extends Point(x, y) { // equals is not symmetric override def equals(other: Any) = other match { case that: ColoredPoint => this equals that case _ => false ColoredPoint case compares Color as def equals(that: ColoredPoint) = well as coordinates this.color == that.color && super.equals(that) but this means that == is not symmetric: val p = new Point(0, 0) val red = new ColoredPoint(0, 0, Color.Red) yields p == red is true but red == p is false COMP4001 CSE UNSW Sydney 9

10 Symmetric equals to fix symmetry,in ColoredPoint we can either use a coarser equality (e.g. just use Point equals) or handle comparison of superclass objects as a special case: class ColoredPoint(x: Int, y: Int, val color: Color.Value) extends Point(x, y) { // equals is symmetric but not transitive override def equals(other: Any) = other match { case that: ColoredPoint => this equals that case that: Point => that equals this case _ => false def equals(that: ColoredPoint) = this.color == that.color && super.equals(that) extra case to handle superclass object using equals in Point COMP4001 CSE UNSW Sydney 10

11 Lack of Transitivity but this version of equals is still faulty! the definition is not transitive with p and red as before, and val blue = new ColoredPoint(0, 0, Color.Blue) we find: and p == blue is true but red == blue is false red == p is true violating the transitivity condition COMP4001 CSE UNSW Sydney 11

12 Correct overriding of equals the trick is to ensure that different objects with different versions of the equals method cannot be equal to model this correctly, need to introduce an extra method canequal(other: Point): Boolean whenever equals is overridden, ensure that canequal is too class Point(val x: Int, val y: Int) { override def equals(other: Any) = other match { case that: Point => this.equals(that) case _ => false def canequal(that: Point) = that.isinstanceof[point] final def equals(that: Point) = that.canequal(this) && (this.x == that.x) && (this.y == that.y) COMP4001 CSE UNSW Sydney 12

13 Correct overriding of equals overriding in ColouredPoint follows the same scheme class ColouredPoint(x: Int, y: Int, val colour: Colour.Value) extends Point(x, y) { override def equals(other: Any) = other match { case that: ColouredPoint => this.equals(that) case _ => false override def canequal(that: ColouredPoint) = that.isinstanceof[colouredpoint] final def equals(that: ColouredPoint) = that.canequal(this) && (this.colour == that.colour) && super.equals(that) COMP4001 CSE UNSW Sydney 13

14 Overriding HashCode if you override equals then you should also override hashcode in general you should combine super.hashcode with hashcodes or Int values of extra fields form of combination is arbitrary but usually combine 2 hashvalues using prime linear combination simple_prime * hash1 + hash2 COMP4001 CSE UNSW Sydney 14

15 Complexity of HashCode for structured objects (e.g. collections), good hashcodes usually depend on the contents of the collection so computing a hash will take time at least linear in the size of the object/collection so relying on hash-based implementations may result in slower than anticipated behaviour e.g. hashtable lookup and insertion is usually considered to be constant time but this assumes that getting the hash is a constant time computation some VMs will cache an object's hashcode to avoid such slowdowns in Scale, can force this by overriding the hashcode method as a val: override val hashcode = or override lazy val hashcode = COMP4001 CSE UNSW Sydney 15

16 Equality for Case Classes in Scala, case classes and object definitions have a default definition for equals and hashcode based on the fields of the defined object the default equals definition is an equivalence relation providing equality on all of the field types is with the defaults, equal objects are guaranteed to have the same hashcode both equals and hashcode may be overridden in which case the defaults are not supplied by the COMP4001 CSE UNSW compiler Sydney 16

17 Lecture Outline object equality design patterns composite interpreter visitor extensibility COMP4001 CSE UNSW Sydney 17

18 Design Patterns as an OO programmer you must be familiar with some standard design patterns all support my favourite dictum: program to interfaces patterns describe possible solutions to common OO design tasks provide a language for talking about designs the pattern names the intent and purpose of a group of classes in a design Gang of Four design patterns Design Patterns: Elements of Reusable OO Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides classification of GOF patterns: creational, structural, behavioural COMP4001 CSE UNSW Sydney 18

19 Creational Patterns flexible construction of objects remove dependencies in code on implementation type Factory Method returns new objects with unknown implementation iterator() in java.util.list Abstract Factory factory methods for related types Builder piece-by-piece construction methods independent of finally constructed object implementation Scala collections use builders Prototype copy an existing object prototype-based languages Singleton use objects as "templates" add behaviours Self, Javascript, IO single instance of a class COMP4001 CSE UNSW Sydney object in Scala 19

20 Structural Patterns Decorator daisy chain objects to extend functionality synchronization wrappers in java.util.collections Adapter adapt code to new interfaces Proxy simple stub for another object Composite tree of objects also Interpreter Design Pattern Flyweight share as much of object context as possible e.g. drawing context for glyphs in GUI Façade simple interface for a whole system: "API" Bridge decouples abstraction from implementation e.g. GUI for different windowing systems COMP4001 CSE UNSW Sydney 20

21 Behavioural Patterns Template Method uses overrideable hook methods Command subclasses implement the hooks encapsulate actions, parameters, results Runnable, Callable, function objects Observer combining with Composite gives a Macro Command / Interpreter publish/subscribe observed objects only know who to notify not what the observers do Mediator controlling communication amongst peer objects State state modelled as distinct (immutable) objects Strategy plug-in different algorithms for a problem Memento support for undo Chain of Responsibility Visitor Iterator commands passed up a chain of objects e.g.contextual help in GUI abstract operation over different classes of objects standard traversal of collections COMP4001 CSE UNSW Sydney 21

22 The Composite Design Pattern hierarchical structures define recursive compositions of primitive and composite objects clients treat individual objects and compositions of objects uniformly COMP4001 CSE UNSW Sydney 22

23 The Composite Pattern acomposite: Composite aleaf: Leaf aleaf: Leaf acomposite: Composite aleaf: Leaf aleaf: Leaf aleaf: Leaf aleaf: Leaf COMP4001 CSE UNSW Sydney 23

24 Composite Structure Client Component +Operation() +Add(Component) +Remove(Component) +GetChild(int) children Leaf +Operation() Composite +Operation() +Add(Component) +Remove(Component) +GetChild(int) for all g in children g->operation() COMP4001 CSE UNSW Sydney 24

25 Composite Participants Component an object in a composition provides common interface and shared implementation provides interface for access to its child components optionally provides access to the parent component Client manipulates objects in the composition Leaf components with no children implements behaviour for primitive objects Composite components with children stores children implements child-related operations COMP4001 CSE UNSW Sydney 25

26 Consequences of Composite makes the client simple Leaf interface is subset of Composite s if identical interface, Leaf implementation needs defaults for Composite operations makes it easier to extend with new types of components design may be overly general types do not constrain the aggregation structure COMP4001 CSE UNSW Sydney 26

27 Implementation Issues in Composite explicit parent references sharing components maximising the Component interface declaring the child management operations should Component implement a list of Components? COMP4001 CSE UNSW Sydney 27

28 Implementation Issues in Composite... Child ordering Caching to improve performance Who should delete components? What's the best data structure for storing components? COMP4001 CSE UNSW Sydney 28

29 Interpreter Consider regular expressions as an example of a composite structure For example: salt & pepper cats dogs rain * raining & ( dogs cats ) * COMP4001 CSE UNSW Sydney 29

30 raining (dogs cats)* This is a parse tree How can we model this tree? COMP4001 CSE UNSW Sydney 30

31 Example Grammar regexp ::= repetition literal alternation sequence repetition ::= regexp * literal ::= identifier alternation ::= regexp regexp sequence ::= regexp regexp COMP4001 CSE UNSW Sydney 31

32 Parse Trees But how does interpret() work? COMP4001 CSE UNSW Sydney 32

33 Interpreting Expressions The interpret() call does the work at each node. LiteralExpression will check if the input matches the literal it defines, AlternationExpression will check if the input matches any of its alternatives, RepetitionExpression will check if the input has multiple copies of expression it repeats, and so on COMP4001 CSE UNSW Sydney 33

34 General Structure COMP4001 CSE UNSW Sydney 34

35 Use Interpreter when the grammar is simple efficiency is not critical often used for dynamic scripting languages query languages implementing rule interpreters to produce different kinds of output experimentation with language design COMP4001 CSE UNSW Sydney 35

36 Visitor Design Pattern when many operations need to be applied across different types of components Visitor classifies by operation rather than component avoids need to extend component classes for each operation simulates double dispatch actual method depends on component and operation type disadvantage classes have method per component hard codes component classification COMP4001 CSE UNSW Sydney 36

37 An Aside: Double Dispatch most OO languages implement dynamic binding code for method call is determined at runtime target object for call + method identifier determine which method implementation to use this is single dispatch multiple dispatch choose method based on runtime type of all call arguments e.g. in class Object: boolean equals(object o) may be specialised in subclasses but we would like to specialise code when the argument is of the same class this is an example of a binary method COMP4001 CSE UNSW Sydney 37

38 Visitor Example: parse tree every node of abstract syntax tree requires similar set of operations syntax structure is stable set of operations needs to be flexible COMP4001 CSE UNSW Sydney 38

39 Visitor Example Visitor says re-classify on basis of operations structure needs to accept visitors each node calls its (abstract) operation for the concrete visitor COMP4001 CSE UNSW Sydney 39

40 Visitor COMP4001 CSE UNSW Sydney 40

41 Visitor Collaboration Diagram COMP4001 CSE UNSW Sydney 41

42 Lecture Outline object equality design patterns composite interpreter visitor extensibility COMP4001 CSE UNSW Sydney 42

43 The Extensibility Problem Component-oriented programming software is assembled from independent components vision has not been fully realized limitations of current programming languages. A particular problem is that most Most languages have a bias towards one kind of decomposition in some languages adding new datatype variants is easy in others, adding new operations is easy Supporting both kinds of extensibility has proved itself quite elusive in FP particularly, also called the expression problem COMP4001 CSE UNSW Sydney 43

44 Issues in Extensibility must we modify existing code? problems for library code even if source is available can we retroactively extend library code? does unmodified code need recompilation? problems if source code is not available achieving separate compilation is important for large systems also for on-the-fly extensions of running systems can we independently extend existing code? COMP4001 CSE UNSW Sydney 44

45 The Extensibility Problem by example: Interpreter version of Composite result types are fixed fixed set of operations datatype is extensible pattern matching fixed set of datatypes set of operations is extensible visitor pattern OO approach to pattern matching COMP4001 CSE UNSW Sydney 45

46 The Extensibility Problem datatype extensibility + extensibility for set of operations can we achieve both together? reuse existing relationships/types without requiring recompilation of existing components can we achieve modularity? OO languages provide datatype extensibility functional programming provides extensibilility for COMP4001 CSE UNSW Sydney 46

47 Interpreter Design Pattern object Interpreter { trait Exp { def eval: Int operation is built-in not so easy to extend available operations case class Add(e1: Exp, e2: Exp) extends Exp { def eval = e1.eval + e2.eval case class Num(x: Int) extends Exp { def eval = x COMP4001 CSE UNSW Sydney 47

48 Interpreter Extensibility new forms of data are easily added no need to touch existing code new data is added as a new class implementing the Interpreter interface new operations are harder must add new operation to interface Interpreter must modify existing implementation add implementation of new operation COMP4001 CSE UNSW Sydney 48

49 Pattern-based version object Patterns { trait Exp case class Add(e1: Exp, e2: Exp) extends Exp case class Num(x: Int) extends Exp def eval(e: Exp): Int = e match { case Add(e1, e2) => eval(e1) + eval(e2) case Num(x) => x any extension to datatypes requires extra cases: not so easy to extend with extra datatypes COMP4001 CSE UNSW Sydney 49

50 Pattern-based Extensibility this is really an FP style of solution operation is defined by data structure cases so: adding a new operation is easy existing code is not modified just implement a new case-based function def adding new forms of data is harder add new case class must add a new case for each existing function modifies existing code COMP4001 CSE UNSW Sydney 50

51 Visitor-based version object Visitor { trait Exp { def accept(op: Op): Int case class Add(e1: Exp, e2: Exp) extends Exp { def accept(op: Op) = op.add(e1.accept(op), e2.accept(op)) case class Num(x: Int) extends Exp { def accept(op: Op) = op.num(x) interface for visitable components concrete components rely on visitor interface trait Op { def add(v1: Int, v2: Int) = v1 + v2 def num(x: Int) = x the visitor fixes the set of operations COMP4001 CSE UNSW Sydney 51

52 Visitor-based Extensibility the visitor is much like the pattern-based version instead of using (static) cases visitor uses a dynamic dispatch selects the concrete operation for the concrete data BUT there is a strong dependency between the form of data (Add, Num) and the Op interface the Op provides an evaluation operation for Exp adding operations is limited by the Op interface adding new forms of data is also hard must extend the Op interface re-implement all existing operations COMP4001 CSE UNSW Sydney 52

53 Generalizing the Visitor object GenericResultVisitor { trait Exp { def accept[r](op: Op[R]): R case class Add(e1: Exp, e2: Exp) extends Exp { generic result of visit def accept[r](op: Op[R]) = op.add(e1.accept(op), e2.accept(op)) case class Num(x: Int) extends Exp { def accept[r](op: Op[R]) = op.num(x) trait Op[R] { def add(v1: R, v2: R): R def num(x: Int): R COMP4001 CSE UNSW Sydney 53

54 Generic Visitor instances trait OpInt extends Op[Int] { def add(v1: Int, v2: Int) = v1 + v2 def num(x: Int) = x generic result of visit trait OpToString extends Op[String] { def add(v1: String, v2: String) = v1 + v2 def num(x: Int) = x.tostring COMP4001 CSE UNSW Sydney 54

55 Extensibility for Generic Visitor adding new types of visit operations is easy just choose the result type R implement Op[R] in a new class still adding new data is not so easy: a new case class must be defined for the data a corresponding method must be added to the Op interface and re-implemented for existing Op implementations COMP4001 CSE UNSW Sydney 55

56 Further Generalization of Visitor object GenericVisitor { trait Exp[Op[_]] { def accept[r](op: Op[R]): R case class Add[Op[R] <: AddOp[R]](e1: Exp[Op], e2: Exp[Op]) extends Exp[Op] { def accept[r](op: Op[R]) = op.add(e1.accept(op), e2.accept(op)) case class Num[Op[R] <: NumOp[R]](x: Int) extends Exp[Op] { def accept[r](op: Op[R]) = op.num(x) trait NumOp[R] { def num(x: Int): R trait AddOp[R] { def add(v1: R, v2: R): R COMP4001 CSE UNSW Sydney 56

57 Extensibility of Visitor GenericVisitor parameterizes the datatype over the set of operations Op[_] is a type constructor think of it as a kind of type function: R => Op[R] but it works on types, not values given a type R, Op[R] will be the type of operation GenericVisitor allows extension of datatype via extra subclasses of Exp independently of the set of operation of operation eg Num, Add because each datatype extension can specify its own constraints on the visitor type constructor COMP4001 CSE UNSW Sydney 57

58 Reference Modular Visitor Components A Practical Solution to the Expression Families Problem Bruno C. d. S. Oliveira ECOOP 2009 A very recent paper takes a different approach it does not rely on Scala's generics and type constructions Extensibility for the Masses Practical Extensibility with Object Algebras Bruno C. d. S. Oliveira and William R. Cook ECOOP 2012 COMP4001 CSE UNSW Sydney 58