क्या स्कैला का पैटर्न मिलान ओपन/क्लोज़ड सिद्धांत का उल्लंघन करता है?

Question

यदि मैं एक नया केस क्लास जोड़ता हूं, तो क्या इसका मतलब है कि मुझे सभी पैटर्न मिलान कोड के माध्यम से खोजना होगा और पता लगाएं कि नई कक्षा को कहां संभालना है? मैं हाल ही में भाषा सीख रहा हूं, और जैसा कि मैंने पैटर्न मिलान के लिए और उसके खिलाफ कुछ तर्कों के बारे में पढ़ा है, मैं इस बारे में उलझन में हूं कि इसका उपयोग कहां किया जाना चाहिए। निम्नलिखित देखें:

प्रो: Odersky1 और Odersky2

कोन: Beust

टिप्पणियां प्रत्येक मामले में काफी अच्छा है, भी कर रहे हैं। तो पैटर्न के बारे में उत्साहित होने के लिए कुछ पैटर्न है या मुझे कुछ टालने से बचना चाहिए? असल में, मुझे लगता है कि जवाब यह है कि "यह उस पर निर्भर करता है जब आप इसका उपयोग करते हैं," लेकिन इसके लिए कुछ सकारात्मक उपयोग के मामले क्या हैं और कुछ नकारात्मक क्या हैं?

Answer 1

जेफ, मुझे लगता है कि आपके पास सही अंतर्ज्ञान है: यह निर्भर करता है।

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

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

ओओ दृष्टिकोण के लिए कैननिकल उदाहरण जीयूआई प्रोग्रामिंग है। जीयूआई तत्वों को बहुत कम कार्यक्षमता का समर्थन करने की आवश्यकता होती है (स्क्रीन पर खुद को चित्रित करना न्यूनतम होता है), लेकिन नए जीयूआई तत्व हर समय जोड़े जाते हैं (बटन, टेबल, चार्ट, स्लाइडर्स इत्यादि)। पैटर्न मिलान दृष्टिकोण के लिए कैनोलिक उदाहरण एक कंपाइलर है। प्रोग्रामिंग भाषाओं में आमतौर पर अपेक्षाकृत निश्चित वाक्यविन्यास होता है, इसलिए सिंटैक्स पेड़ के तत्व शायद ही कभी बदल जाएंगे (यदि कभी भी), लेकिन सिंटैक्स पेड़ पर नए ऑपरेशन लगातार जोड़े जा रहे हैं (तेज़ अनुकूलन, अधिक विस्तृत प्रकार का विश्लेषण, आदि)।

सौभाग्य से, स्कैला आपको दोनों दृष्टिकोणों को गठबंधन करने देता है। केस क्लास दोनों पैटर्न मिलान कर सकते हैं और आभासी विधि प्रेषण का समर्थन कर सकते हैं। नियमित कक्षाएं आभासी विधि प्रेषण का समर्थन करती हैं और संबंधित साथी ऑब्जेक्ट में निकालने वाले को परिभाषित करके मिलान पैटर्न हो सकती हैं। यह तय करने के लिए प्रोग्रामर पर निर्भर करता है कि प्रत्येक दृष्टिकोण उचित कब होता है, लेकिन मुझे लगता है कि दोनों उपयोगी हैं।

Answer 2

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

स्कैला का पैटर्न मिलान हमेशा किसी वर्ग के साथी ऑब्जेक्ट के deconstructor को प्रतिनिधि करता है। एक केस क्लास के साथ, यह deconstructor स्वचालित रूप से जेनरेट किया जाता है (साथी ऑब्जेक्ट में फैक्ट्री विधि के साथ), हालांकि यह ऑटो-जेनरेटेड संस्करण को ओवरराइड करना अभी भी संभव है। हर समय, आप पैटर्न मिलान प्रक्रिया पर पूर्ण नियंत्रण डाल सकते हैं, कक्षा में संभावित परिवर्तनों से किसी भी पैटर्न को इन्सुलेट कर सकते हैं। इस प्रकार, पैटर्न मिलान किसी भी अन्य विधि की तरह, encapsulation के सुरक्षित फ़िल्टर के माध्यम से कक्षा डेटा तक पहुंचने का एक और तरीका है।

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

जहां इसका उपयोग किया जाना चाहिए, यह स्वाद के अनुसार पूरी तरह से है। यदि यह आपके कोड को अधिक संक्षिप्त और रखरखाव योग्य बनाता है, तो इसका इस्तेमाल करें! अन्यथा, मत करो। अधिकांश ऑब्जेक्ट उन्मुख प्रोग्रामों के लिए, पैटर्न मिलान अनावश्यक है। हालांकि, एक बार जब आप अधिक कार्यात्मक मुहावरे को एकीकृत करना शुरू कर देते हैं (Option, List, आदि) मुझे लगता है कि आप पाएंगे कि पैटर्न मिलान से वाक्य रचनात्मक ओवरहेड को कम किया जाएगा और साथ ही प्रकार प्रणाली द्वारा प्रदान की गई सुरक्षा में सुधार होगा। आम तौर पर, जब भी आप कुछ शर्त का परीक्षण करते समय डेटा निकालना चाहते हैं (उदाहरण के लिए Some से मूल्य निकालना), पैटर्न मिलान का उपयोग संभवतः किया जाएगा।

Answer 3

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

इसके अलावा पैटर्न मिलान कक्षा के अनपॅकिंग सदस्यों का एक शानदार तरीका प्रदान करता है।