OOP में कार्यात्मक प्रोग्रामिंग

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

उदाहरण

आइए निम्न वर्ग को देखें (विषय कुछ असामान्य है, लेकिन मुझे आशा है कि यह किसी और के कोड को कम उबाऊ पढ़ने की प्रक्रिया बना देगा):

public class Invasion { private SearchCriterion _searchCriterion = (new GeniousCriterion()).or(new SexyCriterion()); private ExperimentProcedure _experimentProcedure = (new MockProcedure()).then(new WatchProcedure()); private _experience = new Experience(); private HumanBeing[] _humans; private ArrayList<HumanBeing> _chosenOnes; public void investigate() { updateChosenOnesList(); experiment(); } private void updateChosenOnesList() { _chosenOnes.clear(); for (HumanBeing human : _humans) if (_searchCriterion.satisfied(human)) _chosenOnes.add(human); } private void experiment() { for (HumanBeing human : _chosenOnes) _experience.push(_experimentProcedure.do(human)); } } 

जिसमें

आपको यह पता लगाने की आवश्यकता है कि जांच विधि क्या करती है या सुनिश्चित करें कि इसका तर्क सही है। इस मामले में, मैं उन सभी तरीकों के कोड को समझना नहीं चाहूंगा जो इसे कहते हैं।
विधि अद्यतन। इस स्थिति में, विधि के नाम से, आप यह निर्धारित कर सकते हैं कि इसके कार्यान्वयन को _chosenOnes फ़ील्ड को अपडेट करना चाहिए। इसी समय, ऑब्जेक्ट फ़ील्ड्स की सूची को देखते हुए, यह माना जा सकता है कि नए लोगों को _humans के बीच खोजा जाएगा, और _searchCriterion मानदंड का उपयोग खोज के लिए किया जा सकता है। हालाँकि, ऑब्जेक्ट फ़ील्ड की सूची की जाँच करना और उनके नाम और विधि के नाम के बीच के संबंधों को ट्रेस करना बहुत सुविधाजनक नहीं है। प्रयोग विधि के साथ स्थिति समान है।

और दूसरा उदाहरण

इस वर्ग के लिए एक और कार्यान्वयन विकल्प यहां है (टिप्पणियां देखें):

 public class Invasion { // ….......... public void investigate() { //    :      ,    //   updateChosenOnesList(); _chosenOnes = search(_searchCriterion, _humans); //    ,    _experience.push(experiment(_experimentProcedure, _chosenOnes)); } private Experience experiment(ExperimentProcedure procedure, HumanBeing[] humans) { Experience exp = new Experience(); for (HumanBeing human : humans) exp.push(procedure.do(human)); return exp; } private ArrayList<HumanBeing> search(SearchCriterion criterion, HumanBeing[] humans) { ArrayList<HumanBeing> result = new ArrayList<HumanBeing>(); for (HumanBeing human : humans) if (criterion.satisfied(human)) result.add(human); return result; } } 

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

आकर्षण आते हैं

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

विपक्ष

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

उदाहरण के बारे में

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

उपसंहार

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


आपका ध्यान के लिए धन्यवाद! कृपया अपनी टिप्पणियों, टिप्पणियों और आलोचनाओं को टिप्पणियों में लिखें।

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