सीमाओं पर, एप्लिकेशन ऑब्जेक्ट ओरिएंटेड नहीं हैं

मुझे पोका-योक डिजाइन पदों की मेरी हालिया श्रृंखला पर बहुत प्रतिक्रिया मिली (यदि यह अन्यथा था तो मैं परेशान होऊंगा)। इनमें से कई समीक्षाएं विभिन्न सरलीकरण या अनुवाद तकनीकों से संबंधित हैं जो आमतौर पर आवेदन सीमाओं पर उपयोग की जाती हैं: क्रमांकन, एक्सएमएल (डी) जलयोजन (अनुवादक का नोट: क्रमबद्धता के समान), यूआई सत्यापन आदि। ध्यान दें कि यह अनुवाद न केवल आवेदन की परिधि के आसपास होता है, बल्कि दृढ़ता के स्तर पर भी होता है। ओआरएम अनुवादकारी तंत्र भी हैं।
कई टिप्पणियों के लिए सामान्य यह दावा है कि अधिकांश क्रमांकन प्रौद्योगिकियों के लिए डिफ़ॉल्ट निर्माता की आवश्यकता होती है। उदाहरण के लिए, XmlSerializer वर्ग को डिफ़ॉल्ट निर्माता और सार्वजनिक, लिखने योग्य गुणों की आवश्यकता होती है। मेरे द्वारा अध्ययन किए गए अधिकांश ऑब्जेक्ट-रिलेशनल कन्वर्टर्स में समान आवश्यकताएं हैं। Windows प्रपत्र और WPF नियंत्रण (UI भी अनुप्रयोग की सीमा है) लगभग एक डिफ़ॉल्ट निर्माता होना आवश्यक है। क्या इससे एनकैप्सुलेशन टूट जाता है? हाँ और नहीं।

सीमा पर वस्तुएं
यदि आपने अपनी वस्तुओं (डोमेन) को एप्लिकेशन की सीमा पर सही उजागर किया तो निश्चित रूप से एनकैप्सुलेशन टूट जाएगा । एक सरल XML दस्तावेज़ पर विचार करें:

<name> <firstName>Mark</firstName> <lastName>Seemann</lastName> </name> 

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

 <name> <firstName>Mark</firstName> </name> 

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

सेवाएं एक योजना और एक अनुबंध साझा करती हैं, एक वर्ग नहीं।

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

डीटीओ ऑब्जेक्ट एनकैप्सुलेशन को नहीं तोड़ते हैं, क्योंकि वे ऑब्जेक्ट नहीं हैं।

अपने औजारों से मूर्ख मत बनो। .NET फ्रेमवर्क वास्तव में, वास्तव में आप अपने डीटीओ ऑब्जेक्ट्स को वास्तविक ऑब्जेक्ट्स मानना ​​चाहते हैं।
यह कोड जनरेशन से आता है।
इस तरह के ऑटो-जनरेट किए गए वर्गों द्वारा प्रदान की गई सख्त टाइपिंग सुरक्षा की झूठी भावना देती है। आप सोच सकते हैं कि आपको कंपाइलर से तेजी से प्रतिक्रिया मिल रही है , लेकिन कई संभावित स्थितियां हैं जिनमें आपको एक रनटाइम त्रुटि मिलती है (सबसे उल्लेखनीय वे हैं जिन्हें आप प्राप्त करते हैं, सर्किट को अपडेट करने के बाद स्वचालित रूप से उत्पन्न कोड को अपडेट करना भूल जाते हैं)।
वस्तुओं के रूप में इनपुट और आउटपुट डेटा का प्रतिनिधित्व करने का एक और भी बुरा परिणाम यह है कि बहुत सारे डेवलपर्स, धोखा देने वाले, वस्तुओं के वास्तविक मॉडल के रूप में उनके साथ काम करते हैं। सुसंगत परिणाम एक एनीमिक डोमेन मॉडल है ।
अधिक से अधिक, तर्कों की यह श्रृंखला मुझे यह निष्कर्ष निकालने के लिए ले जाती है कि डीटीओ मानसिक मॉडल जो हम पिछले 10 वर्षों से उपयोग कर रहे हैं वह एक मृत अंत है।

