क्या मुझे डेटा ट्रांसफर ऑब्जेक्ट्स के लिए इंटरफेस बनाना चाहिए?

Question

क्या डेटा ट्रांसफर ऑब्जेक्ट के लिए इंटरफ़ेस बनाना एक अच्छा विचार या एक बुरा विचार है? यह मानते हुए कि वस्तु आमतौर पर परिवर्तनशील है।

हालांकि मेरा उदाहरण जावा में है, यह किसी भी अन्य भाषा पर लागू होना चाहिए जिसमें समान अवधारणाएं हैं।

interface DataTransferObject  {
    String getName();
    void setName(String name);
}

class RealDataTransferObject  implements DataTransferObject {

    String name;
    String getName() {
        return name;
    } 
    void setName(String name) {
        this.name = name;
    }
}

बेशक, यह एक सरलीकृत उदाहरण है, वास्तविक जीवन में अधिक क्षेत्र हो सकते हैं।

Answer 1

सामान्य उत्तर नहीं है , क्योंकि आपको इसके लिए एक विशिष्ट, ठोस कारण के बिना कभी भी कोड नहीं जोड़ना चाहिए, और इस तरह के इंटरफ़ेस का कोई सामान्य कारण नहीं है।

कहा जा रहा है, कभी-कभी एक अच्छा कारण हो सकता है। लेकिन सभी मामलों में मैंने देखा है, ये इंटरफेस आंशिक थे, कई वर्गों द्वारा साझा की गई केवल एक या कुछ संपत्तियों को कवर करते हुए मैं उन्हें पॉलीस्पॉर्फिक रूप से एक सामान्य सुपरक्लास दिए बिना उपयोग करना चाहता था। विशिष्ट उम्मीदवार Idकिसी प्रकार की रजिस्ट्री या Nameउपयोगकर्ता को प्रदर्शित करने के लिए एक संपत्ति का उपयोग करने के लिए एक संपत्ति हैं। लेकिन यह किसी भी मामले में उपयोगी हो सकता है, जहां आप चाहते हैं कि कुछ कोड एक एक्स - सब कुछ संभालने के लिए - बस एक XSourceइंटरफ़ेस बनाएं जिसमें getX(और, केवल यदि आवश्यक हो, तो setX) विधियां शामिल हैं।

लेकिन सभी गुणों वाले प्रत्येक मॉडल वर्ग के लिए एक अलग इंटरफ़ेस? मैं ऐसा करने के लिए एक अच्छे कारण की कल्पना नहीं कर सकता। एक बुरा कारण एक बुरी तरह से डिज़ाइन किया गया ढांचा होगा जिसकी आवश्यकता है; Entity EJBs ने बस यही किया, अगर मुझे सही से याद है। शुक्र है कि वे इतने बुरे थे कि उन्हें कभी अधिक कर्षण नहीं मिला और ईजेबी 3.0 के बाद से पदावनत कर दिया गया

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

Comments

"एनीमिक डोमेन मॉडल को एक एंटीपैटर्न माना जाता है" - मार्टिन फाउलर द्वारा, जो PEAA में, स्वीकार करता है कि वह उन लोगों को जानता है, जिन्होंने दशकों से इस तरह से काम किया है "बहुत सफलतापूर्वक"। इस प्रकार, मेरा सुझाव है, कम-विरोधी पैटर्न और अधिक-न-कैसे फाउलर-लाइक-टू-वर्क। बहरहाल, अच्छा जवाब, +1।

— pdr

@pdr: फाउलर ने शब्द गढ़ा हो सकता है, लेकिन वह किसी भी तरह से एकमात्र ऐसा व्यक्ति नहीं है जो उन्हें एक एंटीपैटर्न मानता है। मुझे नहीं लगता कि जो कोई भी वास्तव में OO समझ गया है वह सोचता है कि डोमेन-विशिष्ट तर्क को डोमेन मॉडल से बाहर रखना एक अच्छा विचार है।

— माइकल बोर्गवर्ड 21

शब्द सुधार के लिए धन्यवाद, डीटीओ वह शब्द था जिसे मैं कल रात खोज रहा था लेकिन मुझे अपने जीवन के लिए याद नहीं कर सका। चारों ओर नाम बदलकर, चीजों ने अधिक समझदार डिजाइन को बुद्धिमान बना दिया।

— आर्किमिडीज ट्रेजानो

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

— डैनियल बी

@MichaelBorgwardt: मैं मानता हूं, वह अकेले नहीं हैं। लेकिन न तो वे लोग हैं जो असहमत हैं। यदि आपने कहा है कि "एनीमिक डोमेन मॉडल कुछ लोगों द्वारा एक विरोधी पैटर्न माना जाता है," मैंने कहा था कि कुछ भी नहीं है। सच कहूं, तो मुझे लगता है कि आपका पूरा जवाब वैसे भी पिछले पैराग्राफ के बिना बेहतर होगा। पहले आधे ने बेहतर टिप्पणी की होगी; दूसरी छमाही इस प्रश्न के लिए कुछ भी नहीं प्रदान करता है।

