क्या यह रिटर्न प्रकार के रूप में एक इंटरफ़ेस रखने की सलाह दी जाती है?

Question

मेरे पास समान कार्यों के साथ कक्षाओं का एक सेट है लेकिन विभिन्न तर्क के साथ। हालांकि, प्रत्येक वर्ग समारोह कई वस्तुओं को वापस कर सकता है। रिटर्न प्रकार को इंटरफ़ेस के रूप में सेट करना सुरक्षित है?

प्रत्येक वर्ग (सभी एक ही इंटरफेस का उपयोग कर) यह विभिन्न व्यावसायिक तर्क के साथ कर रहा है।

protected IMessage validateReturnType; <-- This is in an abstract class 

public bool IsValid() <-- This is in an abstract class 
{ 
    return (validateReturnType.GetType() == typeof(Success)); 
} 

public IMessage Validate() 
{ 
    if (name.Length < 5) 
    { 
     validateReturnType = new Error("Name must be 5 characters or greater."); 
    } 
    else 
    { 
     validateReturnType = new Success("Name is valid."); 
    } 

    return validateReturnType; 
} 

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

धन्यवाद।

Answer 1

हालांकि, प्रत्येक वर्ग फ़ंक्शन कई ऑब्जेक्ट्स लौटा सकता है। इंटरफ़ेस के रूप में वापसी प्रकार सेट करने के लिए यह सुरक्षित है?

यह अच्छा अभ्यास और आम है। उदाहरण के लिए COM को बनाया गया तरीका देखें, यह इस पद्धति पर भारी निर्भर करता है।

एक समारोह के वापसी प्रकार का परीक्षण यूनिट के साथ वहाँ किसी भी नुकसान कर रहे हैं

सं

इसके अलावा, यह बुरा डिजाइन के लिए आदेश में चलाने के लिए की आवश्यकता होगी, कार्य करने के लिए माना जाता है उन्हें सफल होने के लिए? इस उदाहरण में, मान्य() को IsValid() से पहले चलाना होगा या अन्यथा IsValid() हमेशा झूठी वापसी करेगा।

ऑब्जेक्ट उन्मुख प्रोग्रामिंग प्रतिमान के साथ काम करने के लिए यह ठीक है, उदाहरण के लिए सॉकेट के साथ काम करना। डेटा भेजने और प्राप्त करने से पहले कनेक्ट विधि होना आम बात है।

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

Answer 2

रिटर्न प्रकार के रूप में इंटरफ़ेस होने के कारण अच्छा है, क्योंकि आपकी विधि अधिक प्रकार के संदेशों के साथ संगत होगी।

Answer 3

साथ ही, क्या इसे सफल होने के लिए कार्यों को चलाने के लिए आवश्यक कार्यों को खराब डिजाइन माना जाता है? इस उदाहरण में, मान्य() को IsValid() से पहले चलाना होगा या अन्यथा IsValid() हमेशा झूठी वापसी करेगा।

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

अपने उदाहरण में, मैं निम्नलिखित डिजाइन लक्ष्यों के साथ एपीआई पुनर्रचना पर विचार करेंगे:

1. अगर है altogther से छुटकारा।
2. प्रमाणीकरण त्रुटियों की एक सूची वापस मान्य करें।
3. मान्य होने के रूप में "सफलता" को फिर से परिभाषित करें() त्रुटियों से रहित एक खाली सूची लौटाएं।

यदि आपके पास बस IsValid होना चाहिए, तो इसे # 3 जांचने के लिए फिर से परिभाषित करें। यदि आप परिणामों को कैश करना चाहते हैं ताकि आपको लगातार IsValid को पुन: गणना नहीं करना पड़े, तो InotifyProperty को लागू करने पर विचार करें PropertyChanged पर कैश किए गए परिणाम को बदलें और अमान्य कर दें।

Answer 4

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

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

मैं बेहतर, IsValid()IMessage को एक सार विधि जोड़ने Success और Error ओवरराइड, और validateReturnType.IsValid() सीधे कॉल चाहते हैं। मेरे लिए और अधिक ओओ लगता है। ओओ और आभासी तरीकों का लक्ष्य लक्ष्य-आधारित केस स्विचिंग से बचने के लिए है जो आप अपने IsValid() में करते हैं। राज्यों के उल्लेख और स्पष्टीकरण के लिए