संघ, एकत्रीकरण और संरचना के बीच अंतर क्या है?

Question

संघ, एकत्रीकरण और संरचना के बीच अंतर क्या है? कृपया कार्यान्वयन के संदर्भ में बताएं।

Comments

यह एक बालक अभी शुरुआत के लिए दवाब डाले हो सकता है लेकिन यूएमएल 2 सुपरस्ट्रक्चर कल्पना के माध्यम से एक सुबह टहलने जा: omg.org/docs/formal/09-02-02.pdf के लिए एसोसिएशन धारा 7.3.3

— chickeninabiscuit

मुझे यह भी जोड़ना चाहिए, यूएमएल 2 में एग्रीगेशन या कम्पोजीशन जैसा कोई तत्व नहीं है (हालांकि यह यूएमएल 1.4 में था)। यूएमएल 2 में, एकत्रीकरण / रचनाओं को एग्रीगेशन के साथ एसोसिएशन तत्वों के रूप में लागू किया जाता है। संपत्ति को साझा या समग्र के लिए सेट किया जाता है।

— चिकनिनबिस्किट

उत्तर पर बहुत पहले से ही: stackoverflow.com/search?q=aggregation+and+composition

— लोथर

उपयोगी लेख यहाँ codeproject.com/Articles/22769/…

— गिब्बो मार्क

मुझे पता है कि यह पहले ही कई बार उत्तर दिया जा चुका है, लेकिन मुझे सबसे अच्छा स्पष्टीकरण लगता है कि मैंने कभी इस मामले पर पढ़ा है यह एक है: holub.com/goodies/uml/#composition

— WLin

Answer 1

दो वस्तुओं के लिए, Fooऔर Barरिश्तों को परिभाषित किया जा सकता है

एसोसिएशन - मेरा किसी वस्तु से संबंध है। Fooका उपयोग करता हैBar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

रचना - मेरे पास एक वस्तु है और मैं इसके जीवनकाल के लिए जिम्मेदार हूं। जब Fooमरता है, तो करता हैBar

public class Foo {
    private Bar bar = new Bar(); 
}

एकत्रीकरण - मेरे पास एक वस्तु है जिसे मैंने किसी और से उधार लिया है। जब Fooमर जाता है, Barपर रह सकता है।

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

Comments

लगता है सी # / जावा कोड। अगर ऐसा है, तो एसोसिएशन और एग्रीगेशन कोड दोनों समान हैं। दोनों ही मामलों में, 'बार' केवल संदर्भित है और Barऑब्जेक्ट पर रह सकता है।

— अजय

@ जेफ़ फोस्टर: मुझे कुछ संदेह है। अगर मैं बाज (बार बार) {बार = नई बार () में बार ऑब्जेक्ट को इंस्टेंट करता हूं; } पहले मामले में। क्या यह अभी भी संघ होगा या यह अब रचना बन जाएगा?

— साकेत

@ अजय: एकत्रीकरण उन वस्तुओं का संदर्भ रखता है जो संगति के मामले में नहीं है। इसलिए कार्यान्वयन का अंतर।

— एबीसीडी

संघ एक विधि पैरामीटर के रूप में उपयोग से थोड़ा मजबूत है। मेरा मानना ​​है कि आपका एसोसिएशन कोड स्निपेट डिपेंडेंसी रिलेशन से ज्यादा मेल खाता है । आप मार्टिन फाउलर से संबंधित लेख

— अहमद अब्देलघानी

@ अहदअबदेल्गनी सही है। पहला उदाहरण एक निर्भरता संबंध है। तीसरा एक संघ और एकत्रीकरण के लिए काम करता है।

— एंड्रे वैलेंटी

Answer 2

मुझे पता है कि इस प्रश्न को C # के रूप में चिह्नित किया गया है, लेकिन अवधारणाएँ इस तरह के पुनर्निर्देशन के समान सामान्य प्रश्न हैं। इसलिए मैं यहाँ अपनी बात प्रदान करने जा रहा हूँ (जावा बिंदु से थोड़ा सा पक्षपाती जहाँ मैं अधिक सहज हूँ)।

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

एकत्रीकरण और संरचना संघ के सबसेट हैं जिसका अर्थ है कि वे एसोसिएशन के विशिष्ट मामले हैं।

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

उलझन में?

संरचना उदाहरण : एक कार और एक इंजन के उदाहरण पर विचार करें जो उस कार के लिए बहुत विशिष्ट है (इसका अर्थ है कि इसे किसी अन्य कार में इस्तेमाल नहीं किया जा सकता है)। कार और विशिष्ट वर्ग के बीच इस प्रकार के संबंधों को रचना कहा जाता है। विशिष्ट वर्ग की वस्तु के बिना कार वर्ग की कोई वस्तु मौजूद नहीं हो सकती है और विशिष्ट वर्ग की वस्तु का कार वर्ग के बिना कोई महत्व नहीं है। सरल शब्दों में कहें तो कार क्लास पूरी तरह से "विशिष्ट" श्रेणी का मालिक है।

एकत्रीकरण उदाहरण : अब क्लास कार और क्लास व्हील पर विचार करें । कार को कार्य करने के लिए व्हील ऑब्जेक्ट की आवश्यकता होती है। मतलब कार ऑब्जेक्ट व्हील ऑब्जेक्ट का मालिक है लेकिन हम यह नहीं कह सकते कि कार ऑब्जेक्ट के बिना व्हील ऑब्जेक्ट का कोई महत्व नहीं है। इसका उपयोग बाइक, ट्रक या अलग-अलग कारों के ऑब्जेक्ट में किया जा सकता है।

