|
Abusing Design Patterns
-- Christopher Bark
A couple of months ago a friend of mine approached me with a problem; he needed a way
to stop the construction of an object upon any failure. The answer was obvious to me, this
was what exception handling was made for. The answer I gave was wrong for the given
context though. The program he was writing was to be part of a real-time system. He wanted
to avoid using exception handling because it would slow his code down too much. There were
several things we could have done.
One solution would have been to use an operation which returned true if the object was
instantiated properly, false if it wasn't (the isOkay() operation). The problem with that
is that any programmer who creates an instance of this object can choose to ignore the
isOkay() operation and use the object anyhow, leaving a dangerously incomplete object in
the system. The other solution I've seen used is the use of double constructors, this is
done by having an operation ( initialize() ) which the programmer must call immediately
after construction. Once again, this solution put a little too much faith in the
programmer and left a possibility of having an incomplete object in the system.
I gave my friend another solution. Make the constructors all protected, and create a
class operation (called Instance() ) which returns an instance of the object if it was
successfully built and NULL if it wasn't (see example i).
That code was based on the Singleton pattern, taken from the book "Design
Patterns: Elements of Reusable Object-Oriented Software" but Erich Gamma, Richard
Helm, Ralph Johnson and John Vlissides. Almost everyone in the world of object oriented
programming is familiar with the 'Group of Four', it is one of the most useful
object-oriented books around. The Singleton pattern involves making the constructors all
protected, having a public class operation ( Instance() ) and a private class attribute (
called _instance in the book). This pattern is used in situations where you only want one
instance of an object which is available globally in your program (A slight variation
allows for a controlled number of instances instead of one). The first time Instance() is
called an instance is created and stored in the _instance attribute and a pointer to that
instance is returned. Anytime Instance() is called after that a pointer to the object
created the first time is returned.
I have seen a lot of the patterns in the book used, mainly at work (at both my current
job and my previous one), but also at school. I don't think I've ever seen anyone take a
pattern and maim it beyond recognition like I did, people seem to be content using the
patterns exactly as they appear in the book. This seems wrong to me, the patterns book
shouldn't be pulled off the shelf just to copy out the class diagrams and code snippets
given. Each of the patterns in the book has a very abstract idea around it, the Singleton
method for example introduces the idea of having complete control of the construction of
the instances of a class. The Singleton itself controls the number of objects constructed,
whereas my program controlled whether an object could be constructed. By not using the
abstract ideas behind each of the patterns, we are abusing them.
|
