Well, there is none…
Simply to put, there is no silver bullet.
Yet, while designing an application, there are several well known extremes:
"Heavy weighted design" – Such a design will use almost each and every pattern described in the bible of "Design Patterns" – by the Gang of Four.
However, squeezing as much as possible patterns into your design has a bad smell.
"Trying to use all the patterns is a bad thing, because you will end up with synthetic designs-speculative designs that have
"flexibility" that no one needs.These days software is too complex. We can't afford speculating what else it should do.
We need to focus on what it actually needs. That's why I like refactoring to patterns. People should learn that
when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution."
"Big ball of mud" or
"no design" at all – Though the application utilizes classes (objects) and methods, it does it solely due to the language
constraints. After all, the code must be placed somewhere and usually it lies in giant classes and methods. Besides that, there are no
abstraction layers or small and specialized objects that have "concise conversations" in order to solve the business
To use the patterns correctly, a Software Engineer must understand the context (=requirements) and the
suggested solutions depicted by the patterns. Usually, in the real life scenario, it's hard to
grasp where exactly is the right context to which a suggested design solution should be applicable. Especially for the inexperienced
Software Engineers, design patterns described by the Gang of Four's bible can confuse and lead to:
- Misidentify contexts and thus creation of "Big ball of mud" or "no design" applications.
- Over identify contexts (even where there is no context at all) and thus creation of "Heavy weighted design" applications.
That's where the Expert
pattern can be handy! Expert pattern is one of the General Responsibility Assignment Software Patterns. In essence it's a very basic and straightforward pattern
that helps to pinpoint what is the main responsibility of a method or a class. Just ask yourself: "What is the
real responsibility of the method/class? Is it really this method's/class's
responsibility to do that operation?". By
answering those questions it's possible to divide a system effectively to a lot of small, but cohesive objects, that really need to
collaborate together in order to solve your business requirements (which is what Object Oriented Design is really about).
So it comes, that though there is no "pattern to rule them all", using the Expert pattern/principle effectively, will allow
you to rule your application.