जब मुझे कुछ आइटम चाहिए, तो क्या मुझे इसके बजाय "int id" का उपयोग करना चाहिए?

Question

मेरे आवेदन में InstrumentFactory है - एकमात्र जगह जहां मैं Instrument उदाहरण बनाता हूं। प्रत्येक उपकरण उदाहरण में कई फ़ील्ड होते हैं, जैसे कि Ticker=MSFT और GateId=1 और अद्वितीय Id =1 भी।

और अब मुझे एहसास हुआ कि मुझे लगभग Instrument उदाहरण की आवश्यकता नहीं है। 90% मामलों में मुझे बस Id की आवश्यकता है। उदाहरण के लिए अब मेरे पास ऐसी विधि है:

public InstrumentInfo GetInstrumentInfo(Instrument instrument) 
{ 
    return instrumentInfos[instrument.Id]; 
} 

हम जानते हैं कि हमें आवश्यकतानुसार पैरामीटर में अधिक जानकारी नहीं देनी चाहिए। मेरी कोड के

public InstrumentInfo GetInstrumentInfo(int instrumentId) 
{ 
    return instrumentInfos[instrumentId]; 
} 

90% अब instrumentId बजाय Instrument उपयोग करने के लिए पुनर्संशोधित किया जा सकता है: तो यह कोड शायद करने के लिए पुनर्संशोधित किया जाना चाहिए।

क्या मुझे ऐसा करना चाहिए? हर जगह बदलना Instrument से instrumentId इसे एक कठिन आवश्यकता के रूप में बना देगा (प्रत्येक उपकरण में बिल्कुल एक अद्वितीय आईडी होना चाहिए)। लेकिन मेरे पास क्या फायदे होंगे? "कठिन आवश्यकताओं" के बदले में मैं इसके लिए कुछ लाभ प्राप्त करना चाहता हूं ... (गति, पठनीयता?) लेकिन मैं उन्हें नहीं देखता हूं।

Answer 1

ऑब्जेक्ट के बजाए हर जगह आईडी का उपयोग करना गलत दृष्टिकोण है और यह ओओपी की भावना के खिलाफ चला जाता है।

वहाँ वस्तु ही उपयोग करने के लिए दो बड़े फायदे हैं:

1. यह प्रकार सुरक्षित। आप पहले संस्करण में Person जैसे गलती से पास नहीं कर सकते हैं, लेकिन आप गलती से दूसरे स्थान पर person.Id पास कर सकते हैं।
2. यह आपके कोड को संशोधित करने में आसान बनाता है। यदि, भविष्य में, आप तय करते हैं कि आपको long आईडी, या किसी अद्वितीय Instrument की पहचान करने के लिए किसी अन्य तरीके की आवश्यकता है, तो आपको कॉलिंग कोड बदलने की आवश्यकता नहीं होगी।

और तुम शायद बहुत अपने शब्दकोश बदलना चाहिए, यह Dictionary<Instrument, InstrumentInfo> की तरह कुछ, नहीं Dictionary<int, InstrumentInfo> होना चाहिए, जैसे आप अब है। इस तरह, आपको वहां दोनों फायदे भी मिलते हैं। इसे काम करने के लिए, आपको Instrument में समानता लागू करने की आवश्यकता है, जिसका अर्थ है Equals() और GetHashCode() और उचित रूप से IEquatable<Instrument> को कार्यान्वित करना।

public InstrumentInfo GetInstrumentInfo(Instrument instrument) 
{ 
    // call GetInstrumentInfo passing the id of the object 
    return GetInstrumentInfo[instrument.Id]; 
} 

public InstrumentInfo GetInstrumentInfo(int instrumentId) 
{ 
    return instrumentInfos[instrumentId]; 
} 

यह आपको पर्याप्त लचीलापन देने के लिए इतना है कि जब तुम कि GetInstrumentInfo कॉल करने के लिए इसे बदलने के लिए किसी भी जगह के माध्यम से जाना होगा:

Answer 2

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

Answer 3

आप प्रत्येक समारोह, एक है कि एक उपकरण ले जाता है और एक है कि एक आईडी लेता ओवरलोड सकता है आईडी पास करें, वर्तमान कोड अभी भी काम करेगा।

चाहे आपको "चाहिए" पूरी तरह से आपके ऊपर है या नहीं। कोड में बदलाव करने के लाभ के मुकाबले आपको इसे बदलने के लिए कितना समय लगेगा।

Answer 4

GetInstrumentInfo(int instrumentId); 

