Presented at NDC 2014 in Oslo (4th June 2014)
Video available on Vimeo: https://vimeo.com/97344527
Apparently, everyone knows about patterns. Except for the ones that don't. Which is basically all the people who've never come across patterns... plus most of the people who have.
Singleton is often treated as a must-know pattern. Patterns are sometimes considered to be the basis of blueprint-driven architecture. Patterns are also seen as something you don't need to know any more because you've got frameworks, libraries and middleware by the download. Or that patterns are something you don't need to know because you're building on UML, legacy code or emergent design. There are all these misconceptions about patterns... and more.
In this talk, let's take an alternative tour of patterns, one that is based on improving the habitability of code, communication, exploration, empiricism, reasoning, incremental development, sharing design and bridging rather than barricading different levels of expertise.
4. Habitability is the characteristic of
source code that enables programmers,
coders, bug-fixers, and people coming
to the code later in its life to
understand its construction and
intentions and to change it comfortably
and confidently.
5. Habitability makes a place livable, like
home. And this is what we want in
software — that developers feel at
home, can place their hands on any
item without having to think deeply
about where it is.
6. pattern
a regular form or sequence discernible in the way in
which something happens or is done.
an example for others to follow.
a particular recurring design problem that arises in
specific design contexts and presents a well-proven
solution for the problem. The solution is specified by
describing the roles of its constituent participants, their
responsibilities and relationships, and the ways in
which they collaborate.
Concise Oxford English Dictionary
Pattern-Oriented Software Architecture, Volume 5: On Patterns and Pattern Languages
7. I don't make stupid mistakes.
Only very, very clever ones.
John Peel
15. Mark Pagel at the University of Reading, UK, doubts that
hominins before Homo sapiens had what it takes to innovate
and exchange ideas, even if they wanted to. He draws a
comparison with chimps, which can make crude stone tools
but lack technological progress. They mostly learn by trial
and error, he says, whereas we learn by watching each other,
and we know when something is worth copying.
http://www.newscientist.com/article/mg21328571.400-
puzzles-of-evolution-why-was-technological-development-so-slow.html
16. Anti-patterns don't provide a resolution of forces as
patterns do, and they are dangerous as teaching
tools: good pedagogy builds on positive examples
that students can remember, rather than negative
examples. Anti-patterns might be good diagnostic
tools to understand system problems.
James Coplien, Software Patterns
17. Wise men profit more from fools than
fools from wise men; for the wise men
shun the mistakes of fools, but fools do
not imitate the successes of the wise.
Cato the Elder
18. One of the hallmarks
of architectural design
is the use of idiomatic
patterns of system
organization. Many of
these patterns — or
architectural styles —
have been developed
over the years as
system designers
recognized the value
of specific
organizational
principles and
structures for certain
classes of software.
19.
20. We know that every pattern is an instruction of the general form:
context conflicting forces configuration
So we say that a pattern is good, whenever we can show that it
meets the following two empirical conditions:
1. The problem is real. This means that we can express the
problem as a conflict among forces which really do occur
within the stated context, and cannot normally be resolved
within that context. This is an empirical question.
2. The configuration solves the problem. This means that when
the stated arrangement of parts is present in the stated
context, the conflict can be resolved, without any side effects.
This is an empirical question.
21.
22.
23. Style is the art
of getting
yourself out of
the way, not
putting yourself
in it.
David Hare
24. Some people, when confronted with a
problem, think, "I know, I'll use threads,"
and then two they hav erpoblesms.
Ned Batchelder
https://twitter.com/#!/nedbat/status/194873829825327104
29. Immutable Value
References to value objects are commonly distributed and
stored in fields. However, state changes to a value caused
by one object can have unexpected and unwanted side-
effects for any other object sharing the same value
instance. Copying the value can reduce the
synchronization overhead, but can also incur object
creation overhead.
Therefore:
Define a value object type whose instances are immutable.
The internal state of a value object is set at construction
and no subsequent modifications are allowed.
30. public class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getDayInMonth() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setDayInMonth(int newDayInMonth) ...
...
}
31. public class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInMonth() ...
public int getDayInWeek() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setWeekInYear(int newWeek) ...
public void setDayInYear(int newDayInYear) ...
public void setDayInMonth(int newDayInMonth) ...
public void setDayInWeek(int newDayInWeek) ...
...
}
32. public class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInMonth() ...
public int getDayInWeek() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setWeekInYear(int newWeek) ...
public void setDayInYear(int newDayInYear) ...
public void setDayInMonth(int newDayInMonth) ...
public void setDayInWeek(int newDayInWeek) ...
...
private int year, month, dayInMonth;
}
33. public class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInMonth() ...
public int getDayInWeek() ...
public void setYear(int newYear) ...
public void setMonth(int newMonth) ...
public void setWeekInYear(int newWeek) ...
public void setDayInYear(int newDayInYear) ...
public void setDayInMonth(int newDayInMonth) ...
public void setDayInWeek(int newDayInWeek) ...
...
private int daysSinceEpoch;
}
34. public final class Date implements ...
{
...
public int getYear() ...
public int getMonth() ...
public int getWeekInYear() ...
public int getDayInYear() ...
public int getDayInMonth() ...
public int getDayInWeek() ...
...
}
35. public final class Date implements ...
{
...
public int year() ...
public int month() ...
public int weekInYear() ...
public int dayInYear() ...
public int dayInMonth() ...
public int dayInWeek() ...
...
}
36. Copied Value
Value objects are commonly distributed and stored in
fields. If value objects are shared between threads,
however, state changes caused by one object to a value
can have unexpected and unwanted side effects for any
other object sharing the same value instance. In a multi-
threaded environment shared state must be synchronized
between threads, but this introduces costly overhead for
frequent access.
Therefore:
Define a value object type whose instances are copyable.
When a value is used in communication with another
thread, ensure that the value is copied.
37. class date
{
public:
date(int year, int month, int day_in_month);
date(const date &);
date & operator=(const date &);
...
int year() const;
int month() const;
int day_in_month() const;
...
void year(int);
void month(int);
void day_in_month(int);
...
};
38. class date
{
public:
date(int year, int month, int day_in_month);
date(const date &);
date & operator=(const date &);
...
int year() const;
int month() const;
int day_in_month() const;
...
void set(int year, int month, int day_in_month);
...
};
today.set(2014, 6, 4);
39. class date
{
public:
date(int year, int month, int day_in_month);
date(const date &);
date & operator=(const date &);
...
int year() const;
int month() const;
int day_in_month() const;
...
};
today = date(2014, 6, 4);
42. Shared memory is like a canvas where
threads collaborate in painting images,
except that they stand on the opposite
sides of the canvas and use guns rather
than brushes. The only way they can
avoid killing each other is if they shout
"duck!" before opening fire.
Bartosz Milewski
"Functional Data Structures and Concurrency in C++"
http://bartoszmilewski.com/2013/12/10/functional-data-structures-and-concurrency-in-c/
43.
44. Instead of using threads and shared memory
as our programming model, we can use
processes and message passing. Process here
just means a protected independent state
with executing code, not necessarily an
operating system process.
Languages such as Erlang (and occam before
it) have shown that processes are a very
successful mechanism for programming
concurrent and parallel systems. Such
systems do not have all the synchronization
stresses that shared-memory, multithreaded
systems have.
Russel Winder
"Message Passing Leads to Better Scalability in Parallel Systems"
45. Multithreading is just one
damn thing after, before, or
simultaneous with another.
Andrei Alexandrescu
48. Sender Receiver A
Message 1Message 3
Receiver B
In response to a message that it receives, an actor
can make local decisions, create more actors, send
more messages, and determine how to respond to
the next message received.
http://en.wikipedia.org/wiki/Actor_model
49.
50.
51. A pattern’s audience
is ultimately always
human. Although a
developer may
support application
of a software pattern
solution through
libraries and
generators, it is the
developer and not the
technology that is
aware of the pattern.
52.
53.
54.
55. History rarely happens
in the right order or
at the right time, but
the job of a historian
is to make it appear
as if it did.
James Burke