Vista - OO design question

Hi!

I am designing a 3-layer architecture and have run into a design issue
where I would like som input on best practise.

Today I have a Member class, and a Person class. My object can then be
used like Member.Person.Name. The Person object holds specifics to a
person like firstname, lastname etc. The Member class holds things
like memberid etc.

Now I am constructing a Customer object. A Customer can either be a
Person (private customer), or a Company (business customer). I was
thinking of having a Person and a Company object as a property on the
Customer object. But that would mean for each Customer.Person object,
there would be an empty Customer.Compay object that holds nothing and
vice versa.

Any input on how to solve this in a nice way?

Are all Persons customers, and all Companies? If so, they could derive from
Customer.

Kevin.

<jostein.solstad@xxxxxx> wrote in message
news:ff9126d4-6a16-409d-b04d-95d9f026d6f6@xxxxxx

Be aware that this mostly fails not as OO but as implementation.

A Customer can have a collection of one or more persons.
In fact it are different entities and therefore different classes.

To give another analogy
You will not derive from a plane class a passenger class, however in this
case you try to do it.

Cor

No, not all Persons are Customers, a Person could also be a Member
(like a member of a web page etc), or in fact any other place where i
need "personal data". A Customer has a 1-1 link to Person if this is a
private Customer, and a 1-1 link to Company if it is a business
customer.

On Thu, 14 May 2009 23:27:04 -0700 (PDT), jostein.solstad@xxxxxx
wrote:
Although it is for a web app I suggest examining "Walkthrough:
Managing Web Site Users with Roles" at
http://msdn.microsoft.com/en-us/library/t32yf0a9.aspx
While it may not be what you want or need the walkthrough can provide
a little more insight into what you're trying to do.
Reconsider the Customer type. The container's content doesn't describe
a customer as it describes a customer's account. Class members might
include a Contact of type Person, a BillingAddress of type Address, a
ShippingAddress of type Address ....

The point is as an account there isn't that much difference whether
the actual customer is an individual or a business entity. If there is
a greater difference than I can see, the account type can be
subclassed into types specific to individuals and businesses.

regards
A.G.

I'm still not sute I get this. Or maybe I have described my situation
in a wrong way. I'll explain a bit more in detail.

The Member class is not a typical member/role situation. Here, a
Member is like a Member of a club. Like it has a valid from and valid
to date, membership number etc.

The Customer is a regular Customer in an online shop on the web page.
You do not have to be a Member to be a Customer and you do not have to
be a Customer to be a Member.

So far I created the Person class to have person specific data, like
firstname, lastname, birth date etc. All the data in the Person class
is valid for both a Customer and a Member, that's why I wanted a
Person class to handle this. Now, the problem is that a customer can
also be a company. The company does not have first name, last name,
birt date etc. So how do I create the structure so that it should
handle both Person and Company as a Customer. Mind, in a list of
Customers, I need to be able to represent them both..

On Fri, 15 May 2009 09:00:26 -0700 (PDT), jostein.solstad@xxxxxx
wrote:
OKI assume a Member can also be a Customer. To me this suggests two
roles, Member and Customer. This would allow an entity to have a
membership in either or both roles. Depending upon what you're trying
to do, an alternative might be making the Member a Customer by
default. I'm thinking a Member can be a Customer who hasn't made a
purchase yet.
So what you're really saying is the Person class is not suitable for
all Customers i.e. Customers that are companies.
If I understand the scenario correctly an entity can be both a
Customer and a Member. Now if a Customer is a company then a company
can also be a Member. This means the Person class is not suitable for
all Members either i.e. Members that are companies. The initial
concept of Members and Customers always being of type Person is where
the problem originates. Let's look at it differently.

The big commonality between individuals and companies using the
front-end is they have to somehow register to be a Member, a Customer
or both. When an entity registers, an account is opened. This can be
represented by an Account type.

Members of the Account type would include the Role(s) along with an
AccountName. The AccountName property doesn't have to be tied to the
name of an individual or company, it is just a way to identify the
account.

Since the account can be used to buy stuff BillingAddress and
ShippingAddress members will also be needed. The account will also
need to include contact information. This would be either the
individual represented by the account or the individual selected by
the company represented by the account. The Account type can be
fleshed out to include whatever other information is pertinent to the
account.

I realize this may not be the solution you desire but you do need to
back away from the design flaw where everything is exclusively based
upon the Person type.