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.
Thoughtful Software Design
Agenda
 Background
 Orienteering
 Basic Principles
 From Legacy to Thoughtful Design
 Tear...
Background
Software Design
is the process of structuring a solution
into components, abstractions and interactions,
with the goal of ...
“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...
Orienteering
2. How do I use it?1. How do I change it?
Think Of:
Extensibility
Maintainability
Implementation
Coupling
Think Of:
C...
How much of one module must be known in order to understand
another module?
The more that we must know of module B in orde...
Coupling
Illustrations from the book: Dependency Injection in NET – Mark Seemann
Tight Lose
Are your components attached t...
The action or fact of forming
a united whole.
The measure of how strongly-
related and focused the various
responsibilitie...
Cohesion
Low Cohesion Examples
Abstraction is an emphasis on the idea,
qualities and properties rather than the
particulars (a suppression of detail)
Abs...
Abstraction & Generalization
We now need to handle a
Toy Dog that acts like a
normal dog but has a special
method: ChangeB...
The inclusion of one thing within another thing so
that the included thing is not apparent
 Protecting state integrity by...
Encapsulation
Should we add these sorting methods
to the List class?
Should a car allow the driver to
control the pressure...
A layer represents a well-encapsulated group of
reusable components perform a common
architectural function within an appl...
Layered Architecture
Layer N+1
Layer N
Data Only
Well-Isolated
Layers
Layer N+1
Layer N
Business Objects
Implementation Le...
Basic Principles
A class should have only one reason to change
Gather together the things that change for the
same reasons. Separate those ...
Single Responsibility Principle
Example:
Accounting
Infrastructure
Operations
Example From: The Single Responsibility Prin...
 Fault-Safe, constrained API
 Commands Queries Separation
 Referential Transparency / Immutability
 Design By Contract...
Principle of Least Astonishment
reporting.PrintReportA()
reporting.PrintReportB()
Example:
reporting.PrintReportB()
report...
Design By Contract
Pre-conditions
Post-conditions
(Class) Invariants
Define formal, precise and verifiable
interface speci...
Design By Contract
Example:
A.K.A. Law Of Demeter
 Each component should have only limited knowledge
about other components: only components "closely...
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 ...
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...
From Legacy To Thoughtful Design
Load & Save an Invoice
Add & Remove Invoice Items
Reschedule the Invoice Delivery Date
Void the Invoice
Calculate Inv...
Legacy Invoice Interface
Tearing It Apart
Add & Remove Invoice Items
Reschedule the Invoice Delivery Date
Void the Invoice
Calculate Invoice Totals & Taxes
Load & S...
Should be immutable!
IEnumerable
Protecting Data
Add & Remove Invoice Items
Reschedule the Invoice
Void the Invoice
Business
Calculate Invoice Totals & Taxes
As an invoice...
Does not belong here
Cohesion
Commands
do not return values!
Command Query Separation
Ask,
don't look
for things!
Generic
reschedule
for any day
Principle Of Least Knowledge
Legacy
Invoice
Model
Invoice
Data
Model
Invoice
Domain
Model
Used By
Used By
- Persistence
- View Models & Reporting
- Bus...
Any change
produces a
new instance
Can extract
Data Model
when needed
Immutability
Questions?
Structured Design: Fundamentals of a Discipline of
Computer Program and Systems Design
Edward Yourdon, Larry L. Constantin...
giovanni.scerra@afsi.com
My Contact Info:
https://www.linkedin.com/in/giovanniscerra
Upcoming SlideShare
Loading in …5
×

Thoughtful Software Design

1,060 views

Published on

An introduction to software design and principles

Published in: Software
  • Login to see the comments

Thoughtful Software Design

  1. 1. Thoughtful Software Design Agenda  Background  Orienteering  Basic Principles  From Legacy to Thoughtful Design  Tearing It Apart  Q & A  Great Reads
  2. 2. Background
  3. 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. 4. “Modeling and Design are often the quickest path to the actual goal” - Eric Evans Motivation
  5. 5. Maintainability Compatibility Reliability Modularity Extensibility Robustness Reusability Leanness Readability Testability Reversibility Predictability Performance Transparency Security Consistency Usability Portability Scalability Simplicity Independence Contextual Tradeoffs
  6. 6. Orienteering
  7. 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. 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. 9. Coupling Illustrations from the book: Dependency Injection in NET – Mark Seemann Tight Lose Are your components attached to the wall?
  10. 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
  11. 11. Cohesion Low Cohesion Examples
  12. 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. 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. 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. 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. 16. A layer represents a well-encapsulated group of reusable components perform a common architectural function within an application Layered Architecture
  17. 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. 18. Basic Principles
  19. 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. 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. 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. 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. 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.
  24. 24. Design By Contract Example:
  25. 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. 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. 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. 28. From Legacy To Thoughtful Design
  29. 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
  30. 30. Legacy Invoice Interface
  31. 31. Tearing It Apart
  32. 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
  33. 33. Should be immutable! IEnumerable Protecting Data
  34. 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. 35. Does not belong here Cohesion
  36. 36. Commands do not return values! Command Query Separation
  37. 37. Ask, don't look for things! Generic reschedule for any day Principle Of Least Knowledge
  38. 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. 39. Any change produces a new instance Can extract Data Model when needed Immutability
  40. 40. Questions?
  41. 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
  42. 42. giovanni.scerra@afsi.com My Contact Info: https://www.linkedin.com/in/giovanniscerra

×