Tổng hợp so với Thành phần [đã đóng]

Tôi đã gặp khó khăn khi hiểu sự khác biệt giữa thành phần và tổng hợp trong UML. Ai đó có thể vui lòng cung cấp cho tôi một so sánh tốt và tương phản giữa chúng không? Tôi cũng muốn học cách nhận ra sự khác biệt giữa chúng trong mã và / hoặc xem một ví dụ ngắn về phần mềm / mã.

Chỉnh sửa: Một phần lý do tại sao tôi yêu cầu là vì hoạt động tài liệu ngược lại mà chúng tôi đang thực hiện. Chúng tôi đã viết mã, nhưng chúng tôi cần quay lại và tạo sơ đồ lớp cho mã. Chúng tôi chỉ muốn nắm bắt các liên kết đúng cách.

Sự phân biệt giữa tập hợp và thành phần phụ thuộc vào ngữ cảnh.

Lấy ví dụ về ô tô được đề cập trong một câu trả lời khác - đúng vậy, đúng là ống xả ô tô có thể tự đứng "riêng" nên có thể không có trong thành phần của ô tô - nhưng nó phụ thuộc vào ứng dụng. Nếu bạn xây dựng một ứng dụng thực sự phải xử lý khí thải ô tô độc lập (ứng dụng quản lý cửa hàng ô tô?), Tổng hợp sẽ là lựa chọn của bạn. Nhưng nếu đây là một trò chơi đua xe đơn giản và ống xả xe hơi chỉ đóng vai trò là một phần của xe hơi - thì, bố cục sẽ khá ổn.

Bàn cờ? Cùng một vấn đề. Một quân cờ không tồn tại nếu không có bàn cờ chỉ trong một số ứng dụng nhất định. Ở những người khác (chẳng hạn như của một nhà sản xuất đồ chơi), một quân cờ chắc chắn không thể được tạo thành một bàn cờ.

Mọi thứ thậm chí còn tồi tệ hơn khi cố gắng ánh xạ thành phần / tổng hợp sang ngôn ngữ lập trình yêu thích của bạn. Trong một số ngôn ngữ, sự khác biệt có thể dễ nhận thấy hơn ("theo tham chiếu" so với "theo giá trị", khi mọi thứ đơn giản) nhưng ở những ngôn ngữ khác thì có thể không tồn tại.

Và một lời khuyên cuối cùng? Đừng lãng phí quá nhiều thời gian cho vấn đề này. Nó không đáng. Sự phân biệt hầu như không hữu ích trong thực tế (ngay cả khi bạn có một "thành phần" hoàn toàn rõ ràng, bạn vẫn có thể muốn triển khai nó dưới dạng tổng hợp vì lý do kỹ thuật - ví dụ: bộ nhớ đệm).

Như một quy luật của:

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

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

Trong bố cục (Người, Trái tim, Bàn tay), "đối tượng phụ" (Trái tim, Bàn tay) sẽ bị phá hủy ngay khi Người bị phá hủy.

Trong tập hợp (Thành phố, Cây, Xe) "các đối tượng phụ" (Cây, Xe) sẽ KHÔNG bị phá hủy khi Thành phố bị phá hủy.

Điểm mấu chốt là, bố cục nhấn mạnh đến sự tồn tại lẫn nhau và trong tổng hợp, thuộc tính này KHÔNG bắt buộc.

Thành phần và Tổng hợp là các loại liên kết. Chúng có liên quan rất chặt chẽ và về mặt lập trình dường như không có nhiều sự khác biệt giữa cả hai. Tôi sẽ cố gắng giải thích sự khác biệt giữa hai điều này bằng các ví dụ mã java

Tổng hợp : Đối tượng tồn tại bên ngoài đối tượng kia, được tạo ra bên ngoài, vì vậy nó được truyền như một đối số (ví dụ) cho hàm tạo. Ví dụ: People - car. Chiếc xe được tạo ra trong một bối cảnh khác và sau đó trở thành tài sản của mỗi người.

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

