SOEN6461: Software Design Methodologies Yann-Gal Guhneuc Yann-Gal - - PowerPoint PPT Presentation
SOEN6461: Software Design Methodologies Yann-Gal Guhneuc Yann-Gal Guhneuc Encapsulation, inheritance and types, polymorphism (overriding/overloading), abstraction and types This work is licensed under a Creative Commons
Yann-Gaël Guéhéneuc
This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License
Yann-Gaël Guéhéneuc
Encapsulation, inheritance and types, polymorphism (overriding/overloading), abstraction and types
2/128
Programming languages have been around
since the 1800s
– In 1801, Joseph Marie Jacquard invented a “code” to represent sewing loom arm movements on punch cards
3/128
http://www.nature.com/nature/journal/v444/n7119/abs/nature05357.html
4/128
http://arstechnica.com/information-technology/2014/03/gears-of-war-when-mechanical-analog-computers-ruled-the-waves/
5/128
– In 1842-43, Ada Lovelace designed a “code” to compute Bernouilli numbers on Charles Babbage's Analytical Engine
6/128
– In 1936, Alan Turing invented the Turing machine and a “code” to program it – In the 1950s, the first modern programming language appear
– Since then, many more have been created…
7/128
– In 1936, Alan Turing invented the Turing machine and a “code” to program it – In the 1950s, the first modern programming language appear
– Since then, many more have been created…
http://rigaux.org/language-study/diagram.png
8/128
The design and implementation of the newer
programming languages all attempt
– To solve problems (real or perceived) in previous languages – To rise the level of abstraction and hide away the hardware systems – To provide constructs that are closer to the domain model or adapt better to hardware
9/128
The design and implementation of the newer
programming languages all attempt
– To solve problems (real or perceived) in previous languages – To rise the level of abstraction and hide away the hardware systems – To provide constructs that are closer to the domain model or adapt better to hardware
Civilization advances by extending the number of important operations that we can perform without thinking about them. —Alfred North Whitehead (1911)
10/128
Before 1968, (modern) programming
languages were mostly unstructured
– No explicit loops (for, while…) – Instruction goto + line number / labels
11/128
Before 1968, (modern) programming
languages were mostly unstructured
– No explicit loops (for, while…) – Instruction goto + line number / labels Problem: lack of structure Solution: structures
12/128
Before 1968, (modern) programming
languages were mostly unstructured
– No explicit loops (for, while…) – Instruction goto + line number / labels
Main (most famous) criticism by Edsger
Dijkstra in “Go To Statement Considered Harmful”, CACM, 1968
Problem: lack of structure Solution: structures
13/128
Between 1968 and 1972, programming languages
began to be structured but data and functions were all visible
– No explicit packaging – No explicit access control
14/128
Between 1968 and 1972, programming languages
began to be structured but data and functions were all visible
– No explicit packaging – No explicit access control
Problem: lack of packaging and access control Solution: information hiding
15/128
Between 1968 and 1972, programming languages
began to be structured but data and functions were all visible
– No explicit packaging – No explicit access control
Main (most famous) criticism by David Parnas in
“On the Criteria to Be Used in Decomposing Systems Into Modules”, CACM, 1972 Problem: lack of packaging and access control Solution: information hiding
16/128
Problem: implementation of information hiding Solution: encapsulation (in OO languages)
17/128
Information hiding can be realised through
– Encapsulation
– Lexical closures
Problem: implementation of information hiding Solution: encapsulation (in OO languages)
18/128
Information hiding can be realised through
– Encapsulation
– Lexical closures
Problem: implementation of information hiding Solution: encapsulation (in OO languages)
19/128
In the 1980s, object-oriented programming
languages became popular, in part because they propose encapsulation
Encapsulation is
– A language mechanism for restricting access to some of the object's components
– A language construct to bundle data with the methods
20/128
In the 1980s, object-oriented programming
languages became popular, in part because they propose encapsulation
Encapsulation is
– A language mechanism for restricting access to some of the object's components
– A language construct to bundle data with the methods
21/128
The “first”, canonical class-based object-oriented
programming language is Smalltalk
– Developed between 1972 and 1980 by Kay et al. at Xerox Parc
Fundamental concepts
– Encapsulation – Inheritance – Polymorphism – Abstraction
22/128
Fundamental concepts
– Encapsulation – Inheritance (typing) – Polymorphism (overriding, overloading) – Abstraction (typing)
23/128
Definition
– A way to reuse code of existing objects, to establish a subtype from an existing object, or both, depending upon programming language support [Wikipedia] – Different between class-based and prototype- based programming languages Problem: reuse code and categorise classes Solution: inheritance and typing
24/128
Class-based, typically Java
– Reuse of code
class CommonCode { protected void foo() { } } public class Reuser1 extends CommonCode { public void method1() { this.foo(); } } public class Reuser2 extends CommonCode { public void method2() { this.foo(); } }
25/128
Class-based, typically Java
– Subtyping, overriding
public interface Type { void foo1(); void bar1(); } public class SubType implements Type { public void bar1() { // TODO Auto-generated method stub } public void foo1() { // TODO Auto-generated method stub } }
26/128
Reuse and subtyping
combined
– To factor out code, e.g., in PADL – To create a taxonomy, e.g., in Java libraries
27/128
Reuse and subtyping combined
package aPackage; public interface Measure { int getValue(); } abstract class AbstractMeasure { public int getValue() { System.out.println("Before..."); return this.getRealValue(); } abstract int getRealValue(); } // Need a factory... public class Length extends AbstractMeasure implements Measure { public int getRealValue() { return 1; } } public class Size extends AbstractMeasure implements Measure { public int getRealValue() { return 2; } }
28/128
Reuse and subtyping combined
package aPackage; public interface Measure { int getValue(); } abstract class AbstractMeasure { public int getValue() { System.out.println("Before..."); return this.getRealValue(); } abstract int getRealValue(); } // Need a factory... public class Length extends AbstractMeasure implements Measure { public int getRealValue() { return 1; } } public class Size extends AbstractMeasure implements Measure { public int getRealValue() { return 2; } }
Distinguishing between reuse and subtyping
29/128
Why distinguish between reuse and subtyping?
30/128
Why distinguish between reuse and subtyping?
31/128
Prototype-based, typically JavaScript
– Reuse of code
var commonCode = new CommonCode(); commonCode.foo(); var reuser1 = new Reuser1(); reuser1.method1(); function CommonCode() { // No instance variables. } CommonCode.prototype.foo = function foo() { document.write("foo()<br>"); }; function Reuser1() { // No instance variables. } Reuser1.prototype = new CommonCode(); Reuser1.prototype.constructor = Reuser1; Reuser1.prototype.method1 = function method1() { this.foo(); document.write("in method1()<br>"); };
32/128
Prototype-based, typically JavaScript
– “Subtyping”
var type = new Type(); type.foo(); type.bar(); var subtype = new SubType(); subtype.foo(); subtype.bar(); function Type() { } Type.prototype.foo = function foo() { throw new Error("This is an abstract method!"); }; Type.prototype.bar = function bar() { throw new Error("This is an abstract method!"); }; function SubType() { } SubType.prototype = new Type(); SubType.prototype.constructor = SubType; SubType.prototype.foo = function foo() { document.write("foo()<br>"); }; SubType.prototype.bar = function bar() { document.write("bar()<br>"); };
33/128
Reuse and subtyping combined
function AbstractMeasure() { } AbstractMeasure.prototype.getValue = function getValue() { document.write("Some code before...<br>"); return this.getRealValue(); }; AbstractMeasure.prototype.getRealValue = function getRealValue() { throw new Error("Abstract method!"); }; function Length() { } Length.prototype = new AbstractMeasure(); Length.prototype.constructor = Length; Length.prototype.getRealValue = function getRealValue() { document.write("Specific code.<br>"); return 1; };
34/128
Reuse and subtyping combined
function AbstractMeasure() { } AbstractMeasure.prototype.getValue = function getValue() { document.write("Some code before...<br>"); return this.getRealValue(); }; AbstractMeasure.prototype.getRealValue = function getRealValue() { throw new Error("Abstract method!"); }; function Length() { } Length.prototype = new AbstractMeasure(); Length.prototype.constructor = Length; Length.prototype.getRealValue = function getRealValue() { document.write("Specific code.<br>"); return 1; };
No real distinction between reuse and “subtyping”
35/128
Java vs. JavaScript
– Make no mistake: JavaScript is no less “powerful” or “clean” than Java! – Different paradigms
– Different implementations of the paradigms
36/128
Definition
– Subtype polymorphism, almost universally called polymorphism in object-oriented programming – The ability to create a variable, a function, or an
– Superset of overloading, overriding Problem: change behaviour of concrete objects Solution: polymorphism
37/128
Definition
– A language feature that allows a subclass or a child class to provide a specific implementation of a method that is already provided by one of its super / parent classes
38/128
Class-based, typically Java
public class SuperClass { public void foo() { System.out.println("One implementation."); } } public class SubClass extends SuperClass { public void foo() { super.foo(); System.out.println("Another implementation."); } }
39/128
Class-based, typically Java
– Declared type vs. Concrete type – Overriding is resolved by the dynamic type of the receiver, not its static type
public class Main { public static void main(final String[] args) throws InstantiationException, IllegalAccessException { final SuperClass superClass = new SubClass(); superClass.foo(); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(); ((SuperClass) subClass.getClass().getSuperclass().newInstance()).foo(); } }
40/128
Class-based, typically Java
– Declared type vs. Concrete type – Overriding is resolved by the dynamic type of the receiver, not its static type
public class Main { public static void main(final String[] args) throws InstantiationException, IllegalAccessException { final SuperClass superClass = new SubClass(); superClass.foo(); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(); ((SuperClass) subClass.getClass().getSuperclass().newInstance()).foo(); } }
Distinction between declared type and concrete type
41/128
Class-based, typically Java
– Declared type vs. Concrete type – Overriding is resolved by the dynamic type of the receiver, not its static type
public class Main { public static void main(final String[] args) throws InstantiationException, IllegalAccessException { final SuperClass superClass = new SubClass(); superClass.foo(); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(); ((SuperClass) subClass.getClass().getSuperclass().newInstance()).foo(); } }
Distinction between declared type and concrete type Runtime dispatch
42/128
Class-based, typically Java
– Declared type vs. Concrete type – Overriding is resolved by the dynamic type of the receiver, not its static type
public class Main { public static void main(final String[] args) throws InstantiationException, IllegalAccessException { final SuperClass superClass = new SubClass(); superClass.foo(); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(); ((SuperClass) subClass.getClass().getSuperclass().newInstance()).foo(); } }
Distinction between declared type and concrete type Runtime dispatch Reflection
43/128 var subClass = new SubClass(); subClass.foo();
Prototype-based, typically JavaScript
– Declared type vs. concrete type
function SuperClass() { } SuperClass.prototype.foo = function foo() { document.write("One implementation...<br>"); }; function SubClass() { } SubClass.prototype = new SuperClass(); SubClass.prototype.constructor = SubClass; SubClass.prototype.parent = SuperClass.prototype; SubClass.prototype.foo = function foo() { this.parent.foo.call(this); document.write("Another implementation...<br>"); };
44/128 var subClass = new SubClass(); subClass.foo();
Prototype-based, typically JavaScript
– Declared type vs. concrete type
function SuperClass() { } SuperClass.prototype.foo = function foo() { document.write("One implementation...<br>"); }; function SubClass() { } SubClass.prototype = new SuperClass(); SubClass.prototype.constructor = SubClass; SubClass.prototype.parent = SuperClass.prototype; SubClass.prototype.foo = function foo() { this.parent.foo.call(this); document.write("Another implementation...<br>"); };
No type declaration Unlike Java!
45/128 var subClass = new SubClass(); subClass.foo();
Prototype-based, typically JavaScript
– Declared type vs. concrete type
function SuperClass() { } SuperClass.prototype.foo = function foo() { document.write("One implementation...<br>"); }; function SubClass() { } SubClass.prototype = new SuperClass(); SubClass.prototype.constructor = SubClass; SubClass.prototype.parent = SuperClass.prototype; SubClass.prototype.foo = function foo() { this.parent.foo.call(this); document.write("Another implementation...<br>"); };
No type declaration Unlike Java! No super Unlike Java!
46/128
Java vs. JavaScript
– Make no mistake: JavaScript is no less “powerful” or “clean” than Java! – Different paradigms
– Different implementations of the paradigms
47/128
Definition
– Methods that have the same name but different signatures inside the same class or a class hierarchy
48/128
Class-based, typically Java
public class Point { public boolean equals(final Object anObject) { System.out.println("One implementation."); return false; } public boolean equals(final Point aPoint) { System.out.println("Another implementation."); return false; } } public class Main { public static void main(final String[] args) { final Point p1 = new Point(); final Point p2 = new Point(); final Object o = p1; System.out.println(p1.equals(p2)); System.out.println(o.equals(p2)); System.out.println(p1.equals(o)); } }
49/128
Class-based, typically Java
public class Point { public boolean equals(final Object anObject) { System.out.println("One implementation."); return false; } public boolean equals(final Point aPoint) { System.out.println("Another implementation."); return false; } } public class Main { public static void main(final String[] args) { final Point p1 = new Point(); final Point p2 = new Point(); final Object o = p1; System.out.println(p1.equals(p2)); System.out.println(o.equals(p2)); System.out.println(p1.equals(o)); } } Another implementation. false
50/128
Class-based, typically Java
public class Point { public boolean equals(final Object anObject) { System.out.println("One implementation."); return false; } public boolean equals(final Point aPoint) { System.out.println("Another implementation."); return false; } } public class Main { public static void main(final String[] args) { final Point p1 = new Point(); final Point p2 = new Point(); final Object o = p1; System.out.println(p1.equals(p2)); System.out.println(o.equals(p2)); System.out.println(p1.equals(o)); } } Another implementation. false One implementation. false
51/128
Class-based, typically Java
public class Point { public boolean equals(final Object anObject) { System.out.println("One implementation."); return false; } public boolean equals(final Point aPoint) { System.out.println("Another implementation."); return false; } } public class Main { public static void main(final String[] args) { final Point p1 = new Point(); final Point p2 = new Point(); final Object o = p1; System.out.println(p1.equals(p2)); System.out.println(o.equals(p2)); System.out.println(p1.equals(o)); } } Another implementation. false One implementation. false One implementation. false
52/128
Class-based, typically Java
– The equals() method in Point takes a Point instead of an Object as an argument – It does not override equals in Object – It is just an overloaded alternative – Overloading is resolved by the static type of the argument, not its run-time type
53/128
Class-based, typically
Java
– Using the static type of the argument is natural in a strongly-typed language... – Else how could the program compile?
final Point p1 = new Point(); final Object o = p1; System.out.println(o.equals(p2));
54/128
Class-based, typically
Java
– Using the static type of the argument is natural in a strongly-typed language... – Else how could the program compile?
// Compiled from Main.java (version 1.6 : 50.0, super bit) public class ca.concordial.soeb6461.overloading.Main { // Method descriptor #6 ()V // Stack: 1, Locals: 1 public Main(); 0 aload_0 [this] 1 invokespecial java.lang.Object() 4 return […] // Method descriptor #15 ([Ljava/lang/String;)V // Stack: 3, Locals: 4 public static void main(java.lang.String[] args); […] 32 aload_3 [o] 33 aload_2 [p2] 34 invokevirtual java.lang.Object.equals(java.lang.Object) : boolean 37 invokevirtual java.io.PrintStream.println(boolean) : void 40 getstatic java.lang.System.out : java.io.PrintStream final Point p1 = new Point(); final Object o = p1; System.out.println(o.equals(p2));
55/128
Prototype-based, typically JavaScript
– The issue here is really that JavaScript is dynamically-typed – Overloading just does not make sense!
56/128
Prototype-based, typically JavaScript
– Implementing the look-up table manually
// addMethod - By John Resig (MIT Licensed) function addMethod(object, name, fn){ var old = object[ name ];
if ( fn.length == arguments.length ) return fn.apply( this, arguments ); else if ( typeof old == 'function' ) return old.apply( this, arguments ); }; } When control enters the execution context of a function an arguments object is created. The arguments object has an array-like structure with an indexed property for each passed argument and a length property equal to the total number of parameters supplied by the caller.
57/128
Prototype-based, typically JavaScript
– Implementing the look-up table manually
function Users(){} addMethod(Users.prototype, "find", function(){ // Find all users... }); addMethod(Users.prototype, "find", function(name){ // Find a user by name }); addMethod(Users.prototype, "find", function(first, last){ // Find a user by first and last name }); var users = new Users(); users.find(); // Finds all users.find("John"); // Finds users by name users.find("John", "Resig"); // Finds users by first and last name users.find("John", "E", "Resig"); // Does nothing
58/128
Java vs. JavaScript
– Make no mistake: JavaScript is no less “powerful” or “clean” than Java! – Different paradigms
– Different implementations of the paradigms
59/128
Definition (recalled)
– Subtype polymorphism, almost universally called polymorphism in object-oriented programming – The ability to create a variable, a function, or an
– Superset of overloading, overriding Problem: change behaviour of concrete objects Solution: polymorphism
60/128
Definition
– Subtype polymorphism is all about type-safety and the “contract” between a superclass and its subclasses – It is all about pre- and post-conditions
61/128
62/128
Liskov’s Substitution Principle
Barbara Liskov
– Born 7 November 1939 – Mother of the Liskov’s substitution principle – IEEE J. von Neumann Medal in 2004 – ACM Turing Award in 2008 – Cf. http://en.wikipedia.org/wiki/ Liskov_substitution_principle
Barbara Liskov *1939
63/128
Liskov’s substitution principle
– Context
– Object-oriented programming is increasingly popular
– Principle
64/128
– Principle (cont’d)
the concept of sub-typing in type theory
– Contravariance of parameters: a parameter of type T can accept object of type S, where S is a sub-type of T – Covariance of return type: the return type can be “enlarged” from T to S
– Pre-conditions cannot be stronger in a sub-type – Post-conditions cannot be weaker in a sub-type – The sub-type S must preserve the invariants of type T
65/128
Definition
– If S is a subtype of T, then objects of type T may be replaced with objects of type S (objects of type S may be substitutes for objects of type T) without altering any of the desirable properties
T S P
66/128
This principle defines the notions of
generalization/specialization formally
Class S is correctly defined as a specialization of T if the
following are true
– For each object s of class S there is an object t of class T such that the expected behavior of any program P defined in terms of T is unchanged if s is substituted for t
Then
– S is a said to be a subtype of T – Any instance of S can stand for an instance of T without any undesired effect on client classes – Any future extension (new subclasses) will not affect existing clients
From Giuliano Antoniol’s slides INF6305
67/128
class Rectangle : public Shape { private: int w, h; public: virtual void set_width(int wi) { w=wi; } virtual void set_height(int he) { h=he; } } class Square : public Rectangle { public: void set_width(int w) { Rectangle::set_height(w); Rectangle::set_width(w); } void set_height(int h) { set_width(h); } } void foo(Rectangle *r) { // This is the client r->set_width(5); r->set_height(4); assert((r->get_width()*r->get_height()) == 20); // Oracle }
client is different (width*height == 16)
From Giuliano Antoniol’s slides for INF6305.
68/128
Class S is correctly defined as a
specialization of T then we say that S is compatible with T
T S P
69/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
70/128
Class-based, typically Java
final SuperClass superClass = new SubClass(); final SubClass subClass = new SubClass();
71/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
72/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
Covariance of return type Objects returned by getSomething in any subclass are always compatible with that expected by the superclass
73/128
Class-based, typically Java
class SuperClass { String getSomething() { return new Object(); } } class SubClass extends SuperClass { Object getSomething() { return new String(); } } public class ContravarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); // This whole piece of code is not legal in Java! For example only. final String result = superClass.getSomething(); } }
74/128
Class-based, typically Java
class SuperClass { String getSomething() { return new Object(); } } class SubClass extends SuperClass { Object getSomething() { return new String(); } } public class ContravarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); // This whole piece of code is not legal in Java! For example only. final String result = superClass.getSomething(); } }
If contavariance of return type Objects returned by getSomething in a subclass would not be compatible with that expected by the superclass
75/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
76/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
Post-conditions in the subtype must be the same as or stronger than in the supertype
77/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
Post-conditions in the subtype must be the same as or stronger than in the supertype
78/128
Class-based, typically Java
class SuperClass { Object getSomething() { return new Object(); } } class SubClass extends SuperClass { String getSomething() { return new String(); } } public class CovarianceOfReturnTypes { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); System.out.println( Object.class.isAssignableFrom(superClass.getSomething().getClass())); } }
Post-conditions in the subtype must be the same as or stronger than in the supertype
79/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
80/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
Contravariance of arguments types Objects used by getSomething in any subclass are always narrower to allow calling the super method
81/128
Class-based, typically Java
class SuperClass { void getSomething(final Object aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final String aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); // This piece of code is not legal in Java! For example only. subClass.getSomething(""); } }
82/128
Class-based, typically Java
class SuperClass { void getSomething(final Object aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final String aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); // This piece of code is not legal in Java! For example only. subClass.getSomething(""); } }
Covariance of arguments types Objects used by getSomething in any subclass would confuse the compiler: which method to use?
83/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
84/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
Pre-conditions in the subtype must be the same as or weaker than in the supertype
85/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
Pre-conditions in the subtype must be the same as or weaker than in the supertype
86/128
Class-based, typically Java
class SuperClass { void getSomething(final String aParameter) { System.out.println("One implementation..."); } } class SubClass extends SuperClass { void getSomething(final Object aParameter) { System.out.println("Another implementation..."); } } public class ContravarianceOfArgumentTypes { public static void main(final String[] args) { final SubClass subClass = new SubClass(); subClass.getSomething(new Object()); subClass.getSomething(""); } }
Pre-conditions in the subtype must be the same as or weaker than in the supertype
87/128
Contra-variance in more depth… Thank you http://www.jdoodle.com,
Firefox Abduction!, and Eclipse compilers
88/128
89/128
with v1.3
90/128
91/128
92/128
https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
93/128
Not
Another implementation… Another implementation…
https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
94/128
95/128
Valid! Valid!
96/128
97/128
Workaround!
98/128
https://stackoverflow.com/questions/2995926/why-is-there-no-parameter-contra-variance-for-overriding
99/128
Thank you to Willian Flageol for the example
100/128
https://underscore.io/blog/posts/2015/11/04/late-binding-and-overloading.html
101/128
https://coderwall.com/p/dlqvnq/simple-example-for-scala-covariance-contravariance-and-invariance
102/128
Generics!
Should be contrasted with Java
https://coderwall.com/p/dlqvnq/simple-example-for-scala-covariance-contravariance-and-invariance
103/128
In Java
– https://stackoverflow.com/questions/3861132/ how-would-contravariance-be-used-in-java- generics
In Eiffel and Sather
– http://www1.icsi.berkeley.edu/~sather/Document ation/EclecticTutorial/node15.html
104/128
Class-based, typically Java
– Dispatching
public class SuperClass { public void foo(final Object anObject) { System.out.println("One implementation."); } } public class SubClass extends SuperClass { public void foo(final Object anObject) { super.foo(this); System.out.println("Another implementation."); } public void foo(final String aString) { super.foo(this); System.out.println("Yet another implementation."); } } public class Main { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); superClass.foo(""); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(""); } }
105/128
Class-based, typically Java
– Dispatching
public class SuperClass { public void foo(final Object anObject) { System.out.println("One implementation."); } } public class SubClass extends SuperClass { public void foo(final Object anObject) { super.foo(this); System.out.println("Another implementation."); } public void foo(final String aString) { super.foo(this); System.out.println("Yet another implementation."); } } public class Main { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); superClass.foo(""); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(""); } } One implementation. Another implementation. One implementation. Another implementation.
106/128
Class-based, typically Java
– Dispatching (cont’d)
public class SuperClass { public void foo(final String anObject) { System.out.println("One implementation."); } } public class SubClass extends SuperClass { public void foo(final Object anObject) { super.foo(""); System.out.println("Another implementation."); } public void foo(final String aString) { super.foo(""); System.out.println("Yet another implementation."); } } public class Main { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); superClass.foo(""); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(""); } }
107/128
Class-based, typically Java
– Dispatching (cont’d)
public class SuperClass { public void foo(final String anObject) { System.out.println("One implementation."); } } public class SubClass extends SuperClass { public void foo(final Object anObject) { super.foo(""); System.out.println("Another implementation."); } public void foo(final String aString) { super.foo(""); System.out.println("Yet another implementation."); } } public class Main { public static void main(final String[] args) { final SuperClass superClass = new SubClass(); superClass.foo(""); final SubClass subClass = new SubClass(); ((SuperClass) subClass).foo(""); } } One implementation. Yet another implementation. One implementation. Yet another implementation.
108/128
Functional-based, typically CommonLisp
– Dispatching
(defgeneric test (x y) (:documentation "Returns the type of the two arguments)) (defmethod test ((x number) (y number)) '(num num)) (defmethod test ((i integer) (y number)) '(int num)) (defmethod test ((x number) (j integer)) '(num int)) (defmethod test ((i integer) (j integer)) '(int int))
109/128
Functional-based, typically CommonLisp
– Dispatching
(defgeneric test (x y) (:documentation "Returns the type of the two arguments)) (defmethod test ((x number) (y number)) '(num num)) (defmethod test ((i integer) (y number)) '(int num)) (defmethod test ((x number) (j integer)) '(num int)) (defmethod test ((i integer) (j integer)) '(int int)) (test 1 1) => (int int) (test 1 1/2) => (int num) (test 1/2 1) => (num int) (test 1/2 1/2) => (num num)
110/128
Java vs. CommonLisp
– Make no mistake: Java is no less “powerful” or “clean” than CommonLisp! – Different paradigms
– Different implementations of the paradigms
111/128
Object-oriented programming languages
typically offer
– Concrete classes – Abstract classes – Pure abstract classes / interfaces
Problem: package reusable data and behaviour Solution: abstraction and typing
112/128
The virtues of abstraction is that “the user of
the abstraction can forget the details of the implementation of the abstraction.”
– By Richard Gabriel, Patterns of Software, Oxford Univeristy Press, 1998
A class should have only one reason to
change
– By Robert C. Martin
113/128
Take a sort algorithm, e.g., an insertion sort
package ca.concordia.soen6461; import java.util.List; public class InsertionSort<E> { public List<E> sort(final List<E> aList) { final List<E> temporaryList = null; // Some implementation... return temporaryList; } } public class Client { public static void main(final String[] args) { final InsertionSort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
114/128
Take a sort algorithm, e.g., an insertion sort
package ca.concordia.soen6461; import java.util.List; public class InsertionSort<E> { public List<E> sort(final List<E> aList) { final List<E> temporaryList = null; // Some implementation... return temporaryList; } } public class Client { public static void main(final String[] args) { final InsertionSort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
115/128
Problems with InsertionSort
– Exposes the implementation of the sort
another?
– Exposes the public interface of the class
116/128
We can “abstract” all sort algorithms
package ca.concordia.soen6461; import java.util.List; public abstract class AbstractSort<E> { public abstract List<E> sort(final List<E> aList); public void someHelperMethod() { // Some implementation... } protected void someOtherHelperMethod() { // Some implementation... } } public class Client { public static void main(final String[] args) { final AbstractSort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
117/128
We can “abstract” all sort algorithms
package ca.concordia.soen6461; import java.util.List; public abstract class AbstractSort<E> { public abstract List<E> sort(final List<E> aList); public void someHelperMethod() { // Some implementation... } protected void someOtherHelperMethod() { // Some implementation... } } public class Client { public static void main(final String[] args) { final AbstractSort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
118/128
Advantage with the abstract class
– Code reuse
Problems with AbstractSort
– Exposes the public interface of the class
– Exposes the “partial” type of the sort
algorithm that is NOT a subclass of AbstractSort?
119/128
We can abstract all sort algorithms
package ca.concordia.soen6461; import java.util.List; public interface ISort<E> { public List<E> sort(final List<E> aList); } public class Client { public static void main(final String[] args) { final ISort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
120/128
We can abstract all sort algorithms
package ca.concordia.soen6461; import java.util.List; public interface ISort<E> { public List<E> sort(final List<E> aList); } public class Client { public static void main(final String[] args) { final ISort<String> s = new InsertionSort<String>(); final List<String> l = null; s.sort(l); } }
121/128
Advantages with the interface (type)
– Hides completely the implementation from the client code – Allows any classes to offer a new sort algorithm by implementing the interface ISort
122/128
Advantages with the interface (type)
– Hides completely the implementation from the client code – Allows any classes to offer a new sort algorithm by implementing the interface ISort
Allow the development of an “economy”, e.g., for Java collections :
123/128
Other examples, from worst to best
Vector Shape.getPoints()
List Shape.getPoints()
Iterator Shape.getPoints()
124/128
Other examples, from worst to best
Vector Shape.getPoints()
List Shape.getPoints()
Iterator Shape.getPoints()
125/128
Other examples, from worst to best
Vector Shape.getPoints()
List Shape.getPoints()
Iterator Shape.getPoints()
126/128
Fundamental concepts of object-oriented
programming languages evolved to solve specific problems
127/128
Lessons to learn
– These concepts do not require a class-based
– They depend on implementation choices
– Visitor design pattern
128/128
In the following, we will see how other
problems that could NOT (yet) be solved by programming languages will be solved by using specific
– Architectures – Designs – Techniques