ऑब्जेक्ट बनाना - स्थिर बिल्डर विधि बनाम बिल्डर क्लास बनाम एक्सटेंशन विधि

Question

मुझे यह जानकर उत्सुकता है कि किसी अन्य ऑब्जेक्ट से डेटा के साथ कस्टम ऑब्जेक्ट बनाने के लिए किसी के पास कोई सुझाव या वैकल्पिक पैटर्न है या नहीं।

हम वर्तमान में तीन दृष्टिकोण खोज रहे हैं।

1) स्टेटिक बिल्ड विधि

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public static MyObject Build(DataRow data) 
    { 
     MyObject newObject = new MyObject(); 
     newObject.Id = Convert.ToInt32(data["ID"]); 
     newObject.Name = Convert.ToString(data["NAME"]); 
     return newOjbect; 
    } 
} 

2) बिल्डर कक्षा

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
} 

public class MyObjectBuilder 
{ 
    public static MyObject Build(DataRow data) 
    { 
     MyObject newObject = new MyObject(); 
     newObject.Id = Convert.ToInt32(data["ID"]); 
     newObject.Name = Convert.ToString(data["NAME"]); 
     return newOjbect; 
    } 
} 

3) विस्तार विधि

public class MyObject 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
} 

public static class MyObjectExtensions 
{ 
    public static void Build(this MyObject obj, DataRow data) 
    { 
     obj.Id = Convert.ToInt32(data["ID"]); 
     obj.Name = Convert.ToString(data["NAME"]); 
    } 
} 

एक मुख्य विचार यह है कि हम जिस भी दृष्टिकोण के साथ जाते हैं, हमें using कक्षा में System.Data का संदर्भ जोड़ने की आवश्यकता है। इस बिंदु पर हम इस निर्भरता को सीधे हमारे MyObject कक्षा में जोड़ने में संकोच कर रहे हैं।

क्या कोई इन दृष्टिकोणों में से किसी के लिए फायदे या नुकसान प्रदान कर सकता है या शायद ऐसे विकल्प प्रदान कर सकता है जो एक्स्टेंसिबिलिटी और टेस्टेबिलिटी को बेहतर ढंग से सक्षम कर सकें?

Answer 1

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

मैं विस्तार की विधि का उपयोग नहीं करता, क्योंकि वे मेरी राय में हैं, ढांचे से विशेषताओं को विस्तारित करने के लिए अधिक प्रासंगिक (आमतौर पर स्ट्रिंग या आईनेमेरेबल क्लासेस) जब आपको अपनी सभी परियोजनाओं के माध्यम से एक विशिष्ट सुविधा की आवश्यकता होती है।

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

Answer 2

आप कंस्ट्रक्टर्स

public class MyObject 
{ 
    public int Id { get; private set; } 
    public string Name { get; private set; } 

    public MyObject(int Id,string Name) 
    { 
     this.Id = Id; 
     this.Name = Name; 
    } 

    public MyObject(DataRow data) 
    { 
     Id = Convert.ToInt32(data["ID"]); 
     Name = Convert.ToString(data["NAME"]); 
    } 
} 

उपयोग कर सकते हैं Id प्रकार था Guid वहाँ डिफ़ॉल्ट निर्माता हो सकता है।

MyObject myObject = new MyObject(data) 

अधिक पठनीय लग रहा है तो

MyObject myObject = MyObject.Build(data) 

मुझे लगता है कि विस्तार विधि स्थिति से संबंधित है क्योंकि वस्तु के निर्माण के फिट नहीं करता है, लेकिन व्यवहार के लिए नहीं, वस्तु के व्यवहार से संबंधित है, जबकि विस्तार तरीकों।