इसे समेटना -

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

अधिक जानकारी यहाँ। मैं http://opensourceforgeeks.blogspot.in का लेखक हूं और अधिक संदर्भ के लिए संबंधित पोस्ट के ऊपर एक लिंक जोड़ा है।

Comments

मैं यह पूछने जा रहा था कि आपने पहले से ही पूछे गए सवाल का जवाब देने की परवाह क्यों की, जो 5 साल से अधिक समय पहले पूछा गया था, लेकिन फिर मैंने आपके ब्लॉग प्रविष्टि को पढ़ा और यह यहाँ के कुछ उत्तरों की तुलना में अधिक जानकारीपूर्ण था। Upvoted!

— डॉनभूपी

मैं @Donbhupi से सहमत आपका जवाब तरह से अधिक सूचनात्मक और कई अन्य लोगों की तुलना में सही है

— zish

जब C # और Java डेवलपर दावा करते हैं कि वे रचना का उपयोग तब करते हैं जब यह केवल उन भाषाओं के साथ आदिम प्रकार पर मौजूद होता है। यदि आप रचना को वास्तव में समझना चाहते हैं तो आपको C ++ का उपयोग करना होगा जहां वस्तुएं वास्तव में अन्य वस्तुओं का हिस्सा हो सकती हैं .. न कि केवल ढेर स्मृति में तैरते हुए और एक दूसरे की ओर इशारा करते हुए और दावा करते हुए कि रचना है ..

— सभी को

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

— पाउलो आंद्रे हाके

क्या हम प्रबंधित मेमोरी का उपयोग करके ac # कोड में रचना कर सकते हैं?

— पाउलो आंद्रे हाके

Answer 3

एसोसिएशन संबंधों की सामान्यीकृत अवधारणा है। इसमें रचना और एकत्रीकरण दोनों शामिल हैं।

रचना ( मिश्रण ) साधारण वस्तुओं या डेटा प्रकारों को एक इकाई में लपेटने का एक तरीका है । रचनाएँ कई बुनियादी डेटा संरचनाओं का एक महत्वपूर्ण निर्माण खंड हैं

एकत्रीकरण ( संग्रह ) सामान्य रचना से इस मायने में अलग है कि यह स्वामित्व में नहीं है। रचना में, जब मालिक वस्तु नष्ट हो जाती है, तो निहित वस्तुएं होती हैं। एकत्रीकरण में, यह जरूरी सच नहीं है।

दोनों वस्तु के बीच संबंध को दर्शाता है और केवल उनकी ताकत में भिन्नता है।

अंतर को याद रखने की ट्रिक: इसमें A - A ggregation और O wn - c O mpositoin है

अब निम्नलिखित छवि को देखते हैं

सादृश्य:

रचना : निम्नलिखित चित्र छवि रचना है अर्थात एक छवि बनाने वाली व्यक्तिगत छवियों का उपयोग करना।

एकत्रीकरण : एकल स्थान में छवि का संग्रह

उदाहरण के लिए, एक विश्वविद्यालय विभिन्न विभागों का मालिक है, और प्रत्येक विभाग में कई प्रोफेसर हैं। यदि विश्वविद्यालय बंद हो जाता है, तो विभाग अब मौजूद नहीं रहेंगे, लेकिन उन विभागों में प्रोफेसरों का अस्तित्व बना रहेगा। इसलिए, एक विश्वविद्यालय को विभागों की संरचना के रूप में देखा जा सकता है, जबकि विभागों में प्रोफेसरों का एकत्रीकरण होता है। इसके अतिरिक्त, एक प्रोफेसर एक से अधिक विभागों में काम कर सकता था, लेकिन एक विभाग एक से अधिक विश्वविद्यालयों का हिस्सा नहीं हो सकता था।

Comments

इस विषय पर इतना पढ़ने के बाद, यह उत्तर सबसे सहज समझ वाला है। विकिपीडिया पर रखा जाना चाहिए।

— जनकपुँतक

सुंदर ढंग से व्यक्त किया गया।

— सिड

एकत्रीकरण के संबंध में, आप कहते हैं कि "बाल वस्तुएं एकल माता-पिता की हैं"। यह सही नहीं है। यह साझा एकत्रीकरण के लिए UML मान्य है, अर्थात एक बच्चा कई माता-पिता का है। आप प्रोफेसरों के एकत्रीकरण के रूप में विभाग के बारे में अपने उदाहरण में इसे स्वीकार करते हैं, क्योंकि आप कहते हैं कि एक प्रोफेसर एक से अधिक विभागों के लिए काम कर सकता है।

— www.admiraalit.nl

@ www.admiraalit.nl AFAIK साझा एकत्रीकरण का मतलब यह नहीं है कि "एक बच्चा कई माता-पिता का है", यह सिर्फ दूसरे तरीके का दौर है, कई बच्चे एक ही माता-पिता के हैं। और यह एक गैर-समग्र एकत्रीकरण है क्योंकि भले ही माता-पिता मर जाते हैं, बच्चे लंबे समय तक जीवित रह सकते हैं।

— एडेरोक्स

Answer 4

