सी # में फैक्टरी पैटर्न: ऑब्जेक्ट इंस्टेंस को सुनिश्चित करने के लिए केवल फ़ैक्टरी क्लास द्वारा ही बनाया जा सकता है?

Question

हाल ही में मैं अपने कुछ कोड को सुरक्षित करने के बारे में सोच रहा हूं। मैं उत्सुक हूं कि कोई यह सुनिश्चित कर सकता है कि कोई ऑब्जेक्ट सीधे कभी नहीं बनाया जा सकता है, लेकिन केवल फैक्ट्री क्लास की कुछ विधि के माध्यम से। मान लें कि मेरे पास कुछ "व्यावसायिक वस्तु" वर्ग है और मैं यह सुनिश्चित करना चाहता हूं कि इस वर्ग के किसी भी उदाहरण में एक वैध आंतरिक स्थिति होगी। इसे प्राप्त करने के लिए मुझे ऑब्जेक्ट बनाने से पहले कुछ रचना करने की आवश्यकता होगी, शायद इसके कन्स्ट्रक्टर में। यह ठीक है जब तक कि मैं फैसला नहीं करता कि मैं यह चेक व्यापार तर्क का हिस्सा बनना चाहता हूं। तो, मैं किसी व्यवसाय ऑब्जेक्ट को केवल अपने व्यवसाय तर्क वर्ग में कुछ विधि के माध्यम से रचनात्मक होने की व्यवस्था कैसे कर सकता हूं लेकिन सीधे कभी नहीं? सी ++ के अच्छे पुराने "दोस्त" कीवर्ड का उपयोग करने की पहली प्राकृतिक इच्छा सी # के साथ कम हो जाएगी। तो हम अन्य विकल्पों की आवश्यकता है ...

के कुछ उदाहरण कोशिश करते हैं:

public MyBusinessObjectClass 
{ 
    public string MyProperty { get; private set; } 

    public MyBusinessObjectClass (string myProperty) 
    { 
     MyProperty = myProperty; 
    } 
} 

public MyBusinessLogicClass 
{ 
    public MyBusinessObjectClass CreateBusinessObject (string myProperty) 
    { 
     // Perform some check on myProperty 

     if (true /* check is okay */) 
      return new MyBusinessObjectClass (myProperty); 

     return null; 
    } 
} 

यह सब ठीक है जब तक आप आप अभी भी सीधे MyBusinessObjectClass उदाहरण बना सकते हैं, इनपुट की जाँच के बिना याद है। मैं उस तकनीकी संभावना को पूरी तरह से बाहर करना चाहता हूं।

तो समुदाय इस बारे में क्या सोचता है?

Answer 1

ऐसा लगता है कि तुम सिर्फ वस्तु बनाने के पहले कुछ व्यापार तर्क चलाना चाहते हैं - तो क्यों तुम सिर्फ "BusinessClass" है कि सभी गंदे "myProperty" जाँच काम करता है के अंदर एक स्थिर विधि बनाने नहीं है, और बनाने के कन्स्ट्रक्टर निजी?

public BusinessClass 
{ 
    public string MyProperty { get; private set; } 

    private BusinessClass() 
    { 
    } 

    private BusinessClass(string myProperty) 
    { 
     MyProperty = myProperty; 
    } 

    public static BusinessClass CreateObject(string myProperty) 
    { 
     // Perform some check on myProperty 

     if (/* all ok */) 
      return new BusinessClass(myProperty); 

     return null; 
    } 
} 

यह होगा कॉलिंग बिल्कुल स्पष्ट हो:

BusinessClass objBusiness = BusinessClass.CreateObject(someProperty); 

Answer 2

आप अपने MyBusinessObjectClass क्लास आंतरिक पर निर्माता बना सकते हैं, और इसे और कारखाने को अपनी स्वयं की असेंबली में ले जा सकते हैं। अब केवल कारखाने वर्ग का एक उदाहरण बनाने में सक्षम होना चाहिए।

public class BusinessObject 
{ 
    private BusinessObject(string property) 
    { 
    } 