Thành phần : Vật chỉ tồn tại, hoặc chỉ có ý nghĩa bên trong vật kia, như một bộ phận của vật kia. Ví dụ: Con người - trái tim. Bạn không tạo ra một trái tim và sau đó chuyển nó cho một người. Thay vào đó, trái tim được tạo ra khi con người được tạo ra.

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

Giải thích ở đây với một ví dụ Sự khác biệt giữa Tổng hợp và Thành phần

Thành phần ngụ ý rằng các đối tượng con có chung tuổi thọ với đối tượng chính. Tổng hợp thì không. Ví dụ, một bàn cờ bao gồm các ô cờ - các ô cờ không thực sự tồn tại nếu không có bàn cờ. Tuy nhiên, một chiếc ô tô là tổng hợp của các bộ phận - ống xả ô tô vẫn là ống xả ô tô nếu nó không phải là một bộ phận của ô tô vào thời điểm đó.

Ví dụ tôi học được là ngón tay với bàn tay. Bàn tay của bạn bao gồm các ngón tay. Nó sở hữu chúng. Nếu bàn tay chết, các ngón tay cũng chết. Bạn không thể "tổng hợp" các ngón tay. Bạn không thể chỉ lấy các ngón tay thừa và gắn và tháo chúng ra khỏi tay theo ý muốn.

Giá trị ở đây, từ quan điểm thiết kế, thường liên quan đến tuổi thọ của đối tượng như một người đăng khác đã nói. Giả sử bạn có Khách hàng và họ có Tài khoản. Tài khoản đó là một đối tượng "sáng tác" của khách hàng (ít nhất, trong hầu hết các ngữ cảnh mà tôi có thể nghĩ đến). Nếu bạn xóa Khách hàng, thì Tài khoản không có giá trị riêng nên nó cũng sẽ bị xóa. Điều ngược lại thường đúng khi tạo đối tượng. Vì Tài khoản chỉ có ý nghĩa trong ngữ cảnh của Khách hàng, bạn nên tạo Tài khoản như một phần của quá trình tạo Khách hàng (hoặc, nếu bạn làm điều đó một cách lười biếng, nó sẽ là một phần của một số giao dịch với Khách hàng).

Nó hữu ích trong thiết kế khi nghĩ về những đối tượng nào sở hữu (cấu thành) các đối tượng khác so với những đối tượng chỉ tham chiếu (tổng hợp) các đối tượng khác. Nó có thể giúp xác định trách nhiệm nằm ở đâu đối với việc tạo / dọn dẹp / cập nhật đối tượng.

Theo như trong mã, thường rất khó để nói. Hầu hết mọi thứ trong mã đều là tham chiếu đối tượng nên có thể không rõ ràng đối tượng được tham chiếu là bao gồm (sở hữu) hay tổng hợp.

Thật đáng ngạc nhiên là có bao nhiêu sự nhầm lẫn tồn tại về sự phân biệt giữa tổng thể - tổng thể các khái niệm liên kết và thành phần . Vấn đề chính là sự hiểu lầm phổ biến (ngay cả giữa các nhà phát triển phần mềm chuyên nghiệp và giữa các tác giả của UML) rằng khái niệm thành phần bao hàm sự phụ thuộc vòng đời giữa tổng thể và các bộ phận của nó sao cho các bộ phận không thể tồn tại mà không có tổng thể. Nhưng quan điểm này bỏ qua thực tế là cũng có những trường hợp liên kết một phần với các bộ phận không thể chia sẻ, nơi các bộ phận có thể tách rời và tồn tại sau sự phá hủy toàn bộ.

