प्रेक्षक पैटर्न: श्रोताओं से सूचियों और नेस्टेड गुड़िया

इस हेब्रस्ट्रेटी में, ऑब्जर्वर और लिंकर पैटर्न के उदाहरण का उपयोग करते हुए, हम विचार करते हैं कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के सिद्धांतों को कैसे लागू किया जाए, कब रचना का उपयोग करना है, और कब वारिस करना है। और यह भी माना जाता है कि कॉपी-पेस्ट को छोड़कर कोड पुन: उपयोग के क्या तरीके मौजूद हैं।

लेख काफी सरल है, यह स्पष्ट चीजों पर चर्चा करता है, लेकिन मुझे उम्मीद है कि यह नौसिखिए प्रोग्रामर के लिए दिलचस्प होगा, जो अब तक प्रोग्रामिंग व्याख्यान में पहले पैराग्राफ से केवल शब्दों के साथ मिले हैं। (वास्तव में, यह लेख प्रोग्रामिंग पर एक व्यावहारिक सबक का एक टुकड़ा है।)


तो, आइए वस्तुओं के अवलोकन के लिए हमारे पास निम्न इंटरफ़ेस है।

interface AListener { public void aChanged(); public void bChanged(); } 

और अवलोकन योग्य वस्तुओं के लिए कुछ ऐसे वर्ग।

 class AEventSource { private List<AListener> listeners = new ArrayList<AListener>(); public void add(AListener listener) { listeners.add(listener); } private void aChanged() { for (AListener listener : listeners) { listener.aChanged(); } } private void bChanged() { for (AListener listener : listeners) { listener.bChanged(); } } public void f() { ... aChanged(); ... bChanged(); ... } ... } 

यहाँ, aChanged() और bChanged() विधियों में, सभी श्रोताओं को सूचित किया जाता है कि यह घटना हुई है। और f() विधि में, इन विधियों को सही समय पर कहा जाता है।

यह सब काम करता है, लेकिन हम कुछ बिंदु पर कहते हैं कि हम समझते हैं कि हमें श्रोताओं को सूचित करने के विभिन्न तरीकों के अवसर की आवश्यकता है। उदाहरण के लिए, कुछ श्रोताओं की कुछ शर्तों के आधार पर, विभिन्न आदेशों में छात्रों को सूचित करने के लिए, न कि परिवर्तनों के बारे में सूचित करने के लिए। इस समस्या के कम से कम दो समाधान हैं। सबसे पहले, आप विभिन्न अधिसूचना विधियों और कुछ कोड को जोड़कर AEventSource वर्ग को जटिल कर सकते हैं जो एक या दूसरे तरीके का चयन करेंगे। दूसरे, छात्रों को सूचित करने से संबंधित हर चीज को एक अलग कक्षा में रखा जा सकता है। फिर वांछित अधिसूचना विधि को एक निर्माण पैरामीटर के रूप में वांछित वस्तु को पास करके, उदाहरण के लिए सेट किया जा सकता है।

दूसरी विधि दो कारणों से बेहतर है। यदि हम देखे गए AEventSource ऑब्जेक्ट्स के लिए एक वर्ग नहीं है, लेकिन दो (या अधिक) कक्षाएं AEventSource1 , AEventSource2 , और यह सबसे अधिक संभावना है, तो, पहली विधि का चयन करते हुए, आपको दो वर्गों में अधिसूचना के लिए एक नया जटिल कोड डुप्लिकेट करना होगा, और यह पहले से ही कॉपी है -पसंद, यानी बुराई। दूसरा कारण यह होगा कि दूसरा दृष्टिकोण एकल जिम्मेदारी (एसआरपी) के सिद्धांत का सम्मान करता है। वास्तव में, अब AEventSource वर्ग को बदलने के दो कारण AEventSource : यदि हम अधिसूचना क्रम बदलना चाहते हैं, और यदि हम अधिसूचना कारण को बदलना चाहते हैं, तो वह है, उपरोक्त उदाहरण से f() फ़ंक्शन।

इसलिए, हम दूसरी विधि चुनते हैं - हम छात्रों को एक अलग कक्षा में सूचित करने के लिए कोड निकालते हैं। उसी समय, हम थोड़ा और दिलचस्प करेंगे, अर्थात्, लिंकर पैटर्न का उपयोग करें। इससे हमें न केवल श्रोताओं को सूचित करने के लिए विभिन्न तरीकों का चयन करना होगा, बल्कि उन्हें संयोजित भी करना होगा।

 class ACompositeListener implements AListener { private List<AListener> listeners = new ArrayList<AListener>(); public void add(AListener listener) { listeners.add(listener); } @Override public void aChanged() { for (AListener listener : listeners) { listener.aChanged(); } } @Override public void bChanged() { for (AListener listener : listeners) { listener.bChanged(); } } } 

