Hỏi sự khác nhau của 2 mối quan hệ Association và Aggregation trong UML

Aggregation

class A {
    function xxx() {
        print("A")
    }
}

class B {
    A a

    function yyy() {
        a.xxx();
    }
}

Association

class A {
    function xxx() {
        print("A")
    }
}

class B {

    function yyy(A a) {
        a.xxx();
    }
}

Capture.PNG1128x593 200 KB

Mình có class diagram như trên. Theo sự giải thích của bạn thì class Order và class OrderList phải có quan hệ là Aggregation mới đúng chứ sao tác giả (thầy của mình) lại thiết kế là Association

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

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

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

Trở về câu hỏi của bạn về UML của 1 shoping cart, Order và Product là quan hệ n-n nên theo chuẩn 3 được tách ra thêm 1 object nữa, gọi là OrderDetail. Còn OrderList là tập hợp (collection) của các order.

• Product và OrderDetail: association vì contructor truyền vào Product, int (giá) và OrderDetail không chứa cái Product ở attributes nên life cycle của Product không ảnh hưởng gì tới OrderDetail cả. Hoàn toàn có thể set Product = null.
• Order và OrderDetail: aggregation vì OrderID được build trong constructor (int, Calendar) và được set vào attribute tên: orderID. Giờ mà xóa cái orderID của OrderDetail là cái attribute orderID tèo.
• OrderList và Order: được build bằng 1 cây TreeSet của Order, chẳng có attribute nào liên quan tới Order cả nên nếu các cây đó không build được, cũng đâu có sao.

Tất nhiên, thiết kế association hay aggregation là tùy bạn. Ví dụ muốn OrderList trở thành Aggregration thì bạn thêm 1 attribute, giả sử Orders. Cái Orders này sẽ được dùng ở các function của OrderList (chắc gọi OrderManager thì hợp lý hơn).

Bạn nào có tool IBM Rational Rose version mới thì share cho anh em với, mấy link trên mạng toàn là v7.0 vể trước, nghe nói version mới đã là v10.xx rồi

anh @Phan_Hoang ơi,
Topic đã lâu, bây giờ em xem lại và có 1 vài thắc mắc muốn nhờ anh giúp đỡ. Mong anh chịu khó xem lại topic này để giúp em

OrderDetail không chứa cái Product ở attributes

OrderDetail phải có attribute Product chứ anh gì mình còn phải tính tổng đơn giá nữa mà

private int quantity;
private Product product;
public double calcTotalPrice()
        {
            return Quantity * product.Price;
        }

Nếu như thế thì em nghĩ thầy em đã thiết kế sai. Em nghĩ mối quan hệ phải là Aggregation

Giờ mà xóa cái orderID của OrderDetail là cái attribute orderID tèo

Thầy em thiết kế chỉ có 2 attribute thôi anh ơi

private int quantity;
private Product product;

Thêm nữa là trong class Order thầy em viết method

public void addLineItem(OrderDetail od) throws Exception
	{
		OrderDetail odNew= new OrderDetail(od.getQuantity(), od.getProduct());
		lineItems.add(odNew);
                //tại sao không viết lineItems.add(od); cho nhanh mà phải làm dài dòng như thế ?
	}

Mong anh giải đáp giúp em những thắc mắc trên. Em cảm ơn anh nhiều!

P/S: Nếu có thể thì em sẽ đưa anh source code để anh xem thử

OrderDetail phải có attribute Product chứ anh gì mình còn phải tính tổng đơn giá nữa mà

Mình nhìn lại thì đúng là OrderDetail bị thiếu Product nên không thể tính tổng giá trị đơn hàng được. Tuy nhiên, mình vẫn có thể thiết kế theo kiểu association bằng cách calcTotalPrice(Product) ^^. Còn nếu cho attribute Product và số lượng vào constructor của OrderDetail thì là aggregation.

Sorry bạn mình chỉ nhìn UML giải thích, quên xừ mất nhìn logic.

Order và OrderDetail: aggregation vì OrderID được build trong constructor (int, Calendar) và được set vào attribute orderID. Giờ mà xóa cái orderID của OrderDetail là cái attribute orderID tèo.

Thầy em thiết kế chỉ có 2 attribute thôi anh ơi

Ý mình chỉ là cái này aggregate lẫn nhau, mặc dù theo lý thuyết thì aggregration nó phải truyền cả 1 object vào, nhưng truyền ID cũng có thể coi là object. Tuy nhiên, đúng là mình lại hiểu sai bài toán rồi (vì mình nghĩ orderID chính là orderDetailID). Thực chất ra Order phải thêm một thuộc tính nữa, đó là OrderList, khi đó thì các function addLineItem mới đúng, và cái hàm calcTotalCharge mới dùng được. Vậy mối quan hệ ở đây là Association.

Nhiều khi thiết kế UML mình hay sót là chuyện bình thường mà. Còn phân ra đâu là association, đây là composition, đâu là aggregation nhiều khi chẳng cần quan tâm lắm đâu, he. Miễn đọc dễ hiểu, dễ nhìn và nếu dùng tool output ra code thì tool nó làm được mà không cần mình code.

Thêm chút về tiếng Anh:
Association: liên kết (2 class liên kết với nhau mà không phụ thuộc gì vào nhau cả. Class2 được truyền vào làm tham số cho các function trong class1, hết function là hết nhiệm vụ)

Compostion: thành phần (class 2 là một thành phần cấu thành nên class1. Class2 còn sống khi class1 còn sống) Giống như thân thể mình composite từ “mắt, tai, mũi, chân, tay”. Khi mình còn sống thì mắt, tai, … còn hoạt động. Khi mình ngoẻo thì tất cả dừng hoạt động.

Aggregation: tổng hợp (là 1 trường hợp của composition, nhưng sự phụ thuộc lỏng hơn). Cũng giống như thân thể mình, có thể lắp tay, chân, mắt mũi giả vào để hoạt động. Khi chân tay giả hỏng, mua cái mới để lắp vào, không có liên quan gì tới cái cũ cả. Từ các thành phần nhỏ, tổng hợp nên thành 1 cái to to hơn. Design pattern này thường được dùng trong Dependency Injection để tránh sự phụ thuộc của class1 vào class2. Hoàn toàn có thể truyền một fake class vào. Ví dụ như để test cầm nắm của tay hoạt động ngon không, giờ nếu fix cứng “chân”, nhỡ cái chân hỏng khiến tay làm việc sai thì lại qui tội cho cái “tay” hỏng ah? Giờ mình truyền vào 1 cái chân thật ngon, lúc nào cũng hoạt động đúng thì cái thân thể sẽ không còn phụ thuộc quá vào “chân” nữa, lúc này test “tay” mới đúng được.

Cảm ơn anh đã giúp em nhe!

em phải đăng nhập để like bác thích nhất mấy ví dụ thực tiễn thế này dễ hình dung hơn lý thuyết nhiều