Design Patterns for Fun and Profit is a talk about design patterns and metaprogramming in multiple languages, comparing static typed languages like Java and C++ with dynamic languages like Python, Ruby and Javascript. Example code can be found here: https://github.com/dlitvakb/patterns_cc2018

1. Design
Patterns
for Fun &
Profit
David Litvak Bruno
@dlitvakb
Contentful
CoderCruise 2018

2. I’m David Litvak Bruno
I’ve been working with and teaching
Python and Ruby for the past 10 years
I currently work at Contentful in Berlin
as an Ecosystem Engineer creating
SDKs, tools and example apps using
Python, Ruby and Javascript.
Recent father of Julián
Who am I?

3. Before we start…
Some stuff we need to know

4. Static Typing
● Explicit typing contracts,
defined before compilation
time
● Typed references
● Immutable object
interfaces
Type Systems - Differences
Dynamic Typing
● Type defined through
usage, and not definition
● References are just names
for object instances and
don’t contain type
information
● Object interfaces are
mutable and can evolve

5. They are static
What tools do they provide?
● Strong, compile-time checked, interfaces
● Compile-time type safety (with the exception for null pointers)
● Limited runtime reflection capabilities
Type Systems - Java & C++

7. They are dynamic
What tools do they provide?
● Duck typing
● Code interception
● Introspection
● Reflection
● Self-modification
Type Systems - Python, Ruby &
Javascript

9. Dynamic Languages - Features
The features that allow us to “obsolete” traditional design patterns:
● Rich types
● Functions and classes as first-order objects
● Magic methods
○ Interceptors
○ Implementors
○ Introspectors
○ Constructors (Allocators)
● Contexts
● Multiple Inheritance

10. Late 70’s: Christopher Alexander’s: “A Pattern Language”
A bit of history

11. A bit of history
10 years later: Kent Beck and Ward Cunningham, started developing
a Pattern Language for Object Oriented Software and presented it at
OOPSLA

12. A bit of history
In 1994: The book that popularized design patterns

13. A bit of history
Throughout the following years: other literature started appearing
covering patterns for software architecture, testing, security and
other areas of software

14. Design Patterns
What’s a pattern?
We often found many problems with similar solutions, by analyzing it
we found that, even though all solutions are different, they all use
similar strategies to solve them.
Therefore, design patterns, are generalizations to those solutions for
common problems while designing software systems.
To explain design patterns, we need to specify 4 key items:
● Problem it solves
● Traditional usage
● Applicability
● Example implementation

16. A foreword of advise

18. Design Patterns - Categories
● Structural
○ Affect interaction of objects with the surrounding system
● Behavioural
○ Affect behaviour of objects
● Creational
○ Affect creation (or not) of objects

19. Proxy
What: Transparently intercepts all methods of an object to add
behaviour surrounding them.
How: Through composition and redefinition of the full interface.
When: An example usage is to add logging to every method call.
Design Patterns - Structural

20. Abstract Factory
What: Creates children objects of multiple different classes within a
family masking the actual implementation class.
How: Static method on an abstract base class that takes some
configuration and decides which implementation to use based on it. It
will return an instantiated object of a concrete child class.
When: An example usage is for instantiating an ORM which supports
different database engines and decides which one to use based on
the connection string.
Design Patterns - Creational

21. Iterator
What: Provides an interface for iterating through an object as if it
were a native collection.
How: Through implementation of an Iterable interface, limiting
heavily the scope of what an actual collection provides.
When: It’s typically used when internal structure is not relevant to be
exposed and it’s desired to be treated as a collection.
Design Patterns - Behavioural

22. Memento
What: Saves intermediate states to allow for replaying an object’s
history.
How: Usually through a persistence layer (in database or in memory)
tightly coupled with the implementation details of the concrete class.
When: When requiring some kind of change log, like a text editor’s
undo/redo, a games replay system or a web-browser’s history.
Design Patterns - Behavioural

23. Observer
What: Monitors state changes and signals interested object.
Composed of an event emitter (Observable) and an event listener
(Observer).
How: Observable objects register to observers. Observers
need to define a tightly coupled interface on how they are
supposed to trigger the received update event.
When: Commonly used in UI programming and when dealing
with database events and other components need notification
of interaction.
Design Patterns - Behavioural

24. State and Strategy
What: Runtime swap of object behaviour. Strategy applies to a single
method, while State applies to the whole class behaviour.
How: Object composition on a tightly coupled hierarchy.
When: In cases where objects need to change behaviour
depending on some object state, for example the calculation
formula of taxes on a purchase may differ from place to place.
Or a Person object could behave differently depending on
their age.
Design Patterns - Behavioural

25. By using dynamic languages, we obtain some superpowers and can
make extremely complex things simple.
Conclusion

26. Conclusion

27. Conclusion
Having access to these tools though, will broader your way of
thinking about problems and surface solutions you may not have
thought about before.

28. Step 1: Apply patterns
Step 2: ???
Step 3: Profit

29. Questions?
@dlitvakb
david.litvak@contentful.com
http://github.com/dlitvakb