Design Pattern lecture 1


Published on

Lecture One,

Covers OOD and Main Principles for a good OOD

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Divide and Conquer Strategy
  • Interface iVehiclee.g. city building contractsAbstract class  Toyota  Camry Corolla
  • If a class has more then one responsibility, then the responsibilities become coupled.Changes to one responsibility may impair or inhibit the class’ ability to meet the others.This kind of coupling leads to fragile designs that break in unexpected ways when changed.
  • When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable.The primary mechanisms behind the Open-Closed principle are abstraction and polymorphism.
  • Fat interfaces are less reusable and increase coupling between classes
  • Car example, pluggable parts.
  • Design Pattern lecture 1

    1. 1. Design Pattern By Julie IskanderMSc. Communication and Electronics
    2. 2. Course outlines• OO Design• Introduction to DP• Creational DP• Structural DP• Behavioral DP
    3. 3. Course Evaluation• 60% Exam• 30% Report• 10% Attendance, Participation & Quizzes
    4. 4. Outlines Lecture 1• Object Oriented Design • Review on OOP • SOLID Principles • Other OO Principles
    5. 5. Object Oriented Design"Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard
    6. 6. Object Oriented Design• Modularization Complex Program
    7. 7. Review on Object Oriented Programming• Encapsulation• Inheritance and Polymorphism• Abstraction • Interface Vs. Abstract Class
    8. 8. Encapsulation• Keeping things private or masked inside the domain of an object, package, namespace, class, or interface and allowing only expected access to pieces of functionality.• Controlling access to fields, properties and methods
    9. 9. Inheritance• Instead of maintaining the same logic in two objects, they can share and even override or change this functionality by using a base or parent class.• The parent should only contain functionality common to all its children.
    10. 10. Abstraction• Abstraction is the ability to abstract into a base class some common functionality or design that is common to several implementations or instanced classes.• It is the possibility to represent the needed information in program without presenting the details.• Abstraction and inheritance are both aspects of polymorphism.
    11. 11. Interface Vs. Abstract classInterface Abstract class• Not a class • "What" functionality a particular• It is simply a protocol in OO kind of object should have, and languages that exists between also "How" a particular classes and objects to provide an functionality is implemented. agreed upon linkage. • Defines abstraction between• "What" functionality a classes, and also to define particular kind of object should concrete definition of functions have, and, it doesnt care about which are common across the exactly "How” this functionality concrete implementation classes. should be implemented. • Increases re-usability and code manageability and allows to build better systems.
    12. 12. A good OOD must be:• Re-USABLE• Changed with minimal effort• Extended without changing existing code.
    13. 13. Solid Principles• S = Single Responsibility Principle• O = Opened Closed Principle• L= Liscov Substitution Principle• I = Interface Segregation Principle• D = Dependency Inversion Principle
    14. 14. Single Responsibility Principle
    15. 15. Single Responsibility Principle• There should never be more than one reason for a class to change• A class should have one and only one responsibility.
    16. 16. Single Responsibility Principle
    17. 17. Single Responsibility Principle
    18. 18. Opened-closed principle
    19. 19. Opened-closed principle• "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."
    20. 20. LisKov Substitution Principle
    21. 21. LisKov Substitution Principle• Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it• .“Subtypes must be substitutable for their base types.”
    22. 22. Interface Segregation Principle
    23. 23. Interface Segregation Principle• "Clients should not be forced to depend upon interfaces that they do not use.“• Fat Interfaces are not recommended
    24. 24. Dependency Inversion Principle
    25. 25. Dependency Inversion Principle• "High level modules should not depend upon low level modules. Rather, both should depend upon abstractions."• Pluggable nature of parts
    26. 26. Dependency Inversion Principle
    27. 27. Other OO Principles• Encapsulate what varies• Favor Composition over inheritance• Program to Interfaces, not implementations• Strive for loosely coupled designs between objects that interact
    28. 28. Example
    29. 29. SimUDuck App
    30. 30. Change was needed!!
    31. 31. Something went wrong!
    32. 32. Use Interfaces
    33. 33. Exercise