2009 training - tim m - object oriented programming


Published on

Public training given about OO

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2009 training - tim m - object oriented programming

  1. 1. OOTim Mahy
  2. 2. History• Buzz now but already old (60’s)• Structured was more populair
  3. 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. 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. 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. 6. Why OO ?• Rigid• Fragile• Not reusable• High Viscosity• Useless complexity• Repetition• Opacity
  7. 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, "dont touch a working system" – Users forced to develop workarounds
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 19. Yeah right .. show me !
  20. 20. OO is all about ..• Objects• Classes• Inheritance• Methods and messages• Encapsulation• Polymorphism• Dynamic binding
  21. 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. 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. 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. 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. 25. Polymorphism• Polymorphism: the same method name can elicit a different response depending on the receiver
  26. 26. OO can also be shitty written ! Soo.. ?
  27. 27. OO goes beyond classes, objects ..• Open-Closed Principle• Liskov Substitution Principle• Dependency Inversion Principle• Interface Segregation Principle• Single-Responsibility Principle• Design Patterns
  28. 28. Open-Closed PrincipleA 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. 29. Liskov Substitution PrincipleSubclasses 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. 30. Dependency Inversion PrincipleDepend 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. 31. Interface Segregation PrincipleMany 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. 32. Single-Responsibility PrincipleA 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. 33. Design patterns• GoF• Design by contract, not by implementation !
  34. 34. Never let your software smell !