शैली में एक अंतर: IDictionary बनाम शब्दकोश

Question

मेरे पास एक दोस्त है जो जावा में उम्र बढ़ने के बाद .NET विकास में शामिल हो रहा है और उसके कुछ कोड देखने के बाद मुझे लगता है कि वह अक्सर निम्नलिखित कर रहा है:

IDictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>(); 

वह कक्षा के बजाए इंटरफ़ेस के रूप में शब्दकोश घोषित कर रहा है। आमतौर पर मैं निम्नलिखित करना होगा:

Dictionary<string, MyClass> dictionary = new Dictionary<string, MyClass>(); 

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

मेरा प्रश्न है: क्या चीजों को करने के अपने तरीके के लिए कोई योग्यता है? जावा में यह एक आम प्रथा है?

Answer 1

यदि IDictionary शब्दकोश से अधिक "अधिक सामान्य" प्रकार है तो यह घोषित करने वाले चर में अधिक सामान्य प्रकार का उपयोग करने के लिए समझ में आता है। इस तरह आपको चर को आवंटित कार्यान्वयन वर्ग के बारे में ज्यादा परवाह नहीं है और आप भविष्य में आसानी से निम्नलिखित कोड को बदलने के बिना आसानी से प्रकार बदल सकते हैं। उदाहरण के लिए, जावा में यह अक्सर बेहतर की तुलना में यह

LinkedList<Integer> intList=new LinkedList<Integer>(); 

इस तरह मुझे यकीन है कि सभी निम्नलिखित कोड एक सूची और नहीं एक LinkedList के रूप में सूची में व्यवहार करता हूँ करना है माना जाता है

List<Integer> intList=new LinkedList<Integer>(); 

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

Answer 2

यह अभ्यास जावा तक ही सीमित नहीं है।

यह अक्सर .NET में उपयोग किया जाता है जब आप उस वर्ग से ऑब्जेक्ट का उदाहरण जोड़ना चाहते हैं जिसका आप उपयोग कर रहे हैं। यदि आप कक्षा के बजाय इंटरफ़ेस का उपयोग करते हैं, तो आप अपने शेष कोड को तोड़ने के बिना जब भी आवश्यक हो बैकिंग प्रकार बदल सकते हैं।

आप इस अभ्यास को फैक्टरी पैटर्न का उपयोग करके आईओसी कंटेनर और इंस्टेंसियस से निपटने के साथ भारी रूप से उपयोग करेंगे।

Answer 3

जहां तक ​​मैंने देखा है कि जावा डेवलपर्स .NET डेवलपर्स की तुलना में अक्सर अबास्ट्रक्शन (और डिज़ाइन पैटर्न) का उपयोग करते हैं। यह इसका एक और उदाहरण है: कंक्रीट क्लास की घोषणा क्यों करें जब वह अनिवार्य रूप से केवल इंटरफ़ेस सदस्यों के साथ काम करेगा?

Answer 4

मुझे पता चला है कि स्थानीय चर के लिए यह आमतौर पर कोई फर्क नहीं पड़ता कि आप इंटरफ़ेस या कंक्रीट क्लास का उपयोग करते हैं या नहीं।

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

हालांकि, विधियों, वर्ग के सदस्यों या इंटरफेस घोषित करते समय, मुझे लगता है कि यह सार्वजनिक एपीआई को एक विशिष्ट वर्ग प्रकार के साथ जोड़ने के बजाय इंटरफ़ेस प्रकार के सामने का उपयोग करने के लिए आपको थोड़ा सिरदर्द बचाएगा।

Answer 5

इंटरफेस का उपयोग करने का अर्थ है कि निम्नलिखित कोड में "शब्दकोश" IDictionary का कोई कार्यान्वयन हो सकता है।

Dictionary1 dictionary = new Dictionary1(); 
dictionary.operation1(); // if operation1 is implemented only in Dictionary1() this will fail for every other implementation 

यह सबसे अच्छा देखा है जब आप वस्तु के निर्माण को छिपाने:

IDictionary dictionary = DictionaryFactory.getDictionary(...); 

Answer 6

आपके मित्र बहुत उपयोगी सिद्धांत निम्नलिखित है:

"सार खुद के कार्यान्वयन विवरण से"

Answer 7

वर्णित स्थिति में लगभग हर जावा डेवलपर चर को घोषित करने के लिए इंटरफ़ेस का उपयोग करेगा। जिस तरह से जावा संग्रह इस्तेमाल कर रहे हैं शायद सबसे अच्छा उदाहरण में से एक है:

Map map = new HashMap(); 
List list = new ArrayList(); 

