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.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply