सी # या ओओपी में, 2 वर्गों को एक-दूसरे से संबंधित होना चाहिए?

Question

मैं सी # का उपयोग कर कक्षा पुस्तकालय पर काम कर रहा हूं। मैंने अपने डेटा को मॉडल करने में मदद के लिए 3 मुख्य कक्षाएं तैयार की हैं। वे तैयार कर रहे हैं ऐसा है कि वर्ग एक वर्ग बी उदाहरणों की एक सूची है, और वर्ग बी यानी एक वर्ग सी उदाहरण के लिए एक संदर्भ, शामिल हैं:

public class Policy 
{ 
    public List <PolicyTerm> myTerms; 
    person Customer; 
    string PolicyNumber; 
} 

public class PolicyTerm 
{ 
    public Billing myBill; 
    Datetime effectivedate; 
    List <Activities> termActivities; 
    public doAction() 
    { 
      use value from Policy, like PolicyNumber; 
    } 

} 

public class Billing 
{ 
    float remainingBalance; 
    Datetime nextDueDate; 
    public void doSomething() 
    { 
     reference value from PolicyTerm, such as effective date; 
     use value from Policy, such as PolicyNumber; 
    } 
} 

समस्या मेरे पास है

है जब मैं PolicyTerm के भीतर एक विधि का उपयोग करने का प्रयास करें या बिलिंग जिसमें युक्त कक्षा से डेटा की आवश्यकता है। उपर्युक्त उदाहरण में, पॉलिसीटर्म से मूल्य का उपयोग करने की कोशिश करने की विधि "doSomething" विधि होगी, जैसे कि हमारे डेटाबेस में डेटा का अनुरोध करने या सहेजने में शब्द की प्रभावी तिथि।

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

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

प्रदान की जा सकने वाली कोई भी सलाह बहुत सराहना की जाएगी।

अपडेट: कोड ब्लॉक को प्रश्न में कोड पर अधिक जानकारी प्रदान करने के लिए अपडेट किया गया था।

Answer 1

तो doSomething() हमेशा C वस्तु की मूल के संदर्भ में की जरूरत है, तो आप वास्तव में सी में इस संदर्भ डाल तुम कहाँ सुनिश्चित कर सकते हैं कि यह दर्शाता है चाहिए सही B उदाहरण के लिए। ओटीओएच अगर वह संदर्भ हमेशा माता-पिता नहीं होता है, लेकिन फिर भी यह हमेशा B उदाहरण को संदर्भित करता है, यह अभी भी C के सदस्य में बदलने का सुझाव देता है। ओटीओएच अगर doSomething() को विभिन्न संदर्भों के साथ बुलाया जा सकता है, तो संदर्भ को विधि पैरामीटर के रूप में रखा जाना चाहिए।

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

सामान्य रूप से घटक कई कक्षाएं शामिल कर सकते हैं - इसकी वस्तुओं और पुनरावर्तक के साथ एक संग्रह वास्तव में एक सामान्य उदाहरण है। हालांकि, यह सलाह दी जाती है कि इन वर्गों के बीच शारीरिक स्तर पर तार्किक निर्भरता भी व्यक्त की जाए, उदा। एक वर्ग को दूसरे की आंतरिक कक्षा बनाकर, या दोनों कक्षाओं को कक्षाओं को तीसरी कक्षा में बनाना।

Answer 2

आपकी आवश्यक कक्षा का संदर्भ बनाना बिल्कुल बुरा विचार नहीं लगता है। यदि यह आवश्यक है, तो आप कक्षा सी के निर्माता को कक्षा बी के संदर्भ में ले सकते हैं और इसे सदस्य चर में संग्रहीत कर सकते हैं।

मैं इस समय एक परियोजना पर काम कर रहा हूं जिसमें कुछ वर्ग इस तरह व्यवहार करते हैं।