तब AEventSource वर्ग कुछ इस तरह दिखाई देगा:

 class AEventSource { private AListener listener; AEventSource(AListener listener) { this.listener = listener; } public void f() { ... listener.aChanged(); ... listener.bChanged(); ... } } 

इस मामले में, आप श्रोताओं से पूरी गुड़िया बना सकते हैं।

 ACompositeListener compositeListener1 = new ACompositeListener(); compositeListener1.add(new AConcreteListener1()); ACompositeListener compositeListener2 = new ACompositeListener(); compositeListener1.add(compositeListener2); compositeListener2.add(new AConcreteListener2()); compositeListener2.add(new AConcreteListener3()); AEventSource source = new AEventSource(compositeListener1); 

सच है, इस समाधान में एक खामी है। अवलोकन करने वाली वस्तुओं का एक समुच्चय बनाने में इतना लचीलापन प्राप्त करने के बाद, इस तरह के आदेश और अधिसूचना नियमों के साथ समुच्चय बनाना संभव है, यह पता लगाना बहुत मुश्किल होगा।

और फिर, यह कोड अपना काम अच्छी तरह से करता है, लेकिन यह अचानक बदल जाता है (कुछ भी नहीं है कि मैंने पत्र A को क्लास के नामों में हर जगह जोड़ा), आपको श्रोताओं के साथ काम करने में भी सक्षम होना चाहिए, जो कि AListener इंटरफ़ेस के AListener अलावा एक और विधि है, चलो इसे dChanged() कहते हैं dChanged() । यही है, DListener श्रोताओं के लिए एक दूसरा इंटरफ़ेस है:

 interface DListener extends AListener { public void dChanged(); } 

इस प्रकार, हमें किसी तरह कोड का पुन: उपयोग करने की आवश्यकता है। कोड का पुन: उपयोग करने के लिए कम से कम तीन तरीके हैं। यह, सबसे पहले, कॉपी-पेस्ट, और दूसरी बात, विरासत और अंत में, रचना + प्रतिनिधिमंडल है। हम वैचारिक कारणों से पहले को तुरंत त्याग देंगे।

आइए देखें कि साधारण उत्तराधिकार हमारे लिए उपयुक्त क्यों नहीं है, इस तथ्य के बावजूद कि DListener इंटरफ़ेस DListener इंटरफ़ेस का विस्तार करता है। लेकिन वास्तव में, जैसे ही हम लिखते हैं

 class DCompositeListener extends ACompositeListener { ... } 

हमारे पास तुरंत add(AListener listener) विधि के साथ एक समस्या है, क्योंकि यह आपको एक ऑब्जेक्ट जोड़ने की अनुमति देता है जो AListener इंटरफ़ेस को लागू कर सकता है, लेकिन DListener नहीं। यदि हम इस विधि को फिर से परिभाषित करना चाहते हैं:

 @Override public void add(DListener listener) { ... } 

तब कंपाइलर सावधानीपूर्वक कहेगा: method does not override or implement a method from a supertype ( method does not override or implement a method from a supertype के लिए धन्यवाद)।

ठीक है, हम इस पद्धति के अंदर एक जांच क्यों नहीं करते हैं, और अगर जोड़ा वस्तु DListener इंटरफ़ेस को लागू नहीं करता है, तो एक अपवाद फेंक दें? यही कारण है कि, कुछ इस तरह से क्यों न लिखें

 @Override public void add(final AListener listener) { if (listener instanceof DListener) { listeners.add(listener); } else { throw new IllegalArgumentException(); } } 

इस तथ्य के अलावा कि यह कुछ अनाड़ी दिखता है, यह अभी भी लिस्क प्रतिस्थापन (एलएसपी एक) के सिद्धांत का उल्लंघन करता है। जिसे निम्न प्रकार से तैयार किया जा सकता है: आधार कक्षाओं के संदर्भों का उपयोग करने वाले कार्य यह जानने के बिना व्युत्पन्न वर्गों की वस्तुओं का उपयोग करने में सक्षम होना चाहिए । वास्तव में, समारोह

 void g(ACompositeListener composite) { composite.add(new AConcreteListener1()); } 