Trong tài liệu đặc tả UML, định nghĩa của thuật ngữ "thành phần" luôn ngụ ý các phần không thể chia sẻ, nhưng vẫn chưa rõ ràng đâu là đặc tính xác định của "thành phần" và đâu chỉ là đặc tính tùy chọn. Ngay cả trong phiên bản mới (tính đến năm 2015), UML 2.5, sau khi cố gắng cải thiện định nghĩa của thuật ngữ "thành phần", nó vẫn còn mơ hồ và không cung cấp bất kỳ hướng dẫn nào về cách lập mô hình liên kết một phần với không các bộ phận có thể chia sẻ được trong đó các bộ phận có thể được tách rời và tồn tại sau sự phá hủy, toàn bộ trái ngược với trường hợp các bộ phận không thể tách rời và bị phá hủy cùng với toàn bộ. Họ nói

Nếu một đối tượng tổng hợp bị xóa, tất cả các thể hiện bộ phận của nó là đối tượng sẽ bị xóa cùng với nó.

Nhưng đồng thời họ cũng nói

Một đối tượng bộ phận có thể bị xóa khỏi đối tượng tổng hợp trước khi đối tượng kết hợp bị xóa và do đó không bị xóa như một phần của đối tượng tổng hợp.

Sự nhầm lẫn này chỉ ra sự không đầy đủ của định nghĩa UML, định nghĩa này không tính đến sự phụ thuộc vòng đời giữa các thành phần và vật liệu tổng hợp. Do đó, điều quan trọng là phải hiểu cách định nghĩa UML có thể được nâng cao bằng cách giới thiệu một khuôn mẫu UML cho các thành phần << không thể tách rời >> trong đó các thành phần không thể tách rời khỏi tổng hợp của chúng và do đó, phải bị phá hủy bất cứ khi nào tổ hợp của chúng bị phá hủy.

1) Thành phần

Như Martin Fowler đã giải thích , vấn đề chính để xác định đặc điểm của bố cục là "một đối tượng chỉ có thể là một phần của một mối quan hệ bố cục". Điều này cũng được giải thích trong bài đăng blog tuyệt vời Thành phần UML so với Tổng hợp và Hiệp hội của Geert Bellekens. Ngoài đặc điểm xác định này của một chế phẩm (có các bộ phận độc quyền hoặc không thể chia sẻ ), một chế phẩm cũng có thể đi kèm với sự phụ thuộc vòng đời giữa hỗn hợp và các thành phần của nó. Trên thực tế, có hai loại phụ thuộc như vậy:

1. Bất cứ khi nào một thành phần phải luôn được gắn vào một tổng hợp, hoặc nói cách khác, khi nó có một tổng hợp bắt buộc , được thể hiện bằng sự đa dạng "chính xác một" ở cạnh tổng hợp của đường thành phần, thì nó phải được sử dụng lại trong (hoặc gắn lại vào) một tổ hợp khác, hoặc bị phá hủy, khi tổ hợp hiện tại của nó bị phá hủy. Điều này được minh họa bởi thành phần giữa Personvà Heart, được hiển thị trong sơ đồ bên dưới. Trái tim bị phá hủy hoặc được cấy ghép cho người khác khi chủ nhân của nó đã chết.
2. Bất cứ khi nào một thành phần không thể tách rời khỏi tổ hợp của nó, hay nói cách khác, khi nó không thể tách rời , thì và chỉ khi đó, thành phần đó phải bị phá hủy, khi tổ hợp của nó bị phá hủy. Một ví dụ về bố cục như vậy với các phần không thể tách rời là bố cục giữa Personvà Brain.

Tóm lại, sự phụ thuộc vòng đời chỉ áp dụng cho các trường hợp cụ thể của thành phần, nhưng không áp dụng chung, do đó chúng không phải là một đặc tính xác định.

Thông số kỹ thuật của UML nêu rõ: "Một phần có thể bị xóa khỏi thể hiện hỗn hợp trước khi đối tượng tổng hợp bị xóa và do đó không bị xóa như một phần của đối tượng tổng hợp." Trong ví dụ về a Car- Enginethành phần, như được hiển thị trong sơ đồ sau, rõ ràng là trường hợp động cơ có thể được tách ra khỏi ô tô trước khi ô tô bị phá hủy, trong trường hợp này động cơ không bị phá hủy và có thể được sử dụng lại. Điều này được ngụ ý bởi số không hoặc một số ở cạnh tổng hợp của đường bố cục.

