If it is important to have one-to-many relationships represented in your code, you could make an Association object, with 1-1, 1-N, and N-N versions. I've seen this several times, and it seemed a little kludgy, but it worked.  

My preferred solution is to have coding conventions for representing relationships. When I see an interface addEmployee:, removeEmployee:, and employeesDo: I know that the object has a set of employees. When I see an interface employer and employer: I know it has only one employer. This particular problem is best solved by idioms, in my opinion.

-- RalphJohnson

See also: MultiCaster