OO Design and Patterns Anil Bapat

What is OO Design? Software design that is organized around objects, rather than functions Design that uses the techniques of – Abstraction Encapsulation Inheritance Polymorphism

Software design that is organized around objects, rather than functions

Design that uses the techniques of –

Abstraction

Encapsulation

Inheritance

Polymorphism

C++ - An OO Programming Language Since C++ has explicit support for all the OO mechanisms, it’s called an OO language Abstraction and Encapsulation (Classes) Inheritance Polymorphism (Dynamic binding via virtual functions)

Since C++ has explicit support for all the OO mechanisms, it’s called an OO language

Abstraction and Encapsulation (Classes)

Inheritance

Polymorphism (Dynamic binding via virtual functions)

C++ - A Multi-paradigm language The power of C++ is that it supports multiple programming paradigms OO programming Structured programming (C style) Generic Programming (Templates) So, a developer could mix and match these techniques as appropriate in the same product

The power of C++ is that it supports multiple programming paradigms

OO programming

Structured programming (C style)

Generic Programming (Templates)

So, a developer could mix and match these techniques as appropriate in the same product

Abstraction Focus on relatively stable operations/services rendered by a concept rather than ‘How’ these operations/services are rendered Allows one to model software based on high level details, without getting bogged down too early with the nitty-gritty details C++ classes provide support for abstraction

Focus on relatively stable operations/services rendered by a concept rather than ‘How’ these operations/services are rendered

Allows one to model software based on high level details, without getting bogged down too early with the nitty-gritty details

C++ classes provide support for abstraction

Encapsulation Encapsulation means data hiding or hiding the implementation details A class can just expose the services/operations rendered by it and hide all the implementation details via access control mechanisms (public/private/protected) Encapsulation enforces abstraction

Encapsulation means data hiding or hiding the implementation details

A class can just expose the services/operations rendered by it and hide all the implementation details via access control mechanisms (public/private/protected)

Encapsulation enforces abstraction

Example: Fast path Lookup abstraction Define a Lookup abstraction that returns the required data given the key (GRE key/ IP Address) Start with a simple implementation of using a lock to access the shared data (AVL tree) Change the data structure from an AVL tree to a hash table for faster random access of nodes Enhance the lookup implementation to use caching and lock free mechanisms later in the cycle, without impacting the users of this abstraction

Define a Lookup abstraction that returns the required data given the key (GRE key/ IP Address)

Start with a simple implementation of using a lock to access the shared data (AVL tree)

Change the data structure from an AVL tree to a hash table for faster random access of nodes

Enhance the lookup implementation to use caching and lock free mechanisms later in the cycle, without impacting the users of this abstraction

Classes C++ classes enable abstraction and encapsulation Improves cohesion by grouping together data and operations on the data together Reduces coupling by hiding implementation details and having software depend only upon operations/services rendered by classes and not on specific implementations

C++ classes enable abstraction and encapsulation

Improves cohesion by grouping together data and operations on the data together

Reduces coupling by hiding implementation details and having software depend only upon operations/services rendered by classes and not on specific implementations

Classes - contd Reduces bugs 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 Copy semantics embedded in the class itself leading to reduced memory leaks and corruptions 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 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)}

Reduces bugs

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

Copy semantics embedded in the class itself leading to reduced memory leaks and corruptions

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

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)}

Classes (Contd) Facilitates code reuse 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 Classes could further be reused via inheritance or composition by other classes

Facilitates code reuse

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

Classes could further be reused via inheritance or composition by other classes

Inheritance and Polymorphism Models the ‘Is-a-kind-of’ relationship between classes Enables specialization of existing concepts by reusing existing concepts and ‘Adding’ stuff Polymorphism is the enabler of the key concept of OO – ‘OLD code can call NEW code’ High level policies and Implementations both depend upon stable abstractions, thus yielding flexible software (Dependency Inversion) Makes software extensible/modifiable without having to change existing code

Models the ‘Is-a-kind-of’ relationship between classes

Enables specialization of existing concepts by reusing existing concepts and ‘Adding’ stuff

Polymorphism is the enabler of the key concept of OO – ‘OLD code can call NEW code’

High level policies and Implementations both depend upon stable abstractions, thus yielding flexible software (Dependency Inversion)

Makes software extensible/modifiable without having to change existing code

Socket Framework Abstractions: SocketClient, SocketServer and SocketConnection Implementation: select/poll loop SocketClient and SocketServer are both factories that create a SocketConnection instance when the socket connection is established Inheritance propagates connect/accept functions to all subclasses

Abstractions: SocketClient, SocketServer and SocketConnection

Implementation: select/poll loop

SocketClient and SocketServer are both factories that create a SocketConnection instance when the socket connection is established

Inheritance propagates connect/accept functions to all subclasses

Benefits of OO design 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 Enables rapid prototyping and iterative development of software Supports code reuse via classes, inheritance, composition and polymorphism Leads to software that can be easily modified or changed (Easy maintenance) Allows for late cycle performance enhancements

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

Enables rapid prototyping and iterative development of software

