การรวมเทียบกับองค์ประกอบ [ปิด]

ฉันมีช่วงเวลาที่ยากลำบากในการทำความเข้าใจความแตกต่างระหว่างองค์ประกอบและการรวมใน UML ใครช่วยเสนอข้อเปรียบเทียบและความแตกต่างที่ดีให้ฉันได้ไหม ฉันชอบที่จะเรียนรู้ที่จะตระหนักถึงความแตกต่างระหว่างสิ่งเหล่านี้ในรหัสและ / หรือเพื่อดูตัวอย่างซอฟต์แวร์ / โค้ดสั้น ๆ

แก้ไข: สาเหตุส่วนหนึ่งที่ฉันถามเป็นเพราะกิจกรรมการจัดทำเอกสารย้อนกลับที่เรากำลังทำในที่ทำงาน เราเขียนโค้ดแล้ว แต่เราต้องกลับไปสร้างคลาสไดอะแกรมสำหรับโค้ด เราต้องการจับการเชื่อมโยงอย่างเหมาะสม

ความแตกต่างระหว่างการรวมและองค์ประกอบขึ้นอยู่กับบริบท

ยกตัวอย่างรถยนต์ที่กล่าวถึงในคำตอบอื่น - ใช่เป็นความจริงที่ท่อไอเสียรถยนต์สามารถยืนได้ "ด้วยตัวมันเอง" ดังนั้นอาจไม่ได้อยู่ในองค์ประกอบของรถ - แต่ขึ้นอยู่กับการใช้งาน หากคุณสร้างแอปพลิเคชันที่ต้องจัดการกับท่อไอเสียรถยนต์แบบแยกส่วน (แอปพลิเคชันการจัดการร้านขายรถยนต์?) การรวมจะเป็นทางเลือกของคุณ แต่ถ้านี่เป็นเกมแข่งรถที่เรียบง่ายและท่อไอเสียของรถทำหน้าที่เป็นส่วนหนึ่งของรถเท่านั้น - องค์ประกอบก็จะค่อนข้างดี

กระดานหมากรุก? ปัญหาเดียวกัน. ไม่มีตัวหมากรุกหากไม่มีกระดานหมากรุกในบางแอปพลิเคชันเท่านั้น ในคนอื่น ๆ (เช่นเดียวกับผู้ผลิตของเล่น) ตัวหมากรุกไม่สามารถประกอบเป็นกระดานหมากรุกได้

สิ่งต่างๆเลวร้ายยิ่งขึ้นเมื่อพยายามจับคู่องค์ประกอบ / การรวมเข้ากับภาษาโปรแกรมที่คุณชื่นชอบ ในบางภาษาความแตกต่างสามารถสังเกตเห็นได้ง่ายขึ้น ("โดยอ้างอิง" เทียบกับ "ตามค่า" เมื่อสิ่งต่างๆเรียบง่าย) แต่ในภาษาอื่น ๆ อาจไม่มีอยู่เลย

และคำแนะนำคำสุดท้าย? อย่าเสียเวลากับปัญหานี้มากเกินไป มันไม่คุ้มค่า ความแตกต่างแทบไม่มีประโยชน์ในทางปฏิบัติ (แม้ว่าคุณจะมี "องค์ประกอบ" ที่ชัดเจนทั้งหมด แต่คุณอาจยังต้องการใช้มันเป็นการรวมเนื่องจากเหตุผลทางเทคนิคเช่นการแคช)

ตามหลักทั่วไป:

class Person {
    private Heart heart;
    private List<Hand> hands;
}

class City {
    private List<Tree> trees;
    private List<Car> cars
}

ในองค์ประกอบ (บุคคลหัวใจมือ) "วัตถุย่อย" (หัวใจมือ) จะถูกทำลายทันทีที่บุคคลถูกทำลาย

ในการรวม (เมืองต้นไม้รถ) "วัตถุย่อย" (ต้นไม้รถ) จะไม่ถูกทำลายเมื่อเมืองถูกทำลาย

บรรทัดล่างคือองค์ประกอบเน้นการดำรงอยู่ร่วมกันและในการรวมกันคุณสมบัตินี้ไม่จำเป็นต้องใช้

