"गहरी रचना पदानुक्रम" भी बुरा नहीं है?

Question

माफी अगर "रचना पदानुक्रम" एक बात नहीं है, लेकिन मैं समझाता हूँ कि मैं इस सवाल से क्या मतलब है।

कोई भी OO प्रोग्रामर नहीं है जो "विरासत वंशानुक्रम फ्लैट रखें" या "वंशानुक्रम पर पसंदीदा रचना" और इत्यादि की विविधता में नहीं आया है। हालांकि, गहरी रचना पदानुक्रम के रूप में अच्छी तरह से समस्याग्रस्त लगता है।

मान लें कि हमें किसी प्रयोग के परिणामों का विवरण देने वाली रिपोर्ट के संग्रह की आवश्यकता है:

class Model {
    // ... interface

    Array<Result> m_results;
}

प्रत्येक परिणाम में कुछ गुण होते हैं। इनमें प्रयोग के समय के साथ-साथ प्रयोग के प्रत्येक चरण के कुछ मेटा-डेटा शामिल हैं:

enum Stage {
    Pre = 1,
    Post
};

class Result {
    // ... interface

    Epoch m_epoch;
    Map<Stage, ExperimentModules> m_modules; 
}

ठीक है अच्छा है। अब, प्रत्येक प्रयोग मॉड्यूल में प्रयोग के परिणाम के साथ-साथ प्रयोगात्मक नमूना सेटों के संदर्भों के संग्रह का वर्णन करने वाला एक स्ट्रिंग है:

class ExperimentalModules {
    // ... interface

    String m_reportText;
    Array<Sample> m_entities;
}

और फिर प्रत्येक नमूने में ... अच्छी तरह से, आपको तस्वीर मिलती है।

समस्या यह है कि अगर मैं अपने एप्लिकेशन डोमेन से ऑब्जेक्ट्स मॉडलिंग कर रहा हूं, तो यह एक बहुत ही प्राकृतिक फिट की तरह लगता है, लेकिन दिन के अंत में Result यह डेटा का सिर्फ एक बेवकूफ कंटेनर है! इसके लिए कक्षाओं का एक बड़ा समूह बनाना सार्थक नहीं लगता।

यह मानते हुए कि डेटा संरचना और कक्षाएं ऊपर दिखाए गए एप्लिकेशन डोमेन में रिश्तों को सही ढंग से दर्शाती हैं, क्या इस तरह के "परिणाम" को मॉडल करने का एक बेहतर तरीका है, एक गहरी रचना पदानुक्रम का सहारा लिए बिना? क्या कोई बाहरी संदर्भ है जो आपको यह निर्धारित करने में मदद करेगा कि ऐसा डिज़ाइन एक अच्छा है या नहीं?

Comments

बाहरी संदर्भ भाग को न समझें।

— ट्यूलेंस कोरडोवा

@ TulainsCórdova मैं यहां जो पूछना चाहता हूं वह है "क्या ऐसी परिस्थितियां हैं जिनके लिए गहरी रचना एक अच्छा समाधान है"?

— बढ़िया

मैंने एक उत्तर जोड़ा।

— ट्यूलेंस कोर्डोवा

हाँ बिल्कुल। जिन समस्याओं को लोग रचना के साथ विरासत से बदलकर ठीक करने का प्रयास करते हैं वे जादुई रूप से सिर्फ इसलिए दूर नहीं हो जाती हैं क्योंकि आपने एक फीचर एकत्रीकरण रणनीति को दूसरे के लिए बदल दिया है। वे दोनों जटिलता के प्रबंधन के समाधान हैं, और यह जटिलता अभी भी है और किसी तरह से संभाला जाना है।

— मेसन व्हीलर 19

मैं गहरे डेटा मॉडल के साथ कुछ भी गलत नहीं देखता। लेकिन मैं यह भी नहीं देखता कि आप इसे कैसे विरासत में मिला सकते हैं क्योंकि यह प्रत्येक परत पर 1: N संबंध है।

— यूएसआर

Answer 1