— pdr

Answer 2

इंटरफ़ेस बनाना ठीक है, लेकिन आपके उदाहरण के काम करने का तरीका नहीं। आपको इंटरफ़ेस से सेटर को हटा देना चाहिए, और यह ठीक हो जाएगा:

interface ValueObject {
  String getName();
};

यह इसके कई अलग-अलग कार्यान्वयनों की अनुमति देता है, जैसे नाम डेटाबेस से प्राप्त किया जा सकता है ... सेटर अलग इंटरफ़ेस में होना चाहिए।

Answer 3

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

तो सवाल का सामान्य उत्तर "क्या मुझे यह इंटरफ़ेस बनाना और उपयोग करना चाहिए?" है: हाँ, यदि आप एक (एक एकल) अवधारणा को अपने ग्राहकों के लिए शब्दार्थ से संबद्ध कर सकते हैं।

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

आपके विशेष मामले में, मेरा मानना ​​है कि आपका इंटरफ़ेस बेकार है। इसका उपयोग कौन, कैसे और कब करेगा? आप प्रत्येक परिवर्तनशील मूल्यों के लिए एक इंटरफ़ेस नहीं बना सकते। तो अपने आप से पूछें कि आपके तरीकों के पीछे क्या प्रासंगिक और दिलचस्प संपत्ति है।

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

Answer 4

जैसा कि माइकल ने कहा, जब तक आपको इसके लिए कोई विशिष्ट आवश्यकता न हो, इंटरफ़ेस न जोड़ें।

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

Comments

युगों में नकली रूपरेखा का उपयोग करने के लिए इंटरफेस आवश्यक नहीं है।

— माइकल बोर्गवर्ड 21

लगता है कि आप मंकीपिंग की वकालत कर रहे हैं। मैं C # में मोल्स के साथ उस सड़क से नीचे गया हूं और यह बहुत सुंदर नहीं है। यदि संभव हो तो अपने सहयोगियों में पास होना बेहतर है।

— 22

हालांकि दो मॉकिंग फ्रेमवर्क जो मैं मॉकिटो का उपयोग करता हूं और इकोमॉक उन्हें अपरिवर्तनीय बनाते समय अंतिम कक्षाओं का मजाक नहीं उड़ा सकता।

— आर्किमिडीज ट्रेजानो

Answer 5

यदि आप चाहते हैं कि यह वस्तु भविष्य में किसी प्रकार के क्षेत्र सत्यापन के लिए है, तो आपको उन्हें शुरुआती चरणों में ही समाप्त कर देना चाहिए।

Answer 6

'वैल्यू फॉर ऑब्जेक्ट' इंटरफ़ेस वह है जो मुझे एक्सेसर को कॉल करने के लिए उपयोग किया जाता है।

मुझे एक्सेसरों की आवश्यकता से संबंधित विभिन्न नीतियों का अनुभव हुआ। कुछ लोग जब जितना संभव हो, वकालत करते हैं, तो कुछ अन्य लिखने के लिए कोड की मात्रा को कम करने के लिए निषेध करते हैं।

एक्सेसर्स (या प्रत्यक्ष मूल्य उपयोग) के लिए कुछ तर्क निम्नलिखित हैं:

• एक्सेसर्स बाद में मूल्य को संग्रहीत करने के तरीके को बदलने की अनुमति देता है
• जब आप अपने सॉफ़्टवेयर को डीबग करना चाहते हैं, तो एक्सेसर्स एक्सेस लॉग को जोड़ने की अनुमति देता है (जब किसी एकल विधि में लॉग कॉल जोड़ते हैं, तो आप हर मूल्य परिवर्तन को कैप्चर करते हैं)
• एक्सेसर्स ऑब्जेक्ट प्रोग्रामिंग के अनुरूप अधिक हैं, प्रत्येक चर विधियों द्वारा एनकैप्सुलेट किया जा रहा है
• एक्सेसर्स कोड एक्सप्रेसिवनेस कम कर देता है (उसी परिणाम के लिए अधिक SLOC)
• एक्सेसर्स कुछ सीपीयू लेते हैं

मैं व्यक्तिगत रूप से एक्सेसरों की संख्या को कम करने और उन्हें उपयोग करने की वकालत करता हूं जब आप सेटर (सेटनाम) से अपेक्षा करते हैं कि वे बाद में एक साधारण प्रभाव से अधिक हो जाएंगे।

Answer 7

इस तरह का मूल्य वस्तु काफी निम्न स्तर है। मेरा सुझाव है कि इसे दो दिशाओं में से एक में धकेलें: (1) मान ऑब्जेक्ट को अपरिवर्तनीय बनाते हैं, अर्थात, वास्तविक मूल्य की तरह , या (2) एक उच्च स्तर के डोमेन उन्मुख व्यावसायिक फ़ंक्शन के लिए उत्परिवर्तन को बढ़ाते हैं, जिसका अर्थ हमें उजागर करना चाहिए कार्यक्षमता की डोमेन प्रासंगिक इकाइयों के संदर्भ में इंटरफेस।