องค์ประกอบและการรวมเป็นประเภทของการเชื่อมโยง พวกเขามีความเกี่ยวข้องอย่างใกล้ชิดและในแง่ของการเขียนโปรแกรมดูเหมือนว่าจะไม่มีความแตกต่างระหว่างสองอย่างนี้มากนัก ฉันจะพยายามอธิบายความแตกต่างระหว่างสองสิ่งนี้ด้วยตัวอย่างโค้ด java

การรวม : วัตถุมีอยู่นอกวัตถุอื่น ๆ ถูกสร้างขึ้นภายนอกดังนั้นจึงถูกส่งผ่านเป็นอาร์กิวเมนต์ (ตัวอย่าง) ไปยังตัวสร้าง เช่นคน - รถ รถถูกสร้างขึ้นในบริบทที่แตกต่างจากนั้นจึงกลายเป็นทรัพย์สินของบุคคล

// 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;
  }
}

องค์ประกอบ : วัตถุมีอยู่เพียงอย่างเดียวหรือมีความหมายเท่านั้นภายในอีกชิ้นเป็นส่วนหนึ่งของอีกชิ้นหนึ่ง เช่นคน - หัวใจ คุณไม่สร้างหัวใจแล้วส่งต่อให้คน ๆ หนึ่ง แต่หัวใจถูกสร้างขึ้นเมื่อมนุษย์ถูกสร้างขึ้น

// 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”);
  }
}

อธิบายที่นี่พร้อมตัวอย่างความแตกต่างระหว่างการรวมและองค์ประกอบ

องค์ประกอบหมายความว่าวัตถุลูกมีอายุการใช้งานร่วมกับผู้ปกครอง การรวมไม่ได้ ตัวอย่างเช่นกระดานหมากรุกประกอบด้วยสี่เหลี่ยมหมากรุก - สี่เหลี่ยมหมากรุกไม่มีอยู่จริงหากไม่มีกระดาน อย่างไรก็ตามรถยนต์คือการรวมกันของชิ้นส่วน - ท่อไอเสียรถยนต์ยังคงเป็นท่อไอเสียของรถยนต์หากไม่ใช่ส่วนหนึ่งของรถยนต์

ตัวอย่างที่ฉันเรียนรู้คือการใช้นิ้วต่อมือ มือของคุณประกอบด้วยนิ้วมือ มันเป็นเจ้าของพวกเขา ถ้ามือตายนิ้วก็ตาย คุณไม่สามารถ "รวม" นิ้วได้ คุณไม่สามารถเพียงแค่จับนิ้วพิเศษแล้วแนบและถอดออกจากมือของคุณได้ตามต้องการ

มูลค่าที่นี่จากมุมมองการออกแบบมักเกี่ยวข้องกับอายุการใช้งานของวัตถุตามที่ผู้โพสต์อื่นกล่าวไว้ สมมติว่าคุณมีลูกค้าและมีบัญชี บัญชีนั้นเป็นวัตถุที่ "ประกอบ" ของลูกค้า (อย่างน้อยก็ในบริบทส่วนใหญ่ที่ฉันคิดได้) หากคุณลบลูกค้าบัญชีจะไม่มีมูลค่าในตัวมันเองดังนั้นบัญชีนั้นก็จะถูกลบเช่นกัน สิ่งที่ตรงกันข้ามมักเป็นจริงกับการสร้างวัตถุ เนื่องจากบัญชีมีความหมายเฉพาะในบริบทของลูกค้าคุณจึงมีการสร้างบัญชีเป็นส่วนหนึ่งของการสร้างลูกค้า (หรือหากคุณทำอย่างเกียจคร้านบัญชีนั้นจะเป็นส่วนหนึ่งของธุรกรรมของลูกค้า)

มีประโยชน์ในการออกแบบที่จะคิดว่าวัตถุใดเป็นเจ้าของ (เขียน) วัตถุอื่นเทียบกับวัตถุที่อ้างอิง (รวม) วัตถุอื่น ๆ สามารถช่วยระบุว่าความรับผิดชอบอยู่ที่ใดสำหรับการสร้างอ็อบเจ็กต์ / ล้างข้อมูล / อัพเดต

เท่าที่ทราบในโค้ดมักจะบอกได้ยาก ทุกอย่างในโค้ดส่วนใหญ่เป็นการอ้างอิงอ็อบเจ็กต์ดังนั้นจึงอาจไม่ชัดเจนว่าอ็อบเจ็กต์ที่อ้างอิงนั้นประกอบด้วย (เป็นเจ้าของ) หรือรวม

