Jump start to OOP, OOAD, and Design Pattern

Slide 1: Nishith Shukla

Slide 2: W y OOP? h ?

Slide 3: W y OOP ? h Take software development close  In real life we deal with to objects, we want to deal with software the same real life way.

Slide 4: W y OOP ? h Separation of concerns  In real life we need not to worry about how an object is made or what it contains for using it.

Slide 5: W y OOP ? h Components are replaceable  In real life component of similar functionality and specification are replaceable.

Slide 6: W y OOP ? h 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.

Slide 7: W y OOP ? h Think about structure and develop prototype  In real life we think about before getting structure, we develop actual prototype like drawings before actually getting instance instance of objects.

Slide 8: W y OOP ? h Use and throw  In real life we use component once we are done with it we discard them.

Slide 9: W y OOP ? h One component can be used (reused) in  In real life one component multiple could be used for multiple systems. systems

Slide 10: W y OOP ? h Component can be pluggable  In real life component could be used for multiple systems.

Slide 11: W y OOP ? h 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.

Slide 12: W a t i s OOP? h All right, what is OOP?

Slide 13: W a t i s OOP? h Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions“; and “data” rather than “logic”.

Slide 14: Pi l l a r s o f OOP  Encapsulation  Inheritance  Abstraction  Polymorphism

Slide 15: Da t a En c a p s u l a t i o n class Account { public: float withdraw(); void deposit(float amount); private: float balance; );

Slide 16: I nhe r i t a nc e  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

Slide 17: I nhe r i t a nc e c ont ’ 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

Slide 18: Ab s t r a c t i o n  Management of complexity  Hierarchical classification: is-a relationship: inheritance has-a relationship: containment

Slide 19: Po l y mo r p h i s m  One interface  Multiple implementations  Inheritance  Method overloading

Slide 21: OOAD De s i g n Pr i n c i p a l s  Single responsibility principal  Open closed principal  Liskov substitution principal  Dependency inversion principal  Interface segregation principal  Law of Demeter  Single choice principal  Information hiding

Slide 22: Si ngl e r e s pons i bi l i t y pr i nc i pa l  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.

Slide 23: Op e n c l o s e d p r i n c i p a l  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.

Slide 24: Li s k o v s u b s t i t u t i o n pr i nc i pa l  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.

Slide 25: De p e n d e n c y i n v e r s i o n pr i nc i pa l  Abstractions should not depend upon details.  Details should depend upon abstractions.

Slide 26: I nt e r f a c e s e gr e ga t i on pr i nc i pa l  The dependency of one class to another one should depend on the smallest possible interface.

Slide 27: L a w o f De me t e r  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.

Slide 28: Si ngl e c hoi c e pr i nc i pa l  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.

Slide 29: I n f o r ma t i o n h i d i n g  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.

Slide 30: Un c o v e r e d p r i n c i p a l  Reuse release equivalence principal  Common closure principal  Common reuse principal  Acrylic dependency principal  Stable dependency principal  Stable abstraction principal

Slide 31: Nishith Shukla

Slide 32: Cr e a t i o n a l Pa t t e r n s  Factory  Abstract Factory  Builder  Prototype  Singleton

Slide 34: F a c t o r y me t h o d  Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

Slide 35: F a c t o r y me t h o d

Slide 36: F a c t o r y me t h o d 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 (); }

Slide 37: F a c t o r y me t h o d  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.

Slide 39: Ab s t r a c t F a c t o r y P a t t e r n Product Mother Board Keyboard Laptop factory Desktop factory Desktop MB Laptop MB Desktop KB Laptop KB  Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Slide 40: Ab s t r a c t F a c t o r y P a t t e r n

Slide 41: Ab s t r a c t F a c t o r y P a t t e r n  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.

Slide 43: Bu i l d e r P a t t e r n  Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Slide 44: Bu i l d e r P a t t e r n

Slide 45: Bu i l d e r P a t t e r n  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

Slide 46: Di f f e r e n c e b e t we e n Bu i l d e r a n d Ab s t r a c t F a c t o r y  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.

Slide 48: Pr o t o t y p e Pa t t e r n  Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.

Slide 49: Pr o t o t y p e Pa t t e r n

Slide 50: Pr o t o t y p e Pa t t e r n  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

Slide 52: S i n g l e t o n Pa t t e r n  Ensure a class has only one instance and provide a global point of access to it.

Slide 53: S i n g l e t o n Pa t t e r n private Logger () { ……… } public static Logger GetLogger() { if (instance == null) instance = new Logger(); return instance; }

Slide 54: S i n g l e t o n Pa t t e r n  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.

Slide 55: S t r u c t u r a l Pa t t e r n  Adapter  Facade  Bridge  Flyweight  Composite  Proxy  Decorator

Slide 56: Be h a v i o r a l Pa t t e r n  Chain of  Observer Responsibility  Command  Visitor  Interpreter  State  Repeater

Slide 57: Qu e s t i o n s ? ?

Slide 58: Fur t he r r e f e r e nc e s Online http://www.oodesign.com http://www.programmersheaven.com http://www.dofactory.com Books