निर्भरता (संदर्भ)
इसका मतलब है कि दो वस्तुओं के बीच कोई वैचारिक संबंध नहीं है। उदाहरण एनरोलमेंट सेवा सेवा छात्र और पाठ्यक्रम वस्तुओं (विधि मापदंडों या वापसी के प्रकार) के संदर्भ में

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

एसोसिएशन (है-ए)
इसका मतलब है कि लगभग हमेशा वस्तुओं (वे जुड़े हुए हैं) के बीच एक कड़ी है। ऑर्डर ऑब्जेक्ट में एक ग्राहक ऑब्जेक्ट है

public class Order {
    private Customer customer
}

एकत्रीकरण (है-एक + पूरे-भाग)
विशेष प्रकार का जुड़ाव जहाँ दो वस्तुओं के बीच पूर्ण-भाग संबंध होता है। हालांकि वे एक दूसरे के बिना रह सकते हैं।

public class PlayList{
    private List<Song> songs;
}

नोट: ट्रिकिएस्ट हिस्सा सामान्य संघ से एकत्रीकरण को अलग करना है। ईमानदारी से, मुझे लगता है कि यह विभिन्न व्याख्याओं के लिए खुला है।

रचना (है-एक + संपूर्ण-भाग + स्वामित्व)
विशेष प्रकार का एकत्रीकरण। एक Apartmentकुछ Roomएस से बना है । A Roomबिना मौजूद नहीं हो सकता Apartment। जब एक अपार्टमेंट हटा दिया जाता है, तो सभी संबद्ध कमरे भी हटा दिए जाते हैं।

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}

Comments

युप, वस्तु संबंधों को निर्धारित करने में एकमात्र मुश्किल हिस्सा एसोसिएशन और एकत्रीकरण के बीच अंतर करना है। बाकी सब स्पष्ट है। मेरे से +1

— फाउड बुकेरेडीन

Answer 5

Comp.object में रॉबर्ट मार्टिन द्वारा एक पोस्ट से :

एक संदेश को दूसरे उदाहरण पर भेजने के लिए एसोसिएशन एक उदाहरण की क्षमता का प्रतिनिधित्व करता है। यह आमतौर पर एक पॉइंटर या संदर्भ उदाहरण चर के साथ कार्यान्वित किया जाता है, हालांकि इसे एक विधि तर्क, या स्थानीय चर के निर्माण के रूप में भी लागू किया जा सकता है।

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

एकत्रीकरण [...] विशिष्ट संपूर्ण / भाग संबंध है। यह अपवाद के साथ एक संघ के रूप में बिल्कुल वैसा ही है कि उदाहरणों में चक्रीय एकत्रीकरण संबंध नहीं हो सकते हैं (यानी एक भाग में इसका संपूर्ण समावेश नहीं हो सकता है)।

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

तथ्य यह है कि यह एकत्रीकरण है जिसका अर्थ है कि नोड के उदाहरण एक चक्र नहीं बना सकते हैं। इस प्रकार, यह एक पेड़ है नोड्स का ग्राफ नहीं है।

रचना [...] बिल्कुल वैसा ही है जैसे सिवाय इसके कि 'भाग' का जीवनकाल 'संपूर्ण' द्वारा नियंत्रित होता है। यह नियंत्रण प्रत्यक्ष या सकर्मक हो सकता है। अर्थात्, 'संपूर्ण' 'भाग' को बनाने या नष्ट करने के लिए प्रत्यक्ष ज़िम्मेदारी ले सकता है, या यह पहले से निर्मित भाग को स्वीकार कर सकता है, और बाद में इसे किसी अन्य को पूरा कर सकता है जो इसके लिए जिम्मेदारी लेता है।

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

Comments

इस परिभाषा का कितना अधिकार है? क्या यह यूएमएल मानक लेखकों द्वारा समर्थित है? मैं यह उपकरण द्वारा समर्थित है?

— रीयरियरपोस्ट

यह रॉबर्ट सी। मार्टिन है। मेरे लिए यह पर्याप्त अधिकार है :-)

— हेलिक जूल

Answer 6

जैसा कि दूसरों ने कहा, एक एसोसिएशन वस्तुओं के बीच एक संबंध है, एकत्रीकरण और संरचना एसोसिएशन के प्रकार हैं।

कार्यान्वयन के दृष्टिकोण से, संदर्भ द्वारा एक वर्ग सदस्य होने से एक एकत्रीकरण प्राप्त होता है । उदाहरण के लिए, यदि वर्ग A वर्ग B की एक वस्तु को एकत्रित करता है, तो आपके पास कुछ ऐसा होगा (C ++ में):

class A {
    B & element;
  // or B * element;
};

एकत्रीकरण का शब्दार्थ यह है कि जब कोई वस्तु A नष्ट हो जाती है, तो वह जिस B वस्तु को संचयित करता है वह अभी भी मौजूद रहेगी। रचना का उपयोग करते समय, आपके पास एक मजबूत संबंध होता है, आमतौर पर सदस्य को मूल्य द्वारा संग्रहीत करके :

class A {
    B element;
};

यहां, जब कोई वस्तु नष्ट हो जाती है, तो उसमें मौजूद B वस्तु भी नष्ट हो जाएगी। इसे प्राप्त करने का सबसे आसान तरीका सदस्य को मूल्य द्वारा संग्रहीत करना है, लेकिन आप कुछ स्मार्ट पॉइंटर का उपयोग भी कर सकते हैं, या सदस्य को विध्वंसक में हटा सकते हैं:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

