Implementing associations

Finding out what associations are is pretty straightforward, what’s interesting is to make sure everybody in the project understand how to implement them on code. In this case, Java code. A couple of nice links on the matter are the ones in Java Ranch and Martin Fowler’s site.

Quick review on associations.

Basically an association is relationship that enables classes to send messages to each other. Composition adds a life cycle relationship. Finally aggregation, a modeling placebo as Rumbaugh puts it, finds its ways on delegation and a definition before being used.

Reading the model.

On the model above we can see the three associations we’re going to define how to implement. Reading from left to right we first see the association between BillPrinter and Bill. Next we see a Customer aggregated to a Bill, a BillingAddress used to compose a Bill, and, a list of Item(s) aggregated to the same Bill.

Implementing the association.

To implement the arrow going from BillPrinter to Bill, it helps to notice in the model they are associated by the print method in BilPrinter. So this association seeks to send a printing message using a Bill as source of information. We could also have a print method without the Bill parameter and a setBill method, but it wouldn’t be this clear we mean to print the Bill.

class BillPrinter {
//attributes
private String serial;
private Location location;
//constructor
public BillPrinter() {
}
//printing a bill
public void print(Bill bill) {//here! here's where the model says "associate with Bill to accomplish this task".
System.out.println(bill.toString());
}
}

In Bill there are no mentions to BillPrinter. Bill is not aware is being used for printing purposes, and it doesn’t need to.

Implementing the aggregations and the composition.

Then, the white diamonds. They are trying to express that a the Customer and the list of Item(s) are part of the Bill to solve this use case, but they can go on with their lifes and have their own operations outside the Bill. They might be in the item’s list at the inventory or the sale campaign for the top 50 customers in the CRM.

class Bill {
// aggregation attributes
private Customer customer;
private List items;
//composition attribute
private AddressInfo address;
//constructor
public(Customer customer, List items) {
this.customer = customer; //Bill uses a Customer that already exists
this.items = items; //the same for the Item(s), they already exist
address = new AddressInfo(this); //here! Bill creates an AddressInfo for its personal use
}
//getters
public Customer getCustomer() {
return customer;
}
public List getItems() {
return customer;
}
public AddressInfo getAddress() {
return customer;
}
//but NO setters!
}

Aggregation attributes already exist, but Bill needs them to be a full object, so their references are taken in the constructor, so we don’t risk we find ourselves with a Bill without a Customer. The same goes for the list of Item(s).

In the other hand, an AddressInfo doesn’t exist as an individual entity but helps to encapsulate a set of attributes that might change over time. So the AddressInfo lives as long as the Bill has a reference, otherwise they both go together to the garbage collector.

Agreement.

The whole point of these efforts are to agree what a model will mean. You might decide in your enterprise these implementations are not good for you and changed them. But do it before modeling and then communicate it, so everybody will be modeling something that everybody will be able to implement in a standard way. This means clear and useful models.