Cookblog — How to leverage lambda expressions for design patterns in Java 8

First of all, what is design pattern? Design pattern is a solution to a software design for a problem having some characteristics.

Perhaps, some people try to fit every problem in one of the design pattern. Do not fit every problem in a design pattern unless needed.

As we know that lambdas have helped to remove the dependency of creating anonymous classes and the boilerplate code. Lambdas have been served as building blocks for other features like streams, etc.

I am here trying to enlist some practices - based on my understanding - to use lambdas for design patterns.

Iterator pattern

Did you know that you can blog right from your published website? After you publish your site, go to your website’s URL and login with your Wix account. There you can write and edit posts, manage comments, pin posts and more! Just click on the 3 dot icon ( ⠇) to see all the things you can do.

With the internal iterators, you can focus more on the business logic than the how to iterate. forEach is available on java collections. Several third party libraries also started providing internal iterators viz. Apache Jackson APIs have forEach.

Things to remember:

1. Pass a function reference, not method reference. Perhaps we use terms method and function interchangeably. But immutability is main difference, function does not mutate the data, whereas method can mutate the data.

2. Do not pass a function which have side effects. For ex: if function is generating some another collection, events, etc.

Template method pattern

Template method pattern defines an common/generic algorithm for a particular operation whereas it calls few other abstract or default methods - traditionally - whose behavior will be defined by its child classes.

Things to remember:

1. Before going to define abstract or default method and implementing or overriding it in the child class. Try to think the other way around as follows:

2. Receive the function reference in the constructor, potentially it will reduce the creation of child classes just to override/implement the method.

Strategy pattern

Typically we create another interface (to have uniform contract to call strategies) and its child class hierarchy for defining strategies.

Instead accept strategy as function reference, it will potentially reduce the class hierarchy created for strategies.

Decorator pattern

Traditionally, you can have a base object and you wrap it using other additives using a common base class. For ex: say, you are buying a gift. You can have several options to decorate it. The cost of gift will be calculated as cost of gift and cost of its all decorated ornaments.

Using lambda, you can create a combo/container class which will contain the collection of base gift item and all additives. For ex: for the above example, you can calculate cost of combo using the cost of each gift item of collection.