महत्वपूर्ण बात यह है कि एक संरचना में, कंटेनर वस्तु है का मालिक है , एक निहित एकत्रीकरण में, यह जबकि संदर्भ देता है यह।

Comments

यह एकमात्र स्वीकृत उत्तर होना चाहिए। रचना आदिम प्रकारों को छोड़कर C # और Java में मौजूद नहीं है ... फिर भी आप उन भाषाओं के डेवलपर्स को "समझाते हुए" रचना को देखते हैं। रचना का अर्थ है एक वस्तु दूसरे में मौजूद है। जावा और C # में भी आप इसे नहीं कर सकते, सब कुछ ढेर पर है और आप इसे केवल पॉइंटर पकड़ते हैं, यह वास्तव में एग्रीगेशन रचना है। सी ++ रचना प्रदान करता है ..

— हर कोई

Answer 7

यह आश्चर्यजनक है कि तीन संबंध अवधारणाओं संघ , एकत्रीकरण और रचना के बीच अंतर के बारे में कितना भ्रम है ।

ध्यान दें कि शब्दों के एकत्रीकरण और संरचना का उपयोग C ++ समुदाय में किया गया है, संभवतः कुछ समय के लिए उन्हें एसोसिएशन के विशेष मामलों के रूप में परिभाषित किया गया है यूएमएल क्लास डायग्राम में ।

मुख्य समस्या व्यापक और चल रही गलतफहमी (यहां तक ​​कि विशेषज्ञ सॉफ्टवेयर डेवलपर्स के बीच) है कि रचना की अवधारणा पूरे और उसके हिस्सों के बीच एक जीवन-चक्र निर्भरता का अर्थ है कि भागों पूरे के बिना मौजूद नहीं हो सकते हैं, इस तथ्य की अनदेखी करते हुए कि वहाँ भी हैं गैर-साझा करने योग्य भागों के साथ भाग-पूरे-संघों के मामले जहां भागों को अलग किया जा सकता है, और पूरे के विनाश से बच सकता है।

जहाँ तक मैं देख सकता हूँ, इस भ्रम की दो जड़ें हैं:

1. C ++ समुदाय में, "एकत्रीकरण" शब्द का उपयोग एक वर्ग के अर्थ में एक अन्य स्वतंत्र वर्ग (देखें, जैसे, [1]) की वस्तुओं को संदर्भित करने के लिए एक विशेषता को परिभाषित करने के लिए किया गया था, जो कि यूएमएल क्लास डायग्राम में संघ की भावना है । शब्द "रचना" का उपयोग उन वर्गों के लिए किया गया था जो अपनी वस्तुओं के लिए घटक वस्तुओं को परिभाषित करते हैं, जैसे कि समग्र वस्तु के विनाश पर, इन घटक वस्तुओं को भी नष्ट किया जा रहा है।

2. यूएमएल कक्षा आरेखों में, "एकत्रीकरण" और "रचना" दोनों को अंश-पूर्ण संबंधों (जो लंबे समय से दर्शन में चर्चा की गई है) का प्रतिनिधित्व करने वाले संघों के विशेष मामलों के रूप में परिभाषित किया गया है । उनकी परिभाषाओं में, "एकत्रीकरण" और "रचना" के बीच का अंतर इस तथ्य पर आधारित है कि क्या यह दो या दो से अधिक के बीच के हिस्से को साझा करने की अनुमति देता है। वे "रचनाओं" को गैर-साझा करने योग्य (अनन्य) भागों के रूप में परिभाषित करते हैं, जबकि "एकत्रीकरण" उनके भागों को साझा कर सकते हैं। इसके अलावा, वे निम्नलिखित जैसे कुछ कहते हैं: बहुत बार, लेकिन सभी मामलों में नहीं, रचनाएं पूरे और उसके हिस्सों के बीच एक जीवन-चक्र निर्भरता के साथ आती हैं जैसे कि पूरे के बिना भाग मौजूद नहीं हो सकते।

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

नीचे सूचीबद्ध अप्रैल 2009 के SO प्रश्न का मेरा विस्तारित उत्तर भी देखें ।

और वह संपत्ति जिसे C ++ समुदाय में OOP वस्तुओं के बीच "संरचना" को परिभाषित करने के लिए ग्रहण किया गया था (और यह विश्वास अभी भी व्यापक रूप से आयोजित है): दो संबंधित वस्तुओं (समग्र और इसके घटक) के बीच रन-टाइम जीवन-चक्र निर्भरता, है "रचना" के लिए वास्तव में विशेषता नहीं है क्योंकि संदर्भात्मक अखंडता के कारण अन्य प्रकार के संघों में भी हमारी निर्भरता हो सकती है।

उदाहरण के लिए, "रचना" के लिए निम्नलिखित कोड पैटर्न एसओ उत्तर में प्रस्तावित किया गया था :

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

प्रतिवादी ने दावा किया कि यह "रचना" के लिए विशेषता होगी कि कोई अन्य वर्ग घटक को संदर्भ / पता नहीं कर सकता है। हालांकि, "रचना" के सभी संभावित मामलों के लिए यह निश्चित रूप से सच नहीं है। विशेष रूप से, एक कार के इंजन के मामले में, कार के निर्माता, संभवतः एक अन्य वर्ग की मदद से लागू किया जाता है, जब भी इसके साथ कोई समस्या होती है तो कार के मालिक से संपर्क करने में सक्षम होने के लिए इंजन को संदर्भित करना पड़ सकता है।