Sự đa dạng của liên kết của một thành phần kết thúc ở phía kết hợp là 1 hoặc 0..1, tùy thuộc vào thực tế nếu các thành phần có một kết hợp bắt buộc (phải được gắn vào một tổng hợp) hay không. Nếu các thành phần không thể tách rời , điều này ngụ ý rằng chúng có một tổ hợp bắt buộc.

2) Tổng hợp

Tập hợp là một dạng liên kết đặc biệt khác với ý nghĩa dự định của mối quan hệ một phần, trong đó các phần của tổng thể có thể được chia sẻ với các phần tử khác. Ví dụ: chúng ta có thể lập mô hình tổng hợp giữa các lớp DegreeProgramvà Course, như được hiển thị trong sơ đồ sau, vì một khóa học là một phần của chương trình cấp bằng và một khóa học có thể được chia sẻ giữa hai hoặc nhiều chương trình cấp bằng (ví dụ: bằng kỹ sư có thể chia sẻ điểm C. khóa học lập trình với bằng khoa học máy tính).

Tuy nhiên, khái niệm tập hợp với các phần có thể chia sẻ thực sự không có nhiều ý nghĩa, vì vậy nó không có bất kỳ tác động nào đến việc triển khai và do đó, nhiều nhà phát triển không muốn sử dụng hình thoi trắng trong sơ đồ lớp của họ, mà chỉ mô hình hóa một liên kết đơn giản. thay thế. Thông số kỹ thuật của UML cho biết: "Ngữ nghĩa chính xác của tập hợp được chia sẻ thay đổi tùy theo khu vực ứng dụng và trình tạo mô hình".

Đa số liên kết của một tập hợp kết thúc ở toàn bộ phía có thể là bất kỳ số nào (*) bởi vì một phần có thể thuộc về hoặc được chia sẻ giữa bất kỳ số sỉ nào.

Theo thuật ngữ mã, thành phần thường gợi ý rằng đối tượng chứa chịu trách nhiệm tạo các thể hiện của thành phần * và đối tượng chứa chứa các tham chiếu lâu dài duy nhất đến nó. Vì vậy, nếu đối tượng cha bị hủy tham chiếu và thu gom rác, thì đối tượng con cũng vậy.

vì vậy mã này ...

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

gợi ý rằng LineItem là một thành phần của Order - LineItems không tồn tại bên ngoài thứ tự chứa của chúng. Nhưng các đối tượng Item không được xây dựng theo thứ tự - chúng được chuyển vào khi cần thiết và tiếp tục tồn tại, ngay cả khi cửa hàng không có đơn đặt hàng. vì vậy chúng được liên kết, thay vì các thành phần.

* nb vùng chứa chịu trách nhiệm cài đặt thành phần, nhưng nó có thể không thực sự tự gọi là new ... () - đây là java, thường có một hoặc hai nhà máy để thực hiện trước!

Các minh họa khái niệm được cung cấp trong các câu trả lời khác rất hữu ích, nhưng tôi muốn chia sẻ một điểm khác mà tôi thấy hữu ích.

Tôi đã nhận được một số dặm từ UML cho việc tạo mã, cho mã nguồn hoặc DDL cho cơ sở dữ liệu quan hệ. Ở đó, tôi đã sử dụng thành phần để chỉ ra rằng một bảng có khóa ngoại không thể null (trong cơ sở dữ liệu) và đối tượng không thể nullable "cha" (và thường là "cuối cùng"), trong mã của tôi. Tôi sử dụng tính năng tổng hợp trong đó tôi dự định một bản ghi hoặc đối tượng có thể tồn tại dưới dạng "trẻ mồ côi", không được gắn với bất kỳ đối tượng mẹ nào hoặc được "nhận nuôi" bởi một đối tượng mẹ khác.

