OO Design question

[Kalpesh]

Hello All,

Please help validate this design problem

Assume that I have several entities in my project (eg Supplier,
Customer etc).
All of them save several common properties - name, address, city,
state, zipcode etc

I thought of making a base class - BusinessEntity (with all of the
above properties)
Then, create Supplier/Customer class which derives from BusinessEntity
& have their own specialized behaviour.

Is this approach valid ?

Also, can a class be made base class solely on the basis of common
data, that it can hold ?
In my example, there is no point repeating (name, address...) in
Supplier, Customer
Hence, I think of creating BusinessEntity with all the above properties
So, is it valid to have base class with only data & no behaviour
(methods) ?
I would love to hear arguments in favour/against of the above approach

Cheers
Kalpesh

[RCS]

Yes, I'd say that's valid.. and there was a good posting last week that had
an example of this (although I couldn't find it).. You could/should break it
down even further:

Have Supplier and Customer inherit from BusinessEntity. .

And BusinessEntity has several members, something like:

public PhoneEntry MainPhone = new PhoneEntry();
public PhoneEntry MainFax = new PhoneEntry();
public PhoneEntry TollFreePhone = new PhoneEntry();

public Contact MainContact = new Contact();
public Contact SalesContact = new Contact();
public Contact SupportContact = new Contact();

And PhoneEntry could have like EntryName, Number, NumberFormatted - Contact
could have Name, Address, and perhaps several "PhoneEntry " fields that hold
homephone, business, mobile, fax, etc..

So yes, it's a good thing to break up any repeating functionality into it's
own class.. HTH

"Kalpesh" <sh*********@gm ail.com> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...

Hello All,

Please help validate this design problem

Assume that I have several entities in my project (eg Supplier,
Customer etc).
All of them save several common properties - name, address, city,
state, zipcode etc

I thought of making a base class - BusinessEntity (with all of the
above properties)
Then, create Supplier/Customer class which derives from BusinessEntity
& have their own specialized behaviour.

Is this approach valid ?

Also, can a class be made base class solely on the basis of common
data, that it can hold ?
In my example, there is no point repeating (name, address...) in
Supplier, Customer
Hence, I think of creating BusinessEntity with all the above properties
So, is it valid to have base class with only data & no behaviour
(methods) ?
I would love to hear arguments in favour/against of the above approach

Cheers
Kalpesh

[Joanna Carter [TeamB]]

"Kalpesh" <sh*********@gm ail.com> a écrit dans le message de news:
11************* ********@f14g20 00...legro ups.com...

| So, is it valid to have base class with only data & no behaviour
| (methods) ?

It is valid, sometimes, but don't make a practice of it :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Bruce Wood]

> Also, can a class be made base class solely on the basis of common data that it can hold ?

That's not really a good way to design your class hierarchy. It's the
way that most people start out, just as most people who were learning
procedural programming split code out into a separate function only
when it was used in more than one place. After a while, though, one
tends to adopt a more sophisticated view of class hierarchy design.

Your idea of creating a BusinessEntity class isn't a bad one... I just
think that there are better reasons for doing it than that a couple of
things share data.

For me the important point here is that Supplier and Customer share
some common qualities in the real world, not just in the data that's
stored inside the computer. As a business, I can buy from (or sell to)
an (unincorporated ) individual or a corporation. I can also contract
services from an individual or a corporation. In fact, there are lots
of relationships that I can have with (external) individuals and
corporations, and in some ways they're interchangeable (in the real
world), and so it makes sense that somewhere in my class hierarchy I
would have a class that represents a generic external
person/corporation with which I'm dealing in some capacity (as a
supplier, a customer, or a contractor, or maybe some combination of
these).

So, a simple class design might be what you proposed: that there is a
BusinessEntity (some person or corporation external to my company) and
that Suppliers and Customers are BusinessEntitys .

That said, can you see how in a very large system things could quickly
become more complicated?

For example, it's fair to assume that Customers who are individuals, or
unincorporated, might have less complex information that Customers who
are corporations, so now you have IndividualCusto mer and
CorporateCustom er. That's fine... they're subclasses of Customer. But
then perhaps you have IndividualSuppl iers and CorporateSuppli ers too,
and perhaps you have a customer who is also a supplier. Now what? Do
you have a CorporateCustom er object and a CorporateSuppli er object that
really represent the same corporation? Your class hierarchy no longer
represents reality as well as it once did.

I don't have a handy class design up my sleeve for this... all I wanted
to point out is that in the end it's real-world concerns that should
dictate your class hierarchy. While "what data is stored where" and
"what data do classes have in common" may be useful questions to direct
your focus on real-world issues, it's the real world that is really the
bottom line.

For example, just because Customer and Supplier share an address and
phone number doesn't necessarily mean that they should derive from the
same base class. In this case, it seems a good idea, but SalesOffice,
an object representing some part of your own company, might not be a
good candidate for inheritance from the same base class as Customer and
Supplier. Perhaps a better solution with SalesOffice is to create a
class called PhysicalLocatio n, which in turn contains an Address object
and a ContactInfo object, which are also objects used in
BusinessEntity. Inheritance isn't the only way to share information.

[tonyt]

Instead of inheritance in this instance you might want to consider
aggregation. For example, you could have a contact class that contains the
phone number, address, etc. And that contact class would be nestled within
your Supplier and Customer classes.
--
Tony
http://geekswithblogs.net/tonyt
"Kalpesh" wrote:

Hello All,

Please help validate this design problem

Assume that I have several entities in my project (eg Supplier,
Customer etc).
All of them save several common properties - name, address, city,
state, zipcode etc

