Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

S.O.L.I.D. Software-Engineering Principles - a must know for developers

658 views

Published on

This presentation focus on the S.O.L.I.D. software engineering principles for object-oriented design. We will see and discuss the rule-set with simple examples. S.O.L.I.D. stands for

S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle

  • Be the first to comment

S.O.L.I.D. Software-Engineering Principles - a must know for developers

  1. 1. SOLID Software-Engineering Principles - A must know for developers - Roland Petrasch 5th SET Meet-up Jan. 6, 2016 Bangkok, Thailand
  2. 2. Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 2 / 36 SET — Software Engineering Thailand The Interest Group from & (not only) for Developers Open Group: Members, Sponsors and Organizers welcome Next topics: S.O.L.I.D., VR Game Design with Unity, IoT Show Case, Eye Tracking, SE Start-ups: Lessons Learned Contact Roland Petrasch Thammasat University, Department of Computer Science, Rangsit Campus, Pathum Thani roland.petrasch@cs.tu.ac.th roland.petrasch@gmail.com
  3. 3. Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 3 / 36 SOLID Software-Engineering Principles Agenda A few Basics, e.g. dependency, coupling, cohesion S.O.L.I.D. Software-Engineering Principles SRP: Responsibilities and OO → OCP Inheritance and Liskov Substitution Principle Modules, components & Interface Segregation Dependency (Abstraction &) Inversion Discussion S O L I D R C S S I P P P P P
  4. 4. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 4 / 36 SOLID Basics Modules & components Module → OO: class(es) + interface(s) Component = module(s), package, service Provider → client, interface(s) Encapsulation / information hiding Can be OO (instantiation) or non-OO Dependency Interdependence between software modules Strong, e.g. inheritance, content Weak, e.g. message passing, parameters M D C C
  5. 5. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 5 / 36 SOLID Basics Coupling Inter-module aspect: Degree of (in)direct dependencies to other components / modules Example Tight coupling: Component uses implementation Loose coupling: Component uses an abstraction OO: Inheritance Loose coupling is better than tight coupling … normally Source: [4] Rodriguez et al., 2001 M D C C
  6. 6. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 6 / 36 SOLID Basics Coupling Example Surveillance App M D C C
  7. 7. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 7 / 36 SOLID Basics Cohesion Intra-module aspect: Degree to which the elements of a module belong together Behavior and attributes of a module should “work together” (calsule), i.e. the functions/method a class must use the attributes → high cohesion Otherwise functions/method and attributes do not belong together → low cohesion High cohesion is good, low cohesion is bad … normally M D C C
  8. 8. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 8 / 36 SOLID Basics Cohesion Example: class Camera { String name; Integer fps; Integer resolution; Boolean motionTracking; public String getName() { ... } } class CameraController { public String validateSettings() { ... if (fps >= 30 && resolution >= ... } } Low or no cohesion M D C C
  9. 9. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 9 / 36 SOLID SE Principles SOLID Bertram Meyer described SE principles, DbC … [1] 5 Principles were introduced in 2000s by Robert C. Martin [3] Principles can lead to better software quality Maintainability Understandability / Readability Correctness M D C C
  10. 10. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 10 / 36 SOLID SE Principles SRP – Single Responsibility Principle SRP A class should have only one reason to change Responsibility relates to features and aspects Technological aspects, e.g. output device(s), persistence Domain-oriented aspects, e.g. CRM, production, HR Architectural aspects, e.g. cloud app, mobile client Cohesion and coupling are important underlying concepts for SRP M D C C
  11. 11. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 11 / 36 SOLID SE Principles SRP – Single Responsibility Principle Example: entity class and persistence M D C C class Camera { String name; Integer fps; Integer resolution; Boolean motionTracking; public String getName() { ... } public void save() { // some JDBC statements ... } } class CameraDAO { public void save( Camera camera) { ... } } 2 reasons for change: domain & persistence FW class Camera { ... Separation of concerns POJO Data Access Object
  12. 12. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 12 / 36 SOLID SE Principles SRP – Single Responsibility Principle DoDOO – Don't destroy Object-Orientation M D C C class Camera { String name; Integer fps; Integer resolution; VDOBuffer buffer; public String getName() { ... } } class CameraLogic { public void record( Camera camera) { ... } public void stream( Camera camera, Stream stream) { ... } } OO Encapsulation: class consists of attributes (data member) and behavior (methods / member functions)
  13. 13. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 13 / 36 SOLID SE Principles SRP – Single Responsibility Principle DoMa – The domain matters M D C C class Camera { String OEM; String name; Integer fps; Integer resolution; VDOBuffer buffer; Location location; IP ip; public String getName() { ... } } object Camera1: OEM = “Yamunaki” name = “Y28” fps = 30 Resolution = “1 MPixel” location = “Office” Ip = 1.2.1.1 A camera (type) is not a camera (device) → 2 domain responsibilities object Camera1: OEM = “Yamunaki” name = “Y28” fps = 20 Resolution = “2 MPixel” location = “Floor” Ip = 1.2.1.2 Redundant data, semantic gaps
  14. 14. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 14 / 36 SOLID SE Principles SRP – Single Responsibility Principle Use the OOA pattern „spec./product“, “model/exemplar”, “type/object“ M D C C class Camera { String OEM; String name; Integer max_fps; Integer max_resolution; public String getName() { ... } } class CameraDevice { Camera camera; Integer fps; Integer resolution; VDOBuffer buffer; Location location; IP ip; public String record() { ... } 1 * Camera type / spec Camera device / exemplar Many-to-one association. NOT inheritance
  15. 15. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 15 / 36 SOLID SE Principles OCP - Open/Closed Principle Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification Use some good 'ol design patterns, e.g. decorator, strategy, wrapper … ? Yes and no: DP can be useful, but OCP goes deeper than that Example: Camera that provides pan, tilt, and zoom functions. Need to change the Camera class? M D C C
  16. 16. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 16 / 36 SOLID SE Principles OCP - Open/Closed Principle Camera class should be closed to modifications → „new features“ M D C C class Camera { String OEM; String name; Integer fps; Integer resolution; Angle pan; Angle tilt; Integer zoom; ... } A camera should only be changed for one reason (core functionality / responsibility), not for new feature implementation (SRP).
  17. 17. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 17 / 36 SOLID SE Principles OCP - Open/Closed Principle Camera extension … so many possibilities Inheritance Simple Wrapper Decorator M D C C class Camera { ... } class PTZCamera extends Camera { ... } class Camera { ... } class PTZCamera { Camera camera; ... } class IPCamera { ... } class PTZCamera { Camera camera; ... } interface Camera { record() }
  18. 18. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 18 / 36 SOLID SE Principles OCP - Open/Closed Principle OCP focuses on class design Strong relationship to SRP, cohesion, and coupling Cohesion should be high when OCP is applied Coupling cannot be avoided, but maybe minimized Avoid over-engineering Coupling is not always so bad as it seems, e.g. domain / entity modeling Using interfaces instead of implementations has advantages, but ask yourself: Do I need this here now or in the future? M D C C
  19. 19. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 19 / 36 SOLID SE Principles Liskov Substitution Principle Derived types must be completely substitutable for their base types Strong behavioral subtyping Barbara Liskov and Jeannette Wing, 1994 Derived class can only override the methods of the superclass when the functionality is preserved Example: A Person provides or “uses“ the surveillance system. It can be the OEM, the home owner or an intruder M D C C
  20. 20. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 20 / 36 SOLID SE Principles Liskov Substitution Principle Example: M D C C Are we really interested in the birthday of the thief? An OEM probably hasn't a first-name. Does the home owner have attributes?
  21. 21. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 21 / 36 SOLID SE Principles Liskov Substitution Principle Example: problems OEM→getFirstName() doesn't really make sense (OEM isn't substitutable for its base type Person) Home owner doesn't have attributes? Really? Intruder/Thief has unknown birthday, first-name etc. (we'll never know) We mixed up 2 concepts: roles and persons Violation of SRP and Liskov substitution principle M D C C
  22. 22. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 22 / 36 SOLID SE Principles Liskov Substitution Principle Persons and Roles … so many possibilities Inheritance Simple Role Pattern ... M D C C
  23. 23. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 23 / 36 SOLID SE Principles Liskov Substitution Principle System Analysis / OOA is not OOD OOA: “The system identifies intruder an other unwanted persons ...“ LSP applies to OOD, not to OOA M D C C OOA OOD
  24. 24. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 24 / 36 SOLID SE Principles ISP Interface Segregation Principle ISP addresses high level architectural aspects A client should never be forced to implement an interface that it doesn’t use A clients shouldn’t be forced to depend on methods it doesn't use Provide specific interfaces to clients (components) Related pattern: facade pattern Example: component interfaces to clients of the surveillance system M D C C
  25. 25. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 25 / 36 SOLID SE Principles ISP Interface Segregation Principle Facade provides one common interface to clients → Clients depend on methods they don't need/use M D C C The monitor doesn't need the configuration features.
  26. 26. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 26 / 36 SOLID SE Principles ISP Interface Segregation Principle Facade interfaces are specific for clients (SRP) M D C C Interfaces of the component are segregated
  27. 27. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 27 / 36 SOLID SE Principles ISP Interface Segregation Principle Camera forces clients to implement methods they don't use M D C C How to implement the CameraControl? A control interface?
  28. 28. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 28 / 36 SOLID SE Principles ISP Interface Segregation Principle Camera interfaces should be client-specific, not implementation- specific M D C C Interfaces for different clients
  29. 29. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 29 / 36 SOLID SE Principles DIP Dependency Inversion principle High-level modules should not depend on low-level modules Both should depend on abstractions. Abstractions should not depend upon details Details should depend upon abstractions Good example is the DAO pattern Data Access (low-level) depends on abstraction (and on technological modules = libs, FW etc.) Entity classes (high-level) do not depend on DAO M D C C
  30. 30. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 30 / 36 SOLID SE Principles DIP Dependency Inversion principle High-level modules should not depend on low-level modules This is also true for inheritance, e.g. Camera (superclass) should never „know“ a subclass PTZCamera. It would detroy the whole hierarchie PTZCamera depends on Camera already and is low-level from the superclass point of view. M D C C
  31. 31. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 31 / 36 SOLID SE Principles DIP Dependency Inversion principle Architecture: Business logic is always high-level M D C C BL BL BL BL BL Controller Controller Controller View View View Persistence Persistence Persistence Communication Communication VO VO Programming Language
  32. 32. S O L I D R C S S I P P P P P Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 32 / 36 SOLID SE Principles DIP Dependency Inversion principle Why it is called “inversion”? What is inverted? High-level module need other low level modules Example: domain objects need to be persisted, so they depend on these features of low-level module for persistence This dependency (high-level module depend on low-level modules) is inverted, so only low-level modules depend on high-level modules, Example: domain objects are independent of low-level module for persistence services M D C C
  33. 33. Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 33 / 36 Discussion SOLID principles are important, but other principles and rules exist, e.g. “No circular dependencies“ rule Tight coupling often causes cyclic dependency Ripple effect: small & local change → “global” effect Source: Agustín Ruiz (espejo)
  34. 34. Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 34 / 36 Discussion SOLID is good, but not a simple formula (Principles are not just rules that can be applied) Don't start with metrics, those numbers can be tricky (start with a goal and ideas and principles and …) Check acceptance for SOLID in your team (A hot potato? Lost in Spaghetti code? Good things need time) Maintainability, re-use and understandability are real cost-savers; go the extra mile for SOLID
  35. 35. Jan. 6, 2015, Bangkok, Thailand SET Meetup: S.O.L.I.D. Software-Engineering Principles Roland Petrasch, Thammasat University 35 / 36 SOLID Software-Engineering Principles References [1] Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, 1997 [2] Erich Gamma et al.: Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley, 1994 [3] Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices. Pearson, 2002 [4] Daniel Rodriguez, Rachel Harrison: An Overview of Object-Oriented Design Metrics. RUCS/2001/TR/A, The University Of Reading, 2001 [5] Patkos Csaba: The SOLID Principles. http://code.tutsplus.com/series/the-solid-principles--cms-634 [6] Tigerfreak: Homer Simpson http://s450.photobucket.com/user/tigersafreak/media/homer-simpson-wal lpaper-brain-1024-.jpg.html
  36. 36. SOLID Software-Engineering Principles - A must know for developers - Roland Petrasch Thank you for your attention

×