对象设计问题 [英] Object Design Question

问题描述

这就是我想要做的......对于冗长的描述感到抱歉;-)


我有一个库存跟踪系统，其中包含跟踪库存水平的物品。

有些项目用小数精度（双精度）计算，其他项目用整数计算

;数据库记录有一个标志，表明特定记录是什么类型的项目（双或整数）。我创建了一个名为ItemBase的抽象类

，我实现了一个继承自

ItemBase的具体类（Item）。 ItemBase有抽象方法，允许我获取/设置库存数量

，或管理项目集合;那些方法在

中实现了具体的类Item。 Item类将是

库存跟踪系统的核心部分，我不希望程序员不断编写

代码来检查传递的数字的精确度在方法中，我想要根据项目'

数据库记录中的标志使计数方法类型安全。


这是一个例子。当一个项目ID输入某个UI时，我希望

客户端代码能够通过Item Factory实例化一个Item对象，

读取记录，找出什么要构建的项目（整数或双重）

并将其交回客户端，而无需客户端知道或关心

它是否返回整数版本或双版本Item类的。声音

如果您正在考虑使用泛型，那么很容易，但是泛型要求您在声明客户端实例时知道您想要的类型。同样使用

装饰器模式，你必须事先知道要创建什么类型（''因为

，即使你用整数装饰器类装饰一个标准的Item类，

你仍然需要创建你的对象作为整数装饰器，以便

使它的方法可见。我也调查过使用Reflection.Emit，但是

看起来也不是正确的解决方案（特别是因为它会使编码更加困难，从长远来看也是如此）客户无法对API进行编码

。


我想要的是一个完全无知的客户端，他会得到一个类型安全的项目

对象，使用整数方法或双重方法，基于项目

工厂从数据库中发现有关在对象

创建期间传入的项目的内容。有什么想法吗？


谢谢！

Don
做********** @ gmail.com

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**********@gmail.com

推荐答案

嗯......


在我看来，你的程序员需要知道这种类型

方式，并且没有解决它。如果你以某种方式使用整数方法或双重方法创建了你的b / b $ b $具体类，你的程序员

仍然需要知道*使用*那些方法时的差异，

否则他可能会调用带有double值的整数方法，这个
没有隐式转换。如果你能以某种方式抽象方法

out这样他们不需要或返回整数或双值，

你可以使用一个接口并拥有一个工厂方法返回

投射到接口的具体对象。如果没有，您的客户需要知道差价。


此外，我的数据库架构存在一些问题。为什么，为什么，

为什么，为什么用双精度值跟踪数量？

数量应始终为整数值。

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


关于使用双精度类型进行库存盘点，有很多

行业使用材料进行测量而不是计算的制造过程。例如，我工作过的一家公司用于雾化的贵金属，如金，用于焊膏。最终产品（焊膏）的成分是一个非常特殊的公司，而不是将计量单位减少到可以用作整数的单位。 />
首选使用小数库存数量。这给他们带来了两件事：他们

能够将他们的产品配方与材料清单相匹配，并且他们要跟踪每日珍贵的库存价值

金属价格，以金衡盎司计算。希望有所帮助。


" Randolpho"写道：

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.

好的，我认为这是有道理的。我已经构建了各种各样的方案

的短视数据库开发人员编制的场景

一些可笑的测量项目的方法，其中第一个小数

的地方意味着一件事，第二个小数位意味着另一个

的东西，等等。


我想我只是这几天一直在阅读The Daily WTF太多了。

:)

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.
:)

这篇关于对象设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！