इसका अर्थ शायद यह ग्राहक कोड एक है नहीं है:

GetInstrumentInfo(instrument.Id); 

अपने विधि चिंता का उन है कि जैसे छोटे विवरण के बारे में मत। उन्हें बस पूरी वस्तु को पारित करने दें और अपनी विधि को काम करने दें।

कोई भी प्रमुख प्रदर्शन नुकसान नहीं दिख रहा है। चाहे आप वास्तविक वस्तु के लिए एक इंट या संदर्भ पास करते हैं।

कहें कि आप GetInstrumentInfo को थोड़ा और विकसित करना चाहते हैं, केवल एक इंट की तुलना में पूरे ऑब्जेक्ट तक पहुंच बनाना आसान है।

Answer 5

पहली बात यह है कि आप अपने आप से पूछना होगा यह है:

"अगर मैं आईडी == 53 के साथ दो उपकरणों है, तो इसका मतलब यह है कि वे निश्चित रूप से एक ही उपकरण हैं, कोई बात नहीं क्या या कोई है? सार्थक मामला जहां वे अलग हो सकते हैं? "

जवाब मानते हुए "वे दोनों एक जैसे हैं। यदि कोई अन्य संपत्ति अलग है, तो यह एक बग है या क्योंकि एक ऐसी वस्तु किसी अन्य के बाद प्राप्त की गई थी, और यह जल्द ही पर्याप्त हो जाएगा (जब भी प्रसंस्करण का धागा होता है पुराने उपकरण का उपयोग करके, इसका उपयोग बंद कर देता है) "फिर:

सबसे पहले, आंतरिक रूप से, जो कुछ भी आपको आसान लगता है उसका उपयोग करें। आपको लगता है कि यह हर समय int द्वारा जाना होगा, हालांकि आपको कुछ प्रकार की सुरक्षा मिलती है कि Instrument विधि को पास कर दिया गया है। यह विशेष रूप से सच है यदि सभी Instrument निर्माण internal या private कारखाने के तरीकों के माध्यम से उपयोग किए गए कन्स्ट्रक्टर से होता है, और कोड के उपयोगकर्ता के लिए एक कोड के साथ Instrument बनाने के लिए कोई तरीका नहीं है जो आपके सिस्टम में कुछ भी मेल नहीं खाता है।

जैसे समानता को परिभाषित करें:

public class Instrument : IEquatable<Instrument> 
{ 
    /* all the useful stuff you already have */ 
    public bool Equals(Instrument other) 
    { 
    return other != null && Id == other.Id; 
    } 
    public override bool Equals(object other) 
    { 
    return Equals(other as Instrument); 
    } 
    public override int GetHashCode() 
    { 
    return Id; 
    } 
} 

अब, खासकर जब हम विचार है कि इसके बाद के संस्करण समय के सबसे inlined होने की संभावना है, वहाँ काफी है कि क्या हम आईडी का उपयोग करने के लिए या के रूप में कोई अंतर नहीं है कार्यान्वयन समानता के मामले में वस्तु, और इसलिए उन्हें एक कुंजी के रूप में उपयोग करने के मामले में भी।

public InstrumentInfo GetInstrumentInfo(Instrument instrument) 
{ 
    return instrumentInfos[instrument]; 
} 

या::

public InstrumentInfo GetInstrumentInfo(Instrument instrument) 
{ 
    return instrumentInfos[instrument.Id]; 
} 

या:

public InstrumentInfo GetInstrumentInfo(Instrument instrument) 
{ 
    return GetInstrumentInfo(instrument.Id); 
} 
private InstrumentInfo GetInstrumentInfo(int instrumentID) 
{ 
    return instrumentInfos[instrumentID] 
} 

प्रदर्शन प्रभाव होगा

अब, आप निम्नलिखित साधन में से किसी में अपने सार्वजनिक विधियों में से सभी को परिभाषित कर सकते वही हो, जो भी आप के लिए जाते हैं। उपयोगकर्ताओं को प्रस्तुत कोड टाइप-सुरक्षित होगा और गारंटी होगी कि वे फर्जी मानों में पास नहीं होते हैं। उठाया गया कार्यान्वयन केवल वही हो सकता है जो आपको अन्य कारणों से अधिक सुविधाजनक लगता है।

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

आप अपने उपयोगकर्ताओं को एक कुंजी के रूप में अपनी वस्तु का उपयोग करने और त्वरित समानता तुलना करने की क्षमता भी देते हैं, अगर यह ऐसा करने के लिए उपयुक्त हो।