[१] http://www.learncpp.com/cpp-tutorial/103-aggregation/

परिशिष्ट - StackOverflow पर रचना बनाम एकत्रीकरण के बारे में बार-बार पूछे जाने वाले सवालों की अधूरी सूची

[ अप्रैल 2009 ]
एकत्रीकरण बनाम रचना [मुख्य रूप से राय के रूप में बंद]
[ अप्रैल २०० ९ ]
रचना और संघ संबंध के बीच अंतर क्या है?
[ मई 2009 ]
संघ, एकत्रीकरण और रचना के बीच अंतर
[ मई 2009 ]
रचना और एकत्रीकरण के बीच अंतर क्या है? [अनुलिपि]
[ अक्टूबर २०० ९ ]
एकत्रीकरण, रचना और निर्भरता में क्या अंतर है? [डुप्लिकेट के रूप में चिह्नित]
[ Nov 2010 ]
एसोसिएशन बनाम एकत्रीकरण [डुप्लिकेट के रूप में चिह्नित]
[अगस्त 2012 ]
जावा में एकत्रीकरण और संरचना के बीच कार्यान्वयन अंतर
[ फ़रवरी 2015 ]
यूएमएल - एसोसिएशन या एकत्रीकरण (सरल कोड स्निपेट)

Comments

बार-बार पूछे जाने वाले सवालों की अधूरी सूची के लिए upvote।

— जैको

Answer 8

संगति

एसोसिएशन दो वर्गों के बीच के संबंध का प्रतिनिधित्व करता है। यह यूनिडायरेक्शनल (एक तरीका) या द्विदिश (दो तरह से) हो सकता है

उदाहरण के लिए:

1. दिशाहीन

ग्राहक स्थानों के आदेश

2. द्विदिश

A, B से विवाहित है

B, A से विवाहित है

एकत्रीकरण

एकत्रीकरण एक प्रकार का जुड़ाव है। लेकिन विशिष्ट विशेषताओं के साथ। लेकिन एक बड़े "संपूर्ण" वर्ग में संबंध एक या अधिक छोटे "भागों" वर्गों में होता है। जाहिर तौर पर, एक छोटा "भाग" वर्ग "संपूर्ण" बड़े वर्ग का एक हिस्सा है। ।

उदाहरण के लिए:

क्लब के सदस्य हैं

एक क्लब ("संपूर्ण") कई क्लब सदस्यों ("भागों") से बना है। क्लब के बाहर के सदस्यों के लिए जीवन है। यदि क्लब ("संपूर्ण") मरना था, तो सदस्य ("भागों") इसके साथ नहीं मरेंगे। क्योंकि सदस्य कई क्लबों ("पूरे") से संबंधित हो सकते हैं।

रचना

यह एकत्रीकरण का एक मजबूत रूप है। "" "इसके" भागों "के निर्माण या विनाश के लिए जिम्मेदार है।"

उदाहरण के लिए:

एक स्कूल में विभाग हैं

इस मामले में स्कूल ("पूरे") को मरना था, विभाग ("भागों") इसके साथ मर जाएगा। क्योंकि प्रत्येक भाग केवल एक "संपूर्ण" से संबंधित हो सकता है।

Comments

एग्रिगेशन के मामले में। क्या मुझे class Club(){ _member = new Member } इसे संदर्भ के रूप में उपयोग या पारित करना चाहिए class Club(){ addMember(Member member) { this._member = member } }

— रोल करें

Answer 9

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

संगति

कक्षाओं के बीच स्थिर संबंध का वर्णन करने के लिए सबसे सार तरीका एसोसिएशन लिंक का उपयोग कर रहा है, जो बस बताता है कि दो वर्गों या अधिक के बीच किसी प्रकार का लिंक या निर्भरता है।

कमजोर संघ

क्लासए को क्लासबी से जोड़ा जा सकता है ताकि यह दिखाया जा सके कि इसके तरीकों में से एक में क्लासबी इंस्टेंस का पैरामीटर शामिल है, या क्लासबी के रिटर्न इंस्टेंस शामिल हैं।

मजबूत एसोसिएशन

क्लासबा को क्लासबी से भी जोड़ा जा सकता है ताकि यह दिखाया जा सके कि यह क्लासबी उदाहरण के लिए संदर्भ है।

एकत्रीकरण (साझा संघ)

ऐसे मामलों में जहां ClassA (पूरे) और ClassB (भाग) के बीच एक संबंध है, हम अधिक विशिष्ट हो सकते हैं और एसोसिएशन लिंक के बजाय एकत्रीकरण लिंक का उपयोग कर सकते हैं, यह दर्शाते हुए कि ClassB को एप्लिकेशन में अन्य वर्गों द्वारा भी एकत्र किया जा सकता है ( इसलिए एकत्रीकरण को साझा संघ के रूप में भी जाना जाता है)।

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

एकत्रीकरण बनाम एसोसिएशन संघ लिंक हर स्थिति में एकत्रीकरण लिंक को बदल सकता है, जबकि एकत्रीकरण उन स्थितियों में एसोसिएशन को प्रतिस्थापित नहीं कर सकता है, जहां कक्षाओं के बीच केवल एक 'कमजोर लिंक' है, अर्थात क्लासए में ऐसी विधि / एस है जिसमें क्लासबी का पैरामीटर होता है लेकिन क्लासए नहीं करता है। ClassB उदाहरण के लिए संदर्भ रखें।

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

