Public training given about OO

1. OO
Tim Mahy

2. History
• Buzz now but already old (60’s)
• Structured was more populair

3. OO vs Structured
• Programming - early 60s
Design - early 70s
Analysis - late 70s
• SA -> SD -> SP
• Separate data and behavior
• Conceptual canyon between phases
• Difficult to validate back to original analysis

4. OO vs Structured
• Programming - late 60s
Design - mid 80s
Analysis - late 80s
• OOA -> OOD -> OOP
• Incorporate data and behavior
• Smooth transition between phases
• Validation of system back to original analysis

5. OO vs Structured
• Programming - late 60s • Programming - early 60s
Design - mid 80s Design - early 70s
Analysis - late 80s Analysis - late 70s
• OOA -> OOD -> OOP
• SA -> SD -> SP
• Incorporate data and
behavior • Separate data and
behavior
• Smooth transition
between phases • Conceptual canyon
between phases
• Validation of system back
to original analysis
• Difficult to validate back
to original analysis

6. Why OO ?
• Rigid
• Fragile
• Not reusable
• High Viscosity
• Useless complexity
• Repetition
• Opacity

7. Why OO ? - Rigid
• Difficulties with changes
– Unforeseen side effects occur frequently
– Hard to estimate time to complete modifications
• "Roach Motel"
– Always in need of more effort
• Management reluctant to allow changes
– Official rigidity, "don't touch a working system"
– Users forced to develop workarounds

8. Why OO ? - Fragil
• Small changes have large side effects
– New bugs appear regularly
– In the limit of P(bug|change) = 1 system is
impossible to maintain
• It looks like control has been lost
– Users become critical
– Program looses credibility
– Developers loose credibility

9. Why OO ? - Not Reusable
• You have a problem and find some piece of
code which might solve it
– but it brings in a lot of other stuff
– it needs changes here and there
• Eventually you have two choices
– Take over maintainance of the branched code
– Roll your own
• You would like to include headers and link a
library maintained by somebody else

10. Why OO ? – High Viscosity
• Viscosity of the design
– Hard to make changes properly, i.e. without
breaking the design → make hacks instead
• Viscosity of the environment
– Slow and inefficient development environment
– Large incentive to keep changes localised even if
they break designs
– Design changes are very difficult

11. Why OO ? – Useless Complexity
• Design/code contains useless elements
• Often for anticipated changes or extension
– May pay off
– Meanwhile makes design/code harder to
understand
• Or leftovers of previous design changes?
– Time for a clean-up
• Trade-off between complexity now and
anticipated changes later

12. Why OO ? - Repetition
• Added functionality using cut-and-paste
– Then slight modifications for local purpose
• Find same structure repeatedly
– More code
– Harder to debug and modify
• There is an abstraction somewhere
– Refactor into function/method
– Create class(es) to do the job

13. Why OO ? - Opacity
• Design/code difficult to understand
– We have all suffered ...
– What is clear now may seem strange later
• Ok when its your code
– You suffer in silence
• Not acceptable in collaboration
– Need to code clearly, may need to rearrange
– Code reviews?

14. OO can solve it !
• Code is less rigid
• Code is less fragile
• Reuse is possible
• Viscosity is low
• When well implemented, OO is not the silver
bullet !

15. OO can solve it – Less rigid code
• Modules can be interchanged
• Changes are confined to a few modules
• Cost of changes can be estimated
• Changes can be planned and scheduled
• Management is possible

16. OO can solve it – Less fragile code
• Confined changes mean P(bug|change) is
small
• New bugs will most likely appear where the
changes was made, i.e. localised
– Easier to fix (hopefully)
• Risk of changes can be estimated
• Credibility of code and developers conserved

17. OO can solve it – Reuse code
• A module can be used in a different context
without changes
– Just use headers and link a library
• No need to compile and/or link lots of
unrelated stuff

18. OO can solve it – Less viscosity
• Design is easy to modify
– No quick hacks needed
– Proper design improvements will actually happen
• Large scale changes affecting many modules
are possible
– Reasonable compile and link times for the whole
system
– May depend on adequate hardware as well

