2012-03-22 10 views
8

एक चर्चा में एक सवाल उठाया गया था कि मेरे पास एक इंटरफ़ेस विधि को कस्टम ऑब्जेक्ट बनाम एक आदिम प्रकार को वापस करना चाहिए या नहीं।क्या एक इंटरफ़ेस विधि कस्टम ऑब्जेक्ट वापस करनी चाहिए?

उदा

public interface IFoo 
{ 
     bool SomeMethod(); 
} 

बनाम

public interface IFoo 
{ 
    MyFooObj SomeMethod(); 
} 

MyFooObj कहां है:

public class MyFooObj 
{ 
    bool SomeProp{get;set;} 
} 

तर्क जा रहा है कि आप आसानी से गुण वस्तु के लिए भविष्य में इंटरफ़ेस अनुबंध बार बदले बिना जोड़ सकते हैं।

मुझे यकीन है कि इस पर मानक दिशानिर्देश क्या हैं?

उत्तर

10

IMHO MyFooObj बदलने को बदलने/IFoo इंटरफ़ेस करने के तरीकों को जोड़ने के समान है - तो कोई मैं यह एक अच्छा विचार है सिर्फ एक और अमूर्त जोड़ने नहीं लगता कि - YAGNI - YAGNI

+0

यही वह विचार है जो मैंने सोचा था। धन्यवाद –

7

मेरे मानक प्रतिक्रिया है याद है।

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

भविष्य का पूर्वानुमान लगाने के लिए बस एक बूलियन लपेटना केवल जटिलता और अतिरिक्त परतों को जोड़ना है जब उन्हें वर्तमान में आवश्यकता नहीं है।

यदि आप अपने कोडबेस में डीडीडी और विशिष्ट मॉडलिंग तकनीकों का उपयोग कर रहे हैं, तो यह आपके डोमेन में सार्थक होने पर ऐसे उपनामों को बूलियंस के लिए समझ सकता है (लेकिन मैं इसे एक बूलियन के मामले में नहीं देख सकता मूल्य)।

2

यह आपकी पसंद के अनुसार कुछ हद तक निर्भर करता है।

  • यह सबसे सरल संभावना
  • कोई भी पढ़ने के लिए है तरीकों कि उपलब्ध नहीं हैं के लिए लग रहा है: मेरी राय है कि अपने नमूना मामले में, मैं उन कारणों के लिए इंटरफ़ेस परिभाषा में सरल bool साथ रहना होगा

आईएमएचओ, एक वस्तु केवल तभी समझ में आती है जब परिणामस्वरूप जटिलता/समूह की एक निश्चित मात्रा की आवश्यकता होती है।

3

मुझे कस्टम ऑब्जेक्ट में आदिम प्रकारों को encapsulating बिंदु नहीं दिखता है।

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

मुझे लगता है कि यह फिर से एक अधिक इंजीनियर "पैटर्न" है।

3

इसके बारे में कोई सामान्य दिशानिर्देश नहीं हैं।

आपके कहे अनुसार, अगर आप वापसी प्रकार है कि आपको लगता है आसपास अर्थ विज्ञान हैदृढ़ विश्वास है बदल सकते हैं या भविष्य में अद्यतन करने की यह बेहतर हो सकता है जटिल प्रकार वापस जाने के लिए आवश्यकता हो सकती है।

लेकिन वास्तविकता यह है कि ज्यादातर परिस्थितियों में चीजों को सरल रखना और आदिम प्रकार को वापस करना बेहतर होता है।

2

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

विस्तार के लिए डिजाइनिंग के साथ यह सही है, यागनी (आपको इसकी आवश्यकता नहीं है)।

एक साइड नोट के रूप में मुझे अपने करियर में इस तरह की चीजों के लिए बताया गया।

2

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

1

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

1

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

+0

अच्छा लिंक। धन्यवाद। –

संबंधित मुद्दे

 संबंधित मुद्दे