डेटा ओरिएंटेड इंटरफेस के लिए प्रोग्रामिंग

Question

हमारे कोडबेस का एक भाग निम्न शैली में लिखा गया है:

// IScheduledTask.cs
public interface IScheduledTask
{
    string TaskName { get; set; }
    int TaskPriority { get; set; }
    List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein
}

// ScheduledTaskImpl.cs
public class ScheduledTaskImpl : IScheduledTask
{
    public string TaskName { get; set; }
    public int TaskPriority { get; set; }
    public List<IScheduledTask> Subtasks { get; set; }
    // ... several more properties in this vein, 
    // perhaps a constructor or two for convenience.
}

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

Comments

एक कारण जो मैंने किया है वह COM संगतता के लिए है, लेकिन यह आपके कारण नहीं लगता है।

— माइक

@ माइक दिलचस्प है, मैंने कभी COM का उपयोग नहीं किया है और इसका उपयोग यहां नहीं किया गया है। मैं कोड के इस खंड के लेखक से पूछूंगा कि क्या वह COM या कुछ भी उपयोग करने की योजना बना रहा था।

— वॉलपेप

मेरा अनुमान होगा कि वह अपेक्षाकृत निकट भविष्य में कम से कम उन संपत्तियों में से एक को गैर-ऑटो बनाने की उम्मीद करता है, और इस बायलरप्लेट को शुरू में लिखना एक आदत है जिसे उसने बाद में कुछ समय के लिए निखरने से बचाया है। C # आदमी नहीं है इसलिए मैं बस इतना ही कह सकता हूं।

— Ixrec

IMHO इसे लागू न करने वाले इंटरफेस पर कोड का अति-जुनून और गलत अर्थ है । एक महत्वपूर्ण कथा-कहानी एकमात्र कार्यान्वयन है । इंटरफेस की बात बहुरूपता है, लेकिन एक गुण-केवल वर्ग अलग-अलग मूल्य होने से एक अर्थ में बहुरूपी है। व्यवहार - विधियों के साथ भी - इसका कोई मतलब नहीं है कि इसे एक ही क्रियान्वयन दिया जाए। यह बकवास हमारे कोड बेस पर है और सबसे अच्छा यह रखरखाव में बाधा डालता है। मैं रास्ता बहुत ज्यादा समय बर्बाद क्यों, क्या, और कहाँ पूछ रहा हूँ। उन्होंने ऐसा क्यों किया, मैं कौन सा डिज़ाइन देख रहा हूं और अन्य कार्यान्वयन कहां हैं?

— राडारबॉब

अधिकांश पूर्ववर्ती टिप्पणियां समयपूर्व अमूर्त के एकल कार्यान्वयन "कोड गंध" पर जाती हैं; हालाँकि, यहाँ एक एनीमिक डोमेन मॉडल "कोड गंध" भी है, देखें: martinfowler.com/bliki/AnemicDomainModel.html

— Eric Eidt

Answer 1

यहाँ मेरे दो सेंट हैं:

• हमें यकीन नहीं है कि एक डीटीओ के पास कभी भी कम से कम थोड़ा सा व्यवहार नहीं होगा। इसलिए मेरे लिए ऐसी वस्तुएं हैं जिनका भविष्य में व्यवहार हो भी सकता है और नहीं भी।
• इतने सारे एकमात्र कार्यान्वयन कक्षाएं होने से एक संभावित कारण डिजाइन की कमी है , उदाहरण है कि देखने के लिए असफल रहने के लिए ScheduledTask, ScheduledJob, ScheduledEvent, ScheduledInspection, आदि, केवल एक अलग होना चाहिए Schedulableकिसी भी implementor schedulable बनाने इंटरफ़ेस।
• पहले इंटरफेस बनाना एक बहुत अच्छा अभ्यास है, यह आपको इस बात की जानकारी देता है कि आपको क्या चाहिए। कई इंटरफेस शुरू से ही लागू नहीं होते हैं। तब कोई एक कार्यान्वयन लिखता है और उनके पास वह एक होता है। एकमात्र कार्यान्वयन की स्थिति अस्थायी है यदि आपने दूसरे बिंदु में जो उल्लेख किया है उससे बचने के लिए। आप पहले से कैसे जानते हैं कि कुछ इंटरफ़ेस कभी तीसरे कार्यान्वयन का दूसरा नहीं होगा?
• एक अच्छी तरह से विचार किए गए इंटरफ़ेस के लिए हम जो नाम चुनते हैं, उसमें भविष्य में बदलाव न करने की प्रवृत्ति होती है, इसलिए उस इंटरफ़ेस पर निर्भरता प्रभावित नहीं होगी। दूसरी ओर एक ठोस वर्ग का नाम बदल दिया जाता है जब परिवर्तन को लागू करने के तरीके में कुछ महत्वपूर्ण होता है, उदाहरण के लिए एक ठोस वर्ग का नाम TaxSheetबदल सकता है SessionAwareTaxSheetक्योंकि एक महत्वपूर्ण ओवरहाल बनाया गया था, लेकिन इंटरफ़ेस ITaxSheetशायद इतनी आसानी से बदला नहीं जाएगा।

जमीनी स्तर:

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

Comments

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

— रॉबर्ट हार्वे

Answer 2

एक विशेष समस्या जो मैंने डीटीओ के साथ देखी है जो इंटरफेस का उपयोग करती है वह यह है कि यह अनुमति देता है:

public interface ISomeDTO { string SomeProperty { get; set; }}

public class SomeDTO : ISomeDTO
{
    public string SomeProperty { get; set; }
    string ISomeDTO.SomeProperty { get { /* different behavior */ } set { SomeProperty = value; } }
}

मैंने कुछ महत्वपूर्ण व्यवहार को लागू करने के लिए इस पैटर्न को त्वरित, गंदे हैक के रूप में लागू किया है। यह कोड है जो बहुत भ्रमित व्यवहार हो सकता है:

SomeDTO a = GetSomeDTO();
ISomeDTO ia = a;
Assert.IsTrue(a.SomeProperty == ia.SomeProperty); // assert fails!

यह बनाए रखने और भ्रमित करने की कोशिश करने के लिए मुश्किल है या अनपेक्षित करने के लिए। आईएमओ, डीटीओ के साथ व्यवहार को जोड़ना एकल जिम्मेदारी सिद्धांत का उल्लंघन करता है। एक डीटीओ का उद्देश्य एक प्रारूप में डेटा का प्रतिनिधित्व करना है जिसे एक दृढ़ता फ्रेमवर्क द्वारा निरंतर और आबाद किया जा सकता है।

डीटीओ डोमेन मॉडल नहीं हैं। अगर डीटीओ एनीमिक हैं तो हमें चिंतित नहीं होना चाहिए। एनीमिक डोमेन मॉडल के मार्टिन फाउलर की चर्चा को उद्धृत करने के लिए :

यह इस बात पर भी जोर देने के लायक है कि डोमेन ऑब्जेक्ट्स में व्यवहार डालने से दृढ़ता और प्रस्तुति जिम्मेदारियों जैसी चीजों से अलग डोमेन लॉजिक के लिए लेयरिंग का उपयोग करने के ठोस दृष्टिकोण का खंडन नहीं होना चाहिए ।