Uploaded byLalit Kale
Jump Start To Ooad And Design Patterns
The document discusses object-oriented programming (OOP) principles and design patterns. It explains that OOP models real-world objects and their relationships, and outlines key OOP concepts like encapsulation, inheritance, abstraction, and polymorphism. It then discusses common design patterns like creational patterns (factory method, abstract factory, builder, prototype, singleton), structural patterns (adapter, bridge, composite, decorator, facade, flyweight, proxy), and behavioral patterns (chain of responsibility, command, interpreter, observer, state, visitor).
Jump Start To Ooad And Design Patterns
- 1.
- 2.
- 3. 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.
- 4. Why OOP? Separationof concerns In real life we need not to worry about how an object is made or what it contains for using it.
- 5. Why OOP? Componentsare replaceable In real life component of similar functionality and specification are replaceable.
- 6. Why OOP? Developcomponent 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.
- 7. Why OOP? Thinkabout 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.
- 8. Why OOP? Useand throw In real life we use component once we are done with it we discard them.
- 9. Why OOP? Onecomponent can be used (reused) in multiple systems In real life one component could be used for multiple systems.
- 10. Why OOP? Componentcan be pluggable In real life component could be used for multiple systems.
- 11. Why OOP? Easyto understand system In real life we can understand complex system by take top-down or bottom-up approach. Which leads us to smaller object.
- 12. What is OOP?All right, what is OOP?
- 13. What is OOP?Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions“ ; and “data” rather than “logic” .
- 14. Pillars of OOPEncapsulation Inheritance Abstraction Polymorphism
- 15. Data Encapsulation classAccount { public: float withdraw(); void deposit(float amount); private: float balance; );
- 16. Inheritance A classwhich 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
- 17. Inheritance cont’d Asub-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
- 18. Abstraction Management ofcomplexity Hierarchical classification: is-a relationship: inheritance has-a relationship: containment
- 19. Polymorphism One interfaceMultiple implementations Inheritance Method overloading
- 20.
- 21. OOAD Design PrincipalsSingle responsibility principal Open closed principal Liskov substitution principal Dependency inversion principal Interface segregation principal Law of Demeter Single choice principal Information hiding
- 22. Single responsibility principalEach 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.
- 23. Open closed principalA 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.
- 24. 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.
- 25. Dependency inversion principalAbstractions should not depend upon details. Details should depend upon abstractions.
- 26. Interface segregation principalThe dependency of one class to another one should depend on the smallest possible interface.
- 27. Law of DemeterOnly 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.
- 28. Single choice principalThe 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.
- 29. Information hiding Thebasic 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.
- 30. Uncovered principal Reuserelease equivalence principal Common closure principal Common reuse principal Acrylic dependency principal Stable dependency principal Stable abstraction principal
- 31.
- 32. Creational Patterns Factory Abstract Factory Builder Prototype Singleton
- 33.
- 34. Factory method Definean interface for creating an object, but let subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.
- 35.
- 36. Factory method publicIDocument CreateDocument(String type) { if (type.isEqual("html")) return new HtmlDocument(); if (type.isEqual(“word")) return new WordDocument(); if (type.isEqual("pdf")) return new PDFDocument (); }
- 37. Factory method Itintroduce 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.
- 38.
- 39. Abstract Factory PatternProvide 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
- 40.
- 41. Abstract Factory PatternWhen 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.
- 42.
- 43. Builder Pattern Separatethe construction of a complex object from its representation so that the same construction process can create different representations.
- 44.
- 45. Builder Pattern Whento 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
- 46. 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.
- 47.
- 48. Prototype Pattern Specifythe kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
- 49.
- 50. Prototype Pattern Whento 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
- 51.
- 52. Singleton Pattern Ensurea class has only one instance and provide a global point of access to it.
- 53. Singleton Pattern private Logger () { ……… } public static Logger GetLogger() { if (instance == null) instance = new Logger(); return instance; }
- 54. Singleton Pattern Whento 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.
- 55. Structural Pattern AdapterBridge Composite Decorator Facade Flyweight Proxy
- 56. Behavioral Pattern Chainof Responsibility Command Interpreter Repeater Observer Visitor State
- 57.
- 58. Further references Onlinehttp://www.oodesign.com http://www.programmersheaven.com http://www.dofactory.com Books