Could You Please Specify This?

Follow the open/closed principle with the specification pattern

As a software developer, you’ve probably found yourself in situations where a feature requested by the business started out simple, but eventually became a nightmare as new use cases were added for which the code was not designed.

To make it a bit more clear, let’s start with a simple exchange you may have heard before:

Customer: Pro users should be highlighted: make their user names bold and red.
Developer: OK, no problem — but when is a user a Pro user?
Customer: Well that’s easy: either the user ID is greater than 1000, or the user flags contain the PRO flag, or the user ID is in our Pro database. Yeah, I think that’s it.
Developer: Hmm OK, those are more criteria than I thought — but I can do that.
Customer: Oh, and don’t forget about the Premium user. They’re similar (but different) and they must not be mixed up with Pro users. A user is a Premium user if their user ID is a premium ID or the user flags contain the PREMIUM flag.
Developer: And what are Premium IDs?
Customer: OK, this time it’s really simple: 5, 8, 234, 444 and 999.
Developer: Um yeah, OK, of course…

I’m pretty sure lots of you have had customers meetings that went like that…

In a simple User class, this logic could look something like this:

That looks good, doesn’t it? Well, it’s OK — but it could be better.

What bothers me here is:

Let’s try to get rid of these pain points by using the specification pattern.

For everyone who already has experience with this pattern, I know this description sounds pretty simple — maybe too simple — but please be lenient with me: I think it’s enough to get a rough idea.

First, let’s remove all the business logic from our User class to make it a simple DTO.

Now let’s create two new specification classes. One for the PRO and another for the PREMIUM logic.

The logic for deciding if the user is a PRO or a PREMIUM user didn’t change, it has just been moved somewhere else.

Let’s compare each approach.

Without the specification pattern, the implementation might look like this:

With the specification pattern, we might implement it like this:

What you can see here is that from a usage perspective not much has changed.

So what are the main benefits of this solution compared to the initial approach?

If you have any thoughts and experiences with the specification pattern, please share in the comments.

Related posts:

A Cape Cod librarian talks about a library’s process of weeding, recycling, and redistributing discarded library books.

Perhaps you have noticed somebody in a costume party who’s not wearing a costume? Looks odd doesn’t it. That’s the reason entrepreneurs utilize something called native advertisements. To put it…

Apache Camel has included support for distributed tracing using OpenTracing since Camel version 2.19.0. OpenTracing is a vendor neutral API to enable applications to report tracing information to a…