Patterns for the People
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Patterns for the People

  • 609 views
Uploaded on

Presented at NDC 2014 in Oslo (4th June 2014) ...

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
609
On Slideshare
554
From Embeds
55
Number of Embeds
3

Actions

Shares
Downloads
4
Comments
0
Likes
1

Embeds 55

https://twitter.com 52
http://www.slideee.com 2
https://tweetdeck.twitter.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Patterns for the People @KevlinHenney kevlin@curbralan.com
  • 2. 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.
  • 3. 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.
  • 4. 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
  • 5. I don't make stupid mistakes. Only very, very clever ones. John Peel
  • 6. http://xkcd.com/612/
  • 7. Failure is a far better teacher than success. Philip Delves Broughton http://www.ft.com/cms/s/0/f33f5508-f010-11e0-bc9d-00144feab49a.html
  • 8. If you want to learn how to build a house, build a house. Don't ask anybody, just build a house. Christopher Walken
  • 9. Programming is difficult business. It should never be undertaken in ignorance. Douglas Crockford JavaScript: The Good Parts
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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.
  • 14. 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.
  • 15. Style is the art of getting yourself out of the way, not putting yourself in it. David Hare
  • 16. 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
  • 17. Concurrency
  • 18. Concurrency Threads
  • 19. Concurrency Threads Locks
  • 20. 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.
  • 21. 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) ... ... }
  • 22. 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) ... ... }
  • 23. 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; }
  • 24. 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; }
  • 25. public final class Date implements ... { ... public int getYear() ... public int getMonth() ... public int getWeekInYear() ... public int getDayInYear() ... public int getDayInMonth() ... public int getDayInWeek() ... ... }
  • 26. public final class Date implements ... { ... public int year() ... public int month() ... public int weekInYear() ... public int dayInYear() ... public int dayInMonth() ... public int dayInWeek() ... ... }
  • 27. 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.
  • 28. 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); ... };
  • 29. 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);
  • 30. 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);
  • 31. Mutable Immutable Unshared Shared Unshared mutable data needs no synchronisation Unshared immutable data needs no synchronisation Shared mutable data needs synchronisation Shared immutable data needs no synchronisation
  • 32. 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/
  • 33. 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"
  • 34. Multithreading is just one damn thing after, before, or simultaneous with another. Andrei Alexandrescu
  • 35. Actor-based concurrency is just one damn message after another.
  • 36. 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
  • 37. 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.
  • 38. 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
  • 39. James Siddle "Choose Your Own Architecture" – Interactive Pattern Storytelling