Thoughtful Software Design
Download as PPT, PDF4 likes1,247 views
The document provides an agenda for a discussion on thoughtful software design. It covers background topics on software design principles like abstraction, encapsulation, and separation of concerns. It then discusses orienteering designer mindsets and basic design principles like the single responsibility principle and principle of least astonishment. The document also addresses migrating legacy systems to more thoughtful designs and techniques for improving design quality like tearing systems apart into isolated layers and components.
Thoughtful Software Design
- 1. Thoughtful Software Design Agenda Background Orienteering Basic Principles From Legacy to Thoughtful Design Tearing It Apart Q & A Great Reads
- 2. Background
- 3. Software Design is the process of structuring a solution into components, abstractions and interactions, with the goal of effectively coping with changes. What Is Software Design?
- 4. “Modeling and Design are often the quickest path to the actual goal” - Eric Evans Motivation
- 6. Orienteering
- 7. 2. How do I use it?1. How do I change it? Think Of: Extensibility Maintainability Implementation Coupling Think Of: Clarity Predictability Intents Cohesion Designer Mindsets
- 8. How much of one module must be known in order to understand another module? The more that we must know of module B in order to understand module A, the more closely connected A is to B. The act of linking two things together. The degree to which software components are dependent upon each other. Coupling
- 9. Coupling Illustrations from the book: Dependency Injection in NET – Mark Seemann Tight Lose Are your components attached to the wall?
- 10. The action or fact of forming a united whole. The measure of how strongly- related and focused the various responsibilities of a software component are. The cohesion of each component, considered in isolation, is determined by how tightly bound or related its internal elements are to one another. Cohesion
- 12. Abstraction is an emphasis on the idea, qualities and properties rather than the particulars (a suppression of detail) Abstraction & Generalization E. g., multiple implementations complying with one interface Generalization is a broadening of application to encompass a larger domain of objects of the same or different type E. g., one implementation can process multiple types (Generics)
- 13. Abstraction & Generalization We now need to handle a Toy Dog that acts like a normal dog but has a special method: ChangeBatteries() Requirement Change Mistake #1: Ruining The Abstraction Mistake #2: Ruining The Generalization Adding ChangeBatteries() to the IDog interface How would you handle it?
- 14. The inclusion of one thing within another thing so that the included thing is not apparent Protecting state integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. Exposing a solution to a problem without requiring the consumer to fully understand the problem domain. Encapsulation
- 15. Encapsulation Should we add these sorting methods to the List class? Should a car allow the driver to control the pressure of the fuel injection?
- 16. A layer represents a well-encapsulated group of reusable components perform a common architectural function within an application Layered Architecture
- 17. Layered Architecture Layer N+1 Layer N Data Only Well-Isolated Layers Layer N+1 Layer N Business Objects Implementation Leaking Layers Example: Content/Common Coupling (strong) Data Structure/Data Coupling (weak)
- 18. Basic Principles
- 19. A class should have only one reason to change Gather together the things that change for the same reasons. Separate those things that change for different reasons Single Responsibility Principle
- 20. Single Responsibility Principle Example: Accounting Infrastructure Operations Example From: The Single Responsibility Principle – Robert C. Martin https://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
- 21. Fault-Safe, constrained API Commands Queries Separation Referential Transparency / Immutability Design By Contract Dependency Injection Null Prevention Patterns, etc. A component of a system should behave in a manner consistent with how users of that component are likely to expect it to behave Principle of Least Astonishment
- 22. Principle of Least Astonishment reporting.PrintReportA() reporting.PrintReportB() Example: reporting.PrintReportB() reporting.PrintReportA() Print report A and then Report B . It works Fine. DB Connection Error! But Why? Changed to print report B before report A A database connection is opened at the Beginning of PrintReportA and closed at the end of PrintReportB
- 23. Design By Contract Pre-conditions Post-conditions (Class) Invariants Define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with pre- conditions, post-conditions and invariants. Assert conditions that must be satisfied prior to the execution of a method. The responsibility is on the caller. Assert for conditions that must be satisfied after to the execution of a method. The responsibility is on the method called. Add assertions for conditions that must be satisfied before and after the execution of any public method. The responsibility is on the class used.
- 25. A.K.A. Law Of Demeter Each component should have only limited knowledge about other components: only components "closely" related to the current component Each component should only talk to its friends: don't talk to strangers. Only talk to your immediate friends The Principle of Least Knowledge
- 26. A.K.A. Law Of Demeter The Principle of Least Knowledge A B C ask for to look for Violation! B is just a middleman, A only needs C Solution 1: Get Rid Of B Solution 2: Encapsulate C A C ask for A ask for B C C is a stranger to A
- 27. A.K.A. Law Of Demeter The Principle of Least Knowledge Don’t look for things Ask for what you need Example From: The Clean Code Talks - Don't Look For Things! – Misko Hevery https://www.youtube.com/watch?v=RlfLCWKxHJ0
- 28. From Legacy To Thoughtful Design
- 29. Load & Save an Invoice Add & Remove Invoice Items Reschedule the Invoice Delivery Date Void the Invoice Calculate Invoice Totals & Taxes Export Invoice to a File Print Invoice Email Invoice Features On The Menu
- 31. Tearing It Apart
- 32. Add & Remove Invoice Items Reschedule the Invoice Delivery Date Void the Invoice Calculate Invoice Totals & Taxes Load & Save an Invoice (DB) Export Invoice to a File Print Invoice Email Invoice Persistence Business Reporting Separating Concerns
- 34. Add & Remove Invoice Items Reschedule the Invoice Void the Invoice Business Calculate Invoice Totals & Taxes As an invoice user I want to... I don't want to deal with it... Why would we expose an internal calculation? Encapsulating Methods
- 35. Does not belong here Cohesion
- 36. Commands do not return values! Command Query Separation
- 37. Ask, don't look for things! Generic reschedule for any day Principle Of Least Knowledge
- 38. Legacy Invoice Model Invoice Data Model Invoice Domain Model Used By Used By - Persistence - View Models & Reporting - Business Logic & Events Business Logic should not leak into other layers Exposes Data Exposes Business Operations Isolating Layers
- 39. Any change produces a new instance Can extract Data Model when needed Immutability
- 40. Questions?
- 41. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design Edward Yourdon, Larry L. Constantine Principles Of Object Oriented Design http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Robert C. Martin Refactoring: Improving the Design of Existing Code Martin Fowler Design Patterns: Elements of Reusable Object-Oriented Software Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin The Art of UNIX Programming Eric S. Raymond The Pragmatic Programmer: From Journeyman to Master Andrew Hunt, David Thomas Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans Great Reads