This document discusses software design principles and patterns, including: 1) Generic programming allows code to work with different data types through interfaces and abstract base classes. Reflection allows examining and manipulating objects at runtime. 2) The document discusses separation of concerns, loose coupling, and high cohesion as important design principles. It gives an example of dividing an application by feature and concern. 3) The document uses a duck simulation example to illustrate issues that can arise from rigid class hierarchies and inheritance. It proposes using the strategy pattern by defining behavior interfaces and swapping concrete strategy classes to vary behavior while keeping classes loosely coupled and extensible.

1. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015
L04 SOFTWARE DESIGN EXAMPLES

2. Agenda
Generic Programming
Reflection
Software Design Principles
Software Design in Action

3. GENERIC PROGAMMING

4. Generic Programming
▪ Programming in an data type independent way
– Same code is used regardless of the data type
▪ Example
– Sort can be applied to any data type
– Generic collection
• Java Collection Framework
▪ Design Principle
– Always use the most generic data type possible

5. Generic Programming
▪ All classes extend Object
– Allows generic algorithms and data structures
static int find (Object[] a, Object key)
{
int i;
for (i=0;i<a.length;i++)
if (a[i].equals(key)) return i;
return -1;
}
Employee[] staff = new Employee[10];
Employee e1 = new Employee("Dilbert");
staff[x] = e1;
int n = find(staff, e1);

6. Generic Programming
▪ Generic collections
– ArrayList is an example class that uses Object
ArrayList al = new ArrayList();
al.add (new Employee ("Dilbert"));
al.add (new Employee ("Wally"));
al.add (new Employee ("Alice"));
Iterator i = al.iterator();
Employee e;
while (i.hasNext())
{
e = (Employee)i.next();
System.out.println(e.getName());
}
Dilbert
Wally
Alice

7. Generic Programming
▪ Generic collections
– The Collections class is another example
List<Employee> list = new ArrayList<Employee>();
list.add (new Employee ("Dilbert"));
list.add (new Employee ("Wally"));
list.add (new Employee ("Alice"));
Collections.sort(list);
for (Employee e: list)
{
System.out.println(e);
}
Alice
Dilbert
Wally

8. REFLECTION

9. Reflection
▪ Reflection allows examination and manipulation of objects at
runtime
– Get information about a class
• Fields, methods, constructors, and super classes
• Constants and method declarations belong to an interface
– Create an instance of a class whose name is not known until
runtime
– Get and set the value of an object's field, even if the field
name is unknown to your program until runtime
– Invoke a method on an object, even if the method is not
known until runtime

10. Reflection
static void showMethods(Object o)
{
Class c = o.getClass();
Method[] theMethods = c.getMethods();
for (int i = 0; i < theMethods.length; i++) {
String methodString = theMethods[i].getName();
System.out.println("Name: " + methodString);
String returnString = theMethods[i].getReturnType().getName();
System.out.println(" Return Type: " + returnString);
Class[] parameterTypes = theMethods[i].getParameterTypes();
System.out.print(" Parameter Types:");
for (int k = 0; k < parameterTypes.length; k ++)
{
String parameterString = parameterTypes[k].getName();
System.out.print(" " + parameterString);
}
System.out.println();
}
} }

11. Bla
public class ReflectMethods
{
public static void main(String[] args)
{
Polygon p = new Polygon();
showMethods(p);
}
Name: getBoundingBox
Return Type: java.awt.Rectangle
Parameter Types:
Name: contains
Return Type: boolean
Parameter Types: java.awt.geom.Point2D
...
Name: toString
Return Type: java.lang.String
Parameter Types:
Reflection

12. ▪ Reflection is very useful in frameworks
– Infrastructure code
– “plumbing” – The “Noise”
▪ Examples
– Create Java objects from XML descriptions
– Load classes at runtime and invoke methods
– Tools and utilities for development
Reflection

13. Dynamically Loading Classes
▪ Classes can be dynamically loaded at runtime
– Offers the flexibility to decide which class to run dynamically
– Class names can be specified in configuration files
▪ Class class
Class instanceClass = Class.forName("RssFeedReader");
reader = (FeedReader)instanceClass.newInstance();

14. A) AB
B) BA
C) ABC
D) Compilation fails
QUIZ
class A
{
public A(String s)
{
System.out.print("A");
}
}
public class B extends A
{
public B(String s) {
System.out.print("B");
}
public static void main(String [] args) {
new B("C");
}
}

15. A) AB
B) BA
C) ABC
D) Compilation fails
QUIZ
✔
class A
{
public A(String s)
{
System.out.print("A");
}
}
public class B extends A
{
public B(String s) {
System.out.print("B");
}
public static void main(String [] args) {
new B("C");
}
}

16. SOFTWARE DESIGN PRINCIPLES

