ओओपी में साइड इफेक्ट्स और स्टेटस से बचने के तरीके सीखने के लिए सबसे अच्छे संसाधन क्या हैं?

Question

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

इस का एक अच्छा उदाहरण रीस्टफुल वेब सेवा है जो आपको वेब एप्लिकेशन में राज्य को कम करने के लिए रणनीतियों देता है। अन्य क्या मौजूद हैं?

याद रखें कि मैं एक और ओओपी विश्लेषकों/डिजाइन पैटर्न पुस्तक की तलाश नहीं कर रहा हूं (हालांकि अच्छा encapsulation और ढीला युग्मन साइड इफेक्ट्स से बचने में मदद करता है) बल्कि एक संसाधन जहां विषय स्वयं राज्य/साइड इफेक्ट्स है।

कुछ संकलित जवाब

• OOP प्रोग्रामर जो ज्यादातर राज्य के बारे में परवाह तो संगामिति की वजह से है, इसलिए Java Concurrency in Practice पढ़ें। [वास्तव में क्या मैं खोज रहा था] TDD
• उपयोग दुष्प्रभाव अधिक दिखाई बनाने के लिए [मुझे यह पसंद है, उदाहरण के लिए: बड़ा अपने सेटअप कर रहे हैं, अधिक राज्य आप जगह में की जरूरत है अपने परीक्षण = अच्छा चेतावनी चलाने के लिए]
• Command-query separation
• तरीके, केवल एक काम करते हैं शायद वर्णनात्मक नाम का उपयोग करता है, तो वे अपने वस्तु की स्थिति बदलने ताकि यह आसान है और [अच्छा सामान, एक समारोह तर्क जो आम तौर पर भ्रामक बदलने का पक्ष प्रभाव से बचाता है] स्पष्ट।
• Make objects immutable [वास्तव में इस तरह मैं] पैरामीटर के रूप में
• दर्रा मूल्यों, बजाय उन्हें सदस्य चर में संग्रहीत करने का । [मैं इसे लिंक नहीं करता; यह फ़ंक्शन प्रोटोटाइप को बंद कर देता है और इसे स्वच्छ कोड और अन्य पुस्तकों द्वारा सक्रिय रूप से निराश किया जाता है, हालांकि मैं मानता हूं कि यह राज्य के मुद्दे की सहायता करता है]
• उन्हें संग्रहीत करने और उन्हें अपडेट करने के बजाय मूल्यों को दोबारा बदलें [मुझे यह भी वाकई पसंद है; ऐप में मैं प्रदर्शन पर काम करता हूं एक मामूली चिंता है]
• इसी तरह, अगर आप इससे बच सकते हैं तो राज्य की प्रतिलिपि न लें। इसे रखने के लिए एक ऑब्जेक्ट को ज़िम्मेदार बनाएं और दूसरों को वहां पहुंचने दें। [मूल OOP सिद्धांत, अच्छी सलाह]

Answer 1

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

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

ओओ प्रोग्रामर इन दिनों ओओ प्रोग्रामर जो राज्य से परहेज करने के बारे में अधिकतर परवाह करते हैं वे समानता पर काम कर रहे हैं। इसके कारण स्पष्ट हैं - जब आप धागे के बीच समवर्ती प्रबंधन का प्रयास कर रहे हैं तो परिवर्तनीय स्थिति और साइड इफेक्ट्स बड़े सिरदर्द का कारण बनते हैं। नतीजतन, राज्य से बचने के बारे में ओओ दुनिया में मैंने देखा है कि सबसे अच्छी चर्चा Java Concurrency in Practice.

Answer 2

मुझे लगता है कि नियम काफी सरल हैं: तरीकों ही कभी एक काम करते हैं, और इरादे विधि नाम पर स्पष्ट रूप से सूचित किया जाना चाहिए चाहिए।

विधियों को या तो डेटा पूछना या बदलना चाहिए, लेकिन दोनों कभी नहीं।

Answer 3

ओओ में साइड इफेक्ट्स को अलग करने का एक तरीका है ऑपरेशन केवल साइड इफेक्ट्स के विवरण वस्तु को वापस करने देना है।

Command-query separation एक ऐसा पैटर्न है जो इस विचार के करीब है।

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

Answer 4

कुछ छोटी बातों मैं करता हूँ:

• अपरिवर्तनीय राज्य पसंद करते हैं, यह अपेक्षाकृत सौम्य है। जैसे जावा में मैं सदस्य चर अंतिम बना देता हूं और जहां भी संभव हो वहां उन्हें कन्स्ट्रक्टर में सेट करता हूं।

• सदस्य चर में उन्हें संग्रहीत करने के बजाय पैरामीटर के रूप में मूल्यों के चारों ओर पास करें।

• उन्हें भंडारण और अद्यतन करने के बजाय मूल्यों को दोबारा लागू करें, अगर इसे सस्ता रूप से पर्याप्त किया जा सकता है। यह इसे अद्यतन करने के लिए भूलकर असंगत डेटा से बचने में मदद करता है।

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