1 / 26

Object- oriented Design Principles

Object- oriented Design Principles. The pyramid of OO. Abstract/ Philosophical. Practical. Object-orientation is good!. Object-orientation is good?. Object-orientation is good (?). Why are we learning about object-orientation in the first place?

ruby-tyler
Télécharger la présentation

Object- oriented Design Principles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object- oriented Design Principles

  2. The pyramid of OO Abstract/ Philosophical Practical DCS – SWC

  3. Object-orientation is good! DCS – SWC

  4. Object-orientation is good? DCS – SWC

  5. Object-orientation is good (?) • Why are we learning about object-orientation in the first place? • Other ”paradigms” for programming exist, for instance functional programming and logic programming • However, OO is currently the dominating paradigm for programming – more or less an industry standard DCS – SWC

  6. Object-orientation is good! • Object-orientation has proven to be a friutful way of connecting real life and software development • However, there are certain ”rules” to obey when playing the OO-game… • At the top, we rely on a few Object-Oriented concepts DCS – SWC

  7. Object-oriented concepts • Abstraction • Encapsulation • Polymorphism • Inheritance • (Composition) DCS – SWC

  8. Abstraction • The idea that we focus only on the essence of a concept • Inessential details are ”abstracted away” • Abstraction works at multiple levels • Can be a challenge to find the appropriate level of abstraction • Abstractions are manifested through interfaces, which define behaviors DCS – SWC

  9. Encapsulation • The idea not to expose details about how behaviors are achieved • Concepts are considered black boxes • This enables us to change how behaviors are achieved, without affecting the user of a particular concept DCS – SWC

  10. Polymorphism • The idea that concrete instances of a behavior can take many forms • All animals can eat – but do so in very different ways… • Eating is polymorphic behavior – it can take many forms, but has the same essence • Allows us to focus on the essence of the behavoir, neglecting actual behaviors DCS – SWC

  11. Inheritance • The idea that concepts can inherit behaviors from other, more general concepts • Allows us to reuse behaviors that have previously been defined • We can easily define hierarchies of related concepts, only needing to add genuinely new behaviors DCS – SWC

  12. Composition • The idea that new concepts can be com-posed by combining existing concepts • A supplement/alternative to inheritance • A different approach to reuse • Composition helps us realise has-a relations between concepts, inheritance is used for is-a relations DCS – SWC

  13. Fine, but… • The OO-concepts are nice, but not particularly operational • We need something more concrete • The OO-principles provide more specific guidelines DCS – SWC

  14. The Object-oriented principles 1. Encapsulate the aspects of your application that vary 2. Favor composition over inheritance 3. Program to an interface, not an implementation 4. Strive for loose couplings between objects that interact 5. Make classes open for extension, closed for modification 6. Depend on abstractions, not concrete classes 7. Only talk to your closest friends 8. Don’t call us, we’ll call you 9. A class should only have one reason to change DCS – SWC

  15. OO principles • Where do these principles come from…? • Not from ”proofs” or theory… • Condensed best practices from real life • Principles are to some extent overlapping DCS – SWC

  16. OO principles • ”Encapsulate the aspects of your applica-tion that vary” • Promotes reusability • When designing classes for a system of concepts, put the varying elements into separate classes • Can be realised both through inheritance and composition, often using interfaces DCS – SWC

  17. OO principles • ”Favor composition over inheritance” • Turns out that composition often – but not always – enables us to design more flexible systems (couplings are weaker) • Systems can also be more dynamic; we can change configurations during run-time • We shall see examples later… DCS – SWC

  18. OO principles • ”Program to an interface, not an imple-mentation” • An essential idea; if we know the interface, we do not need to know any details about a specific implementation (weak coupling) • Allows us the change the implementation without affecting the user • This is more or less encapsulation DCS – SWC

  19. OO principles • ”Strive for loose couplings between objects that interact” • We like loose couplings  • Loose couplings promotes modularity and reuse of classes • We usually achieve this by relying on inter-faces rather than specific implementations • Yet another facet of the same jewel… DCS – SWC

  20. OO principles • ”Make classes open for extension, closed for modification” • Very important principle! • Once we have a well-documented, well-tested class, we should not change it! • If we need more functionality, achieve it through extension, using inheritance and/or composition • Keep classes as ”pure” as possible DCS – SWC

  21. OO principles • ”Depend on abstractions, not concrete classes” • Variation over ”Program to an interface, not an implementation” DCS – SWC

  22. OO principles • ”Only talk to your closest friends” • Hmm, what does that mean…? • A typical application architecture divides classes into a number of layers • Classes in one layer should only know classes in the next layer (loose couplings) • Avoid reliance on the specific composition of a class DCS – SWC

  23. OO principles • What is best, and why…? double temp = station.getThermometer().getTemperature(); double temp = station.getStationTemperature(); • We should not rely on specifics about how a Station is implemented • Only one ”.” in a line of code… DCS – SWC

  24. OO principles • ”Don’t call us, we’ll call you” • The Hollywood Agent principle… • A more advanced principle; instead of imple-menting an algorithm using a lot of calls to generic classes, implement a generic algo-rithm with ”plugins” for specialised behavior • Also known as Inversion of Control • ”Encapsulate what varies…” DCS – SWC

  25. OO principles • ”A class should only have one reason to change” • Classes should have as few responsibilities as possible • ”Closed for modification, open for extension” • Again, low coupling is desired DCS – SWC

  26. Beyond principles • We can use these OO principles directly when developing software • Next step is Design Patterns, which describe designs for solving common problems, relying on the OO principles • We have already seen some patterns (GRASP) DCS – SWC

More Related