2012-05-22 32 views
6

मैं सामान्य रूप से बनाने किया गया है प्रिज्म की तरह EventAggregator द्वारा प्रयोग किया जाता घटनाक्रम:सामान्य कार्यान्वयन के रूप में स्वयं को कक्षा परिभाषित करें। यह क्यों काम करता है?

public class SomeEvent : CompositePresentationEvent<SomeEventArgs> { }

public class SomeEventArgs 
{ 
    public string Name { get; set; } 
} 

लेकिन जब एक सह कार्यकर्ता कोड देख मैंने देखा उन्होंने किया:

public class SomeEvent : CompositePresentationEvent<SomeEvent> 
{ 
    public string Name { get; set; } 
} 

मैं मेरा पहला सवाल यह है कि यह संकलन क्यों करता है? ऐसा लगता है कि यह एक वर्ग को कार्यान्वित कर रहा है जिसे अभी तक परिभाषित नहीं किया गया है। और दूसरा, क्या यह एप्लिकेशन को नकारात्मक रूप से प्रभावित करता है, क्या यह नगण्य है, या बेहतर है?

+0

नोट: यह वास्तव में * कक्षा का कार्यान्वयन नहीं कर रहा है, बस इसका उपयोग कर रहा है। दूसरा नोट: मैं मानता हूं कि यह अजीब लग रहा है (+1)। आधार वर्ग में कार्यान्वयन बनाम उपयोग अलग है, लेकिन अजीब है। – Crisfole

+3

[* उत्सुकता से आवर्ती टेम्पलेट पैटर्न *] में आपका स्वागत है (http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) – dasblinkenlight

उत्तर

8

मुझे लगता है कि मेरा पहला सवाल यह है कि यह संकलन क्यों करता है?

spec में कौन सा नियम आपको विश्वास है कि यह उल्लंघन कर रहा है?

ऐसा लगता है कि यह एक वर्ग को कार्यान्वित कर रहा है जिसे अभी तक परिभाषित नहीं किया गया है।

मुझे लगता है कि आप सटीक बयान के लिए उन शब्दों में से प्रत्येक के अर्थ के रूप में सही है या नहीं आंका जा करने के लिए निर्दिष्ट करने के लिए होगा। संकलक CompositePresentationEvent के बारे में जानता है क्योंकि इसे कहीं और घोषित किया गया है (संभवतः) और यह SomeEvent के बारे में जानता है क्योंकि यह घोषित किया जा रहा है। यह Foo वर्ग Foo के भीतर 0-का एक क्षेत्र होने जैसा है - पूरी तरह से मान्य है।

यह भी उपयोगी यह करने में सक्षम होने के लिए विशेष रूप से तुलना के लिए है। उदाहरण के लिए:

public sealed class Foo : IComparable<Foo> 

कहते वर्ग Foo के किसी भी मामले को पता है कि एक और उदाहरण के साथ ही तुलना करने के लिए, तो यह एक प्रकार-सुरक्षित तरीका में छँटाई के लिए इस्तेमाल किया जा सकता है। Structs के मामले में, यह आपको x.CompareTo(y) पर कॉल करने के लिए मुक्केबाजी को कम करने की अनुमति देता है, जब x को किसी भी बॉक्सिंग की आवश्यकता नहीं होती है जो IComparable<> उचित रूप से लागू करता है।

ध्यान दें कि प्रकार दूर अधिक दिलचस्प और भ्रमित रूप से रिकर्सिव प्राप्त कर सकते हैं। एक "संदेश" और एक "निर्माता" ताकि आप कभी भी एक दूसरे से प्रत्येक निर्माण कर सकते हैं -

public interface IMessage<TMessage, TBuilder> 
    where TMessage : IMessage<TMessage, TBuilder> 
    where TBuilder : IBuilder<TMessage, TBuilder> 

public interface IBuilder<TMessage, TBuilder> 
    where TMessage : IMessage<TMessage, TBuilder> 
    where TBuilder : IBuilder<TMessage, TBuilder> 

यहाँ, उद्देश्य मूल रूप से दो प्रकार के साथ खत्म करने के लिए है: my port of Protocol Buffers से (थोड़ा संशोधित) उदाहरण लें। उदाहरण के लिए:

public class Foo : IMessage<Foo, FooBuilder> 
{ 
    ... 
} 

public class FooBuilder : IBuilder<Foo, FooBuilder> 
{ 
    ... 
} 
+4

इसका नाम भी है। Http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern देखें –

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