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]

Well...

It seems to me that your programmers will need to know the type either
way, and there's no getting around it. If you somehow created your
concrete class with integer methods or double methods, your programmer
will still need to know the difference when *using* those methods,
otherwise he might call an integer method with a double value, which
doesn't have an implicit cast. If you can somehow abstract the methods
out such that they don't require or return integer or double values,
you could just use an interface and have a factory method that returns
the concrete object cast to the interface. If not, your client needs to
know the difference.

Also, I have some problems with your database architecture. Why, why,
why, why are you tracking quantity with a double-precision value?
Quantity should always be integer value.

[Don Miller]

Thanks for your input Randolpho

On the use of double precision types for inventory counts, there are many
industries that use materials for manufacturing processes that are "measured"
rather than "counted". For example, one company I worked for atomized
precious metals, like gold, for use in soldering paste. The composition of
the end product (solder paste) is a very spcific and that company, rather
than reduce the unit of measure to something they could use as integers
preferred to use decimal inventory quantity. This got them 2 things: they
were able to match their product formulas to the bill of material eaasier and
they were to track the value of their inventory against the daily precious
metal prices, which were in troy ounces. Hope that helps.

"Randolpho" wrote:

Well...

It seems to me that your programmers will need to know the type either
way, and there's no getting around it. If you somehow created your
concrete class with integer methods or double methods, your programmer
will still need to know the difference when *using* those methods,
otherwise he might call an integer method with a double value, which
doesn't have an implicit cast. If you can somehow abstract the methods
out such that they don't require or return integer or double values,
you could just use an interface and have a factory method that returns
the concrete object cast to the interface. If not, your client needs to
know the difference.

Also, I have some problems with your database architecture. Why, why,
why, why are you tracking quantity with a double-precision value?
Quantity should always be integer value.

[Randolpho]

Ok, I suppose that makes sense. I had constructed in my head all sorts
of scenarios where a short-sighted database developer had concocted
some ludicrous means of measuring an item, where the first decimal
place meant one thing, and the second decimal place meant another
thing, and so on.

I suppose I've just been reading too much of The Daily WTF these days.
:)

[Göran Andersson]

That would be doable if you totally isolate the actual quantity value
from the client, and for an example only expose it as a readily
formatted string.

Don Miller wrote:

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

[Don Miller]

Can you elaborate on this a bit more please?

"Göran Andersson" wrote:

That would be doable if you totally isolate the actual quantity value
from the client, and for an example only expose it as a readily
formatted string.

Don Miller wrote:

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

[Göran Andersson]

An example, perhaps:

public class Item {

private Item() {} // nope, can't be created that way

public abstract string GetQuantity();

public static Item MakeItem(int quantity) {
return new IntegerItem(qua ntity);
}

public static Item MakeItem(double quantity) {
return new DouleItem(quant ity);
}

}

public class IntegerItem : Item {

private int quantity;

internal IntegerItem(int quantity) {
this.quantity = quantity;
}

public override string GetQuantity() {
return this.quantity.T oString();
}

}

public class DoubleItem : Item {

private double quantity;

internal DoubleItem(doub le quantity) {
this.quantity = quantity;
}

public override string GetQuantity() {
return this.quantity.T oString();
}

}

You create items:

Item item1 = Item.MakeItem(1 .0);
Item item2 = Item.MakeItem(1 );

Now you can only use the GetQuantity method on those items, and you
can't tell what data type they contain unless you check for the actual
type of the items, and even then you can't access the internal value.

Don Miller wrote:

Can you elaborate on this a bit more please?

"Göran Andersson" wrote:

That would be doable if you totally isolate the actual quantity value
from the client, and for an example only expose it as a readily
formatted string.

Don Miller wrote:

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

[Don Miller]

Thank you very much for your example! I think I can use this... I'll try it
tonight...

"Göran Andersson" wrote:

An example, perhaps:

public class Item {

private Item() {} // nope, can't be created that way

public abstract string GetQuantity();

public static Item MakeItem(int quantity) {
return new IntegerItem(qua ntity);
}

public static Item MakeItem(double quantity) {
return new DouleItem(quant ity);
}

}

public class IntegerItem : Item {

private int quantity;

internal IntegerItem(int quantity) {
this.quantity = quantity;
}

public override string GetQuantity() {
return this.quantity.T oString();
}

}

public class DoubleItem : Item {

private double quantity;

internal DoubleItem(doub le quantity) {
this.quantity = quantity;
}

public override string GetQuantity() {
return this.quantity.T oString();
}

}

You create items:

Item item1 = Item.MakeItem(1 .0);
Item item2 = Item.MakeItem(1 );

Now you can only use the GetQuantity method on those items, and you
can't tell what data type they contain unless you check for the actual
type of the items, and even then you can't access the internal value.

Don Miller wrote:

Can you elaborate on this a bit more please?

"Göran Andersson" wrote:

That would be doable if you totally isolate the actual quantity value
from the client, and for an example only expose it as a readily
formatted string.

Don Miller wrote:
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]

So... the solution is to abstract both the integer and the float into a
string. Hmm...

What happens when somebody wants to set the quantity? They'd have to do
something like MyItem.SetQuant ity("1.0"), and SetQuantity would parse
the string as either a float or an integer, depending on the underlying
type. Except... what happens if you call MyItem.SetQuant y("hello
world!")?

Yep.. definitely *not* type-safe, which was an original requirement.

Bottom line -- the programmer using the object needs to know the
difference between an integer quantity and a float quantity.

[Göran Andersson]

No, I showed how one can isolate the value inside the object, and only
expose methods that uses the value. If you want to change the value it
doesn't make sense to hide the type of the value.

Randolpho wrote:

So... the solution is to abstract both the integer and the float into a
string. Hmm...

What happens when somebody wants to set the quantity? They'd have to do
something like MyItem.SetQuant ity("1.0"), and SetQuantity would parse
the string as either a float or an integer, depending on the underlying
type. Except... what happens if you call MyItem.SetQuant y("hello
world!")?

Yep.. definitely *not* type-safe, which was an original requirement.

Bottom line -- the programmer using the object needs to know the
difference between an integer quantity and a float quantity.