    public class Factory 
    { 
     public static BusinessObject CreateBusinessObject(string property) 
     { 
      return new BusinessObject(property); 
     } 
    } 
} 

यह काम करता है क्योंकि नेस्टेड प्रकार उनकी enclosing प्रकार के निजी सदस्यों की पहुंच है:

Answer 3

आप निर्माता निजी कारखाने एक नेस्टेड प्रकार बनाने के लिए, और कर सकते हैं। मुझे पता है कि यह थोड़ा सा प्रतिबंधक है, लेकिन उम्मीद है कि इससे मदद मिलेगी ...

Answer 4

जॉन ने जो सुझाव दिया है उसके अलावा, आप या तो फैक्ट्री विधि (चेक सहित) भी पहले स्थान पर BusinessObject की एक स्थिर विधि हो सकती है। फिर, कन्स्ट्रक्टर निजी है, और हर किसी को स्थिर विधि का उपयोग करने के लिए मजबूर किया जाएगा।

public class BusinessObject 
{ 
    public static Create (string myProperty) 
    { 
    if (...) 
     return new BusinessObject (myProperty); 
    else 
     return null; 
    } 
} 

लेकिन असली सवाल यह है कि - आपको यह आवश्यकता क्यों है? क्या कारखाने या फैक्ट्री विधि को कक्षा में स्थानांतरित करना स्वीकार्य है?

Answer 5

फिर भी एक और (हल्के वजन) विकल्प BusinessObject वर्ग में स्थिर फैक्ट्री विधि बनाना और कन्स्ट्रक्टर को निजी रखना है।

public class BusinessObject 
{ 
    public static BusinessObject NewBusinessObject(string property) 
    { 
     return new BusinessObject(); 
    } 

    private BusinessObject() 
    { 
    } 
} 

Answer 6

या, यदि आप वास्तव में कल्पना जाना चाहते हैं, नियंत्रण को उलटने: वर्ग कारखाने लौट साधन एक प्रतिनिधि उस वर्ग बना सकते हैं के साथ कारखाने है, और।

public class BusinessObject 
{ 
    public static BusinessObjectFactory GetFactory() 
    { 
    return new BusinessObjectFactory (p => new BusinessObject (p)); 
    } 

    private BusinessObject(string property) 
    { 
    } 
} 

public class BusinessObjectFactory 
{ 
    private Func<string, BusinessObject> _ctorCaller; 

    public BusinessObjectFactory (Func<string, BusinessObject> ctorCaller) 
    { 
    _ctorCaller = ctorCaller; 
    } 

    public BusinessObject CreateBusinessObject(string myProperty) 
    { 
    if (...) 
     return _ctorCaller (myProperty); 
    else 
     return null; 
    } 
} 

:)

Answer 7

इसलिए, यह मैं क्या एक "शुद्ध" तरीके से नहीं किया जा सकता है चाहता हूँ की तरह लग रहा है। लॉजिक क्लास में यह हमेशा किसी तरह का "कॉल बैक" होता है।

शायद मैं इसे सरल तरीके से कर सकता हूं, बस ऑब्जेक्ट क्लास में एक कन्स्ट्रक्टर विधि को इनपुट जांचने के लिए लॉजिक क्लास को कॉल करें?

public MyBusinessObjectClass 
{ 
    public string MyProperty { get; private set; } 

    private MyBusinessObjectClass (string myProperty) 
    { 
     MyProperty = myProperty; 
    } 

    pubilc static MyBusinessObjectClass CreateInstance (string myProperty) 
    { 
     if (MyBusinessLogicClass.ValidateBusinessObject (myProperty)) return new MyBusinessObjectClass (myProperty); 

     return null; 
    } 
} 

public MyBusinessLogicClass 
{ 
    public static bool ValidateBusinessObject (string myProperty) 
    { 
     // Perform some check on myProperty 

     return CheckResult; 
    } 
} 

इस तरह, व्यापार वस्तु सीधे रचनात्मक नहीं है और व्यावसायिक तर्क में सार्वजनिक जांच विधि को कोई नुकसान नहीं होगा।

