1. 11 Further abstraction techniques
Objektorienterad programmering d2, förel. 11
11 Further abstraction techniques
BK Chap. 12
Abstract classes and interfaces
DAT050, 16/17, lp 1

2. Main concepts to be covered
Objektorienterad programmering d2, förel. 11
Main concepts to be covered
Abstract classes
Interfaces
Multiple inheritance
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

3. Objektorienterad programmering d2, förel. 11
Simulations
Programs regularly used to simulate real-world activities
city traffic
the weather
nuclear processes
stock market fluctuations
environmental changes
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

4. Objektorienterad programmering d2, förel. 11
Simulations
They are often only partial simulations
They often involve simplifications
Greater detail has the potential to provide greater accuracy
Greater detail typically requires more resources:
Processing power
Simulation time
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

5. Benefits of simulations
Objektorienterad programmering d2, förel. 11
Benefits of simulations
Support useful prediction
The weather
Allow experimentation
Safer, cheaper, quicker
Example:
‘How will the wildlife be affected if we cut a highway through the middle of this national park?’
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

6. Predator-prey simulations
Objektorienterad programmering d2, förel. 11
Predator-prey simulations
There is often a delicate balance between species
A lot of prey means a lot of food
A lot of food encourages higher predator numbers
More predators eat more prey
Less prey means less food
Less food means ...
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

7. The foxes-and-rabbits project
Objektorienterad programmering d2, förel. 11
The foxes-and-rabbits project
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

8. Main classes of interest
Objektorienterad programmering d2, förel. 11
Main classes of interest
Fox
Simple model of a type of predator
Rabbit
Simple model of a type of prey
Simulator
Manages the overall simulation task
Holds a collection of foxes and rabbits
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

9. Objektorienterad programmering d2, förel. 11
The remaining classes
Field
Represents a 2D field
Location
Represents a 2D position
SimulatorView, FieldStats, Counter
Maintain statistics and present a view of the field
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

10. Example of the visualization
Objektorienterad programmering d2, förel. 11
Example of the visualization
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

11. A Rabbit’s state public class Rabbit { Static fields omitted.
// Individual characteristics (instance fields).
// The rabbit's age.
private int age;
// Whether the rabbit is alive or not.
private boolean alive;
// The rabbit's position
private Location location;
// The field occupied
private Field field;
Methods omitted. }
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1

12. Objektorienterad programmering d2, förel. 11
A Rabbit’s behavior
Managed from the run method
Age incremented at each simulation ‘step’
A rabbit could die at this point
Rabbits that are old enough might breed at each step
New rabbits could be born at this point
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

13. Rabbit simplifications
Objektorienterad programmering d2, förel. 11
Rabbit simplifications
Rabbits do not have different genders
In effect, all are female
The same rabbit could breed at every step
All rabbits die at the same age
Others?
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