यह पूरी तरह से हानिरहित दिखता है और अपेक्षा करता है (और उचित रूप से) कि आप एक श्रोता को composite जोड़ सकते हैं। लेकिन यहाँ हम g() कॉल करते हैं g() इस तरह से कार्य करते हैं:

 g(new DCompositeListener()); 

और सब कुछ अपवाद के साथ गिर जाएगा। और हमारा लक्ष्य इसे संकलित करना भी असंभव बनाना है।

हां, AListener इंटरफ़ेस को पूरी तरह से छोड़ने का विकल्प, और उन सभी श्रोताओं के लिए जिनके पास dChanged() विधि नहीं थी, dChanged() पद्धति के अपवाद कार्यान्वयन को खाली या फेंक देते हैं, हम इसे छोड़ देते हैं, क्योंकि यह इंटरफ़ेस पृथक्करण के सिद्धांत का उल्लंघन करता है (उर्फ ISP)।

इसलिए, रचना + प्रतिनिधिमंडल बना हुआ है। ACompositeListener वर्ग से शुरू करने के लिए, हम श्रोताओं को नए ListenerList वर्ग में जोड़ने, हटाने, और पुनरावृति के लिए जिम्मेदार सभी कोड ACompositeListener देते हैं। और चूंकि हमारे पास विभिन्न प्रकार के श्रोता हैं, इसलिए यह एक मानकीकृत वर्ग होगा।

 class ListenerList<T> implements Iterable<T> { protected List<T> listeners = new ArrayList<T>(); public void add(T listener) { listeners.add(listener); } public void remove(T listener) { listeners.remove(listener); } public Iterator<T> iterator() { return listeners.iterator(); } } 

छात्रों को सूचित करने वाली कक्षाएं इस तरह दिखेंगी।

 class ATranslator<T extends AListener> { protected ListenerList<T> listeners; public ATranslator(ListenerList<T> listeners) { this.listeners = listeners; } public void aChanged() { for (AListener listener : listeners) { listener.aChanged(); } } public void bChanged() { for (AListener listener : listeners) { listener.bChanged(); } } } class DTranslator<T extends DListener> extends ATranslator<T> { public DTranslator(ListenerList<T> listeners) { super(listeners); } public void dChanged() { for (DListener listener : listeners) { listener.dChanged(); } } } 

सीमित प्रकार ( <T extends XListener> ) के रूप में किया जाता है, ताकि संबंधित श्रोताओं को लागू करने वाले श्रोताओं को सूची में जोड़ा जा सके। एक श्रोता को जोड़ने का प्रयास जो वांछित इंटरफ़ेस को लागू नहीं करता है, संकलन त्रुटि को जन्म देगा। हमने क्या हासिल किया।

अब ACompositeListener और ACompositeListener बस ACompositeListener :

 class ACompositeListener extends ListenerList<AListener> implements AListener { private ATranslator<AListener> aTranslator = new ATranslator<AListener>(this); @Override public void aChanged() { aTranslator.aChanged(); } @Override public void bChanged() { aTranslator.bChanged(); } } 

 class DCompositeListener extends ListenerList<DListener> implements DListener { private DTranslator<DListener> dTranslator = new DTranslator<DListener>(this); @Override public void aChanged() { dTranslator.aChanged(); } @Override public void bChanged() { dTranslator.bChanged(); } @Override public void dChanged() { dTranslator.dChanged(); } } 

वह सब है।

सामान्य तौर पर, पैटर्न और OOP के बारे में यह स्पष्ट है कि GoF में पढ़ने लायक क्या है। आप habrastatia में Linker पैटर्न के बारे में पढ़ सकते हैं। डिज़ाइन पैटर्न "Linker" / " स्पाइब्रेट हैब्रायज़र " का "समग्र" । आप हॉर्स्टमन और कॉर्नेल द्वारा कोर जावा के पहले खंड के 13 वें अध्याय में जावा में सार्वभौमिक प्रकारों के बारे में पढ़ सकते हैं। आप निवास स्थान में बिल्डर पैटर्न के लिए इसी तरह की समस्याओं के बारे में पढ़ सकते हैं। एक्स्टेंसिबल कक्षाएं - एक्स्टेंसिबल बिल्डर्स! हैबरूसर gvsmirnov और उस लेख पर टिप्पणी। ओओपी विचारों के लिए जो अत्यधिक उत्साह हो सकता है, वह हाब्रस्टैटिया में वर्णित है, इसलिए हम आपके एल्गोरिथ्म में एक कारखाना लगाते हैं या कैसे तथ्यात्मक नहीं माना जाना चाहिए ।