Answer 8

मुझे समझ में नहीं आता कि आप "व्यावसायिक वस्तु" से "व्यावसायिक तर्क" को अलग क्यों करना चाहते हैं। यह ऑब्जेक्ट ओरिएंटेशन के विकृति की तरह लगता है, और आप उस दृष्टिकोण को लेकर अपने आप को गठबंधन में बांध देंगे।

Answer 9

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

public class Person 
{ 
    internal Person() 
    { 
    } 
} 

public class PersonFactory 
{ 
    public Person Create() 
    { 
    return new Person(); 
    } 
} 

हालांकि, मैं अपने दृष्टिकोण :-)

मुझे लगता है कि अगर आप अपने व्यक्ति वर्ग निर्माण पर मान्य होना चाहते हैं आप निर्माता में कोड लगाना होगा सवाल करना चाहिए।

public class Person 
{ 
    public Person(string firstName, string lastName) 
    { 
    FirstName = firstName; 
    LastName = lastName; 
    Validate(); 
    } 
} 

Answer 10

इंटरफेस और कार्यान्वयन के बीच अच्छा पृथक्करण के एक मामले में
संरक्षित-निर्माता-सार्वजनिक-प्रारंभकर्ता पैटर्न एक बहुत साफ समाधान अनुमति देता है।

को देखते हुए एक व्यापार वस्तु:

public interface IBusinessObject { } 

class BusinessObject : IBusinessObject 
{ 
    public static IBusinessObject New() 
    { 
     return new BusinessObject(); 
    } 

    protected BusinessObject() 
    { ... } 
} 

और एक व्यापार का कारखाना:

class BusinessObject : IBusinessObject 
{ 
    public static IBusinessObject New(BusinessFactory factory) 
    { ... } 

    ... 
} 

यहाँ ठोस के लिए एक संदर्भ:

public interface IBusinessFactory { } 

class BusinessFactory : IBusinessFactory 
{ 
    public static IBusinessFactory New() 
    { 
     return new BusinessFactory(); 
    } 

    protected BusinessFactory() 
    { ... } 
} 

BusinessObject.New() प्रारंभकर्ता के लिए निम्न परिवर्तन समाधान देता है BusinessObject.New() पर कॉल करने के लिए व्यवसाय कारखाने की आवश्यकता है प्रारंभकर्ता। लेकिन केवल एक ही जिसके पास आवश्यक संदर्भ है वह व्यवसाय कारखाना है।

हमें जो चाहिए वह मिला: केवल BusinessObjectBusinessFactory बना सकता है।

Answer 11

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

एक विकल्प एक स्थिर निर्माता है जो किसी आईओसी कंटेनर की तरह किसी कारखाने को पंजीकृत करता है।

Answer 12