มันน่าจะมีอยู่ความสับสนมากเกี่ยวกับความแตกต่างระหว่างส่วนทั้งการเชื่อมโยงแนวคิดรวมตัวและองค์ประกอบ ปัญหาหลักคือความเข้าใจผิดอย่างกว้างขวาง (แม้แต่ในหมู่นักพัฒนาซอฟต์แวร์ผู้เชี่ยวชาญและในหมู่ผู้เขียน UML) ว่าแนวคิดของการจัดองค์ประกอบมีความหมายถึงการพึ่งพาวงจรชีวิตระหว่างส่วนทั้งหมดและส่วนต่างๆเพื่อให้ชิ้นส่วนไม่สามารถดำรงอยู่ได้หากไม่มีทั้งส่วน แต่มุมมองนี้เพิกเฉยต่อข้อเท็จจริงที่ว่ายังมีบางกรณีของการเชื่อมโยงบางส่วนกับส่วนที่ไม่สามารถแบ่งปันได้ซึ่งชิ้นส่วนนั้นสามารถแยกออกจากกันได้และรอดจากการทำลายล้างทั้งหมด

ในเอกสารข้อมูลจำเพาะของ UML คำจำกัดความของคำว่า "องค์ประกอบ" มักจะบอกเป็นนัยถึงส่วนที่ไม่สามารถแบ่งปันได้ แต่ยังไม่ชัดเจนว่าอะไรคือลักษณะที่กำหนดของ "องค์ประกอบ" และอะไรเป็นเพียงลักษณะทางเลือก แม้ในเวอร์ชันใหม่ (ณ ปี 2015) UML 2.5 หลังจากพยายามปรับปรุงคำจำกัดความของคำว่า "องค์ประกอบ" ก็ยังคงคลุมเครือและไม่ได้ให้คำแนะนำใด ๆ ในการสร้างแบบจำลองการเชื่อมโยงบางส่วนกับส่วนที่แชร์ไม่ได้ ชิ้นส่วนที่สามารถถอดออกจากชิ้นส่วนและอยู่รอดจากการถูกทำลายได้ซึ่งทั้งหมดตรงข้ามกับกรณีที่ชิ้นส่วนไม่สามารถถอดออกได้และถูกทำลายพร้อมกับทั้งชิ้น พวกเขากล่าวว่า

หากอ็อบเจ็กต์คอมโพสิตถูกลบอินสแตนซ์ส่วนทั้งหมดที่เป็นอ็อบเจ็กต์จะถูกลบออก

แต่ในเวลาเดียวกันพวกเขายังกล่าวว่า

อ็อบเจ็กต์ส่วนหนึ่งอาจถูกลบออกจากอ็อบเจ็กต์คอมโพสิตก่อนที่อ็อบเจ็กต์คอมโพสิตจะถูกลบดังนั้นจึงไม่ถูกลบออกจากอ็อบเจ็กต์คอมโพสิต

ความสับสนนี้ชี้ให้เห็นถึงความไม่สมบูรณ์ของนิยาม UML ซึ่งไม่ได้คำนึงถึงการพึ่งพาวงจรการใช้งานระหว่างส่วนประกอบและคอมโพสิต ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องทำความเข้าใจว่าคำจำกัดความ UML สามารถปรับปรุงได้อย่างไรโดยการแนะนำ UML stereotype สำหรับองค์ประกอบ<< ที่แยกกันไม่ออก >> ซึ่งส่วนประกอบไม่สามารถแยกออกจากคอมโพสิตได้ดังนั้นจึงต้องถูกทำลายทุกครั้งที่คอมโพสิตถูกทำลาย

องค์ประกอบ

ดังที่Martin Fowler ได้อธิบายไว้ประเด็นหลักในการกำหนดลักษณะการจัดองค์ประกอบคือ "วัตถุสามารถเป็นส่วนหนึ่งของความสัมพันธ์ขององค์ประกอบเดียวเท่านั้น" นอกจากนี้ยังมีการอธิบายไว้ในบล็อกโพสต์ที่ยอดเยี่ยมUML Composition vs Aggregation vs Associationโดย Geert Bellekens นอกเหนือจากการกำหนดลักษณะเฉพาะขององค์ประกอบนี้แล้ว (ที่จะมีส่วนที่เป็นเอกสิทธิ์หรือไม่สามารถแบ่งปันได้ ) องค์ประกอบยังอาจมาพร้อมกับการพึ่งพาวงจรชีวิตระหว่างคอมโพสิตและส่วนประกอบ ในความเป็นจริงมีสองประเภทของการอ้างอิงดังกล่าว:

1. เมื่อใดก็ตามที่ต้องแนบองค์ประกอบเข้ากับคอมโพสิตเสมอหรือกล่าวอีกนัยหนึ่งคือเมื่อมีองค์ประกอบที่บังคับตามที่แสดงโดยการทวีคูณ "หนึ่งเดียว" ที่ด้านคอมโพสิตของบรรทัดองค์ประกอบนั้นจะต้องถูกนำมาใช้ใหม่ ใน (หรือติดใหม่กับ) คอมโพสิตอื่นหรือถูกทำลายเมื่อคอมโพสิตปัจจุบันถูกทำลาย นี่คือตัวอย่างขององค์ประกอบระหว่างPersonและHeartแสดงในแผนภาพด้านล่าง หัวใจอาจถูกทำลายหรือปลูกถ่ายให้กับบุคคลอื่นเมื่อเจ้าของเสียชีวิต
2. เมื่อใดก็ตามที่ไม่สามารถแยกส่วนประกอบออกจากคอมโพสิตได้หรือกล่าวอีกนัยหนึ่งคือเมื่อแยกออกจากกันไม่ได้เมื่อนั้นส่วนประกอบจะต้องถูกทำลายเมื่อคอมโพสิตถูกทำลาย ตัวอย่างขององค์ประกอบดังกล่าวกับชิ้นส่วนแยกออกเป็นองค์ประกอบระหว่างและPersonBrain

โดยสรุปการขึ้นต่อกันของวงจรชีวิตใช้กับกรณีเฉพาะขององค์ประกอบเท่านั้น แต่ไม่ใช่โดยทั่วไปดังนั้นจึงไม่ใช่ลักษณะที่กำหนด

ข้อมูลจำเพาะของ UML ระบุ: "บางส่วนอาจถูกลบออกจากอินสแตนซ์แบบผสมก่อนที่อินสแตนซ์ผสมจะถูกลบดังนั้นจึงไม่ถูกลบในฐานะส่วนหนึ่งของอินสแตนซ์แบบผสม" ในตัวอย่างของCar- Engineองค์ประกอบดังที่แสดงในแผนภาพต่อไปนี้เห็นได้ชัดว่าเครื่องยนต์สามารถถอดออกจากรถได้ก่อนที่รถจะถูกทำลายซึ่งในกรณีนี้เครื่องยนต์จะไม่ถูกทำลายและสามารถนำกลับมาใช้ใหม่ได้ นี่เป็นนัยโดยศูนย์หรือหนึ่งคูณที่ด้านคอมโพสิตของเส้นองค์ประกอบ

ความหลายหลากของการเชื่อมโยงขององค์ประกอบที่สิ้นสุดที่ด้านคอมโพสิตคือ 1 หรือ 0..1 ขึ้นอยู่กับความจริงว่าส่วนประกอบมีส่วนประกอบที่จำเป็น (ต้องแนบกับคอมโพสิต) หรือไม่ หากส่วนประกอบต่างๆแยกออกจากกันไม่ได้แสดงว่ามีส่วนประกอบที่จำเป็น

การรวม

การรวมตัวเป็นรูปแบบพิเศษของการเชื่อมโยงอีกรูปแบบหนึ่งที่มีความหมายที่ตั้งใจไว้ของความสัมพันธ์แบบส่วนหนึ่ง - ทั้งหมดโดยที่ส่วนของทั้งหมดสามารถแบ่งปันกับผู้ค้าส่งรายอื่นได้ ตัวอย่างเช่นเราสามารถจำลองการรวมกันระหว่างชั้นเรียนDegreeProgramและCourseดังที่แสดงในแผนภาพต่อไปนี้เนื่องจากหลักสูตรเป็นส่วนหนึ่งของหลักสูตรปริญญาและหลักสูตรสามารถใช้ร่วมกันระหว่างสองหลักสูตรหรือมากกว่านั้นได้ (เช่นปริญญาวิศวกรรมสามารถใช้ C หลักสูตรการเขียนโปรแกรมที่มีปริญญาวิทยาศาสตร์คอมพิวเตอร์)

อย่างไรก็ตามแนวคิดของการรวมกับชิ้นส่วนที่แชร์ได้นั้นไม่ได้มีความหมายมากนักดังนั้นจึงไม่มีผลกระทบใด ๆ ต่อการนำไปใช้งานและนักพัฒนาจำนวนมากจึงไม่ต้องการใช้เพชรสีขาวในไดอะแกรมคลาสของพวกเขา แต่เป็นเพียงการสร้างแบบจำลองการเชื่อมโยงธรรมดา แทน. ข้อมูลจำเพาะ UML ระบุว่า: "ความหมายที่แม่นยำของการรวมที่ใช้ร่วมกันแตกต่างกันไปตามพื้นที่แอปพลิเคชันและผู้สร้างโมเดล"

ความทวีคูณของการเชื่อมโยงของการรวมที่สิ้นสุดที่ด้านข้างทั้งหมดอาจเป็นตัวเลขใดก็ได้ (*) เนื่องจากส่วนหนึ่งอาจเป็นของหรือใช้ร่วมกันระหว่าง wholes จำนวนเท่าใดก็ได้

ในแง่รหัสการจัดองค์ประกอบมักจะชี้ให้เห็นว่าออบเจ็กต์ที่มีอยู่มีหน้าที่ในการสร้างอินสแตนซ์ของคอมโพเนนต์ * และอ็อบเจ็กต์ที่มีจะมีการอ้างอิงที่มีอายุยาวนานเพียงอย่างเดียว ดังนั้นหากอ็อบเจ็กต์พาเรนต์ถูกยกเลิกการอ้างอิงและรวบรวมขยะเด็กก็เช่นกัน

ดังนั้นรหัสนี้ ...

Class Order
   private Collection<LineItem> items;
   ...
   void addOrderLine(Item sku, int quantity){
         items.add(new LineItem(sku, quantity));
   }
}

แสดงให้เห็นว่า LineItem เป็นส่วนประกอบของคำสั่ง - LineItems ไม่มีอยู่นอกเหนือจากคำสั่งซื้อที่มีอยู่ แต่วัตถุไอเทมไม่ได้สร้างตามลำดับ - มันถูกส่งต่อตามความจำเป็นและยังคงมีอยู่แม้ว่าร้านค้าจะไม่มีคำสั่งซื้อก็ตาม ดังนั้นจึงมีความเกี่ยวข้องมากกว่าส่วนประกอบ

* nb คอนเทนเนอร์มีหน้าที่ในการสร้างส่วนประกอบ แต่จริงๆแล้วอาจไม่ได้เรียกใหม่ ... () เอง - นี่คือ java โดยปกติจะมีโรงงานหรือสองแห่งที่ต้องดำเนินการก่อน!

ภาพประกอบแนวความคิดที่ให้ไว้ในคำตอบอื่น ๆ มีประโยชน์ แต่ฉันต้องการแบ่งปันประเด็นอื่นที่ฉันพบว่ามีประโยชน์

ฉันได้รับไมล์สะสมจาก UML สำหรับการสร้างรหัสสำหรับซอร์สโค้ดหรือ DDL สำหรับฐานข้อมูลเชิงสัมพันธ์ ที่นั่นฉันได้ใช้องค์ประกอบเพื่อระบุว่าตารางมีคีย์ต่างประเทศที่ไม่เป็นโมฆะ (ในฐานข้อมูล) และอ็อบเจ็กต์ "parent" ที่ไม่เป็นโมฆะ (และมักจะเป็น "ขั้นสุดท้าย") ในโค้ดของฉัน ฉันใช้การรวมโดยที่ฉันตั้งใจให้เร็กคอร์ดหรืออ็อบเจ็กต์สามารถดำรงอยู่ได้ในรูปแบบ "orphan" ไม่ยึดติดกับอ็อบเจ็กต์พาเรนต์ใด ๆ หรือถูก "นำมาใช้" โดยอ็อบเจ็กต์พาเรนต์อื่น

กล่าวอีกนัยหนึ่งฉันได้ใช้สัญกรณ์องค์ประกอบเป็นชวเลขเพื่อบ่งบอกถึงข้อ จำกัด พิเศษบางอย่างที่อาจจำเป็นเมื่อเขียนโค้ดสำหรับโมเดล

ตัวอย่างที่ชอบ: Composition: Water is a part-of a Pond. (บ่อน้ำเป็นองค์ประกอบของน้ำ) การ รวม: บ่อมีเป็ดและปลา (บ่อรวมเป็ดและปลา)

อย่างที่คุณเห็นว่าฉันมี "บางส่วน" และ "มี" เป็นตัวหนาเนื่องจาก 2 วลีนี้มักจะชี้ให้เห็นว่ามีการเชื่อมต่อแบบใดระหว่างคลาส

แต่ตามที่ผู้อื่นชี้ให้เห็นหลายครั้งว่าการเชื่อมต่อเป็นองค์ประกอบหรือการรวมขึ้นอยู่กับการใช้งาน

เป็นเรื่องยากมากที่จะสร้างความแตกต่างระหว่างความสัมพันธ์แบบรวมและความสัมพันธ์เชิงประกอบ แต่ฉันจะยกตัวอย่างเรามีบ้านและห้องที่นี่เรามีความสัมพันธ์แบบผสมห้องเป็นส่วนหนึ่งของบ้านและชีวิตห้องเริ่มต้น ด้วยชีวิตในบ้านและจะเสร็จสิ้นเมื่อชีวิตในบ้านสิ้นสุดลงห้องเป็นส่วนหนึ่งของบ้านเราพูดถึงองค์ประกอบเช่นประเทศและเมืองหลวงหนังสือและหน้า สำหรับตัวอย่างความสัมพันธ์โดยรวมใช้ทีมและผู้เล่นผู้เล่นสามารถอยู่ได้โดยไม่มีทีมและทีมเป็นกลุ่มผู้เล่นและชีวิตของผู้เล่นสามารถเริ่มต้นก่อนชีวิตของทีมถ้าเราพูดถึงการเขียนโปรแกรมเราสามารถสร้างผู้เล่นและหลังจากที่เราจะสร้างทีม แต่สำหรับองค์ประกอบไม่เราสร้างห้องภายในบ้าน Composition ----> composite | composing. การรวมกลุ่ม -------> กลุ่ม | ธาตุ

มาตั้งเงื่อนไขกัน การรวมเป็น metaterm ในมาตรฐาน UML และวิธีการทั้งสององค์ประกอบและการรวมตัวร่วมกันเพียงชื่อที่ใช้ร่วมกัน บ่อยครั้งที่ชื่อ "การรวม" ไม่ถูกต้อง มันไม่ดีสำหรับการจัดองค์ประกอบก็คือการรวมตัวเช่นกัน ตามที่ฉันเข้าใจคุณหมายถึง "แชร์"

เพิ่มเติมจากมาตรฐาน UML:

คอมโพสิต - ระบุว่าคุณสมบัติถูกรวมเข้าด้วยกันกล่าวคือออบเจ็กต์คอมโพสิตมีความรับผิดชอบในการดำรงอยู่และการจัดเก็บของวัตถุที่ประกอบขึ้น

ดังนั้นความสัมพันธ์ระหว่างมหาวิทยาลัยกับวิหารจึงเป็นองค์ประกอบเนื่องจากมหาวิหารไม่มีอยู่นอกมหาวิทยาลัย (IMHO)

ความหมายที่แม่นยำของการรวมแบบแบ่งใช้จะแตกต่างกันไปตามพื้นที่แอปพลิเคชันและตัวสร้างแบบจำลอง

กล่าวคือความสัมพันธ์อื่น ๆ ทั้งหมดสามารถวาดเป็นการรวมที่ใช้ร่วมกันได้หากคุณปฏิบัติตามหลักการบางอย่างของคุณหรือของคนอื่นเท่านั้น ดูที่นี่ด้วย

พิจารณาส่วนต่างๆของร่างกายมนุษย์เช่นไตตับสมอง หากเราพยายามทำแผนที่แนวคิดขององค์ประกอบและการรวมกันที่นี่มันจะเป็นดังนี้:

ก่อนที่จะมีการปลูกถ่ายชิ้นส่วนของร่างกายเช่นไตและตับร่างกายทั้งสองส่วนนี้มีองค์ประกอบกับร่างกายมนุษย์และไม่สามารถแยกออกจากร่างกายมนุษย์ได้

แต่หลังจากการถือกำเนิดของการปลูกถ่ายชิ้นส่วนของร่างกายพวกเขาสามารถปลูกถ่ายในร่างกายมนุษย์อื่นได้ดังนั้นชิ้นส่วนเหล่านี้จึงรวมเข้ากับร่างกายมนุษย์เนื่องจากการดำรงอยู่แยกกับร่างกายมนุษย์เป็นไปได้ในขณะนี้