यह सिर्फ स्थितियों का एक बहुत में ढीला संयोजन सिद्ध लगता।

Answer 8

जावा संग्रह में कई कार्यान्वयन शामिल हैं। इसलिए, यह मुझे भविष्य में फिर

List<String> myList = new ArrayList<String>(); 

का उपयोग करने के लिए जब मुझे पता है मैं "MyList" की जरूरत है बस के लिए सुरक्षित धागा होने की

List<String> myList = new Vector<String>(); 

और परिवर्तन करने के लिए इस एक लाइन को बदलने के लिए बहुत आसान है कोड की कोई अन्य पंक्ति नहीं। इसमें गेटर्स/सेटर्स भी शामिल हैं। यदि आप उदाहरण के लिए मानचित्र के कार्यान्वयन की संख्या देखते हैं, तो आप कल्पना कर सकते हैं कि यह अच्छा अभ्यास क्यों हो सकता है। अन्य भाषाओं में, जहां कुछ के लिए केवल कुछ कार्यान्वयन हैं (क्षमा करें, एक बड़ा .NET लड़का नहीं) लेकिन उद्देश्य-सी में वास्तव में केवल NSDictionary और NSMutableDictionary है। तो, यह ज्यादा समझ में नहीं आता है।

संपादित करें:

मेरी प्रमुख बिंदु (बस गेटर/setters के साथ यह उल्लेख) में से एक पर हिट करने में विफल।

ऊपर आप की अनुमति देता है:

public void setMyList(List<String> myList) { 
    this.myList = myList; 
} 

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

Answer 9

मुझे जावा डेवलपर के साथ एक ही स्थिति का सामना करना पड़ा है। वह संग्रह और वस्तुओं को उनके इंटरफेस में उसी तरह से तत्काल करता है। उदाहरण के लिए,

IAccount account = new Account(); 

गुण हमेशा/इंटरफेस के रूप में तैयार हो जाओ रहे हैं। इससे क्रमशः here

Answer 10

अधिकतर, आप बाहरी कोड के संपर्क में आने पर इंटरफ़ेस प्रकार (IDictionary) का उपयोग करते हैं, चाहे वह असेंबली के बाहर हो या कक्षा के बाहर हो। आम तौर पर, अधिकांश डेवलपर्स इंटरफ़ेस प्रकार का उपयोग करते हुए एक encapsulated संपत्ति का पर्दाफाश करते हुए आंतरिक रूप से एक वर्ग परिभाषा के लिए ठोस प्रकार का उपयोग करते हैं। इस तरह, वे ठोस प्रकार की क्षमताओं का लाभ उठा सकते हैं, लेकिन यदि वे ठोस प्रकार को बदलते हैं, तो घोषित कक्षा के इंटरफ़ेस को बदलने की आवश्यकता नहीं है।

 
public class Widget 
{ 
    private Dictionary<string, string> map = new Dictionary<string, string>(); 
    public IDictionary<string, string> Map 
    { 
     get { return map; } 
    } 
} 

बाद में बन सकता है:

 

class SpecialMap<TKey, TValue> : IDictionary<TKey, TValue> { ... } 

public class Widget 
{ 
    private SpecialMap<string, string> map = new SpecialMap<string, string>(); 
    public IDictionary<string, string> Map 
    { 
     get { return map; } 
    } 
} 

विजेट के इंटरफ़ेस बदल रहा है और पहले से ही इसे प्रयोग अन्य कोड को बदलने के लिए बिना।

Answer 11

आपको हमेशा ठोस वर्ग की बजाय इंटरफ़ेस में प्रोग्राम करने का प्रयास करना चाहिए।

जावा या किसी अन्य ऑब्जेक्ट उन्मुख प्रोग्रामिंग भाषा में।

.NET दुनिया में I का उपयोग करना आम है यह इंगित करने के लिए कि यह एक इंटरफेस है जिसका आप उपयोग कर रहे हैं। मुझे लगता है कि यह अधिक आम है क्योंकि सी # में उनके पास कक्षा बनाम इंटरफ़ेस विरासत को संदर्भित करने के लिए implements और extends नहीं है।

मुझे लगता है कि मट्ठा

class MyClass:ISome,Other,IMore 
{ 
} 

टाइप करेंगे और आप बता सकते हैं ISome एक IMore इंटरफेस रहे हैं, जबकि Other एक वर्ग है

जावा में ऐसी बात के लिए कोई जरूरत नहीं है

class MyClass extends Other implements Some, More { 
} 

अवधारणा अभी भी लागू होती है, आपको इंटरफ़ेस को कोड करने का प्रयास करना चाहिए।

Answer 12

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

Answer 13

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