Ví dụ:
class A -----------------> class B ( Association)
class A-----------------<>class B ( Aggregation)
Theo em được biết thì 2 mối quan hệ trên có chung đặc điểm là: Nếu object của class B không tồn tại thì object class A(trong class B) vẫn tồn độc lập.
Nhưng em không biết sự khác nhau giữa chúng là gì và khi vẽ UML thì không biết dùng các nào cho phù hợp với đề bài. Mong mọi người giải thích giúp (có ví dụ thì càng tốt).
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();
}
}
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.
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 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
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ử
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.
Ý 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
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?