19. Yeah right .. show me !

20. OO is all about ..
• Objects
• Classes
• Inheritance
• Methods and messages
• Encapsulation
• Polymorphism
• Dynamic binding

21. Object and classes
• An object is some private data and a set of
operations that can access that data
• Contains both data (what it knows) and
behavior (what it can do)
• Attributes: what an object knows (about
itself)
• Methods: what an object can do
• Instance: a particular object == an object
• Identity: each instance is unique, even if very
similar

22. Encapsulation
• Encapsulation means an object’s data (attributes)
is hidden within, and protected by, a shell of
procedures (methods)
• Also known as information hiding
• Methods allow for hiding of information by
concealing the way in which an object satisfies a
request
• When we send a message, we do not know how
or where it will be satisfied
• The interface is public; the internals are private

23. Methods and Messages
• A method is what an object can do; a specific
implementation of an operation by a
particular object
• A message is a command by one object/class
for another object/class to perform an
operation; it is the communication among
objects/classes

24. Inheritance
• A relationship among classes wherein one
class shares the structure or behavior defined
in one (single inheritance) or more (multiple
inheritance) other classes.
• Based on a hierarchical (IS-A) relationship

25. Polymorphism
• Polymorphism: the same method name can
elicit a different response depending on the
receiver

26. OO can also be shitty written ! Soo.. ?

27. OO goes beyond classes, objects ..
• Open-Closed Principle
• Liskov Substitution Principle
• Dependency Inversion Principle
• Interface Segregation Principle
• Single-Responsibility Principle
• Design Patterns

28. Open-Closed Principle
A module (class) should be open for extension but
closed for modification (originally by Bertrand
Meyer).
• Classes should be written so that they can be
extended without requiring modification.
• This allows one to change what a class does
without changing the class’s source code.
• To extend the behaviour of a system (in response
to a requested change) add new code, don’t
modify existing code.
• Abstraction (and subtype polymorphism) are the
keys to the Open Closed Principle.

29. Liskov Substitution Principle
Subclasses should be substitutable for their base classes.
(originally by Barbara Liskov)
• A user of a base class instance should still function if
given an instance of a derived class instead.
• “A derived class should have some kind of specialized
behavior (it should provide the same services as the
superclass, only some, at least, are provided
differently.)”
• The contract of the base class must be honored by the
derived class. (See Design by Contract in Lecture 2.)
• If this principle is violated, then it will cause the Open-
Closed Principle to be violated also. Why?

30. Dependency Inversion Principle
Depend upon abstractions. Do not depend upon concrete
implementations (originally defined by Martin).
• High level classes should not depend on low level classes.
• Abstractions should not depend upon the details.
• If the high level abstractions depend on the low level
implementation details, then the dependency is inverted from what
it should be.
• High level classes should contain the “business logic”, low level
classes should contain the details of the (current) implementation.
• Access instances using interfaces or abstract classes to avoid
dependency inversion.
If higher levels of the application are not going to depend
on particular, low level implementations, how does one
construct the necessary low level implementations?

31. Interface Segregation Principle
Many client-specific interfaces are better than one general
purpose interface. (Martin)
• If you have a class with several different uses, create
separate (narrow) interfaces for each use.
• The alternative is that all uses share the same, large
interface (and most uses will need only a small number of
the methods.)
• Instead the uses of the class can be organized as groups of
related methods, each of which serves a different purpose.
Each of these groups becomes a separate interface.
• The purpose is to make clients use as small and as coherent
an interface as possible.
• Fat interfaces lead to inadvertent couplings and accidental
dependencies between classes.

32. Single-Responsibility Principle
A class should have only one reason to change
(originally by Martin).
• A responsibility is “a reason for change.”
• The responsibilities of a class are axes of
change. If it has two responsibilities, they are
coupled in the design, and so have to change
together.
• Simple, yet hard to get right.
• Hint: delegate, delegate, delegate!

33. Design patterns
• GoF
• Design by contract, not by implementation !

34. Never let your software smell !