The Ambiguous Viewpoint AntiPattern

The ambiguous viewpoint anti-pattern is one that goes to the heart of object-oriented design.  We want to abstract and isolate functionality in a way that follows a pattern of logic.  This goal is often achieved, in part, through segmenting functionality by viewpoint.  Thus, we have the business, data, and view related code grouped in their separate areas.

Defining the Ambiguous Viewpoint AntiPattern

I found a good explanation of this anti-pattern on a page worth checking out for several others as well. [Click Here to See The Page]

"Object-oriented analysis and design  models are often presented without clarifying the viewpoint represented by the model. By default, this models denote an implementation viewpoint that is potentially the least useful. Mixed viewpoints don’t allow the fundamental separation of interfaces from implementation details, which is one of the primary benefits of the object-oriented paradigm."

The definition above helps highlight an essential point of object-oriented design.  If you decide to use it, then do so wholly and correctly.  When you choose to use OOD principle only in select cases, then it tends to make the solution worse rather than better.  It can even lead us to spaghetti code situations.  All-in or not-at-all are your two choices.

Design Before Code

The most common way to fall into this anti-pattern is to code as you go without considering the design.  It often appears in source code that was created with a heads-down approach.  We get into a groove of writing features and skip the step where we think about where they should live.  It is almost a convenience based anti-pattern.  There may be a method to our madness; however, that does not provide comfort to those that have to maintain our code.

Pseudocode To Success

There are many ways to avoid the ambiguous viewpoint problem.  However, I find that one of the best solutions is to use pseudocode or comments before coding.  This simple process forces you to think a little bit before you code and slows us down a little.  This time for reflection and design may be just enough to help us consider that maybe we are doing this in the wrong location.