रचना (साझा साझा नहीं)

हमें और अधिक विशिष्ट होना चाहिए और ऐसे मामलों में कंपोज़िशन लिंक का उपयोग करना चाहिए जहां क्लासए और क्लासबी के बीच के संबंध के अलावा - दोनों के बीच एक मजबूत जीवनचक्र निर्भरता है, जिसका अर्थ है कि जब क्लास को हटा दिया जाता है तो क्लासबी को भी परिणाम के रूप में हटा दिया जाता है

रचना लिंक से पता चलता है कि एक वर्ग (कंटेनर, पूरे) का अन्य वर्ग / भागों (भागों) पर अनन्य स्वामित्व है, जिसका अर्थ है कि कंटेनर वस्तु और उसके हिस्से एक माता-पिता / बच्चे के रिश्ते का निर्माण करते हैं।

संघटन और एकत्रीकरण के विपरीत, रचना संबंध का उपयोग करते समय, कंपोजिट क्लास कंपोज़िट क्लास के रिटर्न प्रकार या पैरामीटर प्रकार के रूप में प्रकट नहीं हो सकता है। इस प्रकार, निर्मित वर्ग में परिवर्तन शेष प्रणाली में नहीं फैल सकता है। नतीजतन, संरचना का उपयोग जटिलता बढ़ता है क्योंकि सिस्टम बढ़ता है।

मापने प्रणाली जटिलता

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

आप मेरे ब्लॉग पर और अधिक पढ़ सकते हैं: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

---

Comments

अच्छा उत्तर। 1) रचना उदाहरण के लिए प्रश्न: लेंग एंड हैंड (रचना) व्यक्ति। अगर मैं एक क्लास एनिमल और स्लीप बनाता हूँ तो स्लीप (एग्रीगेशन) पर्सन; नींद (पीड़ा) पशु। क्या यह सही है? 2)। हाथ रचना व्यक्ति: class Person() { private hand = new Hand }। स्लीप एग्रिगेशन पर्सन स्लीप में class Person() { private sleep = new Sleep }"नया" कुंजी का उपयोग करना मान्य है? या क्या मुझे इसे संदर्भ के रूप में पारित करना चाहिए क्योंकि एग्रीगेशन है? class Person() { private Sleep _sleep; public addSleep(Sleep sleep) { this._sleep = sleep} }

— रोल करें

Answer 10

रचना (यदि आप "संपूर्ण" को हटाते हैं, तो "भाग" को भी स्वचालित रूप से हटा दिया जाता है- "स्वामित्व")

• नई कक्षा के अंदर अपनी मौजूदा कक्षा की वस्तुएँ बनाएँ। इसे रचना कहा जाता है क्योंकि नया वर्ग मौजूदा वर्गों की वस्तुओं से बना होता है।

• आमतौर पर सामान्य सदस्य चर का उपयोग करें।

• यदि पॉकेट क्लास निर्माण / उपवर्गों के विनाश के लिए ज़िम्मेदारी / आवंटन को संभालता है, तो सूचक मानों का उपयोग कर सकते हैं।

सी ++ में रचना

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

उत्पादन

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

एकत्रीकरण (यदि आप "संपूर्ण" को हटाते हैं, तो "भाग" मौजूद हो सकता है - "कोई स्वामित्व नहीं")

• एक एकत्रीकरण एक विशिष्ट प्रकार की रचना है जहां जटिल वस्तु और उपविषयों के बीच कोई स्वामित्व निहित नहीं है। जब एक समुच्चय नष्ट हो जाता है, तो उप-खंड नष्ट नहीं होते हैं।

• आमतौर पर पॉइंटर वैरिएबल / रेफरेंस वैरिएबल का उपयोग करते हैं जो एक ऑब्जेक्ट को इंगित करता है जो कुल वर्ग के दायरे से बाहर रहता है

• संदर्भ मानों का उपयोग कर सकते हैं जो उस वस्तु को इंगित करते हैं जो समुच्चय वर्ग के दायरे से बाहर रहती है

• उपवर्गों को बनाने / नष्ट करने के लिए जिम्मेदार नहीं है

C ++ में एकत्रीकरण कोड

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

उत्पादन

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------

Comments

जिसने भी इस जवाब को वोट दिया है। क्या आप कृपया इसे मतदान करने का कारण बता सकते हैं?

— सौरभ राऊत

वास्तव में जो मुझे भ्रमित करता है, वह यह है कि, कई मामलों में, यह मालिक की चीज नहीं है, बल्कि यह वह चीज है जो मालिक के पास है। उदाहरण के लिए, कार में इंजन * टाइप पॉइंटर नहीं होता है, लेकिन इंजन वर्ग के पास उस कार को स्टोर करने के लिए एक कार प्रकार का सदस्य होता है जो इसके मालिक होते हैं। मैं इसे विशेष रूप से इस मामले में कक्षाओं के uml संबंध को नहीं समझता।

— डुडू

Answer 11

इन उत्तरों के साथ समस्या यह है कि वे आधी कहानी हैं: वे बताते हैं कि एकत्रीकरण और संरचना एसोसिएशन के रूप हैं, लेकिन वे यह नहीं कहते हैं कि क्या एसोसिएशन के लिए संभव है न तो उन में से एक हो।

