• Save
Jump start to OOP, OOAD, and Design Pattern
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Jump start to OOP, OOAD, and Design Pattern

on

  • 19,026 views

Jump start to OOP, OOAD and Design pattern

Jump start to OOP, OOAD and Design pattern

Statistics

Views

Total Views
19,026
Views on SlideShare
18,954
Embed Views
72

Actions

Likes
69
Downloads
0
Comments
8

7 Embeds 72

http://www.slideshare.net 57
http://www.linkedin.com 6
http://www.lmodules.com 4
http://www.coreex.net 2
http://192.168.1.54 1
http://static.slidesharecdn.com 1
https://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

15 of 8 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Jump start to OOP, OOAD, and Design Pattern Presentation Transcript

  • 1. Nishith Shukla
  • 2. Why OOP? ?
  • 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?
    • Separation of 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?
    • Components are replaceable
    • In real life component of similar functionality and specification are replaceable.
  • 6. 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.
  • 7. 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.
  • 8. Why OOP?
    • Use and throw
    • In real life we use component once we are done with it we discard them.
  • 9. Why OOP?
    • One component can be used (reused) in multiple systems
    • In real life one component could be used for multiple systems.
  • 10. Why OOP?
    • Component can be pluggable
    • In real life component could be used for multiple systems.
  • 11. 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.
  • 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 OOP
    • Encapsulation
    • Inheritance
    • Abstraction
    • Polymorphism
  • 15. Data Encapsulation class Account { public: float withdraw(); void deposit(float amount); private: float balance; );
  • 16. 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
  • 17. 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
  • 18. Abstraction
    • Management of complexity
    • Hierarchical classification:
      • is-a relationship: inheritance
      • has-a relationship: containment
  • 19. Polymorphism
    • One interface
    • Multiple implementations
    • Inheritance
    • Method overloading
  • 20.  
  • 21. 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
  • 22. 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.
  • 23. 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.
  • 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 principal
    • Abstractions should not depend upon details.
    • Details should depend upon abstractions.
  • 26. Interface segregation principal
    • The dependency of one class to another one should depend on the smallest possible interface.
  • 27. 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.
  • 28. 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.
  • 29. 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.
  • 30. Uncovered principal
    • Reuse release equivalence principal
    • Common closure principal
    • Common reuse principal
    • Acrylic dependency principal
    • Stable dependency principal
    • Stable abstraction principal
  • 31. Nishith Shukla
  • 32. Creational Patterns
    • Factory
    • Abstract Factory
    • Builder
    • Prototype
    • Singleton
  • 33.  
  • 34. 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.
  • 35. Factory method
  • 36. 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 (); }
  • 37. 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.
  • 38.  
  • 39. 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
  • 40. Abstract Factory Pattern
  • 41. 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.
  • 42.  
  • 43. Builder Pattern
    • Separate the construction of a complex object from its representation so that the same construction process can create different representations.
  • 44. Builder Pattern
  • 45. 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
  • 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
    • Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
  • 49. Prototype Pattern
  • 50. 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
  • 51.  
  • 52. Singleton Pattern
    • Ensure a 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
    • 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.
  • 55. Structural Pattern
    • Adapter
    • Bridge
    • Composite
    • Decorator
    • Facade
    • Flyweight
    • Proxy
  • 56. Behavioral Pattern
    • Chain of Responsibility
    • Command
    • Interpreter
    • Repeater
    • Observer
    • Visitor
    • State
  • 57. Questions? ?
  • 58. Further references Online http://www.oodesign.com http://www.programmersheaven.com http://www.dofactory.com Books