Class Design

Could someone make a suggestion for this, and to make
things simple lets assume every order can only have one
product. (eliminating order details object)

If I have a Order, Product and ShipType object do I return
and Product object as a property of the Order object. Or
do I simply store the productID into an int property of
the order object. Same with the shiptype. I just read
this chapter in an OOP practices book where they were
storing the ID... is this correct?

-mike

Girish
Thu Nov 06 10:08:47 CST 2003

mike morse wrote:

> Could someone make a suggestion for this, and to make
> things simple lets assume every order can only have one
> product. (eliminating order details object)
>
> If I have a Order, Product and ShipType object do I return
> and Product object as a property of the Order object. Or
> do I simply store the productID into an int property of
> the order object. Same with the shiptype. I just read
> this chapter in an OOP practices book where they were
> storing the ID... is this correct?
>
> -mike

Well, "It depends"(tm) .. :)
If you are guaranteed that these three objects are going to live in the
same process space, then storing the ID and using that to look up more
information should be ok. Otherwise, if you are thinking of this being
either distributed or based on a web service, you might be better of
sending the object as the response. Since .NET support serialization
pretty cleanly, you would not notice that big a hit.



--
Girish Bharadwaj

Morse
Thu Nov 06 11:28:25 CST 2003

Yeah but wouldn't it be better if from the Order object
you would directly return the product object and
properties? It seems like it would be more work to have
the order object get the id and then have to create
another product object and look it up with the id.

I'm really just trying to understand if return related
objects from properties is a good practice when trying to
make a truely OO architecture.

-mike


>-----Original Message-----
>mike morse wrote:
>
>> Could someone make a suggestion for this, and to make
>> things simple lets assume every order can only have one
>> product. (eliminating order details object)
>>
>> If I have a Order, Product and ShipType object do I
return
>> and Product object as a property of the Order object.
Or
>> do I simply store the productID into an int property of
>> the order object. Same with the shiptype. I just read
>> this chapter in an OOP practices book where they were
>> storing the ID... is this correct?
>>
>> -mike
>
>Well, "It depends"(tm) .. :)
>If you are guaranteed that these three objects are going
to live in the
>same process space, then storing the ID and using that to
look up more
>information should be ok. Otherwise, if you are thinking
of this being
>either distributed or based on a web service, you might
be better of
>sending the object as the response. Since .NET support
serialization
>pretty cleanly, you would not notice that big a hit.
>
>
>
>--
>Girish Bharadwaj
>
>.
>

lukezhan
Fri Nov 07 00:27:57 CST 2003

Hi Mike,

I agree with you that is it more convenient to leave Product as a property
of order. And I think this is also a better OO design than including a
Product ID. Normally, we can use the design with ID in database, DataSet or
XML document. For an actual Order object, it is better to keep product as a
property. (in fact, it is a reference to a Prodcut object)

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Mike
Fri Nov 07 08:30:07 CST 2003

Thank you for the input. It is appreciated.

-mike
>-----Original Message-----
>Hi Mike,
>
>I agree with you that is it more convenient to leave
Product as a property
>of order. And I think this is also a better OO design
than including a
>Product ID. Normally, we can use the design with ID in
database, DataSet or
>XML document. For an actual Order object, it is better to
keep product as a
>property. (in fact, it is a reference to a Prodcut object)
>
>Luke
>Microsoft Online Support
>
>Get Secure! www.microsoft.com/security
>(This posting is provided "AS IS", with no warranties,
and confers no
>rights.)
>
>.
>