14. A Fox’s state public class Fox { Static fields omitted { 
Static fields omitted
// The fox's age.
private int age;
// Whether the fox is alive or not.
private boolean alive;
// The fox's position
private Location location;
// The field occupied
private Field field;
// The fox's food level, which is increased
// by eating rabbits.
private int foodLevel;
Methods omitted. }
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1

15. Objektorienterad programmering d2, förel. 11
A Fox’s behavior
Managed from the hunt method
Foxes also age and breed
They become hungry
They hunt for food in adjacent locations
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

16. Configuration of foxes
Objektorienterad programmering d2, förel. 11
Configuration of foxes
Similar simplifications to rabbits
Hunting and eating could be modeled in many different ways:
Should food level be additive?
Is a hungry fox more or less likely to hunt?
Are simplifications ever acceptable?
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

17. Objektorienterad programmering d2, förel. 11
The Simulator class
Three key components:
Setup in the constructor
The populate method
Each animal is given a random starting age
The simulateOneStep method
Iterates over separate populations of foxes and rabbits
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

18. Objektorienterad programmering d2, förel. 11
The update step
Iterator<Rabbit> it = rabbits.iterator();
while ( it.hasNext() ) {
Rabbit rabbit = it.next();
rabbit.run(newRabbits);
if(! rabbit.isAlive()) {
it.remove(); } …
Iterator<Fox> it = foxes.iterator();
Fox fox = it.next();
fox.hunt(newFoxes);
if(! fox.isAlive()) {
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

19. Objektorienterad programmering d2, förel. 11
Room for improvement
Fox and Rabbit have strong similarities but do not have a common superclass
The update step involves similar-looking code
The Simulator is tightly coupled to specific classes
It ‘knows’ a lot about the behavior of foxes and rabbits
Refactor!
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

20. The Animal superclass Place common fields in Animal:
age, alive, location
Method renaming to support information hiding:
run and hunt become act
Simulator can now be significantly decoupled
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1

21. Revised (decoupled) iteration
Objektorienterad programmering d2, förel. 11
Revised (decoupled) iteration
Iterator<Animal> it = animals.iterator();
while ( it.hasNext() ) {
Animal animal = it.next();
animal.act(newAnimals);
if(! animal.isAlive()) {
it.remove(); }
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

22. The act method of Animal
Objektorienterad programmering d2, förel. 11
The act method of Animal
Static type checking requires an act method in Animal
There is no obvious shared implementation
Define act as abstract: abstract public void act(List<Animal> newAnimals);
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

23. Abstract classes and methods
Objektorienterad programmering d2, förel. 11
Abstract classes and methods
Abstract methods have abstract in the signature
Abstract methods have no body
Abstract methods make the class abstract
Abstract classes cannot be instantiated
Concrete subclasses complete the implementation
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

24. Objektorienterad programmering d2, förel. 11
The Animal class
public abstract class Animal {
fields omitted
/**
* Make this animal act - that is: make it do
* whatever it wants/needs to do. */
abstract public void act(List<Animal> newAnimals);
other methods omitted }
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

25. Ex. Abstract and Concrete classes
Objektorienterad programmering d2, förel. 11
Ex. Abstract and Concrete classes
<<abstract>> A
f()
g()
h() B C
public abstract class A {
public void f() { ... }
public abstract int g();
public abstract boolean h(float x); }
public abstract class B extends A {
public int g() { ... }
public class C extends B {
public boolean h(float x) { ... }
A a = new A();
B b = new B();
C c = new C();
c.f(); // from A
int x = c.g(); // from B
boolean flag = c.h(3.14); // from C
NOT ALLOWED!
A and B are abstract
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

26. Objektorienterad programmering d2, förel. 11
Further abstraction
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

27. Objektorienterad programmering d2, förel. 11
Multiple inheritance
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

28. Objektorienterad programmering d2, förel. 11
Multiple inheritance
Having a class inherit directly from multiple ancestors
Each language has its own rules
How to resolve competing definitions?
Java forbids it for classes
Java permits it for interfaces
No competing implementation (p.39-42)
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

29. Objektorienterad programmering d2, förel. 11
An Actor interface
public interface Actor {
/**
* Perform the actor's regular behavior.
newActors A list for storing newly created
* actors. */
void act(List<Actor> newActors);
* Is the actor still active?
true if still active, false if not.
boolean isActive(); }
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

30. Classes implement interfaces
Objektorienterad programmering d2, förel. 11
Classes implement interfaces
implements
extends
Animal deklarerar antingen act som abstrakt,
eller så implementerar den act
<<Stereotyper>>
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

31. Classes implement interfaces(2)
Objektorienterad programmering d2, förel. 11
Classes implement interfaces(2)
public interface Actor { ... }
public interface Drawable { ... }
public abstract class Animal implements Actor
{ ... }
public class Fox extends Animal implements Drawable
public class Rabbit extends Animal implements Drawable
public class Ant extends Animal
public class Hunter implements Actor, Drawable
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

32. Objektorienterad programmering d2, förel. 11
Interfaces as types
Implementing classes do not inherit code, but ...
... implementing classes are subtypes of the interface type
So, polymorphism is available with interfaces as well as classes
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

33. Features of interfaces
Objektorienterad programmering d2, förel. 11
Features of interfaces
All methods are abstract
There are no constructors
All methods are public
All fields are public, static and final
So they are public constants
(The above is true for Java version 7 and earlier versions.)
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

34. Interfaces as specifications
Objektorienterad programmering d2, förel. 11
Interfaces as specifications
Strong separation of functionality from implementation
Though parameter and return types are mandated
Clients interact independently of the implementation
But clients can choose from alternative implementations
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

35. Alternative implementations
Objektorienterad programmering d2, förel. 11
Alternative implementations
implements
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

36. Lists – the (nearly) whole truth
Objektorienterad programmering d2, förel. 11
Lists – the (nearly) whole truth
Iterable
Object
Collection
List
AbstractCollection
AbstractList
AbstractSequentialList
OBS! En länkad lista är en FIFO-kö (bl.a.)
ArrayList
LinkedList
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

37. Objektorienterad programmering d2, förel. 11
Interface extension
public interface Iterable
public interface Collection extends Iterable
public interface List extends Collection
Interfaces can be extended by defining sub interfaces.
A sub interface declares additional method signatures.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

38. Ex. Some legal combinations
Objektorienterad programmering d2, förel. 11
Ex. Some legal combinations
Map<String,List<Integer>> m;
m = new HashMap<String,List<Integer>>();
m.put("first",new ArrayList<Integer>());
m.put("second",new LinkedList<Integer>());
OK!
HashMap<String,List<Integer>>
is a subtype of
Map<String,List<Integer>>
OK!
ArrayList and LinkedList
are subtypes of
List
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

39. Ex. Some ILLEGAL combinations
Objektorienterad programmering d2, förel. 11
Ex. Some ILLEGAL combinations
Map<String,List<Integer>> m;
m = new HashMap<String,ArrayList<Integer>>();
Wrong!
HashMap<String,ArrayList<Integer>>
is not a subtype of
Map<String,List<Integer>>
or of
HashMap<String,List<Integer>>
(the same applies to LinkedList)
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

40. Problems with multiple inheritance
Objektorienterad programmering d2, förel. 11
Problems with multiple inheritance
Languages which allow general multiple inheritance have to deal with two problems:
Name conflicts caused by inheritance of the same method from multiple base classes.
Conflicting inheritance of variables (diamond inheritance ).
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

41. Problems with multiple inheritance (2)
Objektorienterad programmering d2, förel. 11
Problems with multiple inheritance (2)
Competing methods
There is a name conflict when calling f in C c = new C(); c.f();
f is inherited from both A and B. Which one should be called?
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

42. Problems with multiple inheritance (3)
Objektorienterad programmering d2, förel. 11
Problems with multiple inheritance (3)
“Diamond” inheritance
The variable x is inherited by both B and C – no problem so far.
Should D inherit two instances of x?
If not, should it inherit x via B or via C?
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

43. Problems with multiple inheritance (4)
Objektorienterad programmering d2, förel. 11
Problems with multiple inheritance (4)
Design issues
Multiple inheritance allows for inheritance hierarchies with many roots. This makes them more complicated to understand and use.
A single rooted hierarchy is simpler and cleaner. In Java the single root is named Object.
To guarantee single rootedness, multiple inheritance should be abandoned.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

44. Objektorienterad programmering d2, förel. 11
Review (1)
Inheritance can provide shared implementation.
Concrete and abstract classes.
Inheritance provides shared type information.
Classes and interfaces.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

45. Objektorienterad programmering d2, förel. 11
Review (2)
Abstract methods allow static type checking without requiring implementation.
Abstract classes function as incomplete superclasses.
No instances.
Abstract classes support polymorphism.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1

46. Objektorienterad programmering d2, förel. 11
Review (3)
Interfaces provide specification without implementation.
Interfaces are fully abstract.
Interfaces support polymorphism.
Java interfaces support multiple inheritance.
Objektorienterad programmering, DAT050, DAI2, 16/17, lp 1
DAT050, 16/17, lp 1