क्या आपके पास एक इंटरफ़ेस कक्षा पर निर्भर हो सकता है?

Question

मैं सोलिड सिद्धांतों का अध्ययन कर रहा हूं और इंटरफेस के संबंध में निर्भरता प्रबंधन के बारे में एक प्रश्न पूछता हूं।

किताब मैं पढ़ रहा हूँ से एक उदाहरण (अनुकूली कोड के माध्यम से सी # गैरी मैकलीन हॉल) एक TradeProcessor वर्ग कि व्यापार डेटा मिलेगा, यह प्रक्रिया से पता चलता है, और डेटाबेस में संग्रहीत। व्यापार डेटा को TradeRecord नामक कक्षा द्वारा मॉडलिंग किया जाता है। TradeParser कक्षा TradeRecord उदाहरण (ओं) में प्राप्त व्यापार डेटा को परिवर्तित करने में संभाल लेगी। TradeProcessor कक्षा केवल ITradeParser इंटरफ़ेस का संदर्भ देती है ताकि यह TradeParser कार्यान्वयन पर निर्भर न हो।

लेखक Parse विधि (ITradeParser इंटरफ़ेस में) IEnumerable<TradeRecord> संग्रह को संसाधित करता है जो संसाधित व्यापार डेटा रखता है। क्या इसका मतलब यह नहीं है कि ITradeParser अब TradeRecord कक्षा पर निर्भर है?

क्या लेखक ने ITradeRecord इंटरफ़ेस बनाने की तरह कुछ नहीं किया है और ParseITradeRecord उदाहरणों का संग्रह लौटाता है? या क्या मुझे कुछ महत्वपूर्ण याद आ रहा है?

कोड यह (TradeRecord के कार्यान्वयन अप्रासंगिक है तो यह छोड़ दिया जाता है):

TradeProcessor.cs

public class TradeProcessor 
{ 
    private readonly ITradeParser tradeParser; 

    public TradeProcessor(ITradeParser tradeParser) 
    { 
     this.tradeParser = tradeParser; 
    } 

    public void ProcessTrades() 
    { 
     IEnumerable<string> tradeData = "Simulated trade data..." 
     var trades = tradeParser.Parse(tradeData); 

     // Do something with the parsed data... 
    } 
} 

ITradeParser.cs

public interface ITradeParser 
{ 
    IEnumerable<TradeRecord> Parse(IEnumerable<string> tradeData); 
} 

Answer 1

यह एक अच्छा सवाल है कि दुविधा में चला जाता है शुद्धता और व्यावहारिकता के बीच।

हाँ, शुद्ध प्रिंसिपल द्वारा, आप कह सकते हैं कि ITradeParser.ParseITraceRecord इंटरफेस का संग्रह वापस करना चाहिए। आखिरकार, एक विशिष्ट कार्यान्वयन के लिए खुद को क्यों बांधें?

हालांकि, आप इसे और ले सकते हैं। क्या आपको IEnumerable<string> स्वीकार करना चाहिए? या आपके पास ITextContainer का कुछ प्रकार होना चाहिए? I32bitNumericint के बजाय? यह रेडक्टियो विज्ञापन absurdum है, लेकिन यह दिखाता है कि हम हमेशा, किसी बिंदु पर, उस बिंदु तक पहुंचते हैं जहां हम पर कुछ पर काम कर रहे हैं, एक ठोस वस्तु (संख्या, स्ट्रिंग, ट्रेस रिकॉर्ड, जो भी हो), न कि अमूर्त।

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

Answer 2

लेखक के पास पार्स विधि (आईट्रेडपेसर इंटरफ़ेस में) एक आईनेमरेबल संग्रह लौटाती है जिसमें संसाधित व्यापार डेटा होता है।

क्या इसका मतलब यह नहीं है कि ITradeParser अब ट्रेडरॉर्ड क्लास पर निर्भर है?

हाँ, ITradeParser अब कसकर TradeRecord के साथ मिलकर कर रहा है। इस प्रश्न के अधिक अकादमिक दृष्टिकोण को देखते हुए, मैं देख सकता हूं कि आप कहां से आ रहे हैं। लेकिन TradeRecord क्या है? परिभाषा के अनुसार एक रिकॉर्ड आम तौर पर डेटा का एक सरल, गैर-बुद्धिमान टुकड़ा होता है (कभी-कभी पीओसीओ, डीटीओ या मॉडल कहा जाता है)।

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

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