Object- oriented Design Principles

1
Object- oriented Design Principles
2
The pyramid of OO
Abstract/ Philosophical
Practical
3
Object-orientation is good!
4
Object-orientation is good?
5
Object-orientation is good (?)

• Why are we learning about object-orientation in
  the first place?
• Other paradigms for programming exist, for
  instance functional programming and logic
  programming
• However, OO is currently the dominating paradigm
  for programming more or less an industry
  standard

6
Object-orientation is good!

• Object-orientation has proven to be a friutful
  way of connecting real life and software
  development
• However, there are certain rules to obey when
  playing the OO-game
• At the top, we rely on a few Object-Oriented
  concepts

7
Object-oriented concepts

• Abstraction
• Encapsulation
• Polymorphism
• Inheritance
• (Composition)

8
Abstraction

• The idea that we focus only on the essence of a
  concept
• Inessential details are abstracted away
• Abstraction works at multiple levels
• Can be a challenge to find the appropriate level
  of abstraction
• Abstractions are manifested through interfaces,
  which define behaviors

9
Encapsulation

• The idea not to expose details about how
  behaviors are achieved
• Concepts are considered black boxes
• This enables us to change how behaviors are
  achieved, without affecting the user of a
  particular concept

10
Polymorphism

• The idea that concrete instances of a behavior
  can take many forms
• All animals can eat but do so in very different
  ways
• Eating is polymorphic behavior it can take many
  forms, but has the same essence
• Allows us to focus on the essence of the
  behavoir, neglecting actual behaviors

11
Inheritance

• The idea that concepts can inherit behaviors from
  other, more general concepts
• Allows us to reuse behaviors that have previously
  been defined
• We can easily define hierarchies of related
  concepts, only needing to add genuinely new
  behaviors

12
Composition

• The idea that new concepts can be com-posed by
  combining existing concepts
• A supplement/alternative to inheritance
• A different approach to reuse
• Composition helps us realise has-a relations
  between concepts, inheritance is used for is-a
  relations

13
Fine, but

• The OO-concepts are nice, but not particularly
  operational
• We need something more concrete
• The OO-principles provide more specific guidelines

14
The Object-oriented principles

• 1. Encapsulate the aspects of your application
  that vary
• 2. Favor composition over inheritance
• 3. Program to an interface, not an implementation
• 4. Strive for loose couplings between objects
  that interact
• 5. Make classes open for extension, closed for
  modification
• 6. Depend on abstractions, not concrete classes
• 7. Only talk to your closest friends
• 8. Dont call us, well call you
• 9. A class should only have one reason to change

15
OO principles

• Where do these principles come from?
• Not from proofs or theory
• Condensed best practices from real life
• Principles are to some extent overlapping

16
OO principles

• Encapsulate the aspects of your applica-tion
  that vary
• Promotes reusability
• When designing classes for a system of concepts,
  put the varying elements into separate classes
• Can be realised both through inheritance and
  composition, often using interfaces

17
OO principles

• Favor composition over inheritance
• Turns out that composition often but not always
  enables us to design more flexible systems
  (couplings are weaker)
• Systems can also be more dynamic we can change
  configurations during run-time
• We shall see examples later

18
OO principles

• Program to an interface, not an imple-mentation
• An essential idea if we know the interface, we
  do not need to know any details about a specific
  implementation (weak coupling)
• Allows us the change the implementation without
  affecting the user
• This is more or less encapsulation

19
OO principles

• Strive for loose couplings between objects that
  interact
• We like loose couplings ?
• Loose couplings promotes modularity and reuse of
  classes
• We usually achieve this by relying on inter-faces
  rather than specific implementations
• Yet another facet of the same jewel

20
OO principles

• Make classes open for extension, closed for
  modification
• Very important principle!
• Once we have a well-documented, well-tested
  class, we should not change it!
• If we need more functionality, achieve it through
  extension, using inheritance and/or composition
• Keep classes as pure as possible

21
OO principles

• Depend on abstractions, not concrete classes
• Variation over Program to an interface, not an
  implementation

22
OO principles

• Only talk to your closest friends
• Hmm, what does that mean?
• A typical application architecture divides
  classes into a number of layers
• Classes in one layer should only know classes in
  the next layer (loose couplings)
• Avoid reliance on the specific composition of a
  class

23
OO principles

• What is best, and why?
• double temp station.getThermometer().getTempera
  ture()
• double temp station.getStationTemperature()
• We should not rely on specifics about how a
  Station is implemented
• Only one . in a line of code

24
OO principles

• Dont call us, well call you
• The Hollywood Agent principle
• A more advanced principle instead of
  imple-menting an algorithm using a lot of calls
  to generic classes, implement a generic
  algo-rithm with plugins for specialised
  behavior
• Also known as Inversion of Control
• Encapsulate what varies

25
OO principles

• A class should only have one reason to change
• Classes should have as few responsibilities as
  possible
• Closed for modification, open for extension
• Again, low coupling is desired

26
Beyond principles

• We can use these OO principles directly when
  developing software
• Next step is Design Patterns, which describe
  designs for solving common problems, relying on
  the OO principles
• We have already seen some patterns (GRASP)