Nishith Shukla

Why OOP? ?

Why OOP? Take software development close to real life In real life we deal with objects, we want to deal with software the same way.

Take

software

development close

to

real life

In real life we deal with objects, we want to deal with software the same way.

Why OOP? Separation of concerns In real life we need not to worry about how an object is made or what it contains for using it.

Separation of concerns

In real life we need not to worry about how an object is made or what it contains for using it.

Why OOP? Components are replaceable In real life component of similar functionality and specification are replaceable.

Components are replaceable

In real life component of similar functionality and specification are replaceable.

Why OOP? Develop component in parts In real life developer of one component need not to worry about complete system, or how his component will be used in complete system.

Develop component in parts

In real life developer of one component need not to worry about complete system, or how his component will be used in complete system.

Why OOP? Think about structure and develop prototype before getting actual instance In real life we think about structure, we develop prototype like drawings before actually getting instance of objects.

Think about structure and develop prototype before getting actual instance

In real life we think about structure, we develop prototype like drawings before actually getting instance of objects.

Why OOP? Use and throw In real life we use component once we are done with it we discard them.

Use and throw

In real life we use component once we are done with it we discard them.

Why OOP? One component can be used (reused) in multiple systems In real life one component could be used for multiple systems.

One component can be used (reused) in multiple systems

In real life one component could be used for multiple systems.

Why OOP? Component can be pluggable In real life component could be used for multiple systems.

Component can be pluggable

In real life component could be used for multiple systems.

Why OOP? Easy to understand system In real life we can understand complex system by take top-down or bottom-up approach. Which leads us to smaller object.

Easy to understand system

In real life we can understand complex system by take top-down or bottom-up approach. Which leads us to smaller object.

What is OOP? All right, what is OOP?

What is OOP? Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions“ ; and “data” rather than “logic” .

Object-oriented programming (OOP) is a

programming language model

organized around

"objects" rather than "actions“ ;

and “data” rather than “logic” .

Pillars of OOP Encapsulation Inheritance Abstraction Polymorphism

Encapsulation

Inheritance

Abstraction

Polymorphism

Data Encapsulation class Account { public: float withdraw(); void deposit(float amount); private: float balance; );

Inheritance A class which is a subtype of a more general class is said to be inherited from it. The sub-class inherits the base class’ data members and member functions

A class which is a subtype of a more general class is said to be inherited from it.

The sub-class inherits the base class’ data members and member functions

Inheritance cont’d A sub-class has all data members of its base-class plus its own A sub-class has all member functions of its base class (with changes) plus its own Inheritance is meant to implement sub-typing

A sub-class has all data members of its base-class plus its own

A sub-class has all member functions of its base class (with changes) plus its own

Inheritance is meant to implement sub-typing

Abstraction Management of complexity Hierarchical classification: is-a relationship: inheritance has-a relationship: containment

Management of complexity

Hierarchical classification:

is-a relationship: inheritance

has-a relationship: containment

Polymorphism One interface Multiple implementations Inheritance Method overloading

One interface

Multiple implementations

Inheritance

Method overloading

OOAD Design Principals Single responsibility principal Open closed principal Liskov substitution principal Dependency inversion principal Interface segregation principal Law of Demeter Single choice principal Information hiding

Single responsibility principal

Open closed principal

Liskov substitution principal

Dependency inversion principal

Interface segregation principal

Law of Demeter

Single choice principal

Information hiding

Single responsibility principal Each responsibility should be a separate class, because each responsibility is an axis of change. A class should have one, and only one, reason to change. If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.

Each responsibility should be a separate class, because each responsibility is an axis of change.

A class should have one, and only one, reason to change.

If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.

Open closed principal A class should be open for extension but closed for modification. This prevents you from introducing new bugs in existing code. If you never change it, you can't break it.

A class should be open for extension but closed for modification.

This prevents you from introducing new bugs in existing code. If you never change it, you can't break it.

Liskov substitution principal Instance of subtype should be able to replace instance of base class without doing any change in the application using base class. If not then, class hierarchy would be mess. If not then, unit test for super class (base class) will fail for subclass.

Instance of subtype should be able to replace instance of base class without doing any change in the application using base class.

If not then, class hierarchy would be mess.

If not then, unit test for super class (base class) will fail for subclass.

Dependency inversion principal Abstractions should not depend upon details. Details should depend upon abstractions.

Abstractions should not depend upon details.

Details should depend upon abstractions.

Interface segregation principal The dependency of one class to another one should depend on the smallest possible interface.

The dependency of one class to another one should depend on the smallest possible interface.

Law of Demeter Only talk to your immediate friends. E.g. one never calls a method on an object you got from another call nor on a global object. This help in avoiding communication havoc between objects.

Only talk to your immediate friends.

E.g. one never calls a method on an object you got from another call nor on a global object.

This help in avoiding communication havoc between objects.

Single choice principal The exhaustive list of alternatives should live in exactly one place. For example there is drawing application which draws circle, rectangle and square. Than selection between these three should be written in code at only one place.

