2009 training - tim m - object oriented programming
History• Buzz now but already old (60’s)• Structured was more populair
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
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
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
Why OO ?• Rigid• Fragile• Not reusable• High Viscosity• Useless complexity• Repetition• Opacity
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
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
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
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
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
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
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?
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 !
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
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
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
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
OO is all about ..• Objects• Classes• Inheritance• Methods and messages• Encapsulation• Polymorphism• Dynamic binding
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
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
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
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
Polymorphism• Polymorphism: the same method name can elicit a different response depending on the receiver
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.
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?
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?
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.
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!
Design patterns• GoF• Design by contract, not by implementation !