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*********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.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*********@gmail.com> a écrit dans le message de news:
11*********************@f14g2000cwb.googlegroups.c om...

| 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 IndividualCustomer and
CorporateCustomer. That's fine... they're subclasses of Customer. But
then perhaps you have IndividualSuppliers and CorporateSuppliers too,
and perhaps you have a customer who is also a supplier. Now what? Do
you have a CorporateCustomer object and a CorporateSupplier 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 PhysicalLocation, 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.MinValue, 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.Add(new PureData(15, "Harry");
pureDataList.Add(new PureData(27, "Frank");
pureDataList.Add(new PureData(355, "Mary");
....
PureData mary = (PureData)pureDataList[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.

[KJ]

Point taken. Perhaps structs aren't the best choice here, especially
for a newbie. And, just for my benefit, and that of any readers of this
thread, could you please post a few notes about when structs are
appropriate? That would help round this out.

p.s. I do still like my point about using delegation -- a good thing
for a beginner to get a grasp on, especially when deep (ridid)
inheritance hierarchies can creep into existence.

p.p.s. Another great place to discuss things of this manner is
comp.object. There are some real OO heavyweights who linger there.

[Kalpesh]

Thank you all for your inputs
Assuming I want a report to be printed (which is like Address book),
for customers, supplier address etc

For which, I can write a base class function (which returns the address
data in some formatted way)
eg string allinfo()

Now, supplier, customer etc can override this method & provide with
their own implementation

What do you say ?

Kalpesh

[Jeff Louie]

Kalpesh.... You may want to consider a special type of inheritance using
interfaces. An interface is just like a base class without any
implementation
details and a class in C# can implement zero or more interfaces. So I
can
think of two approaches to generic printing. An IPrintable interface so
that
each address implements IPrintable and knows how to print itself using a
graphics object and position and provides methods that return its size.
Or an
IXML interface that returns an XML formatted address.

interface IXML {
string ToXML();
}

interface IPrintable {
void Draw(Graphics g, Point position);
}

public class Address : IPrintable, IXML {
void Draw(Graphics g, Point position) {
...}
string ToXML() {
..}
}

public class Customer : IPrintable {
private Address a;
void Draw(Graphics g, Point position) {
.... customer stuff
a.Draw(g, pos);
.... more customer stuff
}
}
Regards,
Jeff

Assuming I want a report to be printed (which is like Address book),

for customers, supplier address etc

For which, I can write a base class function (which returns the address
data in some formatted way)
eg string allinfo()

Now, supplier, customer etc can override this method & provide with
their own implementation<
*** Sent via Developersdex http://www.developersdex.com ***

[Kalpesh]

While, there are many approaches - I would like to know - if this
approach is not good & what are the reasons supporting it ?

Thanks
Kalpesh

[Goran Sliskovic]

"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

...
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++.

....

This is a myth. No, in C++ there is actually no much difference between
class and struct. Buth can have constructors/destructors, virtual methods
etc. The only difference is that default member access for struct is public
and default inheritance access is public, as oppose to private in classes.

Regards,
Goran

[john_teague]

Kalpesh,
OO design is the "Art" of Programming these days. All of the
approaches mentioned are acceptable. The "Best" approach really depends
on your situation and only you can really answer that.

As for my position, I like something close to Jeff's and Tony's
response, where you have an Address / Phone class that associated with
your business. The reason I prefer this is that if more closely
follows the Open-Closed Principle (perform google search for more
info).

This would allow you to specialize based on the differences of
Addresses versus differences of BusinessEntity. This way, if your
different business enities use the same type of Address data, say
USContactData, InternationalContactData, You keep your changes
localized to your ContactData concrete classes instead of having
possibly the same logic spread out in your BusinessEntities.

With keeping with the Open-Closed, If you have an BusinessEntity that
requires a different type of contact data, you don't need to modify
your business entity object, just create a new ContactData class and
use where needed. This should help keeping the number of specialized
BusinessEntity objects low and better encapsulate contact data logic
for more reuse.

hth,
John

[Bruce Wood]

There are several difficulties with this design.

First of all, I assume that you are proposing putting the Allinfo
method in your BusinessEntity base class, from which Customer and
Supplier derive. The best way to show why this is problematic is by
asking some questions: "Will all business entities, including any you
create in the future, have addresses to print?" "Will every entity that
has addresses be a BusinessEntity? What if in the future that are
things that have addresses, etc, but they aren't business entities in
the same sense as a Customer or a Supplier?"

Second, there is the formatting problem. Is it really any business of a
Customer, or a Supplier, to know how to format address data for
printing in an address list? If you want to change the appearance of
your address list, would you hunt for the formatting code in an
AddressList class, or in a Customer class? I would look in AddressList,
or maybe AddressInfo.

Third, the name "Allinfo" is a dead giveaway that something's amiss
here. Vague method names like "Allinfo" or "GetInfo" tend to indicate
that the method / property isn't clearly defined, that you're trying to
cram too much into one method / property, so much so that you can't
think of a specific name for it. In this case it may just be the late
hour, or whipping up a quick example, but it's something of which to be
wary.

This is a situation in which I would use an interface, let's call it
IHasAddress, for the sake of illustration. IHasAddress would insist
that any implementing class have a couple of properties:

public interface IHasAddress
{
// Returns the address object for the business entity, which
contains the street
// address broken up into various properties.
AddressInfo AddressInfo { get; set; }

// Returns the name of the business entity, "Bob's Software House,"
for example.
string[] Name { get; set; }
}

where AddressInfo is some class that holds your address information.
(Remember, this is just for illustration. If you really wanted to print
a report of contact information, you might call it IHasContactInfo and
return a ContactInfo class, or an array of ContactInfo, or something
like that. This is just an example.)

Now, you have Customer and Supplier (or BusinessEntity, depending)
implement IHasAddress:

public class Customer : BusinessEntity, IHasAddress
{
...
}

And, finally, you make yourself an AddressList class. This class has
(at least) a method to which you can pass a collection of IHasAddress
objects and it will fetch, sort, and format the addresses:

public class AddressList
{
...
public void PrintAddressList(List<IHasAddress> entities) ...
}

(Here I used the .NET 2.0 generic list, but you could just as easily
make it an IHasAddress[] array or an ArrayList or something like that.)

Now you can make any object in your class hierarchy an "address"
object, and print the address of any of them regardless of what they
are, so long as they implement the IHasAddress interface. You have also
put the address formatting code into AddressInfo (or AddressList) which
is a more logical place for it than in Customer or Supplier.

[Bruce Wood]

> could you please post a few notes about when structs are appropriate? That would help round this out.

In C#, you want to use a struct whenever you have something that should
_act like a value_. That's really the bottom line: is this something
that is involved in calculations (which don't necessarily have to be
traditional +, -, *, etc.). The world abounds with value types:
anything that is a measurement, for example, is a good candidate for a
value type in C#. Some examples: pressure, temperature, speed, weight,
dimensions, age. Monetary values also stand out as great examples.

"But wait," you say, "I can represent all of those things using the
decimal type!"

True, but then you lose track of units, unless you remember to encode
them in variable names. (In fact, that idea that "I could represent
that with a decimal," (or a double, or an int...) is a hint that maybe
it would make a good value type.) Contrast this:

decimal turtleSpeed = 1;

with this

Speed turtle1Speed = new Speed(1, SpeedUnits.Mph);

In the first case, you have no idea how fast that is. In the second
case, you know that it's pretty slow (well, not for a turtle, but it's
pretty slow for us). The payoff is that you can pass turtleSpeed
throughout your program as an argument, etc, and you always know that
it's 1 mile per hour, and not

Speed turtle2Speed = new Speed(1, SpeedUnits.Mach);

which would be a turtle shot from a cannon. Now, so far struct versus
class hasn't really bought us anything. It doesn't until you say:

Speed twoTurtleSpeed = turtle1Speed < turtle2Speed ? turtle1Speed :
turtle2Speed;

Here, a Speed acts like a value: twoTurtleSpeed is a copy of (in this
case), turtle1Speed, just as it would be if it were an int or a
decimal. The type also offers the possibility of automatic conversions:
here we compared miles per hour with Mach speed measurements and
decided which one was less. Try that with:

decimal turtle1MphSpeed = 1;
decimal turtle2MachSpeed = 1;

....your client code has to do the math, rather than relegating it to a
Speed struct, where it belongs.

I work in the wood industry (thus the moniker), and we do a lot of
mathematics with dimensions and weights. structs are a natural fit for
this. I can do things like this:

Measure thickness = new Measure(1.5, UnitOfMeasure.Inches);
Measure width = new Measure(15, UnitOfMeasure.Inches);
Measure length = new Measure(20, UnitOfMeasure.Feet);
Measure volume = thickness * width * length;

without worrying about conversion headaches, or what units "volume"
should have. The Measure class can take care of all of that for me.
Then I can pass "volume" to another method and that method will know
exactly what volume that represents, units and all:

decimal volumeInCcs = volume.GetAmount(UnitOfMeasure.Cc);

or

Measure volumeInCcs = volume.ConvertTo(UnitOfMeasure.Cc);

Automagical conversions, at your fingertips. Note that in the second
example conversion, the ConvertTo method _returns a new Measure_. It
does _not_ modify the value in "volume".

There are other uses for structs, of course: Microsoft made Point and
Rectangle structs, because (I believe) they do lots of coordinate math
inside their graphics packages. The only thing that MS did that I
disagree with is that they made them _mutable_ structs: structs with
"set" methods on their properties. I find that mutability causes more
problems than it solves in structs, and I prefer to avoid it. That
aside, any kind of coordinate system is a good candidate for structs,
as we naturally tend to think of coordinates as values. Imagine being
able to do this:

Coordinate point1 = new Coordinate(1.5, 6.6, 18.8);
Coordinate point2 = new Coordinate(95, UnitOfMeasure.Degrees, 52.2);
decimal distance = point1.DistanceTo(point2);

Mixing Cartesian and circular coordinate systems? No problem. It just
works.

Anyway, those are some examples. Note that the common denominator is
that all of these things naturally act like _values_: you expect them
to be copied, and you expect operations on them to yield new values,
not alter existing values. In fact, none of these things (a speed, a
temperature, a point in space, etc) has the concept of _identity_: one
point (5,5) is exactly like any other point (5,5). We typically don't
talk about "that 5,5" versus "this 5,5". It doesn't have a UID
(although it could _serve_ as a UID for something else).

Hope all of that helps. :-)

I do still like my point about using delegation

Yes, I thought that was good, too. :-)

[Bruce Wood]

> This is a myth.

OK, I stand corrected: structs in C++ can have methods. However, my
basic point stands, which is that "struct" in C# means something very
different from "class", whereas in C++ it doesn't, much.

The bottom line is that you can't can't bring C++ thinking about
"struct" versus "class" into the .NET world. The "struct" keyword is
the same but the meaning is very different in the two languages.

[Bruce Wood]

> The Measure class can take care of all of that for me.

Brain fart: I should have written:

The Measure struct can take care of all of that for me.

[Jeff Louie]

KJ...With .NET 2.0 you can implement delegation using generics!

using System;
using System.Collections.Generic;
using System.Text;

namespace GenericMI
{
// first we create the abstractions
public interface I1
{
void SayHello();
}
public interface I2
{
int GetValue();
}
public interface IProgram : I1, I2 { }

// second we write the concrete classes that implement the
abstractions
public class Implementation1 : I1
{
public void SayHello()
{
Console.WriteLine("Hello.");
}
}
public class Implementation2 : I2
{
private int i = 1;
public int GetValue()
{
return i;
}
}
// finally we write the wrapper class that contains
// the concrete classes
public class GenericMI<T1, T2> : IProgram where T1 : class, I1,
new()
where T2: class,I2, new()
{
private T1 pimplI1= new T1();
private T2 pimplI2 = new T2();
// we forward calls to the contained object
public void SayHello()
{
pimplI1.SayHello();
}
public int GetValue()
{
return pimplI2.GetValue();
}
}
class Program
{
static void Main(string[] args)
{
GenericMI<Implementation1,Implementation2> mi=
new GenericMI<Implementation1,Implementation2>();
mi.SayHello();
Console.WriteLine(mi.GetValue());
Console.ReadLine();
}
}
}

Regards,
Jeff

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

[Kalpesh]

Hi Everyone,

Although the discussion digressed a little, I got to see different view
points

Bruce, I liked your design :)
John - I will be reading the open-closed principle

I think, it requires great amount of understanding of domain (context),
before designing classes. So, making something base class, based on
common data - MIGHT not be a good idea.

Also, if I make address as part of BusinessEntity, it is kind of a
closed design
However, good discussion helps see different perspective

Thank you everyone & happy x'mas
Kalpesh

[john_teague]

Real Quick, paraphrased Open-Closed principle means "Open for
extensibility, closed for modifications" This means that if you need
to add functionality to a system you do it by writing new code and not
modifiy existing code. Making address part of BusinessEntity is the
opposite of what I'm talking about if there is different functionality
associated with address data.

Good Luck.

[Kalpesh]

Thank you everyone for your views

Kalpesh

[Dave Johnson]

would u please show the Aggregation instead of inheritance in code.

you seem you have experiance doing it before which many coder and i am
one of them didnt encounter the need to do it yet.

would be very please to see any simple code explaining it

Thanks a lot

Sharing makes All the Difference

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com