views:

71

answers:

2

Let's say you've got two applications for working with "Customers"... one might be an account management application, the other might be a support / helpdesk application. Both applications use the same Customer entities... by that I mean they both hit the same datasource to manage Customers.

At a basic level, a Customer is exactly the same to both applications. It has addresses, phone numbers, and so on. Where things start to diverge might be on what a Customer "has". That is, a Customer in the account management application might have a collection of Orders, and the Customer in the support application might have a collection of TroubleTickets. But the support application doesn't care about Orders, and the account management application doesn't care about TroubleTickets.

Now I could have a CustomerService that returned mega customers that had every property that a Customer could ever have for every application that deals with Customers. Or I could extend a base Customer and create a specialized Customer for each application. I could consider only having a one-way relationship from things like Orders to Customers, so that a Customer doesn't have an Order collection, but an Order would have a Customer, and an Order service would have a method like getOrdersForCustomer(Customer).

What advice can you offer, and what specific reading might you recommend on this subject?

+1  A: 

I don't think I'd use composition to model either situation. I'd reify a separate object to encapsulate both. Ownership of TroubleTickets or Orders is not the essence of a Customer.

For example, a Person might be playing the role of a Student in a system for tracking a university. The Catalog might have a collection of Courses that Students can register for, but I wouldn't embed ownership inside the Student. I'd reify a Transcript that encapsulate a Student with their Courses and give me a place to associate Grades.

Same ideas for your problems. Don't be too quick to use composition in this case. Think "roles" and reification.

duffymo
Yes of course, thanks. I think I got a little bit ahead of myself.
Boden
A: 

There are a few options that spring to mind:

  • Extend a base class, as you have already suggested.
  • Use mixins/traits if your language supports them
  • Make use of a class variable that is a collection of different Roles.
Matt