डीडीडी और गेटर्स और सेटर्स का उपयोग

Question

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

अब यह प्रिंसिपल अभी भी मुझे भ्रमित करता है। उदाहरण के लिए, यदि किसी ऑब्जेक्ट के सदस्य चर के मान को बदलने की आवश्यकता है तो क्या होगा? उदाहरण के लिए, यदि किसी व्यक्ति का नाम बदलता है तो मैं मॉडल में इसे कैसे प्रतिबिंबित कर सकता हूं? सबसे पहले मैंने सोचा, ठीक है क्यों 'चेंजनाम' नामक एक फ़ंक्शन नहीं है जो मुझे नए नाम में गुजरता है और बदले में आंतरिक 'नाम' चर बदल सकता है। खैर .... यह सिर्फ एक सेटटर नहीं है!

मुझे स्पष्टीकरण की आवश्यकता है - अगर मैं पूरी तरह से सेटर्स को खत्म करना चाहता था, तो उपरोक्त स्थितियों में, क्या मुझे पूरी तरह से कन्स्ट्रक्टर पैरामीटर पर भरोसा करना चाहिए? क्या मुझे एक कन्स्ट्रक्टर के माध्यम से पुरानी विशेषता मान के स्थान पर नया विशेषता मान पास करना चाहिए, जिसके बाद मैं ऑब्जेक्ट को मेरे पास जो भी स्थिरता बुनियादी ढांचे के पास पास करके परिवर्तनों को जारी रख सकता हूं?

इन दो लेख इस चर्चा में उपयोगी होते हैं:

1. http://kellabyte.com/tag/ddd/
2. http://typicalprogrammer.com/?p=23

Answer 1

खैर, यह एक क्लासिक चर्चा है। इसके बारे में स्टैक ओवरफ़्लो में कई अन्य धागे हैं।

लेकिन। प्राप्त करें/सेट करें (ऑटो गुण?) सभी खराब नहीं हैं। लेकिन वे आपको अपनी संस्थाओं को "मृत" डेटा कंटेनरों के रूप में बनाने के लिए प्रेरित करते हैं, जिनमें केवल प्रोप और विधियां नहीं होती हैं। इसके संकेत अक्सर एनीमिक डोमेन कहा जाता है - और बहुत कम व्यवहार होता है। मेरी सिफारिश है:

1. जितना संभव हो उतना प्रोप का उपयोग करने का प्रयास करें।
2. एक साथ मौजूद डेटा के समूह ढूंढने का प्रयास करें और पूर्व की तरह होना चाहिए। प्रथम नाम मिडलनाम और अंतिम नाम। एक और उदाहरण ज़िपकोड, सिटी, स्ट्रीट है। ये डेटा विधि के माध्यम से सेट करना बेहतर है। यह आपकी इकाई के अमान्य होने की संभावना को कम करता है।
3. अक्सर एक साथ जुड़े डेटा को मूल्य ऑब्जेक्ट के रूप में समूहीकृत किया जा सकता है।
4. अधिक मूल्य वस्तुएं आपकी इकाई से अधिक वर्णनात्मक विधियों को लाती हैं जो आपके आमतौर पर "नाम" इकाइयों के बजाय "क्रियाएं" होती हैं।
5. आपकी मूल्य वस्तुओं के लिए अधिक विधियां भी व्यवहार जोड़ने और शायद "फैट" सेवाओं को कम करने के लिए खुलती हैं (शायद आप में बहुत अधिक लीक किए गए व्यवसाय तर्क वाले सेवाएं नहीं हैं ...)।

यहाँ कहने के लिए और अधिक कर रहे हैं ... लेकिन एक संक्षिप्त उत्तर। कन्स्ट्रक्टर में डेटा सेट करने के बारे में: मैं केवल यही करता हूं अगर यह इकाई उस डेटा के बिना "लाइव"/मौजूद नहीं हो सकती है। इकाई व्यक्ति के लिए मैं कहूंगा कि नाम शायद उस तरह का महत्वपूर्ण नहीं है। लेकिन सामाजिक सुरक्षा संख्या कन्स्ट्रक्टर डेटा के लिए उम्मीदवार हो सकती है। या इकाई कर्मचारी के पास कंपनी में कंस्ट्रक्टर होना चाहिए, क्योंकि केवल एक कर्मचारी को कंपनी से संबंधित होना चाहिए।