Object Design Question

[Don Miller]

Here's what I want to do... sorry for the lengthy description ;-)

I have an inventory tracking system with items that I track stock levels on.
Some items are counted with decimal precision (double) and others are counted
using integers; the database record has a flag that says what kind of item a
particular record is (double or integer). I've created an abstract class
called ItemBase and I implement a concrete class (Item) that inherits from
ItemBase. ItemBase has abstract methods that allow me to get/set the quantity
in stock, or manage collections of items; those methods are implemented in
the concrete class Item. The Item class would be a central part of the
inventory tracking system and I don't want programmers to constantly write
code to check the precision of the number being passed into the methods, I
want to make the counting methods type safe based on the flag in the item's
database record.

Here's an example. When an Item ID is entered into some UI, I want the
client code to be able instantiate an Item object via an Item Factory that
reads the record, figures out what kind of item to build (integer or double)
and hand it back to the client without the client knowing or caring whether
it gets back an integer version or a double version of the Item class. Sounds
easy enough if you're thinking of using generics, but generics requires you
know the type you want when you declare the client instance. Likewise with a
decorator pattern, you have to know in advance what type to create ('cause
even if you decorate a standard Item class with an integer decorator class,
you still have to create your object as the integer decorator in order to
make it's methods visible). I also investigated using Reflection.Emit , but
that doesn't seem like the proper solution either (particularly since it
would make coding more difficult in the long run and clients couldn't code
against an API).

What I want is a completely ignorant client, who gets a type safe Item
object, with integer methods or with double methods, based on what the Item
Factory discovers from the database about the item passed in during object
creation. Anyone have any ideas?

Thanks!
Don
do**********@gm ail.com

[Randolpho]

>From the original post:

ItemBase has abstract methods that allow me to get/set the quantity
in stock, or manage collections of items; those methods are implemented in
the concrete class Item.

The get/set quantity portion implies he wants to modify the value. To
do that in a typesafe way, he cannot hide the value, as the programmer
using the object will need to know what type of value the item uses in
order to use it properly. Hiding it in a string, or even as an object,
is not typesafe.

However, it occurs to me that it's possible to build this system such
that even though the type of quantity for a particular item is not
known at compile time, it is still obtainable during runtime. That
would allow a programmer to use either an integer value or a float
value depending on the situation.

The simplest way would be to have a base class ItemBase that implements
two get/setters -- ValueInt and ValueFloat, and an ItemType property
that indicated whether the Item is an Int or a Float through an enum.
The concrete classes, ItemInt and ItemFloat, would implement one
getter/setter and throw on the other getter/setter. The programmer
could then simply check the ItemType before using the value, and use an
integer or float type as appropriate.

Wow, that pretty much mirrors the original database.

[Registered User]

On Wed, 3 May 2006 04:58:02 -0700, Don Miller <Don
Mi****@discussi ons.microsoft.c om> wrote:

Here's what I want to do... sorry for the lengthy description ;-)
The quantity can be an int or a double but that value is means nothing
without a unit of measure. Rules based upon UOM can be used to
determine the validity of a quantity. A single item can have multiple
UOMs if the UOM is included as part of a key. The inventory for an
item could be reported as two pallets, three cases and 17 individual
units. With the UOMs known calculating the total number of individual
units won't be complicated. The physical conversion from pallet to
cases or case to items can easily be reflected in the database as
well.

regards
A.G.
I have an inventory tracking system with items that I track stock levels on.
Some items are counted with decimal precision (double) and others are counted
using integers; the database record has a flag that says what kind of item a
particular record is (double or integer). I've created an abstract class
called ItemBase and I implement a concrete class (Item) that inherits from
ItemBase. ItemBase has abstract methods that allow me to get/set the quantity
in stock, or manage collections of items; those methods are implemented in
the concrete class Item. The Item class would be a central part of the
inventory tracking system and I don't want programmers to constantly write
code to check the precision of the number being passed into the methods, I
want to make the counting methods type safe based on the flag in the item's
database record.

Here's an example. When an Item ID is entered into some UI, I want the
client code to be able instantiate an Item object via an Item Factory that
reads the record, figures out what kind of item to build (integer or double)
and hand it back to the client without the client knowing or caring whether
it gets back an integer version or a double version of the Item class. Sounds
easy enough if you're thinking of using generics, but generics requires you
know the type you want when you declare the client instance. Likewise with a
decorator pattern, you have to know in advance what type to create ('cause
even if you decorate a standard Item class with an integer decorator class,
you still have to create your object as the integer decorator in order to
make it's methods visible). I also investigated using Reflection.Emit , but
that doesn't seem like the proper solution either (particularly since it
would make coding more difficult in the long run and clients couldn't code
against an API).

