Posts Tagged ‘Design Patterns’

Graphics, Text, And Source Code

December 29, 2011 3 comments

On the left, we have words of wisdom from Grady Booch and friends. On the right, we have sage advice hatched from the “gang of four“. So, who’s right?

Why, both groups are “right“. If all you care about is “recording the design in source code“, then you’re “wrong“…

If you’re a software “anything” (e.g. architect, engineer, lead, manager, developer, programmer, analyst) and you haven’t read these two classics, then either read them or contemplate seeking out a new career.

But wait! All may not be lost. If you think object orientation is obsolete and functional programming is the way of the future, then forget (almost) everything that was presented in this post.

Chain Of Responsibility

February 10, 2011 2 comments

One of the well known design patterns in the object-oriented software world is named “Chain Of Responsibility“. The UML sequence diagram below shows an example of how the software objects in the pattern collaborate with each other in order to ensure that a user initiated help request is handled somewhere in the GUI of an application.

As you might surmise, the world of hierarchical superiority has an analogous pattern, err anti-pattern, named “Chain Of Irresponsibility“. Do ya think I need to add words to explain the inter-object collaborations for this pattern as shown in the UML sequence diagram that follows?

In case you were wondering, S = Senior, BM = Bozo Manager, and DIC = Dweeb In the Cellar.

Recursive Interpretation

February 1, 2011 Leave a comment

In their classic book, Design Patterns, the GoF defines the intent of the Interpreter pattern as:

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

For your viewing pleasure, and because it’s what I like to do, I’ve translated (hopefully successfully) the wise words above into the SysML block diagram below.

Moving on, observe the copied-and-pasted pseudo-UML class diagram of the GoF Interpreter design pattern below. In a nutshell, the “client” object builds and initializes the context of the sentence to be interpreted and invokes the interpret() operation – passing a reference to the context (in the form of a syntax tree) down into the concrete “xxxExpression” interpreter objects in a recursive descent so that they can do their piece of the interpretation work and then propagate the results back up the stack.

In their writeup of the Interpreter design pattern, the GoF state:

Terminal nodes generally don’t store information about their position in the abstract syntax tree. Parent nodes pass them whatever context they need during interpretation. Hence there is a distinction between shared (intrinsic) state and passed-in (extrinsic) state.

Since the classes in the Interpreter design pattern aren’t thinking, feeling, scheming humans concerned about status and looking good, the collection of collaborating classes do their jobs effectively and efficiently, just like mindless machines should. However, if you try to implement the Interpreter pattern on a project team with human “objects”, fuggedabout it. To start with, the “client” object (i.e. the boss) at the top of the recursion sequence won’t know how to create a coherent sentence or context.  Even if the boss does do it, he/she may intentionally or unitentionally  withhold the context from the recursion chain and invoke the interpret() operation of the first “XXXExpression” object (i.e. worker) with garbage. When the final interpretation of the garbled sentence is returned to the boss, it’s a new form of useless garbage.

On it’s way down the stack, at any step in the recursive descent, the propagated context can be distorted or trashed on purpose by self-serving intermediate managers and workers. Unlike a software system composed of mindless objects working in lock-step to solve a problem, the chances that the work will be done right, or even defined right, is miniscule in a DYSCO.

%d bloggers like this: