2010-04-05 10 views
8

मेरे पास मेरे वर्तमान प्रोजेक्ट में कुछ कक्षाएं हैं जहां ईमेल/वेबसाइट पते की सत्यापन आवश्यक है। ऐसा करने के तरीके सभी समान हैं।एक ही तरीके से कई कक्षाएं - सर्वोत्तम पैटर्न

मुझे आश्चर्य हुआ कि इसे लागू करने का सबसे अच्छा तरीका क्या है, इसलिए मुझे इन विधियों की प्रतिलिपि प्रतिलिपि बनाने की आवश्यकता नहीं है?

कक्षाएं स्वयं आवश्यक रूप से संबंधित नहीं हैं, उनके पास केवल उन सत्यापन विधियों को आम है।

+0

कक्षाएं और क्या करती हैं? स्पष्टता के लिए, एक वर्ग के पास एक ही उद्देश्य होना चाहिए। निराश WithFormsDes का समाधान इस सिद्धांत का पालन करता है। – outis

उत्तर

15

इंटरफ़ेस जोड़ने और एक्सटेंशन विधि का उपयोग करने के बारे में कैसे?

public interface IFoo { } 

public class A : IFoo {} 
public class B : IFoo {} 
public class C : IFoo {} 

public static class FooUtils { 
    public static void Bar(this IFoo foo) { /* impl */ } 
} 

इस तरह:

  • कोई अनावश्यक विरासत
  • कोई दोहराव
+0

कक्षा ए के अंदर, क्या अब मैं विधि बार तक पहुंच सकता हूं? –

+0

हाँ var aClass = new A(); aClass.Bar(); –

+2

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

7

हो सकता है कि आप सभी सत्यापन कोड को वैलिडेटर क्लास में रखना चाहें, फिर उस कक्षा का उपयोग कहीं भी सत्यापन की आवश्यकता है। सत्यापन के लिए एक विधि, Validate(object Something) हो सकता है। मुझे लगता है कि इसे "रचना" कहा जाता है (जहां तक ​​डिजाइन पैटर्न जाते हैं)।

बाद में, आपके पास वैलिडेटर के उप-वर्ग हो सकते हैं जो शायद अधिक विशिष्ट हो या विभिन्न प्रकार के सत्यापन हो।

आप सभी वर्गों को सत्यापन श्रेणी की आवश्यकता होती है जो बेस क्लास या अमूर्त वर्ग का विस्तार करती है जिसमें इसमें 9 0% सत्यापन है।

+1