मैं एसओ पर कई पदों के कुछ संक्षिप्त रीडिंग और कुछ यूएमएल डॉक्स के आधार पर इकट्ठा करता हूं कि क्लास एसोसिएशन के 4 मुख्य ठोस रूप हैं:

1. रचना: ए-कंपोजिट ऑफ ए बी; B A के बिना मौजूद नहीं है, जैसे घर में एक कमरा
2. एकत्रीकरण: ए में एक बी है; B, A के बिना कक्षा में एक छात्र की तरह मौजूद हो सकता है
3. निर्भरता: एक का उपयोग करता है-एक बी; ए और बी के बीच कोई जीवनचक्र निर्भरता नहीं है, जैसे विधि कॉल पैरामीटर, रिटर्न वैल्यू, या एक विधि कॉल के दौरान बनाई गई अस्थायी
4. सामान्यीकरण: ए-ए बी है

जब दो संस्थाओं के बीच एक संबंध इनमें से एक नहीं है, तो इसे केवल शब्द की सामान्य अर्थ में "एक संघ" कहा जा सकता है, और आगे अन्य तरीकों (नोट, स्टीरियोटाइप, आदि) का वर्णन किया जा सकता है।

मेरा अनुमान है कि "जेनेरिक एसोसिएशन" को मुख्य रूप से दो परिस्थितियों में उपयोग करने का इरादा है:

• जब किसी रिश्ते की बारीकियों पर अभी भी काम किया जा रहा है; आरेख में इस तरह के रिश्ते को जितनी जल्दी हो सके रूपांतरित किया जाना चाहिए कि यह वास्तव में क्या है / (अन्य 4 में से एक) होगा।
• जब कोई संबंध UML द्वारा पूर्वनिर्धारित उन 4 में से किसी से मेल नहीं खाता; "जेनेरिक" एसोसिएशन अभी भी आपको एक ऐसे रिश्ते का प्रतिनिधित्व करने का एक तरीका देता है जो "अन्य लोगों में से एक नहीं है", ताकि आप एक नोट के साथ एक गलत संबंध का उपयोग करके फंस न जाएं "यह वास्तव में एकत्रीकरण नहीं है, यह केवल यूएमएल है हमारे पास कोई अन्य प्रतीक नहीं है जिसका हम उपयोग कर सकते हैं "

Comments

यदि अन्य सभी विकल्पों को खारिज कर दिया जाता है तो आप वास्तव में एक सामान्य एसोसिएशन को कैसे लागू करेंगे? यदि A, B से बना नहीं है (B का मान A में है), A, B का एकत्रीकरण नहीं है (B का संदर्भ A में नहीं है), B को विरासत में मिला / प्राप्त नहीं है और न ही B का उपयोग रिटर्न, पैरामीटर या भीतर किया गया है A का फ़ंक्शन उपयोग, आप जो भी हो कोई संबंध नहीं है।

— डीन पी।

@DeanP यह समय के लिए सामान्य हो सकता है, और बाद में 4 में से एक में परिवर्तित हो जाएगा (तब यह लागू हो जाता है); या यह एक ऐसा संबंध हो सकता है जो 4 को फिट नहीं करता है जैसे कि आप एक एसोसिएशन चाहते हैं जिसका अर्थ है "जैसा दिखता है", एक सामान्य एसोसिएशन के बिना आपको 4 में से एक का उपयोग करने के लिए मजबूर किया जाएगा, इस प्रकार पाठक को भ्रमित करता है, जबकि यदि आप उपयोग करते हैं जेनेरिक आप संभवतः इसे एनोटेट करेंगे या यह बताएंगे कि यह क्या है, और एक नोट डाल दिया, और ज्यादातर लोग केवल नोट्स पढ़ते हैं यदि वे प्रतीक को समझते हैं;)

— ओलिवर

Answer 12

मुझे लगता है कि यह लिंक आपका होमवर्क करेगा: http://ootips.org/uml-hasa.html

उन शर्तों को समझने के लिए जिन्हें मुझे अपने शुरुआती प्रोग्रामिंग दिनों में एक उदाहरण याद है:

यदि आपके पास एक 'शतरंज बोर्ड' ऑब्जेक्ट है जिसमें 'बॉक्स' ऑब्जेक्ट्स हैं जो कि रचना है क्योंकि अगर 'शतरंज बोर्ड' को हटा दिया गया है तो बक्से के अब मौजूद होने का कोई कारण नहीं है।

आप एक 'वर्ग' वस्तु है कि एक 'रंग' वस्तु और वर्ग हटा हो जाता है 'रंग' वस्तु अभी भी मौजूद हो सकता है है, तो वह यह है कि एकत्रीकरण

वे दोनों संघ हैं , मुख्य अंतर वैचारिक है

Answer 13

रचना : यह वह जगह है जब आप एक वस्तु (स्कूल) को नष्ट कर देते हैं, तो दूसरी वस्तु (क्लासरूम) जो इसके लिए बाध्य होती है वह भी नष्ट हो जाएगी। वे दोनों स्वतंत्र रूप से मौजूद नहीं हो सकते।

एकत्रीकरण : यह उपर्युक्त ( Composition) संघ के ठीक विपरीत है, जहां एक बार आप किसी वस्तु को मारते हैं ( Company), दूसरी वस्तु ( Employees) जो उससे बंधी होती है, वह अपने आप मौजूद हो सकती है।

एसोसिएशन ।
रचना और एकत्रीकरण संघ के दो रूप हैं।

