सामान्यीकृत CLOS सुविधाएँ

कोई भी डेवलपर जो किसी भी तरह ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में आया था और यह पता लगाने की कोशिश की थी, उसने CLOS के बारे में सुना होगा, कॉमन लिस्प भाषा की एक ऑब्जेक्ट सिस्टम, जिसमें से एक मूलभूत विशेषता तथाकथित "सामान्यीकृत कार्य" या, लोगों में, "मल्टीमिथोड्स" "।

हालांकि बहुत से लोग मानते हैं कि सामान्यीकृत कार्य केवल स्थैतिक फ़ंक्शन ओवरलोड के अनुरूप होते हैं, लेकिन केवल गतिशीलता में, यह पूरी तरह से असत्य है।
यह कहना भी पूरी तरह से सही नहीं होगा कि यह कई तर्कों के लिए, "वर्चुअल फ़ंक्शंस" के स्वयं / इस द्वारा प्रेषण का विस्तार है।

बेशक, कई प्रेषण सामान्यीकृत कार्यों की मुख्य विशेषताओं में से एक है, लेकिन उनका सार न केवल है, और इतना भी नहीं है, इसमें।

मैं एक उदाहरण के साथ समझाऊंगा - सरल गणितीय अभिव्यक्तियों का एक कैलकुलेटर।

यदि हम OOP के एक "शास्त्रीय" कार्यान्वयन के साथ एक भाषा लेते हैं, उदाहरण के लिए C #, तो हमें निम्न जैसा कुछ मिलता है:

interface IExpression { int Evaluate(); } class Negation : IExpression { IExpression expr; public Negation(IExpression e) { expr = e; } public int Evaluate() { return -expr.Evaluate(); } } class Addition : IExpression { IExpression left, right; public Addition(IExpression l, IExpression r) { left = l; right = r; } public int Evaluate() { return left.Evaluate() + right.Evaluate(); } } class Number : IExpression { int value; public Number(int v) { value = v; } public int Evaluate() { return value; } } 

लिस्प पर विकल्प यह होगा:

 (defstruct (negation (:constructor negation (expr)) (:conc-name nil)) expr) (defstruct (addition (:constructor addition (left right)) (:conc-name nil)) left right) (defgeneric evaluate (expr) (:method ((expr negation)) (- (evaluate (expr expr)))) (:method ((expr addition)) (+ (evaluate (left expr)) (evaluate (right expr)))) (:method ((expr number)) expr)) ;; (evaluate (addition 5 (negation -5))) ;; ==> 10 

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

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

हां, CLOS पर क्लासिक OOP का सीधा प्रक्षेपण काम नहीं करता है, या कम से कम यह भयानक लग रहा है, लेकिन इसके लिए एक बहुत ही विशिष्ट कारण है, और इसमें निम्नलिखित शामिल हैं:

तरीकों को एक कारण से कक्षाओं से अलग नहीं किया जाता है। CLOS ऑब्जेक्ट प्रतिमान मूल रूप से शास्त्रीय OOP से भिन्न होता है, जो संदेशों के प्रसारण और प्रसंस्करण (संदेश पास करना) से बंधा होता है।

सीएलओएस एक दूसरे के साथ और बाहरी दुनिया के साथ अपनी बातचीत के लिए राज्य और संस्थाओं के व्यवहार से जोर देते हैं।

मैंने ऊपर लिखा है कि CLOS में कोई इंटरफेस नहीं हैं। वास्तव में, यह पूरी तरह से सच नहीं है - सामान्यीकृत कार्य इंटरफेस हैं, और उनके तरीके कार्यान्वयन हैं।

इस बिंदु पर, कार्यात्मक प्रोग्रामिंग के अनुयायियों में से एक पूछ सकता है: "ठीक है, ठीक है, यह सब कैसे सामान्य मिलान से भिन्न होता है?"

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

मैंने एक बार अपने लाइवजर्नल में मेथड कॉम्बिनर्स के बारे में लिखा था , जो कोई भी व्यक्ति इसे पढ़ सकता है, लेकिन यहाँ मैं दिखाऊंगा कि कैसे, एक निर्मित कॉम्बीनेटरों में से एक का उपयोग करके, प्रागंण में, सामान्य ओय भाषाओं से "कंस्ट्रक्टर्स" की समानता को लागू करने के लिए:

 (defgeneric construct (object &key) (:method-combination progn :most-specific-last)) (defun new (class &rest args &key &allow-other-keys) (let ((object (make-instance class))) (apply #'construct object args) object)) (defclass superclass () (some-slot)) (defclass subclass (superclass) ()) (defmethod construct progn ((object superclass) &key value) (setf (slot-value object 'some-slot) value) (write-line "Superclass constructed")) (defmethod construct progn ((object subclass) &key) (write-line "Subclass constructed") (format t "Slot value: ~s~%" (slot-value object 'some-slot))) ;; (new 'subclass :value 123) ;; ==> Superclass constructed ;; Subclass constructed ;; Slot value: 123 

मेरी राय में, CLOS ऑब्जेक्ट मॉडल ने व्यवस्थित रूप से OOP और कार्यात्मक प्रोग्रामिंग के सर्वश्रेष्ठ को संश्लेषित किया है, और अभी भी इसमें प्रस्तुत प्रतिमान का सबसे सही कार्यान्वयन है।
यह शर्म की बात है कि मुख्यधारा अपने विचारों को बेहद धीरे और अनिच्छा से स्वीकार करती है, लेकिन यह इसे और भी बदतर बना देती है।