Design Principles & Tools
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C.A.R. Hoare
"The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague." - Edsger Dijkstra
"Controlling complexity is the essence of computer programming." - Brian Kernighan
why?
SPINE Model
| Needs | Maslow's Hierarchy of Needs | |
|---|---|---|
| Values | Excellence; Competence; Creativity; Correctness; Maintainability; Elegance; | |
| Principles | Loosely Coupling & Cohesiveness; SOLID; | |
| Practices | Design; Unit Testing; XP Practices: Code Reviews; Configurabilty; Standards; Often & Small Releases; | |
| Tools | LINX; Stadium; Basecamp; SVN; |
*when to adapt to tools?
Principles
| Loose Coupling & Cohesiveness | cohesion refers to the degree to which the elements of a module belong together. ... Cohesion is often contrasted with coupling, a different concept. High cohesion often correlates with loose coupling, and vice versa. |
|---|---|
| SOLID | SRP - Single Responsibility Principle |
| OCP - Open Close Principle | |
| LSP - Liskov Substitution Principle | |
| ISP - Interface Segregation Principle | |
| DIP - Dependency Inversion Principle | |
| DRY | Don't Repeat Yourself |
| KISS | Keep it simple |
| YAGNI Layers of Abstraction Side effects Temporal Coupling |
You Ain't Gonna Need It Ubiquitous domain language Indirection & Unintended consequences (braking SRP) Also a form of coupling |
{fizzbuzz}
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Practices
Adhering to Principles driven by our values
- Design - BDUF vs Emergent;
- Unit Testing;
- UX - User Experience Design;
- XP Practices: Code Reviews;
- Design for Configurabilty;
- Defining and adhering to Standards;
- Often & Small Releases;
Practice - Design
Software design is the process of implementing software solutions to one or more sets of problems.
IEEE 42010-2011: Systems and software engineering — Architecture description
- Functional Requirements
- Non-Functional Requirements (Quality Requirements)
Architectural Patterns
Practice - Design
- SOA
- Broker Pattern
- Event-driven architecture
- Implicit invocation
- Ports and Adapters
- Microservices
- MVC
- Multitier architecture (often three-tier or n-tier)
Design Patterns
GOF
-
Structural Patterns
- Decorator (AOP),Bridge,Adapter
-
Creational Patterns
- Factory, Abstract Factory, Builder
-
Behavioural Patterns
- Iterator, Observer, State
*discussion point WO model and factory patterns
Practice - Unit Testing
Testing Triangle
TDD
Rule #1 Don’t confuse unit tests with integration tests
Rule #2 Unit tests should be deterministic
Rule #3 Inject dependencies where possible
Rule #4 Don’t test external code
Rule #5 Unit tests should only test a single unit
Rule #6 Don’t mix test code and production code
Rule #7 Integration tests shouldn’t contribute to code coverage
Rule #9 Don’t use software tests to verify the environment
Rule #10 Ensure tests are isolated and idempotent
Testing Rules
Practice - Unit Testing
Practice - XP Practices
- Pair programming - code reviews/pairing
- Small releases - Cost of change (Problem cycle)
- Metaphor - Ubiquitous Domain Language
- Collective ownership
- Coding standard
- Simple design
- Refactoring
- Testing
- On-site customer - collaboration
- 40-hour work week - work smarter!
- Continuous integration - DEV/UAT/PROD env.
Tools
Models
Code Smells
Test Patterns
Using models in software engineering has several advantages, including:
- reuse at the design level,
- reduced system complexity,
- reduced coding costs,
- reduced testing costs,
- reduced documentation costs, and
- increased maintainability and enhance-ability
Layes of Abstraction
Form Consistent Abstractions
Abstraction is the ability to engage with a concept while safely ignoring some of
its details— handling different details at different levels. Any time you work
with an aggregate, you’re working with an abstraction. If you refer to an object
as a “house” rather than a combination of glass, wood, and nails, you’re making
an abstraction. If you refer to a collection of houses as a “town,” you’re making
another abstraction.
Tools - Models
Kructhen 4+1 view model
Tools - Code Smells
- Duplicated code
- Contrived complexity
- Large class
- Lazy class / freeloader
- Feature envy
- Inappropriate intimacy
- Refused bequest (LSP non-adherance)
- Excessive use of literals
- Cyclomatic complexity
- Downcasting
- Orphan variable or constant class
- Too many parameters
- Long method
- Excessively long identifiers
- Excessively short identifiers
- Excessive return of data
*do not get stuck here
Tools - Test Patterns
Golden Master Test Pattern
Input
Output
{fizz buzz example}
Black
Box
{real world example}
Sources
Books:
XUnit Test Patterns: Refactoring Test Code - Gerard Meszaros
Refactoring: Improving the Design of Existing Code - Martin Fowler
- Code Comlplete 2 - Steve McConnell
SOA Patterns - Arnon Rotem-Gal-Oz
C# 3.0 Design Patterns - Judith Bishop
Specifications:
- IEEE std 42010-2011: Systems and software engineering - architecture description
Websites:
- http://spinemodel.info/
- https://spin.atomicobject.com/2013/02/23/ports-adapters-software-architecture/
- http://jasonpolites.github.io/tao-of-testing/ch4-1.1.html
- http://www.sparxsystems.com/downloads/whitepapers/FCGSS_US_WP_Applying_4+1_w_UML2.pdf
Tank you!
