Design Pattern Session for Legacy Code Rocks Meetup

1. Understanding design
patterns fundamentals
Raquel Pau - WalkMod

2. When we do not use design patterns...
We need to add extra hours to modify features
We need to add extra hours to make test work
We have technical debt

3. Given When Then for Patterns
Given
an existing source code
When
I need to add a new feature X
Then
I do not need to modify
NOTHING
OPEN-CLOSE PRINCIPLE

4. Extensibility Metrics
u Coupling:
uHow many components are we using?
u Cohesion:
uHow many responsibilities this component
has?
But usually more components implies more responsibilities

5. Tools:
u Static Code Analysis Tools
u Coupling:
u To detect duplicated code
u To detect dead code
u To detect excessively referenced components
u Cohesion:
u Number of methods / fields of a component
u Modeling Language Tools to discuss architectures
u UML class diagrams
u UML sequence diagrams

6. Conway’s law:
interfaces are similar communication
channels between companies
and we have communication patterns, right?

7. everything consists of using interfaces
u Interfaces isolates definitions from implementations
u Please, delegate work! (Demeter’s law):
u Delegate the maximum work to the specialized components
u The most common interface usage scenarios are called design
patterns.
u Having clear and uniform architectures could allow generating
code when new domain entities need to be added.

8. Design Pattern Categories
u Architectural/Application patterns
u Gang of Four patterns
u Creational
u Structural
u Behavioural
u Concurrency patterns

9. Architectural / Application patterns
u Inversion of Control
u Front Controller
u Interceptor Controller
u Data Access Object
u Data Transfer Object
u ...
and application frameworks usually implement most of them

10. Gang of Four Patterns
u Creational Design Patterns
u Singleton, Factory, Builder, Object Pool
u Behavioural Design Patterns
u Chain of Responsibility, Command, Iterator, Observer,
Facade, Strategy, Template, Visitor, ...
u Structural Design Patterns
u Adapter, Decorator, Bridge, Proxy, ...
most of them are domain driven strategies

11. Concurrency Patterns
u Scheduler
u Thread Pool
u Thread Local Storage
u Event-based asynchronous
u ...

12. Applying design patterns on legacy code
u Keep calm:
u It is impossible to predict all the future changes of a software
u Over engineering risk.
u Algorithm:
u Add test coverage if it is missing for legacy code first.
u Refactor existing code with the desired patterns afterwards.

13. Programming languages and Patterns
u Motivation of a programming language:
u Do more in less code
u Resolve specific performance/concurrency problem
u Write less do not always mean be more readable or
reusable
u Functional programming

14. Exercise
https://github.com/rpau/designpatterns