"प्रबंधक" कक्षाओं के उपयोग को कम करने के बारे में सुझाव / सलाह

Question

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

क्या वास्तव में जितना संभव हो प्रबंधक कक्षाओं से बचना चाहिए? इसके अलावा, मुझे उन लेखों / पत्रों को कैसे पढ़ना चाहिए जो सामान्य / सामान्य मामलों के लिए वैकल्पिक काम को लागू करने के बारे में हैं जहां इन प्रबंधकों को हटाया जा सकता है?

Comments

प्रोग्रामर.स्टैकएक्सचेंज .com/ questions/ 59866/ … का उत्तर आपके लिए उपयोगी हो सकता है।

— Tesserex

वे या वे "प्रबंधन" कर रहे हैं, उन वर्गों के तर्क क्या हैं? अपने आप से उन सवालों को पूछें, और उन वर्गों के तर्क को विस्तार या कम करने, या स्थानांतरित करने में आपकी सहायता कर सकते हैं।

— umlcat

Answer 1

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

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

Answer 2

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

"सूचना विशेषज्ञ" के सिद्धांत का पालन करते हुए , एक तार्किक ऑपरेशन को उस डेटा के करीब रहना चाहिए, जिसकी आवश्यकता होती है। इसका मतलब होगा कि डोमेन लॉजिक को वापस डोमेन मॉडल में ले जाना, ताकि यह इन लॉजिकल ऑपरेशंस हों, जो कि डोमेन मॉडल की स्थिति पर एक चौकस प्रभाव डालते हैं, न कि बाहर से डोमेन मॉडल की स्थिति को बदलने वाली लेन-देन लिपियों के बजाय।

Answer 3

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

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