17. Software Design Principles
Software development has over the years established a
set of principles that apply to building software
Separation of Concern
Coupling
Cohesion
Information Hiding

18. Separation of Concern
The process of dividing the application into distanct
units without overlapping
Concern can be feature, functionality, point of interest,
data, or process
Allows for changing one area without affecting other
areas
Examples: Presentaion, Domain, Data Source
Model View Controller
HTML, CSS, JavaScript

19. Separation of Concern
Divide by Feature - vertical
Customer Wallet
Single
Sign-on
Single
Sign-on
Logging Security Session I18N Caching
Cross-
cutting
concerns

20. Coupling
Refers to the degree of dependence between objects
The objective is to assign responsibility to classes so
that coupling is low
If coupling is high, any
change becomes difficult
Loosely coupled systems
are easier and cheaper to
maintain
Goal is: Low Coupling

21. Cohesion
Refers to the degree to which the elements of a module
belong together
measures the strength of
relationship between pieces
of functionality within
a given module.
In highly cohesive systems
functionality is strongly
related
Goal is: High Cohesion

22. SOFTWARE DESIGN IN ACTION

23. Object Oriented Design
▪ Design and implementation of software needs to be of quality
– Badly designed, well implemented = problem!
– Well designed, badly implemented = problem!
CODE
HORROR!!
CODE HORROR DUDE

24. Object Oriented Design
Good design
Is based on OO principles
Abstracts complex APIs such as J2EE
Is flexible and can be changed
Contains loosely coupled components

26. Example from Head First Design Patterns

27. Getting Started
SimUDuck is highly successful duck pond simulation game
Original design
MallardDuck
display() { }
Duck
quack
swim
display
// other methods
RedHeadDuck
display() { }

28. Change Request!
But now we need the ducks to FLY
MallardDuck
display() { }
Duck
quack
swim
display
// other methods
RedHeadDuck
display() { }

29. Change Request!
Ok just add the fly method to Duck
MallardDuck
display() { }
Duck
quack
swim
display
fly
// other methods
RedHeadDuck
display() { }

30. Problem!
But not all duck fly – We forgot Rubber Duck!
MallardDuck
display() { }
Duck
quack
swim
display
fly
// other methods
RedHeadDuck
display() { }
RubberDuck
display() { }

31. How can we fix this?
Just override fly to do nothing
MallardDuck
display() { }
Duck
quack
swim
display
fly
// other methods
RedHeadDuck
display() { }
RubberDuck
quack() {
// squeck
}
fly() {
// do nothing
}

32. We even think ahead
We fix all non-flyable and non-quackable ducks as well
Duck
quack
swim
display
fly
// other methods
RedHeadDuck
display() { }
RubberDuck
quack() {
// squeck
}
fly() {
// do nothing
DecoyDuck
quack() {
// no sound
}
fly() {
// do nothing
Code smell!
MallardDuck
display() { }

33. Which of the following are disadvantages of using inheritance to
provide Duck behaviour?
A) Code is duplicated across subclasses
B) Runtime behaviour changes are difficult
C) We can’t make ducks dance
D) Hard to gain knowledge of all duck behaviours
E) Ducks can’t fly and quack at the same time
F) Changes can unintentionally affect other ducks
QUIZ

34. Which of the following are disadvantages of using inheritance to
provide Duck behaviour?
A) Code is duplicated across subclasses
B) Runtime behaviour changes are difficult
C) We can’t make ducks dance
D) Hard to gain knowledge of all duck behaviours
E) Ducks can’t fly and quack at the same time
F) Changes can unintentionally affect other ducks
QUIZ
✔
✔
✔
✔

35. The Problem
▪ The problem is this
– Derived classes (RubberDuck) are forced to inherit
behaviour they don’t have
– Derived classes (RubberDuck) needs to be exposed to the
inner workings of the superclass (Duck)
– Users of the base class (Duck) should expect same
functionality
– Violation of the Liskov Substitution Principle

36. Subtypes must be substitutable for
their base types. Code that uses
references to base class must be
able to use objects of derived
classes without knowing it.
Liskov Substitution Principle

37. Trying to fix the Problem
Let’s try using interfaces! Flyable and Quackable
MallardDuck
display() { }
fly() { }
quack() { }
Duck
swim
display
// other methods
RedHeadDuck
display() { }
fly() { }
quack() { }
RubberDuck
display() { }
quack() {
// squeck
}
DecoyDuck
Code
duplication!
Flyable
fly
Quackable
quack
display() { }

38. What is the Problem?
▪ We tried this
– Inheritance changes all subcasses
– Interfaces cause code duplication
▪ The problem is we are mixing different types of code in one
type of classes
▪ Fix
– Separate Variation Design Principle
– Take what varies and encapsulate it so it wont affect the rest
of the code

