यूएमएल में रचना और एकत्रीकरण के बीच अंतर को समझने में मुझे कठिन समय मिला है। क्या कोई मुझे उनके बीच एक अच्छी तुलना और इसके विपरीत की पेशकश कर सकता है? मैं कोड और / या लघु सॉफ्टवेयर / कोड उदाहरण देखने के लिए उनके बीच के अंतर को पहचानना सीखना पसंद करूंगा।
संपादित करें: मेरे द्वारा पूछे जाने वाले कारण का एक उल्टा प्रलेखन गतिविधि के कारण है जो हम काम कर रहे हैं। हमने कोड लिखा है, लेकिन हमें कोड के लिए वापस जाने और वर्ग आरेख बनाने की आवश्यकता है। हम बस संघों को ठीक से पकड़ना चाहते हैं।
जवाबों:
एकत्रीकरण और रचना के बीच का अंतर संदर्भ पर निर्भर करता है।
एक अन्य उत्तर में उल्लेखित कार उदाहरण लें - हां, यह सच है कि एक कार निकास "अपने दम पर" खड़ा हो सकता है इसलिए कार के साथ रचना में नहीं हो सकता है - लेकिन यह आवेदन पर निर्भर करता है। यदि आप एक ऐसे अनुप्रयोग का निर्माण करते हैं जो वास्तव में स्टैंड अलोन कार एग्जॉस्ट (कार शॉप मैनेजमेंट एप्लिकेशन?) से निपटना है, तो एकत्रीकरण आपकी पसंद होगा। लेकिन अगर यह एक सरल रेसिंग गेम है और कार का निकास केवल कार के हिस्से के रूप में कार्य करता है - ठीक है, तो रचना काफी ठीक होगी।
शतरंज का बोर्ड? एक ही समस्या है। एक शतरंज का टुकड़ा शतरंज बोर्ड के बिना केवल कुछ अनुप्रयोगों में मौजूद नहीं है। दूसरों में (एक खिलौना निर्माता की तरह), एक शतरंज टुकड़ा निश्चित रूप से एक शतरंज बोर्ड में नहीं बनाया जा सकता है।
अपनी पसंदीदा प्रोग्रामिंग भाषा में रचना / एकत्रीकरण का प्रयास करते समय चीजें और भी बदतर हो जाती हैं। कुछ भाषाओं में, अंतर को नोटिस करना आसान हो सकता है ("संदर्भ" बनाम "मूल्य से", जब चीजें सरल होती हैं) लेकिन दूसरों में बिल्कुल भी मौजूद नहीं हो सकती हैं।
और सलाह का एक आखिरी शब्द? इस मुद्दे पर बहुत समय बर्बाद मत करो। यह इसके लायक नहीं है। व्यवहार में भेद शायद ही उपयोगी है (भले ही आपके पास पूरी तरह से स्पष्ट "रचना" हो, आप अभी भी तकनीकी कारणों से एक एकत्रीकरण के रूप में इसे लागू करना चाह सकते हैं - उदाहरण के लिए, कैशिंग)।
निर्धारित नियम के रूप में:
class Person {
private Heart heart;
private List<Hand> hands;
}
class City {
private List<Tree> trees;
private List<Car> cars
}रचना (व्यक्ति, हृदय, हाथ) में, "उप वस्तुओं" (हृदय, हाथ) को नष्ट कर दिया जाएगा जैसे ही व्यक्ति नष्ट हो जाएगा।
एकत्रीकरण में (सिटी, ट्री, कार) "सब ऑब्जेक्ट्स" (ट्री, कार) तब नष्ट नहीं होगा जब सिटी नष्ट हो जाएगी।
लब्बोलुआब यह है कि, संरचना आपसी अस्तित्व पर जोर देती है, और एकत्रीकरण में, इस संपत्ति की आवश्यकता नहीं है।
रचना और एकत्रीकरण संघों के प्रकार हैं। वे बहुत निकट से संबंधित हैं और प्रोग्रामिंग के मामले में दोनों के बीच बहुत अंतर नहीं है। मैं जावा कोड के उदाहरणों से इन दोनों के बीच के अंतर को समझाने की कोशिश करूंगा
एकत्रीकरण : वस्तु दूसरे के बाहर मौजूद है, बाहर बनाई गई है, इसलिए इसे कंस्ट्रक्टर को एक तर्क (उदाहरण के लिए) के रूप में पारित किया जाता है। Ex: लोग - कार। कार एक अलग संदर्भ में बनाई गई है और फिर एक व्यक्ति संपत्ति बन जाती है।
// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer(HttpListener listener, RequestProcessor processor) {
this.listener = listener;
this.processor = processor;
}
}रचना : वस्तु केवल मौजूद है, या केवल दूसरे के अंदर, दूसरे के हिस्से के रूप में समझ में आता है। Ex: लोग - दिल। आप एक दिल नहीं बनाते हैं और फिर इसे एक व्यक्ति को पास करते हैं। इसके बजाय, दिल बनाया जाता है जब मानव बनाया जाता है।
// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
private HttpListener listener;
private RequestProcessor processor;
public WebServer() {
this.listener = new HttpListener(80);
this.processor = new RequestProcessor(“/www/root”);
}
}उदाहरण के साथ यहां बताया गया है कि एकत्रीकरण और संरचना के बीच अंतर
रचना का अर्थ है कि बच्चे की वस्तुओं को माता-पिता के साथ जीवनकाल साझा करना है। एकत्रीकरण नहीं करता है। उदाहरण के लिए, एक शतरंज बोर्ड शतरंज वर्गों से बना है - शतरंज वर्ग वास्तव में बोर्ड के बिना मौजूद नहीं है। हालांकि, एक कार भागों का एक एकत्रीकरण है - एक कार निकास अभी भी एक कार निकास है यदि यह समय पर कार का हिस्सा नहीं है।
मैंने जो उदाहरण सीखा वह हाथ की उंगलियां थीं। आपका हाथ उंगलियों से बना है। यह उनका मालिक है। हाथ मर जाता है, तो उंगलियां मर जाती हैं। आप उंगलियों को "एकत्रित" नहीं कर सकते। आप बस अतिरिक्त उंगलियों को पकड़ नहीं सकते हैं और उन्हें अपनी इच्छा से संलग्न कर सकते हैं।
एक डिजाइन के दृष्टिकोण से यहाँ मूल्य, अक्सर एक और पोस्टर के रूप में ऑब्जेक्ट जीवन काल से संबंधित है। कहते हैं कि आपके पास एक ग्राहक है और उनके पास एक खाता है। वह खाता ग्राहक की एक "रचना" वस्तु है (कम से कम, अधिकांश संदर्भों में मैं सोच सकता हूं)। यदि आप ग्राहक को हटाते हैं, तो खाते का अपना कोई मूल्य नहीं है, इसलिए इसे भी हटा दिया जाएगा। ऑब्जेक्ट निर्माण पर रिवर्स अक्सर सही होता है। चूंकि एक खाते का केवल ग्राहक के संदर्भ में अर्थ होता है, आपके पास ग्राहक निर्माण के हिस्से के रूप में खाता निर्माण होगा (या, यदि आप इसे आलस्य करते हैं, तो यह कुछ ग्राहक लेनदेन का हिस्सा होगा)।
यह उन वस्तुओं के बारे में सोचने के लिए डिज़ाइन में उपयोगी है जो अन्य वस्तुओं बनाम खुद को बनाते हैं (जो केवल अन्य वस्तुओं को संदर्भित करते हैं)। यह निर्धारित करने में मदद कर सकता है कि वस्तु निर्माण / सफाई / अपडेट के लिए जिम्मेदारी कहां है।
जहां तक कोड में है, यह बताना मुश्किल है। कोड में अधिकांश सब एक वस्तु संदर्भ है, इसलिए यह स्पष्ट नहीं हो सकता है कि संदर्भित वस्तु की रचना (स्वामित्व) या एकत्र की गई है या नहीं।
यह आश्चर्यजनक है कि भाग-पूरे - संघ अवधारणाओं के एकत्रीकरण और रचना के बीच के अंतर के बारे में कितना भ्रम है । मुख्य समस्या व्यापक रूप से गलतफहमी है (यहां तक कि विशेषज्ञ सॉफ्टवेयर डेवलपर्स के बीच और यूएमएल के लेखकों के बीच) कि रचना की अवधारणा पूरे और उसके हिस्सों के बीच एक जीवन-चक्र निर्भरता का अर्थ है जैसे कि भागों पूरे के बिना मौजूद नहीं हो सकते। लेकिन यह दृष्टिकोण इस तथ्य को नजरअंदाज करता है कि गैर-साझाकरण वाले हिस्सों के साथ भाग-पूरे-संघों के मामले भी हैं जहां भागों को अलग किया जा सकता है, और पूरे के विनाश से बच सकता है।
यूएमएल विनिर्देश दस्तावेज में, "रचना" शब्द की परिभाषा हमेशा गैर-साझा करने योग्य भागों को निहित करती है, लेकिन यह स्पष्ट नहीं किया गया है कि "रचना" की परिभाषित विशेषता क्या है, और केवल एक वैकल्पिक विशेषता क्या है। यहां तक कि नए संस्करण (2015 तक) में, यूएमएल 2.5, "रचना" शब्द की परिभाषा में सुधार करने के प्रयास के बाद भी, यह अभी भी अस्पष्ट है और गैर-के साथ भाग-पूरे-संघों को मॉडल करने के लिए कोई मार्गदर्शन प्रदान नहीं करता है। उन हिस्सों को जहां से अलग किया जा सकता है, बचना चाहिए और नष्ट होने से बच जाता है, पूरे उस मामले के विपरीत जहां भागों को अलग नहीं किया जा सकता है और पूरे के साथ नष्ट हो जाते हैं। वे कहते हैं
यदि किसी कंपोज़िट ऑब्जेक्ट को हटा दिया जाता है, तो उसके सभी भाग इंस्टेंस जो ऑब्जेक्ट हैं, उसके साथ हटा दिए जाते हैं।
लेकिन साथ ही वे यह भी कहते हैं
कंपोज़िट ऑब्जेक्ट डिलीट होने से पहले एक पार्ट ऑब्जेक्ट को किसी कंपोज़िट ऑब्जेक्ट से हटाया जा सकता है, और इस तरह कंपोज़िट ऑब्जेक्ट के हिस्से के रूप में डिलीट नहीं किया जा सकता है।
यह भ्रम यूएमएल परिभाषा की अपूर्णता को इंगित करता है, जो घटकों और कंपोजिट के बीच जीवन चक्र निर्भरता के लिए जिम्मेदार नहीं है। इसलिए यह समझना महत्वपूर्ण है कि UML परिभाषा को किस प्रकार यूएमएल स्टीरियोटाइप के लिए बढ़ाया जा सकता है << अविभाज्य >> रचनाओं के लिए जहां घटकों को उनके समग्र से अलग नहीं किया जा सकता है, और इस प्रकार, जब भी उनका समग्र नष्ट हो जाता है, तब उन्हें नष्ट करना होगा।
जैसा कि मार्टिन फाउलर ने समझाया है , रचना को चिह्नित करने के लिए मुख्य मुद्दा यह है कि "एक वस्तु केवल एक रचना संबंध का हिस्सा हो सकती है"। यह भी उत्कृष्ट ब्लॉग पोस्ट UML संरचना बनाम एकत्रीकरण बनाम एसोसिएशन गेर्ट बेलेकेंस द्वारा समझाया गया है । किसी रचना की इस परिभाषित विशेषता ( विशेष , या गैर-श्रुत , भागों) को परिभाषित करने के अलावा , एक रचना समग्र और उसके घटकों के बीच एक जीवन-चक्र निर्भरता के साथ भी आ सकती है। वास्तव में, इस तरह की निर्भरताएं दो प्रकार की होती हैं:
Personऔर Heartनीचे चित्र में दिखाया गया है। एक दिल या तो नष्ट हो जाता है या किसी अन्य व्यक्ति को प्रत्यारोपित किया जाता है, जब उसके मालिक की मृत्यु हो गई हो।Personऔर के बीच की रचना है Brain।
सारांश में, जीवन-चक्र निर्भरता केवल रचना के विशिष्ट मामलों पर लागू होती है, लेकिन सामान्य रूप से नहीं, इसलिए वे एक परिभाषित विशेषता नहीं हैं।
यूएमएल कल्पना में कहा गया है: "समग्र उदाहरण हटाए जाने से पहले एक हिस्से को समग्र उदाहरण से हटाया जा सकता है, और इस प्रकार समग्र उदाहरण के भाग के रूप में हटाया नहीं जा सकता है।" एक Car- Engineरचना के उदाहरण में , जैसा कि निम्नलिखित चित्र में दिखाया गया है, यह स्पष्ट रूप से मामला है कि कार के नष्ट होने से पहले इंजन को कार से अलग किया जा सकता है, इस स्थिति में इंजन नष्ट नहीं होता है और इसका पुन: उपयोग किया जा सकता है। यह रचना रेखा के संयुक्त पक्ष में शून्य या एक गुणा से निहित है ।
कंपोजिशन के अंत में कंपोजिशन के अंत की बहुलता या तो 1 या 0..1 होती है, इस तथ्य पर निर्भर करता है कि कंपोनेंट्स में कंपोजिट अनिवार्य है (कंपोजिट से जुड़ा होना चाहिए) या नहीं। यदि घटक अविभाज्य हैं , तो इसका मतलब है कि उनके पास एक अनिवार्य समग्र है।
एक एकत्रीकरण भाग-पूरे-संबंध के इच्छित अर्थ के साथ जुड़ाव का एक और विशेष रूप है, जहाँ एक पूर्ण के हिस्सों को अन्य पूर्ण के साथ साझा किया जा सकता है। उदाहरण के लिए, हम वर्गों के बीच एक एकत्रीकरण मॉडल कर सकते हैं DegreeProgramऔर Courseके रूप में निम्नलिखित चित्र में दिखाया गया, क्योंकि एक कोर्स एक डिग्री कार्यक्रम का हिस्सा है और एक कोर्स (दो या अधिक डिग्री कार्यक्रमों के बीच साझा किया जा सकता है जैसे एक इंजीनियरिंग की डिग्री एक सी साझा कर सकता कंप्यूटर साइंस की डिग्री के साथ प्रोग्रामिंग कोर्स)।
हालांकि, साझा करने योग्य भागों के साथ एकत्रीकरण की अवधारणा का वास्तव में बहुत मतलब नहीं है, इसलिए इसका कार्यान्वयन पर कोई प्रभाव नहीं पड़ता है और कई डेवलपर्स इसलिए अपने वर्ग आरेखों में सफेद हीरे का उपयोग नहीं करना पसंद करते हैं, लेकिन सिर्फ एक सादे संघ का मॉडल बनाते हैं बजाय। यूएमएल कल्पना कहती है: "साझा एकत्रीकरण का सटीक शब्दार्थ आवेदन क्षेत्र और मॉडलर द्वारा भिन्न होता है"।
एक समग्र संघ के अंत की बहुलता पूरे पक्ष में किसी भी संख्या (*) के रूप में हो सकती है क्योंकि एक हिस्सा किसी भी संख्या के साथ हो सकता है या साझा किया जा सकता है ।
कोड शब्दों में, रचना आमतौर पर बताती है कि घटक * के उदाहरणों को बनाने के लिए युक्त वस्तु जिम्मेदार है, और युक्त वस्तु इसके लिए केवल लंबे समय तक जीवित संदर्भ रखती है। तो अगर माता-पिता वस्तु को डी-रेफर किया जाता है और कचरा एकत्र किया जाता है, तो बच्चा होगा।
तो यह कोड ...
Class Order
private Collection<LineItem> items;
...
void addOrderLine(Item sku, int quantity){
items.add(new LineItem(sku, quantity));
}
}पता चलता है कि लाइन इटेम ऑर्डर का एक घटक है - लाइनटाइम्स का उनके युक्त ऑर्डर के बाहर कोई अस्तित्व नहीं है। लेकिन आइटम ऑब्जेक्ट का निर्माण क्रम में नहीं किया गया है - वे आवश्यकतानुसार पारित किए जाते हैं, और मौजूद रहते हैं, भले ही दुकान के पास कोई आदेश न हो। इसलिए वे घटकों के बजाय जुड़े हुए हैं।
* nb कंटेनर घटक को अस्थिर करने के लिए जिम्मेदार है , लेकिन यह वास्तव में नया नहीं कह सकता है ... () खुद - यह जावा होने के नाते, आमतौर पर पहले से गुजरने के लिए एक कारखाना या दो है!
अन्य उत्तरों में प्रदान की गई वैचारिक चित्रण उपयोगी हैं, लेकिन मैं एक और बिंदु साझा करना चाहता हूं जो मुझे उपयोगी लगा है।
मैंने कोड जनरेशन के लिए UML से कुछ माइलेज प्राप्त किया है, रिलेशनल डेटाबेस के लिए सोर्स कोड या DDL के लिए। वहां, मैंने यह इंगित करने के लिए कि तालिका में एक गैर-अशक्त विदेशी कुंजी (डेटाबेस में), और एक गैर-अशक्त "माता-पिता" (और अक्सर "अंतिम") ऑब्जेक्ट है, रचना का उपयोग किया है। मैं एकत्रीकरण का उपयोग करता हूं जहां मैं एक "अनाथ" के रूप में मौजूद होने में सक्षम होने के लिए एक रिकॉर्ड या वस्तु का इरादा रखता हूं, किसी भी मूल वस्तु से जुड़ा नहीं है, या एक अलग मूल वस्तु द्वारा "अपनाया" जा सकता है।
दूसरे शब्दों में, मैंने मॉडल के लिए कोड लिखते समय आवश्यक कुछ अतिरिक्त बाधाओं को लागू करने के लिए शॉर्टहैंड के रूप में रचना संकेतन का उपयोग किया है।
उदाहरण जो मुझे पसंद है: रचना: पानी एक तालाब का एक हिस्सा है । (तालाब पानी की एक संरचना है।) एकत्रीकरण: तालाब है बतख और मछली हैं (तालाब बतख और मछली एकत्र करते हैं)
जैसा कि आप देख सकते हैं कि मैंने "पार्ट-ऑफ" और "है" बोल्ड किया है, क्योंकि ये 2 वाक्यांश आमतौर पर इंगित कर सकते हैं कि कक्षाओं के बीच किस तरह का कनेक्शन मौजूद है।
लेकिन जैसा कि दूसरों द्वारा बताया गया है, कई बार कि क्या कनेक्शन एक रचना है या एक एकत्रीकरण आवेदन पर निर्भर करता है।
समग्र संबंध और समग्र संबंध के बीच अंतर करना बहुत मुश्किल है, लेकिन मैं कुछ उदाहरण लेने जा रहा हूं, हमारे पास एक घर और कमरे हैं, यहां हमारा एक समग्र संबंध है, कमरा यह घर का एक हिस्सा है, और कमरे का जीवन शुरू हो गया है घर के जीवन के साथ और खत्म हो जाएगा जब घर का जीवन खत्म हो जाएगा, कमरा यह घर का एक हिस्सा है, हम देश और राजधानी, पुस्तक और पृष्ठों की तरह रचना के बारे में बात करते हैं। समग्र संबंध उदाहरण के लिए, टीम और खिलाड़ियों को लें, खिलाड़ी टीम के बिना मौजूद हो सकता है, और टीम खिलाड़ियों का एक समूह है, और टीम जीवन से पहले खिलाड़ी का जीवन शुरू हो सकता है, अगर हम प्रोग्रामिंग के बारे में बात करते हैं, तो हम खिलाड़ी बना सकते हैं और हम टीम बनाने के बाद, लेकिन रचना संख्या के लिए, हम घर के अंदर कमरे का निर्माण करते हैं। रचना ----> समग्र | रचना | एकत्रीकरण -------> समूह | तत्त्व
शर्तें तय करते हैं। एकत्रीकरण यूएमएल मानक में एक मेटाटर्म है, और इसका अर्थ है बीओटीएच रचना और साझा एकत्रीकरण, जिसका नाम साझा है । अक्सर इसे गलत तरीके से "एकत्रीकरण" नाम दिया जाता है। यह BAD है, रचना के लिए एक एकत्रीकरण भी है। जैसा कि मैं समझता हूं, आपका मतलब "साझा" है।
UML मानक से आगे:
सम्मिश्र - इंगित करता है कि संपत्ति को समग्र रूप से संयोजित किया गया है, अर्थात, मिश्रित वस्तु की रचना (ऑब्जेक्ट) के अस्तित्व और भंडारण के लिए जिम्मेदारी है।
अतः, कैथेड्रस एसोसिएशन के लिए विश्वविद्यालय एक रचना है, क्योंकि कैथेड्रा विश्वविद्यालय (IMHO) से बाहर नहीं है
साझा एकत्रीकरण का सटीक शब्दार्थ आवेदन क्षेत्र और मॉडलर द्वारा भिन्न होता है।
यानी, अन्य सभी संघों को साझा एकत्रीकरण के रूप में तैयार किया जा सकता है, यदि आप केवल आपके या किसी और के कुछ सिद्धांतों का पालन कर रहे हैं। इसके अलावा देखने के लिए यहाँ ।
मानव शरीर के अंगों जैसे किडनी, लिवर, मस्तिष्क पर विचार करें। यदि हम यहां रचना और एकत्रीकरण की अवधारणा को मानचित्रित करने का प्रयास करते हैं, तो यह निम्नानुसार होगा:
किडनी और लीवर की तरह शरीर के अंगों के प्रत्यारोपण के आगमन से पहले, ये दो शरीर के अंग मानव शरीर के साथ संरचना में थे और मानव शरीर के साथ अलगाव नहीं हो सकते।
लेकिन शरीर के अंग प्रत्यारोपण के आगमन के बाद, उन्हें दूसरे मानव शरीर में प्रत्यारोपित किया जा सकता है, इसलिए ये अंग मानव शरीर के साथ एकत्र होते हैं क्योंकि मानव शरीर के साथ अलगाव में उनका अस्तित्व अब संभव है।