एक और विकल्प जो थोड़ा अधिक "सीन" हो सकता है, कक्षा सी पर एक कार्यक्रम होना है, यह "SuchAndSuchDataRequired" जैसा कुछ है। कक्षा बी तब उस घटना को सुन सकता है जब इसे सी क्लास सी का उदाहरण मिलता है, घटना को कुछ करने के भीतर आग लगती है() जब इसे बी, बी से डेटा की आवश्यकता होती है तो उसके ईवेंट हैंडलर में डेटा लौटाता है और बिंगो-क्लास सी में है डेटा और यह भी नहीं जानता कि यह कक्षा बी से आया है।

Answer 3

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

और कैओसपैंडियन की तरह कहा: कृपया कुछ और विशिष्ट कोड पोस्ट करें ताकि हम आपकी मदद कर सकें।

संपादित करें:

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

Answer 4

यह वास्तव में स्थिति पर निर्भर करता है। आम तौर पर, जब तक कक्षा "बी" और "सी" के बीच स्पष्ट, स्पष्ट संबंध नहीं है, तो यह एक लाल झंडा है कि C.doSomething() को B तक पहुंच की आवश्यकता होगी, क्योंकि सी बी के भीतर निहित है ...

हालांकि, बी में एक विधि सी के लिए उपयोग की आवश्यकता होती है, समझ में आता है के बाद से सी बी

कहा जा रहा है, कई बार है कि इस उचित है के भीतर एक सदस्य है। अपने वास्तविक कक्षाएं बिना जाने, और वे क्या प्रतिनिधित्व करते हैं, इसकी मुश्किल अधिक कहने के लिए ...

Answer 5

दो कक्षाएं नहीं होनी चाहिए, लेकिन दो इंटरफेस ठीक है।

बेशक, छोटे इंटरफेस बेहतर होते हैं। आप पाएंगे कि यदि इंटरफेस पर्याप्त छोटे हैं (जो उन्हें होना चाहिए - Interface Segregation Principal देखें), आपको वास्तव में 2 की आवश्यकता नहीं होगी।

Answer 6

मेरी राय में आपका मॉडलिंग थोड़ा सा दिखता है यानी नीति के भीतर व्यक्ति की संपत्ति क्यों है और पॉलिसी यानी पॉलिसीर्म में ठोस कार्यान्वयन की सूची क्यों है। यह कक्षाओं को एक साथ जोड़ता है और सही महसूस नहीं करता - यानी पॉलिसी एक ग्राहक है? ग्राहक होना चाहिए ए पॉलिसी

मेरा सुझाव कर सकते हैं निम्नलिखित (जल्दी से मॉडलिंग की है और परीक्षण किया है, लेकिन आप क्या मैं पर हो रही है यह देखने के लिए सक्षम होना चाहिए)

public class Customer() 
{ 
    prop name,etc,etc; 
    public List<IPolicyTerm> Policies{get;set;}//I use public getters and setters throughout but you need to choose what level of encapsulation you want 
    private Account customerAccount{get;set}   

    public Customer() 
    { 
     //ctor 
     customerAccount = doDbCall; 
     Policies = doDbCall; 
    } 

    public decimal GetCurrentPolicyCost() 
    { 
     decimal cost = 0; 
     foreach(var policy in Policies) 
     { 
      if(policy.DueDate < DateTime.Now){ 
      cost += policy.GetCost(); //for example but you can call whatever is defined at the interface level 
      } 
     } 
     return cost; 
    } 

    public bool HasEnoughFunds() 
    { 
     return customerAccount.Balance >= GetCurrentPolicyCost(); 
    } 

    //keeping Account hidden in Person as Person has a reference to Account. 
    //By doing so there is type coupling between the two classes 
    //BUT you can still modify Policies away from Person 
    private class Account 
    { 
     //should only contain properties and I assume only one 'Account' per person 
    } 
} 

public interface IPolicyTerm 
{ 
    object Id{get;set} 
    DateTime DueDate {get;set;} 
    decimal GetCost(); 
} 

///now we can have polymorphic Policies i.e. the cost of one can be calculated differently based on policy 

public class LifeCoverPolicy : IPolicyTerm 
{ 

    public object Id; 
    public DateTime DueDate{get;set;}   

    public decimal GetCost() 
    { 
      return 10; 
    } 
}