Question

I am modelling the domain model in my application. Obviously, some of the object relationships are assocations, but those associations also have attributes. For example:

Foo can have one-to-many Bars. However, the association has attributes, such as a date range for how long that association is valid. So, the way I have done this is as follows:

public interface Association<S, T> {
     public S getSource();

     public T getTarget();
}

Then for something like the above:

public class FooToBarAssociation implements Association<Foo, Bar> {
    public Foo getSource();
    public Bar getTarget();
    public Date getFromDate();
    public Date getToDate();
}

Then the Foo class has:

private List<FooToBarAssociation> associations;

My questions are:

1. Is this an appropriate way to model the association with attributes?

2. Where should the business logic be for adding/removing the associations to Foo? Creating a FooToBarAssociation will sometimes require a bit of business logic and I’m wondering if that should be handled in a FooService, which then calls setAssociations rather than being in the model object. I’ve always heard to keep biz logic out of the model objects as much as possible.

Answer 1

IMHO same rules apply as when you implement association classes in UML.
What you created is one way, other might be nesting – Foo contains Assoc which in turn contains Bar. You can create it also the other way around Bar containing Assoc and Assoc containing Foo. Foo can contain Assoc and Bar can contain Assoc. There are many possibilities, it depends only on you requirements.
In your example your solution looks good.
What you heard seems good, but sometimes it might be complicated.