यह कम से कम ज्ञान के कानून / सिद्धांत के कानून के बारे में क्या है। Modelजरूरी नहीं कि एक उपयोगकर्ता के बारे में पता होना चाहिएExperimentalModules अपना काम करने के लिए 'इंटरफ़ेस के ।

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

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

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

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

लेकिन अगर मेरे इंटरफेस का उपयोग केवल आंतरिक रूप से किया जाता है, या यदि मैं जो इंटरफेस उजागर करता हूं, वे बहुत मौलिक हैं (एक मानक पुस्तकालय का हिस्सा है, या एक पुस्तकालय का इतना मौलिक है कि यह कभी भी इसे बदलने के लिए समझ में नहीं आएगा), तो इसे छिपाने के लिए बेकार हो सकता है ये इंटरफेस। हमेशा की तरह, कोई भी एक आकार-फिट-सभी जवाब नहीं है।

Comments

आपने एक प्रमुख चिंता का उल्लेख किया था जो मुझे हो रहा था; यह विचार कि मुझे अमूर्तता के उच्च स्तरों पर कुछ उपयोगी करने के लिए कार्यान्वयन में दूर तक पहुँचना था। एक बहुत उपयोगी चर्चा, धन्यवाद।

— AwesomeSauce

Answer 2

"गहरी रचना पदानुक्रम" भी बुरा नहीं है?

बेशक। नियम को वास्तव में कहना चाहिए "सभी पदानुक्रमों को यथासंभव सपाट रखें।"

लेकिन गहरी रचना पदानुक्रम गहरी विरासत पदानुक्रम की तुलना में कम भंगुर होती है, और बदलने के लिए अधिक लचीली होती है। सहज रूप से, यह कोई आश्चर्य के रूप में आना चाहिए; परिवार के पदानुक्रम उसी तरह हैं। आपके रक्त संबंधियों के साथ आपका संबंध आनुवांशिकी में तय हो गया है; आपके मित्र और जीवनसाथी के साथ आपके रिश्ते नहीं हैं।

आपका उदाहरण मुझे "गहरी पदानुक्रम" के रूप में नहीं मारता है। एक प्रपत्र एक आयत से विरासत में मिला है जो अंकों के एक सेट से विरासत में मिला है जो x और y निर्देशांक से विरासत में मिला है, और मैंने अभी तक भाप का एक पूर्ण सिर नहीं प्राप्त किया है।

Answer 3

पैराफ्रासिंग आइंस्टीन:

सभी पदानुक्रमों को यथासंभव फ्लैट रखें, लेकिन चापलूसी नहीं

मतलब अगर आप जो समस्या मॉडलिंग कर रहे हैं, वह वैसी ही है, तो आपको मॉडलिंग के बारे में ऐसा नहीं होना चाहिए जैसा वह है।

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

Answer 4

हां, आप इसे रिलेशनल टेबल की तरह मॉडल कर सकते हैं

Result {
    Id
    ModelId
    Epoch
}

आदि जो अक्सर एक डेटाबेस के लिए आसान प्रोग्रामिंग और सरल मानचित्रण के लिए नेतृत्व कर सकते हैं। लेकिन अपने रिश्तों की कड़ी कोडिंग खोने की कीमत पर

Answer 5

मैं वास्तव में जावा में इसे हल करने का तरीका नहीं जानता, क्योंकि जावा इस विचार के आसपास बनाया गया है कि सब कुछ एक वस्तु है। आप उन्हें एक डिक्शनरी द्वारा बदलकर इंटरमीडिएट कक्षाओं को दबा नहीं सकते क्योंकि आपके डेटा ब्लब्स में प्रकार विषम हैं (जैसे टाइमस्टैम्प + सूची, या स्ट्रिंग + सूची ...)। अपने क्षेत्र के साथ एक कंटेनर वर्ग को बदलने का विकल्प (जैसे "m_modules" के साथ "m_epoch" चर के साथ गुजरता है) बस बुरा है, क्योंकि यह एक अंतर्निहित वस्तु बना रहा है (आपके पास एक के बिना दूसरा नहीं हो सकता है) विशेष रूप से फायदा।

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