साइड-इफेक्ट-फ्री सेटर्स के दृष्टिकोण

Question

मैं आपकी राय प्राप्त करना चाहता हूं कि साइड-इफेक्ट-फ्री सेटर्स के साथ कितना दूर जाना है।

Activity activity; 
activity.Start = "2010-01-01"; 
activity.Duration = "10 days"; // sets Finish property to "2010-01-10" 

ध्यान दें कि तारीख और अवधि के लिए महत्व देता है केवल सांकेतिक प्रयोजनों के लिए दिखाए गए हैं:

निम्न उदाहरण पर विचार करें।

तो किसी भी गुण Start, Finish और Duration के लिए सेटर का उपयोग करके अन्य गुणों को बदलेगा और इस प्रकार साइड-इफेक्ट-फ्री नहीं माना जा सकता है। Rectangle कक्षा के उदाहरणों के लिए भी लागू होता है, जहां X के लिए सेटटर Top और Bottom और अन्य मानों को बदल रहा है।

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

Answer 1

मुझे लगता है कि आप "साइड इफेक्ट" शब्द को गलत समझ रहे हैं क्योंकि यह प्रोग्राम डिज़ाइन पर लागू होता है। एक संपत्ति सेट करना एक साइड इफेक्ट है, इससे कोई फर्क नहीं पड़ता कि यह कितनी या कितनी छोटी आंतरिक स्थिति बदलती है, जब तक कि यह कुछ प्रकार की स्थिति बदलती है। एक "साइड-इफेक्ट-फ्री सेटर" बहुत उपयोगी नहीं होगा।

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

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

तो, सीधे सवाल का जवाब दें: मैं रेखा कहां खींचूं? कहीं भी, जब तक विधि/संपत्ति वास्तव में उसके नाम का तात्पर्य नहीं करती है। यदि Duration को सेट करने से ActivityName भी बदल गया है, तो यह एक समस्या हो सकती है। यदि यह Finish संपत्ति को बदलता है, तो यह स्पष्ट होना चाहिए; Duration को बदलने के लिए असंभव होना चाहिए और Start और Finish दोनों ही रहें। ओओपी का मूल आधार यह है कि वस्तुएं इन परिचालनों को अपने आप प्रबंधित करने के लिए पर्याप्त बुद्धिमान हैं।

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

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

Answer 2

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

बेशक, ऐसे समय होते हैं जहां आपको या तो पठनीयता के लिए नियम तोड़ना होता है, ताकि आपके ऑब्जेक्ट मॉडल को तार्किक बनाया जा सके, या सिर्फ चीजों को सही काम करने के लिए। जैसा कि आपने कहा, वास्तव में सामान्य रूप से वरीयता का मामला।

Answer 3

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

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

Answer 4

मुझे लगता है कि यह ज्यादातर सामान्य ज्ञान का विषय है।

इस विशेष उदाहरण में, मेरी समस्या इतनी अधिक नहीं है कि आपके पास "संबंधित" गुणों को समायोजित करने वाले गुण हैं, यह है कि आपके पास स्ट्रिंग मान लेने वाले गुण हैं जो आप अंततः डेटटाइम में पार्सिंग कर रहे हैं (या जो कुछ भी) मूल्य।

Activity activity; 
activity.Start = DateTime.Parse("2010-01-01"); 
activity.Duration = Duration.Parse("10 days"); 

है, तो आप स्पष्ट रूप से ध्यान दें कि आप तार को पार्स कर रहे हैं:

मैं बहुत बल्कि कुछ इस तरह देखना होगा।प्रोग्रामर को मजबूत टाइप किए गए ऑब्जेक्ट्स को निर्दिष्ट करने की अनुमति दें जब यह उचित हो।

Answer 5

एक विकल्प आपकी कक्षा को अपरिवर्तनीय बनाना है और विधियों को उस वर्ग के नए उदाहरण बनाने और वापस करने के तरीके हैं जिनके सभी उचित मूल्य बदल गए हैं। फिर कोई दुष्प्रभाव या सेटर्स नहीं हैं। DateTime जैसे कुछ के बारे में सोचें जहां आप AddDays और AddHours जैसी चीजें कॉल कर सकते हैं जो लागू किए गए परिवर्तन के साथ एक नया DateTime उदाहरण वापस कर देगा।