Optimistic locking is like leaving the door to the toilet open: you have a number of toilets, select one, and you are optimistic that nobody will come to use the same toilet, too. If someome comes, it will of course be embarassing, an exception is raised, and he must abort his try, but you hope that these conflicts are the execption.

Pessimistic locking is like always locking the door to the toilet: although there are a number of different toilets, you are expecting every time that somebody else will come to use one, too, and that the only safe option is to lock all toilet doors (which corresponds to page locking). If someone comes and wants to use a toilet, he cannot enter and must wait before the locked door.

Found at Optimistic vs. Pessimistic Locking.

Well, clear naming has nothing special to talk about. High granularity is all about code decomposition (The Single Responsibility principle can also be applied here).

One of frequent reasons for the code branching is a ramification of logic depending on some object’s internal state (normally, it is a domain class object). Such branching can be “switch”-style – when you compare a particular state variable with its possible values. However, a more common and basic is the binary branching, which operates on boolean conditions. E.g., if object is in this state then do this else do that.

Often there is a need to repeat such logic in many places throughout the application code. Additionally, such logic may happen to be more intricate than one conditional if statement. To simplify it one may define appropriate isXXX() method(s) to the examined object’s class. But what if the object state is fairly complex or domain class is not aware of its possible states, or the logic examining its state is not limited to several cases, but more cases can be developed in future. Or even, you can be trapped in a situation, when you are not allowed to change the domain object class.

So here is an elegant solution… it’s the Matcher pattern! This is a pretty simple design pattern that consists of three classes in general case. The pattern’s class diagram is following:

There are the Entity class which is the specific domain class, the Matcher which is an abstract class or interface with a single abstract method that represents the matching algorithm, and the ConcreteMatcher which is a specific implementation of Matcher.

When implementing the pattern, Java generics can be leveraged to provide more flexibility with less code.

What is even more beautiful about the Matcher is that it can be injected into classes that rely on its logic. E.g.

Besides logic reuse and simplification, another nice use of Matcher is the collection filtering.

I believe, similar “Matcher” approaches have been used in many projects independently. One described here can have pretty big number of various applications, so is worthy of being stated as a design pattern.

For these and other similar reasons the design patterns and agile methodologies are “mainstream” now, and that’s why are severely required to follow in many organizations (perhaps, you have heard something like “this is not compliant with this or that design pattern or best practice, so is wrong!”). However, while thinking of patterns against real life, you may find that they are merely common recommendations and do not provide “every hole fitting” solutions – ’cause simply it’s (almost) impossible – and then you spent long time searching for a pattern that fits your problem the best or how to apply that given pattern to it. There are so many general design patterns, so that in some cases they overlap and provide confusion. In the end, we’ve got lots of anti-pattens. Doesn’t it sound a bit of non-sense?

Thinking of pattens further, I find them restricting a developer’s fantasy (one, who is able to think and generate his own ideas). Moreover, patterns are simply a set of terms or names for widely known notions which were (and are being!) forged in many organizations. With time new patterns appear, evolve, replace older ones, and it is normal process since new problems to be solved appear. Patterns are being “invented” and shouted out and sold (indirectly).

Concluding, in my opinion, the design patterns or principles should not be considered as a rigorous tool and used blindly, though do not forget that patterns are your basic and fast knowledge and don’t afraid improve them… so sometimes you will have to make a choice: to drag in a mainstream (for the “it’s cool!” sake), or start your own one!