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

[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*******@cana da.com> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.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, InternationalCo ntactData, You keep your changes
localized to your ContactData concrete classes instead of having
possibly the same logic spread out in your BusinessEntitie s.

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 PrintAddressLis t(List<IHasAddr ess> 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 turtle2MachSpee d = 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.I nches);
Measure width = new Measure(15, UnitOfMeasure.I nches);
Measure length = new Measure(20, UnitOfMeasure.F eet);
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.GetAmoun t(UnitOfMeasure .Cc);

or

Measure volumeInCcs = volume.ConvertT o(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.D egrees, 52.2);
decimal distance = point1.Distance To(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.