Nói cách khác, tôi đã sử dụng ký hiệu thành phần như một cách viết tắt để ngụ ý một số ràng buộc bổ sung có thể cần thiết khi viết mã cho mô hình.

Ví dụ mà tôi thích: Thành phần: Nước là một phần của Ao. (Ao là một thành phần của nước.) Tính tổng hợp: Ao có vịt và cá (Ao tổng hợp vịt và cá)

Như bạn có thể thấy, tôi đã in đậm "part-of" và "has", vì 2 cụm từ này thường có thể chỉ ra loại kết nối tồn tại giữa các lớp.

Nhưng như những người khác đã chỉ ra, nhiều khi kết nối là một thành phần hay một tập hợp phụ thuộc vào ứng dụng.

Thật khó để phân biệt giữa quan hệ tổng hợp và quan hệ tổng hợp, nhưng tôi sẽ lấy một số ví dụ, Chúng ta có một ngôi nhà và các phòng, ở đây chúng ta có một quan hệ tổng hợp, phòng là một phần của ngôi nhà và cuộc sống phòng bắt đầu với house life's và Sẽ kết thúc khi house life kết thúc, căn phòng là một phần của ngôi nhà, chúng ta nói về bố cục, như quốc gia và thủ đô, sách và các trang. Ví dụ về mối quan hệ tổng hợp, lấy đội và người chơi, người chơi có thể tồn tại mà không cần đội và đội là một nhóm người chơi và cuộc sống của người chơi có thể bắt đầu trước khi cuộc sống của đội, nếu chúng ta nói về lập trình, chúng ta có thể tạo người chơi và sau khi chúng ta sẽ tạo nhóm, nhưng đối với bố cục không, chúng tôi tạo phòng bên trong ngôi nhà. Thành phần ----> tổng hợp | sáng tác. Tổng hợp -------> nhóm | thành phần

Hãy thiết lập các điều khoản. Tổng hợp là một đại lượng đo lường trong tiêu chuẩn UML và có nghĩa là CẢ thành phần và tổng hợp được chia sẻ, được đặt tên đơn giản là shared . Thường nó được đặt tên không chính xác là "tổng hợp". Nó là BAD, vì bố cục cũng là một tập hợp. Theo tôi hiểu, bạn có nghĩa là "được chia sẻ".

Hơn nữa từ tiêu chuẩn UML:

composite - Cho biết thuộc tính được tổng hợp một cách lịch sự, tức là, đối tượng tổng hợp có trách nhiệm đối với sự tồn tại và lưu trữ của các đối tượng (bộ phận) được cấu thành.

Vì vậy, liên kết Đại học với cathedras là một thành phần, bởi vì cathedra không tồn tại ngoài Đại học (IMHO)

Ngữ nghĩa chính xác của tập hợp được chia sẻ khác nhau tùy theo khu vực ứng dụng và trình mô hình.

Tức là, tất cả các liên kết khác có thể được rút ra dưới dạng tổng hợp được chia sẻ, nếu bạn chỉ tuân theo một số nguyên tắc của bạn hoặc của người khác. Cũng xem ở đây .

Xem xét các bộ phận trên cơ thể người như thận, gan, não. Nếu chúng ta cố gắng lập bản đồ khái niệm về thành phần và tổng hợp ở đây, nó sẽ giống như:

Trước khi sự ra đời của các bộ phận cơ thể được cấy ghép như thận và gan, hai bộ phận cơ thể này cùng cấu tạo với cơ thể người và không thể tồn tại biệt lập với cơ thể người.

Nhưng sau khi cấy ghép bộ phận cơ thể ra đời, chúng có thể được cấy ghép vào cơ thể người khác, vì vậy những bộ phận này được kết hợp với cơ thể người vì sự tồn tại của chúng tách biệt với cơ thể người là hoàn toàn có thể.