What I want is a completely ignorant client, who gets a type safe Item
object, with integer methods or with double methods, based on what the Item
Factory discovers from the database about the item passed in during object
creation. Anyone have any ideas?

Thanks!
Don
do**********@g mail.com

--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

[Don Miller]

Excellent point. I do have uom conversions in the design but hadn't thought
of using them in that way (i.e. for determining inventory quantity). After
much consideration, I think what I'm going to do is declare the quantity as
double throughout the app, then when it's determined the item should use
integers rather than doubles, I'll set some internal precision validator and
have the numbers validated against that (should have thought of that LAST
week!).

Thanks all for your comments--I hope I can return the favor some day...

"Registered User" wrote:

On Wed, 3 May 2006 04:58:02 -0700, Don Miller <Don
Mi****@discussi ons.microsoft.c om> wrote:

Here's what I want to do... sorry for the lengthy description ;-)

The quantity can be an int or a double but that value is means nothing
without a unit of measure. Rules based upon UOM can be used to
determine the validity of a quantity. A single item can have multiple
UOMs if the UOM is included as part of a key. The inventory for an
item could be reported as two pallets, three cases and 17 individual
units. With the UOMs known calculating the total number of individual
units won't be complicated. The physical conversion from pallet to
cases or case to items can easily be reflected in the database as
well.

regards
A.G.

I have an inventory tracking system with items that I track stock levels on.
Some items are counted with decimal precision (double) and others are counted
using integers; the database record has a flag that says what kind of item a
particular record is (double or integer). I've created an abstract class
called ItemBase and I implement a concrete class (Item) that inherits from
ItemBase. ItemBase has abstract methods that allow me to get/set the quantity
in stock, or manage collections of items; those methods are implemented in
the concrete class Item. The Item class would be a central part of the
inventory tracking system and I don't want programmers to constantly write
code to check the precision of the number being passed into the methods, I
want to make the counting methods type safe based on the flag in the item's
database record.

Here's an example. When an Item ID is entered into some UI, I want the
client code to be able instantiate an Item object via an Item Factory that
reads the record, figures out what kind of item to build (integer or double)
and hand it back to the client without the client knowing or caring whether
it gets back an integer version or a double version of the Item class. Sounds
easy enough if you're thinking of using generics, but generics requires you
know the type you want when you declare the client instance. Likewise with a
decorator pattern, you have to know in advance what type to create ('cause
even if you decorate a standard Item class with an integer decorator class,
you still have to create your object as the integer decorator in order to
make it's methods visible). I also investigated using Reflection.Emit , but
that doesn't seem like the proper solution either (particularly since it
would make coding more difficult in the long run and clients couldn't code
against an API).

What I want is a completely ignorant client, who gets a type safe Item
object, with integer methods or with double methods, based on what the Item
Factory discovers from the database about the item passed in during object
creation. Anyone have any ideas?

Thanks!
Don
do**********@g mail.com

--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

[Don Miller]

That's about as close as I'm going to get I'm afraid. In my strugle to solve
the small problem I kinda lost sight of the bigger problem: what type are the
programmers going to set their code to use?!?!?

It's been a very enlightening discussion and thank you both for your input.

"Randolpho" wrote:

From the original post:

ItemBase has abstract methods that allow me to get/set the quantity
in stock, or manage collections of items; those methods are implemented in
the concrete class Item.

The get/set quantity portion implies he wants to modify the value. To
do that in a typesafe way, he cannot hide the value, as the programmer
using the object will need to know what type of value the item uses in
order to use it properly. Hiding it in a string, or even as an object,
is not typesafe.

However, it occurs to me that it's possible to build this system such
that even though the type of quantity for a particular item is not
known at compile time, it is still obtainable during runtime. That
would allow a programmer to use either an integer value or a float
value depending on the situation.

The simplest way would be to have a base class ItemBase that implements
two get/setters -- ValueInt and ValueFloat, and an ItemType property
that indicated whether the Item is an Int or a Float through an enum.
The concrete classes, ItemInt and ItemFloat, would implement one
getter/setter and throw on the other getter/setter. The programmer
could then simply check the ItemType before using the value, and use an
integer or float type as appropriate.

Wow, that pretty much mirrors the original database.