Comments

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

— अलेक्जेंडर

हाँ, बिल्कुल। सहमत हो ... +1 धन्यवाद @AlexPopov इसे इंगित करने के लिए। :)

— कुलसंगर

Answer 14

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

Answer 15

एक बहुत ही सरल वाक्य में:
एकत्रीकरण और रचना संघ के सबसेट हैं।

• A उपयोग B -> यह एक एकत्रीकरण है

• A की आवश्यकता B -> रचना है।

और अधिक पढ़ें यहाँ ।

Answer 16

मैं बताना चाहता हूं कि रेल में तीन पद कैसे लागू होते हैं। ActiveRecord दो मॉडलों के बीच किसी भी प्रकार के संबंध को कहता है a association। ActiveRecord से संबंधित दस्तावेज़ीकरण या लेख पढ़ते समय, किसी को बहुत बार शब्द compositionऔर नहीं मिलेंगे aggregation। एक एसोसिएशन क्लास मैक्रोज़ को क्लास के बॉडी में जोड़कर बनाया जाता है। इन मैक्रो में से कुछ हैं belongs_to, has_one,has_many आदि ..

यदि हम compositionया स्थापित करना चाहते हैं aggregation, तो हमें belongs_toस्वामित्व वाले मॉडल (जिसे बच्चा भी कहा जाता है) और has_oneया has_manyमालिक मॉडल (जिसे माता-पिता भी कहा जाता है) में जोड़ना होगा । वेदर हम सेट करते हैं compositionया aggregationउन विकल्पों पर निर्भर करते हैं जिन्हें हम belongs_toचाइल्ड मॉडल में कॉल करने के लिए पास करते हैं । रेल 5 से पहले, belongs_toबिना किसी विकल्प के सेटिंग करने aggregationसे बच्चे का अस्तित्व बिना माता-पिता के हो सकता है। यदि हम चाहते थे composition, तो हमें विकल्प जोड़कर इसे स्पष्ट रूप से घोषित करना चाहिए required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

रेल 5 में यह बदल गया था। अब, एक belongs_toएसोसिएशन की घोषणा compositionडिफ़ॉल्ट रूप से बनाता है , बच्चा बिना माता-पिता के मौजूद नहीं हो सकता है। तो उपरोक्त उदाहरण को फिर से लिखा जा सकता है:

class Room < ApplicationRecord
  belongs_to :house
end

यदि हम बच्चे को बिना माता-पिता के मौजूद होने की अनुमति देना चाहते हैं, तो हमें विकल्प के माध्यम से इसे स्पष्ट रूप से घोषित करने की आवश्यकता है optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

Answer 17

प्रेषक: रेमो एच। जैनसेन की पुस्तक “शुरुआती प्रतिक्रिया: लर्निंग टाइपस्क्रिप्ट 2.x - दूसरा संस्करण”:

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

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

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

Answer 18

एसोसिएशन दो अलग-अलग वर्गों के बीच एक संबंध है और एसोसिएशन किसी भी प्रकार का हो सकता है एक से एक, एक से हो सकता है आदि। यह दो पूरी तरह से अलग संस्थाओं में शामिल होता है।

एकत्रीकरण संघ का एक विशेष रूप है, जो कि वर्गों (या संस्थाओं) के बीच एक तरह से अप्रत्यक्ष रूप से संबंध है, उदाहरण के लिए वॉलेट और मनी कक्षाएं। वॉलेट में पैसा है लेकिन पैसे के लिए वॉलेट जरूरी नहीं है इसलिए यह एक दिशात्मक संबंध है। इस रिश्ते में दोनों प्रविष्टियाँ जीवित रह सकती हैं यदि अन्य एक समाप्त होता है। हमारे उदाहरण में अगर वॉलेट क्लास मौजूद नहीं है, तो इसका मतलब यह नहीं है कि मनी क्लास मौजूद नहीं है।

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

Answer 19

https://www.linkedin.com/pulse/types-relationships-object-oriented-programming-oop-sarah-el-dawody/

रचना: एक "पार्ट-ऑफ" रिलेशनशिप है।

उदाहरण के लिए "इंजन कार का हिस्सा है", "दिल शरीर का हिस्सा है"।

एसोसिएशन: एक "है" एक प्रकार का संबंध है

उदाहरण के लिए, मान लें कि हमारे पास दो वर्ग हैं, तो इन दो वर्गों को "एक" संबंध कहा जाता है यदि ये दोनों संस्थाएं एक-दूसरे की वस्तु को किसी काम के लिए साझा करती हैं और एक ही समय में वे एक-दूसरे की निर्भरता के बिना मौजूद हो सकती हैं या दोनों की अपनी खुद का जीवनकाल।

उपरोक्त उदाहरण कर्मचारी और प्रबंधक वर्ग दोनों के एक-दूसरे की वस्तु का उपयोग करने और अपने स्वयं के स्वतंत्र जीवन चक्र दोनों के कारण संघ संबंध दर्शाता है।

एकत्रीकरण: "ए-ए" संबंध पर आधारित है और यह \\ एसोसिएशन का एक विशेष रूप है

उदाहरण के लिए, "छात्र" और "पता"। प्रत्येक छात्र के पास एक पता होना चाहिए ताकि छात्र वर्ग और पता वर्ग के बीच का संबंध "हस-ए" प्रकार का संबंध होगा लेकिन इसके विपरीत सच नहीं है।