I've been having a bit of trouble blogging recently. In an effort to get back into it, I thought I'd take a talk that I presented at JAX London last year, split it up into blog-sized posts as it's pretty long, and post them all week. If you haven't read it before or seen the talk, I hope you enjoy it.
Oh, and if you'd rather just read the whole thing in one go, flick through the slides (which are almost entirely code), or watch the recorded version as a video, head to my talks page.
What do you want from me?
I want you to stop using design patterns.
OK, let me rephrase that.
I want you to stop using design patterns like it's 1999.
This is a book.
Design Patterns was a book by the "Gang of Four", first published very nearly 20 years ago (at the time of writing this essay), which attempted to canonicalise and formalise the tools that many experienced software developers and designers found themselves using over and over again.
The originator of the concept (and the term "design pattern") was Christopher Alexander, who wasn't a software developer at all. Alexander was an architect who came up with the idea of rigorously documenting common problems in design with their potential solutions.
The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. — Christopher Alexander
Alexander, and the Gang of Four after him, did more than just document solutions to common problems in their respective universes. By naming these patterns and providing a good starting point, they hoped to provide a consistent language, as well as providing these tools up front so that even novices might benefit from them.
Because Preparation is an interface with a Single Abstract Method, any lambda with the same type signature as Preparation's method signature can be assigned to an object of type Preparation. This means that Preparation is a functional interface.
We can go one further. Let's extract that new CakeMix out. Assuming it's an immutable object with no external dependencies, this shouldn't be a problem.
Mixmix = new CakeMix(eggs, butter, sugar);PreparationprepareCake =deliciousIngredient-> mix.combinedWith(deliciousIngredient);
Then we can collapse that lambda expression into a method reference.