जब मैं बड़ी विधियों (या प्रक्रियाओं, या फ़ंक्शंस) को विभाजित करता हूं - यह प्रश्न OOP के लिए विशिष्ट नहीं है , लेकिन जब से मैं OOP भाषाओं में 99% समय पर काम करता हूं, तो यह शब्दावली है कि मैं बहुत छोटे लोगों में सबसे आरामदायक हूं) , मैं अक्सर खुद को परिणामों से अप्रसन्न पाता हूं। इन छोटे तरीकों के बारे में तर्क करना तब कठिन हो जाता है जब वे बड़े में सिर्फ कोड के ब्लॉक होते थे, क्योंकि जब मैं उन्हें निकालता हूं, तो मैं बहुत सारी अंतर्निहित धारणाओं को खो देता हूं जो कॉलर के संदर्भ में आती हैं।
बाद में, जब मैं इस कोड को देखता हूं और अलग-अलग तरीकों को देखता हूं, तो मुझे तुरंत नहीं पता कि वे कहां से बुलाए जाते हैं, और उनके बारे में साधारण निजी तरीकों के रूप में सोचते हैं जिन्हें फ़ाइल में कहीं से भी बुलाया जा सकता है। उदाहरण के लिए, एक प्रारंभिक विधि (कंस्ट्रक्टर या अन्यथा) की कल्पना छोटे लोगों की एक श्रृंखला में विभाजित करें: विधि के संदर्भ में, आप स्पष्ट रूप से जानते हैं कि ऑब्जेक्ट की स्थिति अभी भी अमान्य है, लेकिन एक साधारण निजी विधि में आप संभवतः उस वस्तु को मानने से चले जाते हैं। पहले से ही आरंभिक है और एक मान्य स्थिति में है।
इसका एकमात्र समाधान मैंने देखा है कि whereहास्केल में क्लॉज है, जो आपको केवल "पैरेंट" फ़ंक्शन में उपयोग किए जाने वाले छोटे कार्यों को परिभाषित करने की अनुमति देता है। मूल रूप से, यह इस तरह दिखता है:
len x y = sqrt $ (sq x) + (sq y)
where sq a = a * a
लेकिन मैं जिन अन्य भाषाओं का उपयोग करता हूं, उनमें ऐसा कुछ भी नहीं है - निकटतम चीज एक स्थानीय क्षेत्र में एक लंबो को परिभाषित कर रही है, जो शायद बहुत भ्रामक है।
तो, मेरा सवाल है - क्या आप इससे मुठभेड़ करते हैं, और क्या आप यह भी देखते हैं कि यह एक समस्या है? यदि आप करते हैं, तो आप आमतौर पर इसे कैसे हल करते हैं, विशेष रूप से "मुख्यधारा" ओओपी भाषाओं में, जैसे जावा / सी # / सी ++?
डुप्लिकेट के बारे में संपादित करें: जैसा कि दूसरों ने देखा है, पहले से ही विभाजन विधियों और छोटे-छोटे प्रश्नों पर चर्चा करने वाले प्रश्न हैं जो एक-लाइनर हैं। मैं उन्हें पढ़ता हूं, और वे अंतर्निहित मान्यताओं के मुद्दे पर चर्चा नहीं करते हैं जो कि कॉलर के संदर्भ से प्राप्त हो सकते हैं (उदाहरण के लिए, ऑब्जेक्ट को आरंभीकृत किया जा रहा है)। मेरे सवाल का यही मतलब है, और इसीलिए मेरा सवाल अलग है।
अद्यतन: यदि आपने इस सवाल और चर्चा का अनुसरण किया है, तो आप विशेष रूप से इस मामले पर जॉन कार्मैक के इस लेख का आनंद ले सकते हैं :
वास्तविक कोड के क्रियान्वयन के बारे में जागरूकता के अलावा, इनलाइनिंग फ़ंक्शन का अन्य स्थानों से फ़ंक्शन को कॉल करने के लिए संभव नहीं करने का भी लाभ है। यह हास्यास्पद लगता है, लेकिन इसके लिए एक बिंदु है। जैसे-जैसे उपयोग के वर्षों में एक कोडबेस बढ़ता है, शॉर्टकट लेने और बस एक फ़ंक्शन को कॉल करने के बहुत सारे अवसर होंगे जो आपको लगता है कि केवल वही काम करता है जो आपको करने की आवश्यकता है। एक FullUpdate () फ़ंक्शन हो सकता है जो PartialUpdateA (), और PartialUpdateB () को कॉल करता है, लेकिन कुछ विशेष मामले में आपको एहसास हो सकता है (या लगता है) कि आपको केवल PartialUpdateB () करने की आवश्यकता है, और आप दूसरे से बचकर कुशल हो रहे हैं काम। बहुत सारे और कीड़े इस से स्टेम। अधिकांश कीड़े निष्पादन की स्थिति के परिणामस्वरूप नहीं हैं कि आप क्या सोचते हैं।