सर्वोत्तम शब्द "एसोसिएशन" है, जो एक पैटर्न के बजाय एक वर्ग संबंध (http://en.wikipedia.org/wiki/Class_diagram#Instance_Level_Relationships) है। पैटर्न के लिए, रणनीति पैटर्न (http://en.wikipedia.org/wiki/Strategy_pattern) शामिल हो सकता है। – outis

0

मान्यता तर्क वर्गों और इंटरफेस बनाने के लिए, और उन्हें अपने कोड में इंजेक्शन की जा रही है ... तो अलग प्रमाणीकरण से तर्क ताकि इसे पुन: उपयोग किया जा सके ...

1

एक उपयोगिता बनाएं वाई कक्षा और उपयुक्त वर्ग/इंटरफेस के लिए विस्तार विधियों के रूप में इन तरीकों को परिभाषित करें।

2

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

public static class Utilities{ 
    public static bool validEmail(string email) 
    { 
     //Your code here 
    } 
} 
5

लग रहा है।
EmailString के बजाय अपनी कक्षाओं में गुण/पैरामीटर/वापसी मान के रूप में उपयोग करें।
ईमेल पते के रूप में तारों को सत्यापित करने के लिए EmailValidator बनाएं।
EmailFactory बनाएं जो वैध ईमेल पता और शून्य के बाद ईमेल लौटाता है।

(वेबसाइट के लिए भी ऐसा करें)।

+1

सादगी के लिए +1। – stmax

+1

+1 उपयोगिता वर्ग यहां जाने के तरीके की तरह दिखता है। स्थिरता विधियों के साथ एक उपयोगिता वर्ग है जो ईमेल मान्य करता है, वेब पते और अन्य प्रकार की मान्यताओं की जांच करता है। और जब भी आपको उन तरीकों की आवश्यकता हो, तो इस उपयोगिता स्थिर विधियों को कॉल करें। –

0

एक अलग वर्ग के रूप में Email बनाएं

1

आपको वास्तव में पहलू उन्मुख प्रोग्रामिंग पद्धति (एओपी) पर एक अच्छा नज़र डालने की आवश्यकता है। एंटरप्राइज़ लाइब्रेरी 4.1 में एक एओपी कार्यान्वयन है जिसे यूनिटी इंटरसेप्शन कहा जाता है।

http://msdn.microsoft.com/en-us/library/dd140045.aspx

इस ढांचे आप ईमेल सत्यापन के लिए एक एकल हैंडलर वर्ग कोड करने के लिए अनुमति देता है। तो यह क्या है कि सत्यापन कोड एक हैंडलर वर्ग में जाता है, और अब वर्ग (एसएस) का हिस्सा नहीं है। अगली चीज़ जो आप करते हैं वह कक्षाओं को अवरोध के लिए चिह्नित करती है।

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

0

मैं आपको एक IValidator इंटरफ़ेस बनाने की सलाह दूंगा, फिर विभिन्न परिदृश्यों को संभालने वाले कई अलग-अलग सत्यापनकर्ता बनाएं। यहाँ एक उदाहरण है:

public interface IValidator { 
    bool CanValidateType(string type); 
    bool Validate(string input); 
} 

CanValidateType() विधि में थोड़ा और अधिक जटिल हो सकता है, लेकिन मुझे आशा है कि आप विचार मिलता है। यह मूल रूप से पहचानता है कि क्या वैधकर्ता आपूर्ति किए गए इनपुट को संभाल सकता है या नहीं। यहां पर कुछ कार्यान्वयन हैं:

public class UrlValidator : IValidator { 
    bool CanValidateType(string type) { 
     return type.ToLower() == "url"; 
    } 

    bool Validate(string input) { 
     /* Validate Url */ 
    } 
} 

public class EmailValidator : IValidator { 
    bool CanValidateType(string type) { 
     return type.ToLower() == "email"; 
    } 

    bool Validate(string input) { 
     /* Validate Email */ 
    } 
} 

अब आप अपने वर्ग में निर्भरता सुई निर्माता इंजेक्शन का उपयोग करेगा:

public class SomeSimpleClass { 
    private IValidator validator; 

    public SomeComplexClass(IValidator validator) { 
     this.validator = validator; 
    } 

    public void DoSomething(string url) { 
     if (validator.CanValidateType("url") && 
      validator.Validate(url)) 
      /* Do something */ 
    } 
} 

CanValidateType काम में आता है जब आप एक वर्ग कई प्रमाणकों उपयोग कर सकते हैं कि की है। इस परिदृश्य में आप कन्स्ट्रक्टर को एक सूची या सत्यापनकर्ताओं की एक सरणी में पास करते हैं।

public class SomeComplexClass { 
    private List<IValidator> validators; 

    public SomeComplexClass (List<IValidator> validators) { 
     this.validators = validators; 
    } 

    public bool ValidateUrl(string url) { 
     foreach (IValidator validator in this.validators) 
      if (validator.CanValidateType("url")) 
       return validator.Validate(url); 
     return false; 
    } 


    public bool ValidateEmail(string email) { 
     foreach (IValidator validator in this.validators) 
      if (validator.CanValidateType("email")) 
       return validator.Validate(email); 
     return false; 
    } 
} 

आपको किसी भी तरह से अपने वर्गों में वैधकर्ता के आवश्यक उदाहरण में पास करना होगा। यह अक्सर आईओसी कंटेनर (कैसल विंडसर की तरह) के साथ किया जाता है या इसे स्वयं करता है।

IValidator emailValidator = new EmailValidator(); 
IValidator urlValidator = new UrlValidator(); 
SomeSimpleClass simple = new SomeSimpleClass(urlValidator); 
SomeComplexClass complex = new SomeComplexClass(new List<IValidator> { emailValidator, urlValidator }); 

उपरोक्त कोड स्वयं को करने के लिए कठिन हो जाता है, यही कारण है कि आईओसी कंटेनर इतने आसान हैं।

SomeSimpleClass simple = container.Resolve<SomeSimpleClass>(); 
SomeComplexClass complex = container.Resolve<SomeComplexClass(); 

सभी इंटरफेस के मानचित्रण अपने app.config या web.config में किया जाता है: एक आईओसी कंटेनर के साथ आप निम्नलिखित की तरह कुछ कर सकते हैं।

निर्भरता इंजेक्शन और कैसल विंडसर आईओसी कंटेनर पर an awesome tutorial है।

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