创建新类型时如何处理多个对象类型
被委托编写一些资产跟踪软件... 想要尝试以正确的方式执行此操作。所以我认为很多资产都有共同的领域。例如,计算机具有手机也具有的型号和制造商。创建新类型时如何处理多个对象类型
我想存储计算机,显示器,手机等。所以我认为可以使用抽象基类来考虑常见的东西。其他不相互关联的属性将存储在实际的类本身中。
例如,
public abstract class Asset {
private string manufacturer;
public string Manufacturer { get; set; }
//more common fields
}
public class Computer : Asset {
private string OS;
public strin OS { get; set; }
//more fields pertinent to a PC, but inherit those public properties of Asset base
}
public class Phone : Asset {
//etc etc
}
但我有2个顾虑:
1)如果我有一个Web表单,要求别人添加的资产,我想给他们说的一个单选框选择他们正在创建的资产类型。东西的效果:
你在创建
[]计算机
[]电话
[]监测
[确定] [取消]
而且他们会选择一个,但我不想结束这样的代码:
伪代码:
select case(RadioButtonControl.Text)
{
case "Computer": Computer c = new Computer(args);
break;
case "Phone": Phone p = new Phone(args);
break;
....
}
这可能会变得丑陋....
问题2)我想在一个数据库表中该信息这种方式存储与TYPEID场当插入到数据库完成本值成为该行的typeid(区分它是计算机,显示器,电话等)。这个typeid字段是否应该作为某种枚举在基本抽象类中声明?
谢谢
我的建议是完全避免这种通用设计。根本不要使用继承。当不同类型的对象具有不同的行为时,对象方向效果很好。对于资产跟踪,没有一个对象真的有任何行为 - 你存储的是相对“哑”的数据,它们都没有(或者应该)真的做任何事情。
现在,你似乎正在接近这个作为一个面向对象程序与数据库作为支持存储(可以这么说)。我会反过来:它是一个前端(或至少可能是)面向对象的数据库。
然后,除非您在资产追踪中有一些非常特殊和不寻常的需求,否则很有可能您不应该这样做。市场上已经有几十种完全合理的资产跟踪软件包。除非你的需求真的非常不寻常,否则重新发明这个特定的轮子不会有太大的成就。
编辑:我不打算建议在应用程序本身内使用OOP。恰恰相反,MVC(例如)工作得很好,我几乎肯定会将它用于这类任务。
在哪里我会避免OOP将在被存储的数据的设计。在这里,您从使用诸如OLE DB,ODBC或JDBC之类的基于SQL的数据库之类的东西中获益更多。
为此,使用半标准组件几乎可以自动为您提供可伸缩性和增量备份等功能,并且很可能使将来的需求(例如与其他系统集成)相当容易,因为您将拥有标准化的理解层访问数据。编辑2:至于什么时候使用(或不使用)继承,一个提示(尽管我承认它不超过)是行为,以及您是否真的考虑层次结构反映对您的计划很重要的行为。在某些情况下,您使用的数据在程序中相对“活跃” - 即程序本身的行为围绕着数据的行为。在这种情况下,它是有意义的(或者至少可以有意义)在数据和代码之间具有相对紧密的关系。
然而,在其他情况下,代码的行为相对不受数据影响。我认为资产追踪就是这种情况。对于资产追踪计划来说,无论现在的物品是电话,收音机还是汽车,它都不会产生太大的影响(如果有的话)。有一些(通常更广泛的)类别可能想要考虑 - 至少对于不少业务来说,重要的是资产是否被视为“房地产”,“设备”,“办公用品”等。这些分类导致了资产如何跟踪,必须支付的税款等方面的差异。
同时,属于办公用品(如回形针和订书钉)的两件物品没有明显不同的行为 - 每种物品都有描述,成本,位置等等。根据您的尝试当数量低于一定水平时,每个人可能都会触发事件,让别人知道是时候重新订购了。
总结这种方式的一种方式可能是考虑程序是否可以合理地处理并非真正设计的数据。对于资产跟踪,您几乎不可能(或者想要)为某人可能决定跟踪的每种对象创建一个类。您需要从一开始就计划它将用于您在原始设计中未明确说明的各种数据。很可能对于大多数项目,您需要设计自己的代码,以便能够传递数据,而不必知道(或关心)很多关于内容的大部分。
对代码中的数据进行建模主要在何时/如果程序确实需要知道数据的确切属性,并且在没有它的情况下无法合理运行。
@Jerry Coffin好的,我相信你和建议。所以我猜想我们想要一些内部写的东西,这会很简单。我应该坚持写一个简单的应用程序,而不是以面向对象的方式使其复杂化,这就是你所说的吗?另外,我只需创建一个3层数据层,业务逻辑层和演示文稿,而不需要所有这些OOP和继承。你怎么看? – oJM86o 2010-02-02 19:54:10
或多或少,是的。如果您打算使用.NET编写代码,那么您几乎可以肯定地希望在那里使用通常的OO内容(例如MVC)。但是,我认为这些数据是以一个普通的SQL(或其他)数据库的形式出现的,大部分的设计归结为规范化数据,定义键和索引等。 – 2010-02-02 20:05:16
好吧,这很有意义。我想我很难确定是否应该用纯粹的OOP术语来写实体。我知道如何在面向对象程序设计中编写代码,但是我总是会因为什么时候用纯粹的面向对象编程来编写特定应用程序而导致大脑冻结...任何指针? – oJM86o 2010-02-02 20:11:02