Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Oo Design And Patterns


Published on

A brief talk explaining the benefits of OO design and some important OO design patterns

Published in: Technology
  • Be the first to comment

Oo Design And Patterns

  1. 1. OO Design and Patterns Anil Bapat
  2. 2. What is OO Design? <ul><li>Software design that is organized around objects, rather than functions </li></ul><ul><li>Design that uses the techniques of – </li></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul><ul><ul><li>Polymorphism </li></ul></ul>
  3. 3. C++ - An OO Programming Language <ul><li>Since C++ has explicit support for all the OO mechanisms, it’s called an OO language </li></ul><ul><ul><li>Abstraction and Encapsulation (Classes) </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul><ul><ul><li>Polymorphism (Dynamic binding via virtual functions) </li></ul></ul>
  4. 4. C++ - A Multi-paradigm language <ul><li>The power of C++ is that it supports multiple programming paradigms </li></ul><ul><ul><li>OO programming </li></ul></ul><ul><ul><li>Structured programming (C style) </li></ul></ul><ul><ul><li>Generic Programming (Templates) </li></ul></ul><ul><li>So, a developer could mix and match these techniques as appropriate in the same product </li></ul>
  5. 5. Abstraction <ul><li>Focus on relatively stable operations/services rendered by a concept rather than ‘How’ these operations/services are rendered </li></ul><ul><li>Allows one to model software based on high level details, without getting bogged down too early with the nitty-gritty details </li></ul><ul><li>C++ classes provide support for abstraction </li></ul>
  6. 6. Encapsulation <ul><li>Encapsulation means data hiding or hiding the implementation details </li></ul><ul><li>A class can just expose the services/operations rendered by it and hide all the implementation details via access control mechanisms (public/private/protected) </li></ul><ul><li>Encapsulation enforces abstraction </li></ul>
  7. 7. Example: Fast path Lookup abstraction <ul><li>Define a Lookup abstraction that returns the required data given the key (GRE key/ IP Address) </li></ul><ul><li>Start with a simple implementation of using a lock to access the shared data (AVL tree) </li></ul><ul><li>Change the data structure from an AVL tree to a hash table for faster random access of nodes </li></ul><ul><li>Enhance the lookup implementation to use caching and lock free mechanisms later in the cycle, without impacting the users of this abstraction </li></ul>
  8. 8. Classes <ul><li>C++ classes enable abstraction and encapsulation </li></ul><ul><li>Improves cohesion by grouping together data and operations on the data together </li></ul><ul><li>Reduces coupling by hiding implementation details and having software depend only upon operations/services rendered by classes and not on specific implementations </li></ul>
  9. 9. Classes - contd <ul><li>Reduces bugs </li></ul><ul><ul><li>CTOR/DTOR ensures initialization and cleanup of data, rather than depend upon the users to do this. Imagine having to call cleanup of a stack variable in each return path </li></ul></ul><ul><ul><li>Copy semantics embedded in the class itself leading to reduced memory leaks and corruptions </li></ul></ul><ul><ul><li>Easier to fix bugs – A missed out deep copy of a struct member, has to be changed in one place, rather than having to search where all this has to be done </li></ul></ul><ul><ul><li>Easy to enforce policies to prevent misuse {Eg: If a string class wants to prevent comparison with a character, it could hide the operator==(char& c)} </li></ul></ul>
  10. 10. Classes (Contd) <ul><li>Facilitates code reuse </li></ul><ul><ul><li>A date class contains code related to comparing 2 dates (<,>,== operators), checking for leap year, printing dates (<< operator) etc. If date were a struct we could end up with users of this struct duplicating these code lines at several places </li></ul></ul><ul><ul><li>Classes could further be reused via inheritance or composition by other classes </li></ul></ul>
  11. 11. Inheritance and Polymorphism <ul><li>Models the ‘Is-a-kind-of’ relationship between classes </li></ul><ul><li>Enables specialization of existing concepts by reusing existing concepts and ‘Adding’ stuff </li></ul><ul><li>Polymorphism is the enabler of the key concept of OO – ‘OLD code can call NEW code’ </li></ul><ul><li>High level policies and Implementations both depend upon stable abstractions, thus yielding flexible software (Dependency Inversion) </li></ul><ul><li>Makes software extensible/modifiable without having to change existing code </li></ul>
  12. 12. Socket Framework <ul><li>Abstractions: SocketClient, SocketServer and SocketConnection </li></ul><ul><li>Implementation: select/poll loop </li></ul><ul><li>SocketClient and SocketServer are both factories that create a SocketConnection instance when the socket connection is established </li></ul><ul><li>Inheritance propagates connect/accept functions to all subclasses </li></ul>
  13. 13. Benefits of OO design <ul><li>Is more intuitive. The objects we deal with in the real world have both attributes and behavior, just like classes and we keep abstracting things all the time </li></ul><ul><li>Enables rapid prototyping and iterative development of software </li></ul><ul><li>Supports code reuse via classes, inheritance, composition and polymorphism </li></ul><ul><li>Leads to software that can be easily modified or changed (Easy maintenance) </li></ul><ul><li>Allows for late cycle performance enhancements </li></ul>
  14. 14. Key step for OO project success <ul><li>Identifying the right abstractions. </li></ul><ul><li>Know the domain very well, so that concepts that are stable could be identified as ‘Abstractions’ and things that could change be encapsulated away behind abstract interfaces (Eg: specific Protocols/Hardware details etc) </li></ul>
  15. 15. Design Patterns <ul><li>Commonly used design techniques described in abstract terms so they can be applied to any field </li></ul><ul><li>“ Reuse of Knowledge” as opposed to reuse of code </li></ul><ul><li>The “GoF book” introduced the concept and has ever since been the bible on this topic </li></ul>
  16. 16. Some Useful Design Patterns <ul><li>Singleton </li></ul><ul><li>State </li></ul><ul><li>Factory </li></ul><ul><li>Publish/Subscribe or Observer </li></ul><ul><li>Wrapper facade </li></ul><ul><li>Reactor </li></ul><ul><li>Proxy </li></ul><ul><li>Scoped Locking </li></ul>
  17. 17. Singleton <ul><li>Ensure that a class has a single instance </li></ul><ul><li>Provide a global point of access to the single instance of the class </li></ul><ul><li>Double checked locking for Singletons </li></ul><ul><li>Use templates to hold single instance, to reuse code </li></ul>
  18. 18. State <ul><li>Avoids long nested switch-cases and makes large state machine code more readable </li></ul><ul><li>Easy to introduce new states in state machines </li></ul><ul><li>Each state object needs to implement only subset of event handlers. Unhandled events fallback to base class handlers </li></ul>
  19. 19. Factory <ul><li>If some high level logic depends only upon abstractions, it should not depend upon concretions even for object creation </li></ul><ul><li>Have an abstract interface for object creation and have all logic use this interface for object creation, rather than have if-else logic at all places where an object instance is to be created </li></ul><ul><li>Eg: SocketConnector and SocketAcceptor in the Socket framework? </li></ul>
  20. 20. Publish/Subscribe <ul><li>Loose (Abstract) coupling between subjects and observers </li></ul><ul><li>Adding new observers doesn’t need any change in Subject code </li></ul><ul><li>Eg: T1Link (Subject) and Callp/Alarms (Observers). Remove Callp and add ISUP protocol module as observer, add 1 more observer (ISDN protocol module) – No change required in the ‘Subject’ (T1 Link) that notifies all subscribers about events </li></ul>
  21. 21. Wrapper facade <ul><li>Provide an higher level interface class to a set of functions/operations that always happen together </li></ul><ul><li>Eg: SocketServer façade – Do the calls – socket(), bind(), listen, and accept() together. </li></ul><ul><li>Hides users from the devilish things like htons on the port, calling these functions in the right order, without missing any call etc </li></ul>
  22. 22. Reactor <ul><li>Encapsulates the “select loop” </li></ul><ul><li>Could internally incorporate select/poll without having any impact on users (FDs > 1024 not supported by select) </li></ul><ul><li>Achieves OS abstraction (Can change select to WaitForMultipleObjects of NT) </li></ul><ul><li>Loose coupling between the event de-mux logic (Framework) and the applications that handle the events </li></ul>
  23. 23. Proxy <ul><li>Hide the fact that the service is being implemented in a different address space (Eg: RMI, CORBA etc implement this pattern) </li></ul><ul><li>Used to implement stuff like lazy instantiation, Copy on write etc for optimizing creation/copying of costly resources </li></ul>
  24. 24. Scoped Locking <ul><li>Automatically release locks whenever the reference to the lock is lost (function return or exception) </li></ul><ul><li>Better way to guard critical sections as it leads to more robust and maintainable code </li></ul>
  25. 25. Push to Talk server design <ul><li>Example Requirements: </li></ul><ul><li>Support the Push to talk application </li></ul><ul><li>Use the ISUP protocol </li></ul><ul><li>Use a particular 3 rd party Media Card that supports H.110 interconnect of DS0s, capture of DTMFs etc </li></ul><ul><li>Generate billing records in a file in a specific format </li></ul>
  26. 26. PTT server using Functional Programming <ul><li>Consists of the PTT call control logic all using the APIs provided by the ISUP protocol stack, the 3 rd party media card and the file system APIs (For billing). </li></ul><ul><li>Smaller footprint code ideal for very small embedded devices </li></ul><ul><li>Difficult to extend or to maintain this code </li></ul>
  27. 27. How requirements change <ul><li>We would have to add support for the SIP protocol in addition to ISUP </li></ul><ul><li>We would have to support an RTP media controller in addition to the TDM media controller </li></ul><ul><li>Too much file access for the billing makes the system I/O bound and there’s a requirement to move the billing module to another card </li></ul>
  28. 28. OO design allows us to easily accommodate changes <ul><li>All of the PTT call control is coded in terms of “Abstract” interfaces </li></ul><ul><li>We can add SIP and the new media controller, both as new code that conforms to the earlier abstractions, without changing any of the existing code </li></ul><ul><li>We could “Proxy” out the billing module where the “Guts” reside on a different card </li></ul>