Design Pattern lecture 1
•
2 gefällt mir•1,044 views
Lecture One, Covers OOD and Main Principles for a good OOD
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie Design Pattern lecture 1
Ähnlich wie Design Pattern lecture 1 (20)
Mehr von Julie Iskander
Mehr von Julie Iskander (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design Pattern lecture 1
- 1. Design Pattern By Julie Iskander MSc. Communication and Electronics
- 2. Course outlines • OO Design • Introduction to DP • Creational DP • Structural DP • Behavioral DP
- 3. Course Evaluation • 60% Exam • 30% Report • 10% Attendance, Participation & Quizzes
- 4. Outlines Lecture 1 • Object Oriented Design • Review on OOP • SOLID Principles • Other OO Principles
- 5. Object Oriented Design "Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard
- 6. Object Oriented Design • Modularization Complex Program
- 7. Review on Object Oriented Programming • Encapsulation • Inheritance and Polymorphism • Abstraction • Interface Vs. Abstract Class
- 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. 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. 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. Interface Vs. Abstract class Interface 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 doesn't 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. A good OOD must be: • Re-USABLE • Changed with minimal effort • Extended without changing existing code.
- 13. Solid Principles • S = Single Responsibility Principle • O = Opened Closed Principle • L= Liscov Substitution Principle • I = Interface Segregation Principle • D = Dependency Inversion Principle
- 14. Single Responsibility Principle
- 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. Single Responsibility Principle
- 17. Single Responsibility Principle
- 19. Opened-closed principle • "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."
- 20. LisKov Substitution Principle
- 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. Interface Segregation Principle
- 23. Interface Segregation Principle • "Clients should not be forced to depend upon interfaces that they do not use.“ • Fat Interfaces are not recommended
- 24. Dependency Inversion Principle
- 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. Dependency Inversion Principle
- 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. Example
- 29. SimUDuck App
- 33. Use Interfaces
- 41. Exercise
Hinweis der Redaktion
- 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.