39. Separate Variations Design Principle
Identify the aspects of your
application that vary and separate
them from what stays the same

40. fly
behaviour
fly
behaviour
Separation of Concerns
FlyWithWings flyBehavior = new FlyWithWings();
DATA TYPE IS TOO SPECIFIC
Duck
class
▪ Separate what changes from what stays the same
– Move duck behaviour to a separate class
fly
behaviour
quack
behaviour
quack
behaviour
quack
behaviour
Duck Behaviours

41. fly
behaviour
fly
behaviour
Separation of Concerns
Duck
class
▪ Duck classes cannot use the concrete behaviour classes!
▪ We need an interface or supertype
fly
behaviour
quack
behaviour
quack
behaviour
quack
behaviour
Duck Behaviours
FlyBehaviour
<interface>
FlyBehavior flyBehavior = new FlyWithWings();
INTERFACE - POLYMORPHISIM

42. The Interface Design Principle (GoF)
Program to an interface, not an
implementation

43. Loose Coupling with Interfaces
▪ Advantages
– The ability to change the implementing class of any
application object without affecting calling code
– Total freedom in implementing interfaces
– The ability to provide simple test implementations and stub
implementations of application interfaces as necessary

44. Program to Interfaces
Program to an implementation
Program to interface/subtype
Program to unknown creation
Dog d = new Dog();
d.bark();
Animal animal = new Dog();
animal.makeSound();
Animal animal = getAnimal();
animal.makeSound();
We are making
classes
responsible for
their
dependencies

45. Program to Interfaces
Another way is to make the caller responsible for setting the
dependency
class Zoo {
private Animal animal;
public setAnimal(Animal animal)
{
this.animal = animal;
}
...
animal.makeSound();
Injection
happens here
Dependency Injection Design Pattern

46. Implementing Behaviour
We can add new behaviour without touching the Duck classes
FlyWithWings
fly() { }
FlyBehaviour
<interface>
fly();
FlyNoWay
fly() { }
Quack
quack() { }
QuackBehaviour
<interface>
quack();
Squeak
quack() { }
implements implements

47. Integrating Behaviour
The Duck classes will now delegate its flying and
quacking behaviour
Duck
QuackBehaviour quackBehaviour;
FlyBehaviour flyBehaviour;
swim() { }
display() { }
performQuack() { }
performFly() { }
Behaviour Interfaces
Performing the behaviour

48. Integrating Behaviour
The Duck classes will now delegate its flying and
quacking behaviour
public class Duck
{
QuackBehavior quackBehavior;
...
public void performQuack()
{
quackBehavior.performQuack()
}
}
We don’t care what this object is
behind the interface, we just call it

49. Integrating Behaviour
But how do we set the behaviour classes?
public class MallardDuck extends Duck
{
public MallardDuck()
{
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
}
This is not
programming to
interfaces!

50. Setting the Behaviour Dynamically
Use Dependency Injection - make the caller responsible
Add two new methods to the Duck class
QuackBehavior quackBehavior;
FlyBehavior flyBehavior;
public void setFlyBehavior(FlyBehavior flyBehavior)
{
this.flyBehavior = flyBehavior
}
public void setQuackBehavior(QuackBehavior quackBehavior)
{
this.quackBehavior = quackBehavior
}
DuckFactory
{
public Duck getMallardDuck()
{
Duck duck = new MallardDuck()
duck.setFlyBehavior(new FlyWithWings());
duck.setQuackBehavior(new Quack());
return duck;
}
}
This is an
assembler class

51. Setting the Behaviour Dynamically
Use Dependency Injection - make the caller responsible
Creating systems using composition give flexibility
You can change the behaviour at runtime
The idea: Don´t think: Mallard is-a flying duck, think: it has-a
flying behaviour
Put two classes together using composition
One is member in the other

52. The Composition Design Principle (GoF)
Favour composition over inheritance

53. Object Composition
Problems with concrete inheritance
Class hierarchies are rigid
Difficult to change the implementation
Object Composition is more flexible
Allows the behaviour of an object to be altered at run
time, through delegating part of its behaviour to an
interface and allowing callers to set the implementation
of that interface

54. Generic programming
Using classes, abstract classes and interfaces can lead to
powerful and flexible programs
Reflection
Powerful for building infrastructure
Design
Decouple behaviour of objects from the object them selves
Loosely coupled with interfaces and dependency injection
Program to interfaces
Favour composition over inheritance
Summary

55. Job interview question
You are given the assignment of creating a component that needs to know
sales statistics of Lottery tickets. You know that there is a another
component in the system, Sale Server, that handles the sale. You need real-
time information. What would you suggest?
EXERCISE

56. Design pattern is a general solution to a common problem in
software design
Fyrirlestur mánudaginn 31.08 er video fyrirlestur vegna
ferðalaga
Next