I thought of making a base class - BusinessEntity (with all of the
above properties)
Then, create Supplier/Customer class which derives from BusinessEntity
& have their own specialized behaviour.

Is this approach valid ?

Also, can a class be made base class solely on the basis of common
data, that it can hold ?
In my example, there is no point repeating (name, address...) in
Supplier, Customer
Hence, I think of creating BusinessEntity with all the above properties
So, is it valid to have base class with only data & no behaviour
(methods) ?
I would love to hear arguments in favour/against of the above approach

Cheers
Kalpesh

[KJ]

Today your base class *only* has common data. That may change tomorrow,
when you realize you need methods x y and z in your base class.

Pure data-only objects are well-expressed using structs. I suggest
instantiating your structs as private members of the base class, and
provide protected accessors to the structs' members so that the
subclasses can use them. This is sometimes known as
multiple-inheritance by delegation, and it helps keep things neat. It
also happens to be far more flexible than using multiple levels of
inheritance (base->subclass level1->subclass level 2 ...).

For example:

namespace Example
{
public class BaseClass
{
private PureData _pd;

public BaseClass() : this(int.MinVal ue, string.Empty) {}

public BaseClass(int id, string name)
{
_pd = new PureData(id, name);
}

protected string Name
{
get
{
return _pd.Name;
}
set
{
_pd.Name = value;
}
}

protected int ID
{
get
{
return _pd.ID;
}
set
{
_pd.ID = value;
}
}
}

public struct PureData
{
private int _id;
private string _name;

public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}

public int ID
{
get
{
return _id;
}
set
{
_id = value;
}
}

public PureData(int id, string name)
{
_id = id;
_name = name;
}
}
}

[Bruce Wood]

> Pure data-only objects are well-expressed using structs.

Sigh. Apologies for climbing back onto my well-worn soapbox, but no,
no, no... this is a C / C++ -ism and does not translate to C#.

"struct" in C# has very specific uses. It is not a "class-lite" and
should not be used like that. In particular, the example of PureData
given in your post is a _mutable_ struct: a struct with set methods. A
mutable struct is difficult to work with and should be used _only_ if
you get major payback for the pain you're going to suffer as a result
of using one.

Furthermore, structs cannot participate in inheritance, so you lose
polymorphism and all of the other goodies that come with the class
hierarchy.

IMHO, "struct" in C# is far more useful than it is in C++, where it is
nothing more than a hold-over keyword that indicates a class with no
methods, only data. In C# it allows you to create value types that can
act like the built-in value types (e.g. int, double, DateTime).
However, this also means that it shouldn't be in the same situations as
it would be used in C++.

You can see the following thread for more discussion on this point:

http://groups.google.com/group/micro...7ba80c02dd3cc8

[KJ]

Thank you for your response. I read the thread you posted, and, though
the discussion is relevant and enlightening, it is a tad different from
the usage (delegation) I suggested. Yes, a struct is a value-type. But
does this invalidate the example? An instance of PureData is still a
private member of BaseClass, inaccessable to derived classes. Perhaps
you can show how that could create a problem for derived classes?

[Jeff Louie]

Kalpesh... My gut reaction is to use containment for addresses. Create
zero or
more address objects and store them in the entity, perhaps as some type
of
generic collection. The lifetime of the addresses would be dependent on
the
lifetime of the entity (composition). So Address is an object. (OOP)

The second approach would be to generate a unique ID for each entity and
create a collection of addresses which hold entity ID's. You could then
lookup
addresses related to any entity at runtime. (Relational)

A customer seems like a giant container of information. The essential
aspect of
a customer and supplier is perhaps a unique financial identity that that
can
engage in contractural relationships. So customer and supplier could
inherit
from a class that uniquely defines a financial entity. Customers can
make
purchase and suppliers can make sales. A unique financial entity could
be both a
customer and a supplier!

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Bruce Wood]

> ...does this invalidate the example?

I wasn't taking issue with the example, but with the statement that
"Pure data-only objects are well-expressed using structs," which I
directly quoted. A very, very few objects are well-expressed as
structs, and it has nothing to do with whether they are pure data-only
or not. My Fraction class, for example, has a number of methods. I
found the statement misleading and wanted to correct the impression
that "data-only object" should lead one to think of "struct".

An instance of PureData is still a private member of BaseClass, inaccessable to derived classes. Perhaps you can show how that could create a problem for derived classes?

The field is inaccessible to derived classes, true, but the struct
itself is completely public and open to be used by other classes
(derived or not) in any way they see fit. In addition, as I pointed
out, PureData is mutable, which means that people will try to do things
like this:

ArrayList pureDataList = new ArrayList();
pureDataList.Ad d(new PureData(15, "Harry");
pureDataList.Ad d(new PureData(27, "Frank");
pureDataList.Ad d(new PureData(355, "Mary");
....
PureData mary = (PureData)pureD ataList[2];
mary.Name = "Mary Smith";

and then wonder why the data in their ArrayList doesn't change. As I
mentioned in the other thread, real-world objects with identities (ID,
Name) are poor candidates for C# structs. Programmers, newbies or not,
just don't expect objects like "Customer", "Invoice", etc. to act like
values.

All of this for... what? Why not just use a class? What does a struct
buy you here that a class wouldn't? I see no advantage to using struct
here, and several disadvantages, which brings me back to the original
statement that caught my attention:
Pure data-only objects are well-expressed using structs.

No, they're not, or rather the decision to use a struct or class is
tangential to that concern. There are lots of reasons to use structs,
but that's not one of them.