यह समाधान munificents पर आधारित है जो कन्स्ट्रक्टर में टोकन का उपयोग करने का विचार है।इस जवाब make sure object only created by factory (C#)

public class BusinessObject 
    { 
     public BusinessObject(object instantiator) 
     { 
      if (instantiator.GetType() != typeof(Factory)) 
       throw new ArgumentException("Instantiator class must be Factory"); 
     } 

    } 

    public class Factory 
    { 
     public BusinessObject CreateBusinessObject() 
     { 
      return new BusinessObject(this); 
     } 
    } 

Answer 13

यहाँ में हो गया की नस में एक और उपाय है "सिर्फ इसलिए कि आप मतलब यह नहीं है कर सकते हैं चाहिए" ...

यह व्यापार वस्तु निर्माता रखने की आवश्यकताओं को पूरा करता है निजी और कारखाने के तर्क को किसी अन्य वर्ग में डालना। इसके बाद यह थोड़ा स्केची हो जाता है।

फैक्ट्री क्लास में व्यावसायिक वस्तुओं को बनाने के लिए एक स्थिर विधि है। निजी कन्स्ट्रक्टर को आमंत्रित करने वाली स्थिर संरक्षित निर्माण विधि तक पहुंचने के लिए यह व्यावसायिक ऑब्जेक्ट क्लास से निकला है।

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

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

मैं किसी को भी उनके सही दिमाग में सुझाव देने की कोशिश नहीं कर रहा हूं, लेकिन यह एक ऐसा था दिलचस्प अभ्यास। एफडब्ल्यूआईडब्ल्यू, मेरा पसंदीदा समाधान एक आंतरिक कन्स्ट्रक्टर और असेंबली सीमा का उपयोग गार्ड के रूप में करना होगा। विभिन्न समझौतों से साथ

using System; 

public class MyBusinessObjectClass 
{ 
    public string MyProperty { get; private set; } 

    private MyBusinessObjectClass(string myProperty) 
    { 
     MyProperty = myProperty; 
    } 

    // Need accesible default constructor, or else MyBusinessObjectFactory declaration will generate: 
    // error CS0122: 'MyBusinessObjectClass.MyBusinessObjectClass(string)' is inaccessible due to its protection level 
    protected MyBusinessObjectClass() 
    { 
    } 

    protected static MyBusinessObjectClass Construct(string myProperty) 
    { 
     return new MyBusinessObjectClass(myProperty); 
    } 
} 

public abstract class MyBusinessObjectFactory : MyBusinessObjectClass 
{ 
    public static MyBusinessObjectClass CreateBusinessObject(string myProperty) 
    { 
     // Perform some check on myProperty 

     if (true /* check is okay */) 
      return Construct(myProperty); 

     return null; 
    } 

    private MyBusinessObjectFactory() 
    { 
    } 
} 

Answer 14

public class HandlerFactory: Handler 
    { 
     public IHandler GetHandler() 
     { 
      return base.CreateMe(); 
     } 
    } 

    public interface IHandler 
    { 
     void DoWork(); 
    } 

    public class Handler : IHandler 
    { 
     public void DoWork() 
     { 
      Console.WriteLine("hander doing work"); 
     } 

     protected IHandler CreateMe() 
     { 
      return new Handler(); 
     } 

     protected Handler(){} 
    } 

    public static void Main(string[] args) 
    { 
     // Handler handler = new Handler();   - this will error out! 
     var factory = new HandlerFactory(); 
     var handler = factory.GetHandler(); 

     handler.DoWork();   // this works! 
    } 

Answer 15

एकाधिक दृष्टिकोण उल्लेख किया गया है।

• निजी रूप से निर्मित कक्षा में फैक्ट्री क्लास को नज़रअंदाज़ करने से केवल कारखाने को 1 वर्ग का निर्माण करने की अनुमति मिलती है। उस समय आप Create विधि और एक निजी सीटीआर के साथ बेहतर हो सकते हैं।
• विरासत का उपयोग और संरक्षित सीटीआर का एक ही मुद्दा है।

मैं फैक्ट्री को आंशिक कक्षा के रूप में प्रस्तावित करना चाहता हूं जिसमें सार्वजनिक रचनाकारों के साथ निजी नेस्टेड कक्षाएं हों। आप अपने फैक्ट्री का निर्माण कर रहे ऑब्जेक्ट को 100% छुपा रहे हैं और केवल एक या एकाधिक इंटरफेस के माध्यम से आप जो चुनते हैं उसे उजागर कर रहे हैं।

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

== ChemicalFactory.cs == 
partial class ChemicalFactory { 
    private ChemicalFactory() {} 

    public interface IChemical { 
     int AtomicNumber { get; } 
    } 

    public static IChemical CreateOxygen() { 
     return new Oxygen(); 
    } 
} 


== Oxygen.cs == 
partial class ChemicalFactory { 
    private class Oxygen : IChemical { 
     public Oxygen() { 
      AtomicNumber = 8; 
     } 
     public int AtomicNumber { get; } 
    } 
} 



== Program.cs == 
class Program { 
    static void Main(string[] args) { 
     var ox = ChemicalFactory.CreateOxygen(); 
     Console.WriteLine(ox.AtomicNumber); 
    } 
}