इंटरफेस का डिफ़ॉल्ट कार्यान्वयन उपयोगी क्यों है?

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

पिछड़े संगतता के साथ इंटरफेस का विस्तार

प्रलेखन कहता है:

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

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

एक उदाहरण पर विचार करें:

interface ICar { string Make { get; } } public class Avalon : ICar { public string Make => "Toyota"; } 

यदि मैं इस इंटरफ़ेस में एक नया GetTopSpeed ​​() विधि जोड़ना चाहता हूं, तो मुझे एवलॉन में इसके कार्यान्वयन को जोड़ना होगा:

 interface ICar { string Make { get; } int GetTopSpeed(); } public class Avalon : ICar { public string Make => "Toyota"; public int GetTopSpeed() => 130; } 

हालांकि, अगर मैं ICar में GetTopSpeed ​​() पद्धति का डिफ़ॉल्ट कार्यान्वयन बनाता हूं , तो मुझे इसे प्रत्येक विरासत वाले वर्ग में नहीं जोड़ना होगा।

 interface ICar { string Make { get; } public int GetTopSpeed() => 150; } public class Avalon : ICar { public string Make => "Toyota"; } 

यदि आवश्यक हो, तो मैं अभी भी उन वर्गों में कार्यान्वयन को अधिभारित कर सकता हूं जिनके लिए डिफ़ॉल्ट उपयुक्त नहीं है:

 interface ICar { string Make { get; } public int GetTopSpeed() => 150; } public class Avalon : ICar { public string Make => "Toyota"; public int GetTopSpeed() => 130; } 

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

मिश्रण और लक्षण (या ऐसा कुछ)

मिश्रण और लक्षण की समान भाषा की अवधारणा कई विरासत की आवश्यकता के बिना रचना के माध्यम से किसी वस्तु के व्यवहार का विस्तार करने के तरीकों का वर्णन करती है।

मिक्सी के बारे में विकिपीडिया निम्नलिखित रिपोर्ट करता है:

मिक्सिन को डिफ़ॉल्ट तरीकों के साथ एक इंटरफ़ेस के रूप में भी माना जा सकता है

क्या वह आवाज़ ऐसी है?

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

