thoughtful software design
TRANSCRIPT
Thoughtful Software Design
Agenda Background Orienteering Basic Principles From Legacy to Thoughtful Design Tearing It Apart Q & A Great Reads
Background
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?
“Modeling and Design are often the quickest path to the actual goal”
- Eric Evans
Motivation
Maintainability
Compatibility
Reliability
Modularity
Extensibility
Robustness
Reusability
Leanness
Readability
Testability
Reversibility
Predictability
Performance
Transparency
Security
Consistency
Usability
Portability
Scalability
Simplicity
Independence
Contextual Tradeoffs
Orienteering
2. How do I use it?1. How do I change it?
Think Of:ExtensibilityMaintainabilityImplementationCoupling
Think Of:ClarityPredictabilityIntentsCohesion
Designer Mindsets
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
Coupling
Illustrations from the book: Dependency Injection in NET – Mark Seemann
Tight Lose
Are your components attached to the wall?
The action or fact of forminga 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
CohesionLow Cohesion Examples
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)
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?
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
EncapsulationShould we add these sorting methods to the List class?
Should a car allow the driver tocontrol the pressure of the fuel injection?
A layer represents a well-encapsulated group of reusable components perform a common architectural function within an application
Layered Architecture
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)
Basic Principles
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
Single Responsibility PrincipleExample:
Accounting
Infrastructure
Operations
Example From: The Single Responsibility Principle – Robert C. Martinhttps://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
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
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
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.
Design By ContractExample:
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
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 Cask for
Aask for
B C
C is a stranger to A
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 Heveryhttps://www.youtube.com/watch?v=RlfLCWKxHJ0
From Legacy To Thoughtful Design
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
Legacy Invoice Interface
Tearing It Apart
Add & Remove Invoice ItemsReschedule the Invoice Delivery DateVoid the InvoiceCalculate Invoice Totals & Taxes
Load & Save an Invoice (DB)Export Invoice to a File
Print InvoiceEmail Invoice
Persistence
Business
Reporting
Separating Concerns
Should be immutable!
IEnumerable
Protecting Data
Add & Remove Invoice ItemsReschedule the InvoiceVoid 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
Does not belong here
Cohesion
Commands do not return values!
Command Query Separation
Ask, don't look for things!
Genericreschedule for any day
Principle Of Least Knowledge
LegacyInvoiceModel
Invoice Data Model
InvoiceDomain 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
Any change produces a new instance
Can extractData Model
when needed
Immutability
Questions?
Structured Design: Fundamentals of a Discipline of Computer Program and Systems DesignEdward Yourdon, Larry L. Constantine
Principles Of Object Oriented Designhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodRobert C. Martin
Refactoring: Improving the Design of Existing CodeMartin Fowler
Design Patterns: Elements of Reusable Object-Oriented SoftwareEric Gamma, Richard Helm, Ralph Johnson, John Vlissides
Clean Code: A Handbook of Agile Software CraftsmanshipRobert C. Martin
The Art of UNIX ProgrammingEric S. Raymond
The Pragmatic Programmer: From Journeyman to Master Andrew Hunt, David Thomas
Domain-Driven Design: Tackling Complexity in the Heart of SoftwareEric Evans
Great Reads
