Design Patterns – Should Object-Oriented Code Always Follow a Design Pattern?

designdesign-patternsobject-orientedobject-oriented-design

Is there a conceivable design pattern for any object-oriented program? I ask this because recently I saw an implementation of a Door class with a Lock. It was part of a test and the answer said that the code is following the Null Object pattern:

class Lock
{
public:
    virtual void close() = 0;
    virtual void open() = 0;
    virtual bool is_open() const = 0;
    virtual ~Lock() { }
};

class DummyLock
    : public Lock
{
private:
    DummyLock();
    DummyLock(const DummyLock&) = delete;
    DummyLock& operator=(const DummyLock&) = delete;

private:
    void close() { }
    void open() { }
    bool is_open() const { return true; }

public:
    static DummyLock m_instance;
};

class Door
{
public:
    Door() : m_lock(DummyLock::m_instance) { }
    Door(Lock &lock) : m_lock(lock) { }

public:
    Lock& get_lock() const { return m_lock; }

private:
    Lock &m_lock;
};

This made me think: This code follows a good design pattern even though the description is so simple (this class is designing a door class with a lock), so if I am writing more complex code, should there always be some design pattern that I am following?

Best Answer

should there always be some design pattern that I am following?

Dear God NO!

I mean, you can go ahead and say that any random code is following some random XYZ pattern, but that's no more useful than me claiming to be king of my computer chair. Nobody else really knows what that means and even those that do won't exactly respect my claim.

Design patterns are a communication tool so that programmers can tell other programmers what has been done or what should be done without spending a bunch of time repeating themselves. And since they're things that come up a bunch of times, they're useful concepts for programmers to learn "hey, making XYZ always seems to come up because it's good/useful".

They do not replace the need for you to think for yourself, to tailor the patterns for the unique problem in front of you, or to handle all of the inevitable things that don't fit into nice buckets.

Related Topic