निम्नलिखित कोड पर विचार करें, जो ऑब्जेक्ट "आंदोलन" में कार्यक्षमता जोड़ता है और इसके स्थान को ट्रैक करता है (उदाहरण के लिए, गेम देव में):

 public interface IMovable { public (int, int) Location { get; set; } public int Angle { get; set; } public int Speed { get; set; } // ,         public void Move() => Location = ...; } public class Car : IMovable { public string Make => "Toyota"; } 

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

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

इस C # इंटरफेस में मिक्सिन्स की अवधारणा के साथ अंतर हैं (जहाँ तक मैं उन्हें समझता हूँ, मिक्सिन्स वैचारिक रूप से स्टोर कर सकते हैं), लेकिन हम अभी भी मूल लक्ष्य प्राप्त कर सकते हैं:

 public interface IMovable { public (int, int) Location { get; set; } public int Angle { get; set; } public int Speed { get; set; } // A method that changes location // using angle and speed public void Move() => Location = ...; } public class Car : IMovable { public string Make => "Toyota"; // ,         public (int, int) Location { get; set; } public int Angle { get; set; } public int Speed { get; set; } } 

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

अधिक पूर्ण और व्यावहारिक उदाहरण के रूप में, लॉगिंग के लिए एक मिश्रण पर विचार करें:

 public interface ILogger { public void LogInfo(string message) => LoggerFactory .GetLogger(this.GetType().Name) .LogInfo(message); } public static class LoggerFactory { public static ILogger GetLogger(string name) => new ConsoleLogger(name); } public class ConsoleLogger : ILogger { private readonly string _name; public ConsoleLogger(string name) { _name = name ?? throw new ArgumentNullException(nameof(name)); } public void LogInfo(string message) => Console.WriteLine($"[INFO] {_name}: {message}"); } 

अब किसी भी वर्ग में मैं ILogger इंटरफ़ेस से वारिस कर सकता हूँ:

 public class Foo : ILogger { public void DoSomething() { ((ILogger)this).LogInfo("Woot!"); } } 

और ऐसा कोड:

 Foo foo = new Foo(); foo.DoSomething(); 

आउटपुट:

 [INFO] Foo: Woot! 

विस्तार के तरीकों की जगह

सबसे उपयोगी एप्लिकेशन जो मैंने पाया है वह बड़ी संख्या में विस्तार विधियों की जगह ले रहा है। आइए एक सरल लॉगिंग उदाहरण पर वापस आते हैं:

 public interface ILogger { void Log(string level, string message); } 

डिफ़ॉल्ट कार्यान्वयन से पहले इंटरफेस में दिखाई दिया, एक नियम के रूप में, मैं इस इंटरफ़ेस के लिए कई विस्तार विधियां लिखूंगा, ताकि विरासत में मिली कक्षा में केवल एक विधि को लागू किया जाए, जिसके परिणामस्वरूप उपयोगकर्ताओं को कई एक्सटेंशन तक पहुंच प्राप्त होगी:

 public static class ILoggerExtensions { public static void LogInfo(this ILogger logger, string message) => logger.Log("INFO", message); public static void LogInfo(this ILogger logger, int id, string message) => logger.Log("INFO", $"[{id}] message"); public static void LogError(this ILogger logger, string message) => logger.Log("ERROR", message); public static void LogError(this ILogger logger, int id, string message) => logger.Log("ERROR", $"[{id}] {message}"); public static void LogError(this ILogger logger, Exception ex) => logger.Log("ERROR", ex.Message); public static void LogError(this ILogger logger, int id, Exception ex) => logger.Log("ERROR", $"[{id}] {ex.Message}"); } 

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

 this ILogger logger logger.Log 

अब मैं डिफ़ॉल्ट कार्यान्वयन के साथ एक्सटेंशन बदल सकता हूं:

 public interface ILogger { void Log(string level, string message); public void LogInfo(string message) => Log("INFO", message); public void LogInfo(int id, string message) => Log("INFO", $"[{id}] message"); public void LogError(string message) => Log("ERROR", message); public void LogError(int id, string message) => Log("ERROR", $"[{id}] {message}"); public void LogError(Exception ex) => Log("ERROR", ex.Message); public void LogError(int id, Exception ex) => Log("ERROR", $"[{id}] {ex.Message}"); } 

मुझे यह कार्यान्वयन क्लीनर और पढ़ने में आसान (और समर्थन) लगता है।

डिफ़ॉल्ट कार्यान्वयन का उपयोग करने के विस्तार विधियों पर कई और फायदे हैं:

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

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

इस समस्या को हल करने के लिए, मैंने उन इंटरफ़ेसों को घोषित करना शुरू कर दिया है जिनके सदस्य डिफ़ॉल्ट कार्यान्वयन के रूप में आंशिक (शायद बहुत ही सरल को छोड़कर) हैं। फिर मैंने फॉर्म के नामकरण सम्मेलन "ILogger.LogInfoDefaults.cs" , "ILogger.LogErrorDefaults.cs" और इतने पर एक अलग फ़ाइल में डिफ़ॉल्ट कार्यान्वयन रखा। यदि कुछ डिफ़ॉल्ट कार्यान्वयन हैं और अतिरिक्त ग्रुपिंग की कोई आवश्यकता नहीं है, तो मैं "ILogger.Defaults.cs" फ़ाइल का नाम देता हूं।

यह गैर-कार्यान्वयन योग्य अनुबंध से डिफ़ॉल्ट कार्यान्वयन वाले सदस्यों को अलग करता है, जिन्हें लागू करने के लिए विरासत में मिली कक्षाएं आवश्यक हैं। इसके अलावा, यह आपको बहुत लंबी फ़ाइलों को काटने की अनुमति देता है। किसी भी प्रारूप की परियोजनाओं में ASP.NET -स्टाइल संलग्न फाइलों को रेंडर करने के साथ एक मुश्किल ट्रिक भी है। ऐसा करने के लिए, प्रोजेक्ट फ़ाइल या निर्देशिका में जोड़ें। Bild.props :

 <ItemGroup> <ProjectCapability Include="DynamicDependentFile"/> <ProjectCapability Include="DynamicFileNesting"/> </ItemGroup> 

अब आप समाधान एक्सप्लोरर में "फाइल नेस्टिंग" का चयन कर सकते हैं और आपकी सभी .Defaults.cs फाइलें "मुख्य" इंटरफेस फाइल के वंशज के रूप में दिखाई देंगी।

निष्कर्ष में, अभी भी कई स्थितियाँ हैं जिनमें विस्तार विधियों को प्राथमिकता दी जाती है:

• यदि आप आमतौर पर कक्षाओं के साथ काम करते हैं, तो इंटरफेस नहीं (क्योंकि आपको डिफ़ॉल्ट कार्यान्वयन तक पहुंचने के लिए ऑब्जेक्ट्स को इंटरफेस में डालना है)
• यदि आप अक्सर टेम्पलेट्स के साथ एक्सटेंशन का उपयोग करते हैं: सार्वजनिक स्थैतिक T SomeExt < T > (यह T foo) (जैसे कि फ्लू एपीआई में )