Additional Options
  • Sections:

  • Your accented quote and dictionary feed
    Vig: the interest paid to a loanshark for the loan. Abbreviation of vigorish; also see juice. Usually two points or 2%.
    The Sopranos: Mobspeak
    Design Patterns: Path to a Solution or a Path to Over-Engineering? 06/27/2011 14:01

    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 to your high-level object-oriented programming languages such as Java or C#. If you want your code to be readable, re-usable, flexible, scalable, and perhaps solve real-world problems, a good start would be reading about Design Patterns. In my own experience, reading about 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 >
        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. Here, 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.


    Leave a Reply

    Your email address will not be published. Required fields are marked *


    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

      Who is it?
      What's the password?
     Don't forget.
    Still a nobody?
    Lost password

    05/22/2011 21:12
    Welcome real humans! Shoo spammers and bots!

    Only members can participate.