Supports code reuse via classes, inheritance, composition and polymorphism

Leads to software that can be easily modified or changed (Easy maintenance)

Allows for late cycle performance enhancements

Key step for OO project success Identifying the right abstractions. 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)

Identifying the right abstractions.

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)

Design Patterns Commonly used design techniques described in abstract terms so they can be applied to any field “ Reuse of Knowledge” as opposed to reuse of code The “GoF book” introduced the concept and has ever since been the bible on this topic

Commonly used design techniques described in abstract terms so they can be applied to any field

“ Reuse of Knowledge” as opposed to reuse of code

The “GoF book” introduced the concept and has ever since been the bible on this topic

Some Useful Design Patterns Singleton State Factory Publish/Subscribe or Observer Wrapper facade Reactor Proxy Scoped Locking

Singleton

State

Factory

Publish/Subscribe or Observer

Wrapper facade

Reactor

Proxy

Scoped Locking

Singleton Ensure that a class has a single instance Provide a global point of access to the single instance of the class Double checked locking for Singletons Use templates to hold single instance, to reuse code

Ensure that a class has a single instance

Provide a global point of access to the single instance of the class

Double checked locking for Singletons

Use templates to hold single instance, to reuse code

State Avoids long nested switch-cases and makes large state machine code more readable Easy to introduce new states in state machines Each state object needs to implement only subset of event handlers. Unhandled events fallback to base class handlers

Avoids long nested switch-cases and makes large state machine code more readable

Easy to introduce new states in state machines

Each state object needs to implement only subset of event handlers. Unhandled events fallback to base class handlers

Factory If some high level logic depends only upon abstractions, it should not depend upon concretions even for object creation 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 Eg: SocketConnector and SocketAcceptor in the Socket framework?

If some high level logic depends only upon abstractions, it should not depend upon concretions even for object creation

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

Eg: SocketConnector and SocketAcceptor in the Socket framework?

Publish/Subscribe Loose (Abstract) coupling between subjects and observers Adding new observers doesn’t need any change in Subject code 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

Loose (Abstract) coupling between subjects and observers

Adding new observers doesn’t need any change in Subject code

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

Wrapper facade Provide an higher level interface class to a set of functions/operations that always happen together Eg: SocketServer façade – Do the calls – socket(), bind(), listen, and accept() together. Hides users from the devilish things like htons on the port, calling these functions in the right order, without missing any call etc

Provide an higher level interface class to a set of functions/operations that always happen together

Eg: SocketServer façade – Do the calls – socket(), bind(), listen, and accept() together.

Hides users from the devilish things like htons on the port, calling these functions in the right order, without missing any call etc

Reactor Encapsulates the “select loop” Could internally incorporate select/poll without having any impact on users (FDs > 1024 not supported by select) Achieves OS abstraction (Can change select to WaitForMultipleObjects of NT) Loose coupling between the event de-mux logic (Framework) and the applications that handle the events

Encapsulates the “select loop”

Could internally incorporate select/poll without having any impact on users (FDs > 1024 not supported by select)

Achieves OS abstraction (Can change select to WaitForMultipleObjects of NT)

Loose coupling between the event de-mux logic (Framework) and the applications that handle the events

Proxy Hide the fact that the service is being implemented in a different address space (Eg: RMI, CORBA etc implement this pattern) Used to implement stuff like lazy instantiation, Copy on write etc for optimizing creation/copying of costly resources

Hide the fact that the service is being implemented in a different address space (Eg: RMI, CORBA etc implement this pattern)

Used to implement stuff like lazy instantiation, Copy on write etc for optimizing creation/copying of costly resources

Scoped Locking Automatically release locks whenever the reference to the lock is lost (function return or exception) Better way to guard critical sections as it leads to more robust and maintainable code

Automatically release locks whenever the reference to the lock is lost (function return or exception)

Better way to guard critical sections as it leads to more robust and maintainable code

Push to Talk server design Example Requirements: Support the Push to talk application Use the ISUP protocol Use a particular 3 rd party Media Card that supports H.110 interconnect of DS0s, capture of DTMFs etc Generate billing records in a file in a specific format

Example Requirements:

Support the Push to talk application

Use the ISUP protocol

Use a particular 3 rd party Media Card that supports H.110 interconnect of DS0s, capture of DTMFs etc

Generate billing records in a file in a specific format

PTT server using Functional Programming 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). Smaller footprint code ideal for very small embedded devices Difficult to extend or to maintain this code

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).

Smaller footprint code ideal for very small embedded devices

Difficult to extend or to maintain this code

How requirements change We would have to add support for the SIP protocol in addition to ISUP We would have to support an RTP media controller in addition to the TDM media controller 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

We would have to add support for the SIP protocol in addition to ISUP

We would have to support an RTP media controller in addition to the TDM media controller

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

OO design allows us to easily accommodate changes All of the PTT call control is coded in terms of “Abstract” interfaces 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 We could “Proxy” out the billing module where the “Guts” reside on a different card

All of the PTT call control is coded in terms of “Abstract” interfaces

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

We could “Proxy” out the billing module where the “Guts” reside on a different card