Domain Model/Object Design question

I'm trying to modem a relationship with classes and I'm having trouble
finding the correct design pattern. Maybe someone with more experience
knows which pattern(s) I'm looking for. Here's an explanation of what I
have and in which direction I'm thinking:

CLASS DESIGN
=============
1. Generic class "Company" contains general company information (name,
address, reference person, phone, etc...)

2. A class "Manufacturer", which is another type of company with a
particular function, namely that they manufacture products. It has
manufacturer-specific properties

3. A class "Publisher", which is a type of company with a particular
function, namely that they publish books. They could be considered a
"Manufacturer" as well, since they create books, but they do more than
just create them... they also publish them, and that's an action that
doesn"t apply to manufacturers in general. This class also has
publisher-specific properties.

4. A class "Distributor", which is yet another type of company with a
particular function, namely that they distribute products. They don't
necessarily create products, but only distribute them.
This class has distributor-specific properties.

5. A class CompanyFactory, which is responsible for company-related
actions such as CRUD actions, listing methods, etc...


REQUIREMENTS
=============
1. A company can be a manufacturer, publisher or distributor, or any
combination of these 3. It's possible for a company to have just 1 role
or have all 3.

2. In the UI I need to be able to display lists of companies by type
(e.g. a list of all manufacturers, a list of all distributors)

3. In code, I would like to see something like
//Create a new company that is both a publisher and a distributor
Company newCompany = new Company();
newCompany.Name = "Henle Verlag";
newCompany.IsPublisher = true;
newCompany.IsDistributor = true;

//This code returns the same object
Publisher publisher = CompanyFactory.GetPublisher("Henle Verlag");
Distributor distributor = CompanyFactory.GetDistributor("Henle
Verlag");

4. In the above code, could I somehow ensure that Company has the
IsPublisher, IsDistributor and IsManufacturer fields (probably related
to the corresponding DB field in table Companies), but that the derived
classes don't show this field (they don't need to because the class, by
its name, already knows what type it is)?

5. In the future, we may need additonal types of companies, such as
"sponsor".

DESIGN IDEAS
============
Thus far I came up with the idea that Company is a base class from
which Publisher, Distributor and Manufacturer are derived (inherited).
The problem with that is that a Publisher can also be a Distributor,
but a Publisher object cannot be changed into a Distributor object once
it's created as a Publisher object, or can it in some way? On the other
hand, if I instantiate the object simply as Company, then I don't have
the type-specific properties...
Related to point 4 of the Requirements, I have a visibility issue:
If I want CompanyFactory.GetPublishers to return a list of all
publishers, then I need to have access to the Company.IsPublisher
property, so it must be public. On the other hand, if I don't want to
see that property in the inherited Publisher class, it shouldn't be in
the Company class... what to do?

re: Domain Model/Object Design question

I would make four classes:

Manufacturer, Publisher, Distributor which each have information
specific to their scope and there is no inheritance relationship
between these classes--they're totally independent.

Then have one Company class which has the generic info all companies
have and then an optional instance of Manufacturer, Publisher,
Distributor. So each Company instance can be a Manufacturer,
Publisher, and/or Distributor based on it's composed classes. You
could create helper classes fo IsXXX and whatever else is needed to
make this scenario quicker to program.

HTH,

Sam


------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.



On 2 Jan 2007 09:25:00 -0800, "Froefel" <hansdeschryver@gmail.com>
wrote:

re: Domain Model/Object Design question

"Froefel" <hansdeschryver@gmail.coma écrit dans le message de news:
1167758699.961784.87620@k21g2000cwa.googlegroups.c om...

| DESIGN IDEAS
| ============
| Thus far I came up with the idea that Company is a base class from
| which Publisher, Distributor and Manufacturer are derived (inherited).
| The problem with that is that a Publisher can also be a Distributor,
| but a Publisher object cannot be changed into a Distributor object once
| it's created as a Publisher object, or can it in some way? On the other
| hand, if I instantiate the object simply as Company, then I don't have
| the type-specific properties...
| Related to point 4 of the Requirements, I have a visibility issue:
| If I want CompanyFactory.GetPublishers to return a list of all
| publishers, then I need to have access to the Company.IsPublisher
| property, so it must be public. On the other hand, if I don't want to
| see that property in the inherited Publisher class, it shouldn't be in
| the Company class... what to do?

This topic was answered only two weeks ago in this same group. My guess is
that this is a homework assignment ?

Nevertheless, forget deriving from Company, look at the idea of having a
Role base class, from which Publisher, Distributor and Manufacturer derive.
Then have a Roles property in the Company class.

This way a Company can optionally adopt any one or more Roles without
polluting the Company class with irrelevant details. You do not need a
Comapny.IsPublisher property, all the factory has to do is scan the
Companies, checking which ones have a Publisher object in the Roles list
property.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

re: Domain Model/Object Design question

I second the role based idea, this is the direction i would go in. Its
possible that a company could be both a Publisher & a Disributor, or as
you mentioned, a Publisher and a Manufacturer. So any given company
would have zero to many possible roles such as Publisher, Distributor,
Manufacturer. This is the only way you can change the roles at run
time. You can't change inheritance at runtime.

So a Company might have a Roles property, which is a collection of the
roles mentioned above. Also, each role (manuf., publisher, etc) may
need a reference back to their "parent" company, so you should do that
as well.

-Fregas

Joanna Carter [TeamB] wrote: