एक इकाई की एकल जिम्मेदारी (बदलने का कारण) को विशिष्ट रूप से स्वयं को पहचानना चाहिए, दूसरे शब्दों में, इसकी जिम्मेदारी खोजने योग्य है।
एरिक इवान की डीडीडी पुस्तक, पृ। 93:
Entities की सबसे बुनियादी जिम्मेदारी निरंतरता स्थापित करना है ताकि व्यवहार स्पष्ट और अनुमानित हो सके। वे यह सबसे अच्छा करते हैं अगर उन्हें अतिरिक्त रखा जाए। विशेषताओं या यहां तक कि व्यवहार पर ध्यान केंद्रित करने के बजाय, एंटिटी ऑब्जेक्ट की परिभाषा को सबसे आंतरिक विशेषताओं तक नीचे ले जाएं, विशेष रूप से वे जो इसे पहचानते हैं या आमतौर पर इसे खोजने या मिलान करने के लिए उपयोग किया जाता है। केवल उस व्यवहार को जोड़ें जो उस व्यवहार के लिए आवश्यक अवधारणा और विशेषताओं के लिए आवश्यक है।
इसके अलावा, कोर एंटिटी से जुड़ी अन्य वस्तुओं में व्यवहार और विशेषताओं को हटाने के लिए देखें। पहचान के मुद्दों के अलावा, एंटिटीज उन वस्तुओं के संचालन का समन्वय करके अपनी जिम्मेदारियों को पूरा करते हैं।
1।
... सबसे आंतरिक विशेषताओं के लिए ईएनटीिटी ऑब्जेक्ट की परिभाषा को पट्टी करें, विशेष रूप से जो इसे पहचानते हैं या आमतौर पर इसे खोजने या मैच करने के लिए उपयोग किया जाता है। केवल वही व्यवहार जोड़ें जो अवधारणा के लिए आवश्यक है ...
एक बार जब किसी संस्था को एक विशिष्ट आईडी दी जाती है , तो उसकी पहचान स्थापित हो जाती है और इसलिए मुझे लगता है कि ऐसी इकाई को अपनी पहचान बनाए रखने या स्वयं की पहचान करने में मदद करने के लिए किसी व्यवहार की आवश्यकता नहीं है । इस प्रकार, मुझे समझ में नहीं आ रहा है कि लेखक " व्यवहार (जो कि अवधारणा के लिए आवश्यक है ) के साथ (इसके अलावा findऔर match संचालन ) किस तरह का व्यवहार कर रहा है ?"
2।
... सबसे आंतरिक विशेषताओं के लिए ईएनटीिटी ऑब्जेक्ट की परिभाषा को पट्टी करें, विशेष रूप से जो इसे पहचानते हैं या आमतौर पर इसे खोजने या मैच करने के लिए उपयोग किया जाता है। ... इसके अलावा, मुख्य ईएनटीआईटी से जुड़ी अन्य वस्तुओं में व्यवहार और विशेषताओं को हटाने के लिए देखें।
तो कोई भी व्यवहार जो इकाई की पहचान करने में मदद नहीं करता है, लेकिन हम उस व्यवहार को उस इकाई की आंतरिक विशेषता के रूप में चित्रित करेंगे (यानी भौंकना कुत्तों के लिए आंतरिक है, उड़ना हवाई जहाज के लिए आंतरिक है, अंडे देना पक्षियों के लिए आंतरिक है ..) ।), उस इकाई से जुड़ी अन्य वस्तुओं में डाल दिया जाना चाहिए (उदाहरण: हमें एक कुत्ते इकाई से जुड़ी वस्तु में भौंकने वाला व्यवहार करना चाहिए)?
3।
इसके अलावा, कोर ENTITY से जुड़ी अन्य वस्तुओं में व्यवहार और विशेषताओं को हटाने के लिए देखें।
क) क्रमशः MyEntityजिम्मेदारियों A_respऔर B_respवस्तुओं को सौंपता है aऔर b।
हालांकि के सबसे A_respऔर B_respकाम द्वारा किया जाता है aऔर bउदाहरणों, ग्राहकों को अभी भी सेवा कर रहे हैं A_respऔर B_respके माध्यम से MyEntity, जिसका मतलब है कि ग्राहक के नजरिए से दो जिम्मेदारियों से संबंध रखते हैं MyEntity। इस प्रकार, इसका मतलब MyEntityयह भी नहीं है कि जिम्मेदारियां भी हैं A_respऔर एसआरपीB_resp का उल्लंघन हो रहा है ?
ख) यहां तक कि अगर हम मान लेते हैं कि A_respऔर B_respसे संबंधित नहीं है MyEntity, MyEntityअभी भी एक जिम्मेदारी है AB_respवस्तुओं के संचालन के समन्वय की aऔर b। एसआरपी काMyEntity उल्लंघन नहीं करता है क्योंकि कम से कम इसकी दो ज़िम्मेदारियाँ हैं - विशिष्ट रूप से स्वयं की पहचान करना और भी ?AB_resp
class MyEntity
{
private A a = ...
private B b = ...
public A GetA()
{ ... }
public B GetB()
{ ... }
/* coordinates operations of objects a and b */
public int AworkB()
{ ... }
}
/* A encapsulates a single responsibility resp_A*/
/* A is value object */
class A
{ ... }
/* B encapsulates a single responsibility resp_B*/
/* B is value object */
class B
{ ... }
अपडेट करें:
1।
इस संदर्भ में व्यवहार शब्दार्थ व्यवहार का उल्लेख है। उदाहरण के लिए, एक वर्ग पर एक संपत्ति (यानी एक डोमेन ऑब्जेक्ट पर विशेषता) जो विशिष्ट रूप से पहचानने के लिए उपयोग की जाती है, उसका व्यवहार होता है। जबकि यह सीधे कोड में दर्शाया नहीं गया है। अपेक्षित व्यवहार यह है कि उस संपत्ति के लिए कोई डुप्लिकेट मान नहीं होगा।
इसलिए कोड में हमें वास्तव में एक व्यवहार (यानी एक ऑपरेशन) को लागू करने की आवश्यकता नहीं होगी जो किसी भी तरह इकाई की पहचान बनाए रखेगा, क्योंकि जब तक आप इस तरह के व्यवहार को केवल एक डोमेन मॉडल में एक अवधारणा के रूप में मौजूद हैं (आईडी विशेषता के रूप में मौजूद हैं) एक इकाई), लेकिन जब हम इस आईडी विशेषता का कोड में अनुवाद करते हैं, तो इसके शब्दार्थ का एक हिस्सा खो जाता है (यानी वह हिस्सा जो यह सुनिश्चित करता है कि आईडी मान अद्वितीय है खो गया है)?
2।
फर्थमोर, एक संपत्ति जैसे कि आयु का एक व्यक्ति इकाई के बाहर कोई संदर्भ नहीं है, और इस तरह, एक अलग वस्तु में स्थानांतरित करने के लिए कोई मतलब नहीं है ... हालांकि यह जानकारी आसानी से एक अलग स्थान में संग्रहीत की जा सकती है जो अद्वितीय पहचानकर्ता, इसलिए व्यवहार के लिए भ्रामक संदर्भ। आयु एक आलसी भरी हुई कीमत हो सकती है।
a) यदि Ageसंपत्ति आलसी है, तो हम इसे एक व्यवहार कह सकते हैं, भले ही शब्दार्थ Ageसिर्फ एक विशेषता है?
3।
आप आसानी से परिचालन जैसे पते के लिए विशिष्ट हो सकते हैं जैसे कि यह एक वैध पता है। आप यह नहीं जान सकते हैं कि डिजाइन के समय, लेकिन यह पूरी अवधारणा वस्तुओं को उनके सबसे छोटे भागों में विभाजित करने के लिए है
हालांकि मैं मानता हूं कि हम Ageअलग-अलग ऑब्जेक्ट में जाने से संदर्भ खो देंगे , अगर हम DateOfBirthएक अलग ऑब्जेक्ट में संपत्ति स्थानांतरित करते हैं , तो संदर्भ खो नहीं जाएगा , लेकिन हम आमतौर पर इसे स्थानांतरित नहीं करते हैं।
क्या मुख्य कारण है कि हम Addressकिसी अन्य वस्तु में चले जाएँगे, लेकिन नहीं DateOfBirth? क्योंकि इकाई के DateOfBirthलिए अधिक आंतरिक है Personया क्योंकि कम संभावनाएं हैं कि भविष्य में कहीं हमें परिचालन के लिए विशिष्ट परिभाषित करने की आवश्यकता हो सकती है DateOfBirth?
4. मैं कहना होगा मैं अभी भी नहीं पता कि MyEntityयह भी है A_respऔर B_respजिम्मेदारियों और क्यों MyEntityभी होने AB_respका उल्लंघन नहीं माना जाता है SRP
EULERFX
1)
लेखक जिन व्यवहारों की बात कर रहा है, वे इकाई से जुड़े व्यवहार हैं। ये ऐसे व्यवहार हैं जो इकाई की स्थिति को संशोधित करते हैं
a) यदि मैं आपको सही तरीके से समझता हूं, तो आप कह रहे हैं कि इकाई में केवल उन व्यवहारों को शामिल करना चाहिए जो इसकी विशेषताओं (अर्थात इसकी स्थिति ) को संशोधित करते हैं ?
ख) और उन व्यवहारों के बारे में जो आवश्यक रूप से इकाई की स्थिति को संशोधित नहीं करते हैं , लेकिन फिर भी उन्हें उस इकाई की आंतरिक विशेषता के रूप में माना जाता है (उदाहरण: भौंकना एक इकाई की आंतरिक विशेषता होगी , भले ही वह संशोधित न हुई हो कुत्ते की अवस्था )? क्या हमें इन व्यवहारों को एक इकाई में शामिल करना चाहिए या उन्हें अन्य वस्तुओं में ले जाना चाहिए? Dog
2)
जहां तक अन्य वस्तुओं के साथ व्यवहार करने की बात है, लेखक विशेष रूप से मूल्य वस्तुओं का उल्लेख कर रहा है।
हालाँकि मेरे उद्धरण में इसे शामिल नहीं किया गया है, लेकिन लेखक उसी पैराग्राफ में उल्लेख करता है कि कुछ मामलों में व्यवहार (और विशेषताएँ ) अन्य संस्थाओं में भी स्थानांतरित हो जाएंगे (हालांकि मैं वीओ के व्यवहार को समझने के लाभों को समझता हूं )
3) यह मानते हुए MyEntity(प्रश्न देखें 3. अपने मूल पोस्ट में) SRP का उल्लंघन नहीं है, हम कहते हैं कि एक करता जिम्मेदारी की MyEntityअन्य बातों के भी शामिल में से एक है:
ए। A_resp + B_resp + AB_resp ( AB_respनिर्देशांक वस्तुओं aऔर b)
या
ख। AB_resp + प्रतिनिधि A_respऔर B_respवस्तुओं ( aऔर b) के साथ जुड़े MyEntity?
4) एरिक इवान की डीडीडी पुस्तक, स्नातकोत्तर। 94:
CustomerID ग्राहक ENTITY (आंकड़ा 5.5) का एक और एकमात्र पहचानकर्ता है, लेकिन ग्राहक को खोजने या मिलान करने के लिए अक्सर फ़ोन नंबर और पते का उपयोग किया जाएगा। नाम किसी व्यक्ति की पहचान को परिभाषित नहीं करता है, लेकिन अक्सर इसे निर्धारित करने के साधन के हिस्से के रूप में उपयोग किया जाता है।
इस उदाहरण में, फ़ोन और पता विशेषताएँ ग्राहक में चली गईं, लेकिन एक वास्तविक परियोजना पर, यह विकल्प इस बात पर निर्भर करेगा कि डोमेन के ग्राहक आमतौर पर कैसे मेल खाते हैं या प्रतिष्ठित हैं। उदाहरण के लिए, यदि किसी ग्राहक के पास विभिन्न उद्देश्यों के लिए कई संपर्क फोन नंबर हैं, तो फोन नंबर पहचान से जुड़ा नहीं है और उसे बिक्री संपर्क के साथ रहना चाहिए।
ए)
CustomerID ग्राहक ENTITY (आंकड़ा 5.5) का एक और एकमात्र पहचानकर्ता है, लेकिन ग्राहक को खोजने या मिलान करने के लिए अक्सर फ़ोन नंबर और पते का उपयोग किया जाएगा। नाम किसी व्यक्ति की पहचान को परिभाषित नहीं करता है, लेकिन अक्सर इसे निर्धारित करने के साधन के हिस्से के रूप में उपयोग किया जाता है।
उद्धरण में कहा गया है कि केवल पहचान से जुड़ी विशेषताओं को एक इकाई में रहना चाहिए । मुझे लगता है कि लेखक का मतलब है कि इकाई में केवल वे विशेषताएँ शामिल होनी चाहिए जो इस इकाई को खोजने या मिलान करने के लिए उपयोग की जाती हैं , जबकि अन्य सभी विशेषताओं को स्थानांतरित किया जाना चाहिए?
ख) लेकिन अन्य विशेषताओं को कैसे / कहां स्थानांतरित किया जाना चाहिए ? उदाहरण के लिए (यहाँ धारणा यह है कि पता लगाने या मिलान करने के लिए पता विशेषता का उपयोग नहीं किया जाता है Customerऔर इस प्रकार हम पता विशेषता को बाहर ले जाना चाहते हैं Customer):
यदि हमारे पास Customer.Address(प्रकार का string) होने के बजाय , हम Customer.Addressप्रकार की संपत्ति बनाते हैं Address, तो क्या हमने पते की विशेषता को संबद्ध VO ऑब्जेक्ट (जो प्रकार का है Address) में स्थानांतरित किया है या हम कहेंगे कि Customerअभी भी पता विशेषता शामिल है ?
सी)
इस उदाहरण में, फ़ोन और पता विशेषताएँ ग्राहक में चली गईं, लेकिन एक वास्तविक परियोजना पर, यह विकल्प इस बात पर निर्भर करेगा कि डोमेन के ग्राहक आमतौर पर कैसे मेल खाते हैं या प्रतिष्ठित हैं। उदाहरण के लिए, यदि किसी ग्राहक के पास विभिन्न उद्देश्यों के लिए कई संपर्क फोन नंबर हैं, तो फोन नंबर पहचान से जुड़ा नहीं है और उसे बिक्री संपर्क के साथ रहना चाहिए।
क्या यहाँ लेखक गलत नहीं है, क्योंकि यदि हम कई कॉन्टेक्ट फ़ोन नंबरों में से प्रत्येक को मानते हैं जो Customerकेवल उस विशेष से संबंधित हैं Customer, तो मैं कहूंगा कि ये फ़ोन नंबरों की पहचान के साथ जुड़े हुए हैं जब Customerकेवल एक फोन नंबर था। ?
5)
लेखक द्वारा इकाई को छीनने का कारण यह बताया गया है कि जब कोई प्रारंभ में ग्राहक इकाई बनाता है, तो उसे किसी भी विशेषता के साथ आबाद करने की प्रवृत्ति होती है जिसे कोई ग्राहक के साथ जुड़ा होने के बारे में सोच सकता है। यह एक डेटा-केंद्रित दृष्टिकोण है जो अंत में एनीमिक डोमेन मॉडल के लिए व्यवहार को अनदेखा करता है।
विषय से बाहर, लेकिन मुझे लगा कि एनीमिक डोमेन मॉडल एक इकाई से बाहर व्यवहार करने से परिणाम देता है , जबकि आपका उदाहरण एक इकाई को बहुत सारी विशेषताओं के साथ आबाद कर रहा है , जिसके परिणामस्वरूप बहुत अधिक व्यवहार होगा (क्योंकि हम शायद उन व्यवहारों में भी शामिल होंगे जो इन अतिरिक्त विशेषताओं को संशोधित करें ) और इस तरह एसआरपी का उल्लंघन?CustomerCustomer
धन्यवाद