क्या किसी वस्तु-उन्मुख कार्यक्रम के लिए एक बोधगम्य डिजाइन पैटर्न है? मैं यह पूछता हूं क्योंकि हाल ही में मैंने एक Doorवर्ग के कार्यान्वयन को देखा था Lock। यह एक परीक्षण का हिस्सा था और जवाब में कहा गया था कि कोड नल ऑब्जेक्ट पैटर्न का अनुसरण कर रहा है:
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;
};
इससे मुझे लगता है: यह कोड अच्छे डिज़ाइन पैटर्न का अनुसरण करता है, भले ही विवरण इतना सरल हो (यह वर्ग एक लॉक के साथ एक डोर क्लास डिजाइन कर रहा है), इसलिए यदि मैं अधिक जटिल कोड लिख रहा हूं, तो क्या हमेशा कुछ डिज़ाइन पैटर्न होना चाहिए कि मैं पीछा कर रहा हूँ?
3
बहुत संबंधित: सही डिज़ाइन पैटर्न चुनना
क्या आपको लगता है कि आप पूरी तरह से मुहावरों में बोल सकते हैं? नहीं? फिर आपको अपने कार्यक्रमों का निर्माण एक साथ डिज़ाइन पैटर्न के अनुसार करना चाहिए।
—
किलियन फोथ
आपके उदाहरण में, नल ऑब्जेक्ट पैटर्न केवल शैक्षणिक उद्देश्यों के लिए जोड़ा गया है, यह इस कोड में "एक अच्छा डिज़ाइन" नहीं पेश करता है।
—
डॉक्टर ब्राउन 19
@djechlin: दूसरे शब्दों में, "दो शब्द" डिजाइन पैटर्न का उपयोग करें :)
—
माइकल शॉ
समस्या यह है कि बहुत से लोग मानते हैं कि डिजाइन पैटर्न विचार का एक विकल्प है, और अनुभव का एक विकल्प है (जो एक निश्चित मात्रा में परीक्षण और त्रुटि का अर्थ है)। आप गैर-तुच्छ आकार और जटिलता और सभ्य गुणवत्ता के साथ एक एप्लिकेशन का निर्माण करने के लिए डिज़ाइन पैटर्न से भरी किताब नहीं ले सकते हैं और उन्हें टिंकर खिलौने की तरह एक साथ रख सकते हैं। यहां तक कि अनुभवी प्रोग्रामर को भी दो या तीन डिजाइनों की कोशिश करने की आवश्यकता होती है इससे पहले कि वे एक काम करते हैं।
—
डैनियल आर हिक्स