I guess every programmer needs some guidelines in designing Object-oriented (OO) software. Especially when you're dealing with programming languages such as C , which isn't very syntactically friendly as compared with your high-level object-oriented programming languages such as Java or C#. If you want your code to be readable and flexible, and perhaps solve real world problems a good start would be reading about Design Patterns. In my own experience in reading about design patterns, design patterns will aid you in realizing the following items:
- See how you can make objects out of everything -- even your own code!
- Gain insight of what available design strategies in coding are already available.
- Turn your code into something both elegant and efficient.
With that said, many programmers are often misguided by reading about design patterns as well. Quite contradictory ain't it? It's primarily because of the programmers who read about it are trying too hard to put their problems into patterns, whereas they should be trying their best in solving their problems in the first place. Programmers are often engrossed with design patterns after knowing about it, and would like to apply them in their arsenal forcefully. This is wrong and should be avoided. If you haven't noticed how many times I've placed the word "guidelines" in describing design patterns. That's because that's what they really are -- guidelines. They are not rules that you strictly follow. You shouldn't even implement the patterns 1:1 as how they are in literature. You must first check your problem first and see if some techniques in existing patterns would work out.
For instance I've been wondering if I should really apply Singleton and Abstract Factory to handle the creation of my classes of the same kind but with different implementations like so:
class ObjectFactory : public Singleton< ObjectFactory >
{
public:
Object * Create( eObjectTypes p_type )
{
switch( p_type )
... // cut for brevity
}
};
True, I need a factory to simplify object creation of classes of the same kind but with different implementations. However, I need it such that I can accessibly call it in most areas of my code, and I just needed one instance of it. Herein comes the Singleton pattern.
After a few minutes of thinking. I realized that the Singleton is unnecessary because it acts just like a namespace! Another problem to using Singleton is you have to bother yourself with handling the instance of the singleton (creating and destroying). Namespace can make it differentiate from other possible implementations with the same name. Namespaces also provide the bounds provided by class but with lesser memory footprint. No need for instatiation and destruction of the factory. So, in the end I have this much simpler implementation:
namespace ObjectFactory
{
Object * Create( eObjectTypes p_type )
{
switch( p_type )
... // cut for brevity
}
}
Same purpose, same functionality, and same accessibility but easier and shorter to write, and less memory consumed. A fine example wherein you just have to see Design Patterns as a guide and not as a rule.
