ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में किस ऑब्जेक्ट को कई रिश्तों को बनाए रखना चाहिए? (यदि कोई हो)

Question

मैं इस वर्णन करने के लिए एक उदाहरण का उपयोग करेंगे:

class Company { 

} 

class Person { 

} 

Company और Person कई रिश्ते के लिए कई पकड़ो। एक Person एकाधिक Companies से संबंधित हो सकता है और Company एकाधिक People रख सकता है। कंपनी इसे संभाल चाहिए

class CompanyPerson { 

} 

या:

मैं तो एक तृतीय श्रेणी बनाने की आवश्यकता चाहेंगे

class Company { 
    function add_person() { 

    } 
} 

या शायद Person चाहिए?

class Person { 
    function add_to_company() { 

    } 
} 

Answer 1

गुण एक Person और Company उदाहरण के कुछ यादृच्छिक संयोजन के लिए आम एक "संघ वर्ग" का उपयोग कर तैयार किया जा सकता।

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

विचार यह है कि Person और Company से संबंधित वस्तुओं की यादृच्छिक जोड़ी का रिश्ता है, और यह रिश्ता स्वयं एक वस्तु है। यह न तो Person और न ही Company है, लेकिन एक विशेष Person और Company उदाहरण के बीच कनेक्शन से जुड़े सामान।

वह सामान (गुण, विधियां) एक वर्ग का गठन करती है: Person-Company एसोसिएशन क्लास।

मैंने इस काम को लिस्प में पहले बनाया था, कुछ मैक्रोज़ कक्षाओं के लिए एक एसोसिएशन क्लास को परिभाषित करने के लिए, और ऑब्जेक्ट जोड़े को उनके एसोसिएशन क्लास ऑब्जेक्ट में मैप करने के लिए वैश्विक कमजोर हैश टेबल (ताकि किसी दिए गए व्यक्ति के लिए और कंपनी एसोसिएशन को पुनः प्राप्त करना संभव था, और जब ये वस्तुएं कचरा बन जाती हैं तो वह संगठन दूर हो जाएगा)।

विशेष कंपनियों और लोगों के बीच वास्तविक लिंक उदाहरण का उपयोग करना आसान है। सूचियों या अन्य सहयोगी डेटा संरचनाओं। एक व्यक्ति वस्तु में कंपनियों की एक सूची हो सकती है, और इसके विपरीत। एसोसिएशन क्लास विचार व्यक्ति-कंपनी सामान कहां रखना है, इस समस्या को संबोधित करता है। उदाहरण के लिए प्रत्येक Person में Company (मान लें) के भीतर एक भूमिका है। हमारे पास role एक Person में परिवर्तनीय नहीं हो सकता है क्योंकि इसमें कई भूमिकाएं हो सकती हैं w.r.t कई कंपनियां। हम निश्चित रूप से कंपनी में role नहीं रख सकते हैं क्योंकि यह एक व्यक्ति भी नहीं है; इसमें लोगों के साथ जुड़ा हुआ है जिनके पास भूमिकाएं हैं। भूमिका एसोसिएशन में जा सकती है: समस्या हल हो गई।

Answer 2

यह पूरी तरह से उपयोग परिदृश्य पर निर्भर करता है।

यदि आपको केवल कंपनी के लिए काम करने वाले लोगों को खोजने की ज़रूरत है, तो कंपनी पर लोगों की सूची संग्रहित करें; अगर आपको केवल उन कंपनियों को ढूंढने की ज़रूरत है जो लोग काम करते हैं तो वहां स्टोर करें।

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

Answer 3

अच्छी तरह से मुझे नहीं लगता कि आपको तीसरी कक्षा की आवश्यकता है।

क्या एक ORM (php के लिए Doctrin, Hybernate forn जावा) की Think करता है:

कंपनी, उपयोगकर्ता और Company_user (तालिका में शामिल होने beetween:

एक databse परत पर इस मामले में आप 3 टेबल होगा उपयोगकर्ता और कंपनी जो कहती है कि कौन सा उपयोगकर्ता कौन सा कंपनी है)।

इसके अलावा, आप इस स्थिति को मैप कर सकते सिर्फ दो डाटाबेस टेबल के साथ:

कंपनी, उपयोगकर्ता और उपयोगकर्ता में आप कंपनी के लिए एक संदर्भ की ओर इशारा करते है। तो इस संदर्भ के आधार पर आप उस कंपनी को कह सकते हैं जिस पर उपयोगकर्ता संबंधित है।

अंत में एक वर्ग के डिजाइन पर मुझे लगता है कि:

• कक्षा companuy उपयोगकर्ता (उपयोगकर्ता कंपनी से संबंधित की सूची) की एक सरणी धारण कर सकते हैं
• कक्षा उपयोगकर्ता कंपनी के लिए एक संदर्भ (कंपनी धारण कर सकते हैं करने के लिए उपयोगकर्ता bleongs)

Answer 4

यह उपयोग के मामले पर निर्भर करता है, लेकिन आम तौर पर कई वस्तु संबंध बनाने के लिए कई एक संदर्भ वर्ग

class CompanyPersonRelationship { 
    public $company; 
    public $person; 
} 

का उपयोग कर तैनात किया जा सकता

तो अब, दोनों कंपनी और व्यक्ति उनके रिश्ते झूठ

class Company { 
    public $persons = array(); 
} 

class Person { 
    public $companies = array(); 
} 

[वर्ग के साथ मॉडलिंग अभिभावक-बच्चे रिश्ते] (की