आवेदन की सीमा पर क्या होना चाहिए
मान लीजिए कि हम ऑब्जेक्ट-ओरिएंटेड कोड लिखते हैं, और बॉर्डर पर डेटा ऑब्जेक्ट-ओरिएंटेड ऑब्जेक्ट्स के अलावा कुछ भी है। हम उनके साथ कैसे काम करते हैं?
एक विकल्प यह है कि हमारे पास जो भी है उसके साथ बने रहें इस मामले में, छेद को भरने के लिए, हमें एक अनुवाद परत विकसित करनी चाहिए जो डीटीओ ऑब्जेक्ट को ठीक से एन्कैप्सुलेटेड डोमेन ऑब्जेक्ट में अनुवाद कर सके। यह वह पथ है जिसका मैं अपनी पुस्तक में उदाहरणों में अनुसरण करता हूं । हालांकि, यह निर्णय, मुझे अधिक से अधिक संदेह है, सबसे अच्छा नहीं है। यह समर्थन समस्याओं का कारण बनता है। (वैसे, पुस्तक लिखते समय इस तरह की समस्या उत्पन्न होती है: जब आप समाप्त हो जाते हैं, तब तक आप जितना जानते हैं उससे कहीं अधिक जानते हैं जब आपने इसे शुरू किया था ... मैं पुस्तक की निंदा नहीं कर रहा हूं, यह आदर्श नहीं है ...)
एक और संभावना यह है कि डेटा को ऑब्जेक्ट के रूप में मानना ​​बंद कर दें और उन्हें संरचित डेटा के रूप में मानना ​​शुरू करें, जो वे वास्तव में हैं। यह बहुत अच्छा होगा यदि हमारी प्रोग्रामिंग भाषा में संरचित डेटा की एक अलग अवधारणा है ... दिलचस्प है, जबकि सी # ऐसा कुछ भी नहीं करता है, एफ # में डेटा संरचनाओं के मॉडलिंग की संभावनाओं का एक गुच्छा है जिसमें व्यवहार नहीं है। शायद यह डेटा के साथ काम करने के लिए एक अधिक ईमानदार दृष्टिकोण है ... इसके साथ प्रयोग करना आवश्यक होगा ...
तीसरा विकल्प गतिशील प्रकारों की ओर देखना है। डिनो एस्पोसिटो ने अपने लेख " ऑन द एज: एक्सपेंडो ऑब्जेक्ट्स इन सी # 4.0 " में, संरचित डेटा की खपत के लिए एक गतिशील दृष्टिकोण की रूपरेखा तैयार की है, जो स्वचालित रूप से कोड उत्पन्न करता है और संरचित डेटा के लिए एक हल्का एपीआई प्रदान करता है। यह एक आशाजनक दृष्टिकोण की तरह भी दिखता है ... यह संकलन चरण में प्रतिक्रिया प्रदान नहीं करता है, लेकिन यह सुरक्षा की झूठी भावना के बाद है। हमें त्वरित प्रतिक्रिया प्राप्त करने के लिए इकाई परीक्षणों का सहारा लेना चाहिए, हम सभी टीडीडी का अभ्यास करते हैं, है ना?
अंत में, मेरी पूरी एनकैप्सुलेशन श्रृंखला ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से संबंधित है। यद्यपि डेटा को "ऑब्जेक्ट" के रूप में प्रस्तुत करने के लिए कई प्रौद्योगिकियां हैं, लेकिन वे झूठी वस्तुएं हैं। भले ही हम सीमा पर ऑब्जेक्ट-ओरिएंटेड का उपयोग करते हैं, इस कोड का ऑब्जेक्ट ओरिएंटेशन से कोई लेना-देना नहीं है। इसलिए, यहां पोका-योक डिजाइन नियम लागू नहीं हैं।
अब शुरुआत में वापस जाएं और पोस्ट को फिर से पढ़ें "डीटीओ" की जगह "एंटिटी" (या ऐसा कुछ जिसे आपका ORM एक संबंधपरक तालिका में एक पंक्ति का प्रतिनिधित्व कहता है) और आपको ऑब्जेक्ट-रिलेशनल रिलेटर्स की रूपरेखा देखनी चाहिए इतना संदिग्ध।