The exhaustive list of alternatives should live in exactly one place.

For example there is drawing application which draws circle, rectangle and square. Than selection between these three should be written in code at only one place.

Information hiding The basic idea is that if a object doesn't really need to know something about how another object does some job, don't make it know it. So that if first object change its internal methods, another objects are not effected.

The basic idea is that if a object doesn't really need to know something about how another object does some job, don't make it know it. So that if first object change its internal methods, another objects are not effected.

Uncovered principal Reuse release equivalence principal Common closure principal Common reuse principal Acrylic dependency principal Stable dependency principal Stable abstraction principal

Reuse release equivalence principal

Common closure principal

Common reuse principal

Acrylic dependency principal

Stable dependency principal

Stable abstraction principal

Nishith Shukla

Creational Patterns Factory Abstract Factory Builder Prototype Singleton

Factory

Abstract Factory

Builder

Prototype

Singleton

Factory method Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

Factory method

Factory method public IDocument CreateDocument(String type) { if (type.isEqual("html")) return new HtmlDocument(); if (type.isEqual(“word")) return new WordDocument(); if (type.isEqual("pdf")) return new PDFDocument (); }

public IDocument CreateDocument(String type)

{ if (type.isEqual("html")) return new HtmlDocument(); if (type.isEqual(“word")) return new WordDocument(); if (type.isEqual("pdf")) return new PDFDocument (); }

Factory method It introduce separation between application and family of classes. It provides a simple way of extending the family of products. If objects are created directly in application, its hard to replace/change them. The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory method design pattern.

It introduce separation between application and family of classes.

It provides a simple way of extending the family of products.

If objects are created directly in application, its hard to replace/change them.

The factory has to be used for a family of objects. If the classes doesn't extend common base class or interface they can not be used in a factory method design pattern.

Abstract Factory Pattern Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Laptop factory Desktop factory Laptop MB Desktop MB Mother Board Product Keyboard Laptop KB Desktop KB

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Abstract Factory Pattern

Abstract Factory Pattern When to use: The system needs to be independent from the way the products works which are created The system is or should be configured to work with multiple families of products A family of products is designed to work only all together The creation of a library of products is needed, for which is relevant only the interface, not the implementation.

When to use:

The system needs to be independent from the way the products works which are created

The system is or should be configured to work with multiple families of products

A family of products is designed to work only all together

The creation of a library of products is needed, for which is relevant only the interface, not the implementation.

Builder Pattern Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Builder Pattern

Builder Pattern When to use: The creation algorithm of a complex object is independent from the parts that actually compose the object The system needs to allow different representations for the objects that are being built

When to use:

The creation algorithm of a complex object is independent from the parts that actually compose the object

The system needs to allow different representations for the objects that are being built

Difference between Builder and Abstract Factory Builder builds one complex object through several method calls. With Abstract Factory, every method call returns its own little object. Abstract Factory allows to decide which object to create runtime, where as builder is design time decided about which complex object to construct. Builder can be instructed on how to create object, Abstract factory is instructed on which object to be created.

Builder builds one complex object through several method calls. With Abstract Factory, every method call returns its own little object.

Abstract Factory allows to decide which object to create runtime, where as builder is design time decided about which complex object to construct.

Builder can be instructed on how to create object, Abstract factory is instructed on which object to be created.

Prototype Pattern Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.

Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.

Prototype Pattern

Prototype Pattern When to use: If the cost of creating a new object is large and creation is resource intensive, we clone the object. Classes to be instantiated are specified at run-time Avoiding the creation of a factory hierarchy is needed It is more convenient to copy an existing instance than to create a new one

When to use:

If the cost of creating a new object is large and creation is resource intensive, we clone the object.

Classes to be instantiated are specified at run-time

Avoiding the creation of a factory hierarchy is needed

It is more convenient to copy an existing instance than to create a new one

Singleton Pattern Ensure a class has only one instance and provide a global point of access to it.

Ensure a class has only one instance and provide a global point of access to it.

Singleton Pattern private Logger () { ……… } public static Logger GetLogger() { if (instance == null) instance = new Logger(); return instance; }

private Logger ()

{

………

}

public static Logger GetLogger()

{

if (instance == null) instance = new Logger();

return instance;

}

Singleton Pattern When to use: When only single instance is required to be created for an object. Object’s methods does not depend on instance of object. Singleton pattern can also be achieved by using static class.

When to use:

When only single instance is required to be created for an object.

Object’s methods does not depend on instance of object.

Singleton pattern can also be achieved by using static class.

Structural Pattern Adapter Bridge Composite Decorator Facade Flyweight Proxy

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

Behavioral Pattern Chain of Responsibility Command Interpreter Repeater Observer Visitor State

Chain of Responsibility

Command

Interpreter

Repeater

Observer

Visitor

State

Questions? ?

Further references Online http://www.oodesign.com http://www.programmersheaven.com http://www.dofactory.com Books