负责编写一些资产跟踪软件...... 想以正确的方式尝试这样做。所以我认为很多资产都有共同的领域。 例如,计算机具有移动电话也具有的型号和制造商。
我想存储计算机,显示器,移动电话等。所以我认为使用抽象基类可以考虑常见的东西。其他不相关的属性将存储在实际的类本身中。
例如,
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
}
但我有两个问题:
1)如果我有一个要求某人添加资产的网络表单,我想让他们说出他们正在创建的资产类型的无线电盒选择。有什么影响:
你在创造什么
[]计算机
[]电话
[]监测
[确定] [取消]
他们会选择一个,但我不想最终得到这样的代码:
伪代码:
select case(RadioButtonControl.Text)
{
case "Computer": Computer c = new Computer(args);
break;
case "Phone": Phone p = new Phone(args);
break;
....
}
这可能会变得丑陋......
问题2)我想将此信息存储在一个带有TypeID字段的数据库表中,当插入数据库时,该值成为行的typeid(区分它是计算机,监视器,还是电话等)。这个typeid字段是否应该在基本抽象类中声明为某种枚举?
由于
答案 0 :(得分:5)
我的建议是完全避免这种一般性设计。根本不要使用继承。当不同类型的对象具有不同的行为时,面向对象很有效。对于资产跟踪,没有一个对象真的有任何行为 - 你存储相对“愚蠢”的数据,其中没有一个(或者应该)真的做任何事情。
现在,您似乎正在将此作为面向对象的程序,将数据库作为后备存储(可以这么说)。我反过来说:它是一个前端的数据库(或者至少可能是)面向对象。
然后,除非您的资产跟踪中有一些非常具体和不寻常的需求,否则您根本不应该这样做。市场上已经有数十种完全合理的资产跟踪软件包。除非你的需求真的很不寻常,重新发明这个特殊的轮子不会有太大的成就。
编辑:我不打算建议不要在应用程序本身中使用OOP。恰恰相反,MVC(例如)工作得很好,我几乎肯定会将它用于几乎任何类似的任务。
我在哪里避免OOP将在设计存储的数据。在这里,您可以通过OLE DB,ODBC或JDBC等方式从基于SQL的数据库中获益更多。
使用半标准组件几乎可以自动为您提供可扩展性和增量备份等功能,并且可能会使未来的需求(例如与其他系统的集成)变得相当容易,因为您将拥有标准化的,易于理解的用于访问数据的层。
Edit2:至于何时使用(或不使用)继承,一个提示(虽然我承认它不会更多)是看行为,以及你是否层次结构正在考虑真正反映对您的计划很重要的行为。在某些情况下,您使用的数据在程序中相对“活跃” - 即程序本身的行为围绕数据的行为。在这种情况下,在数据和代码之间建立相对紧密的关系是有道理的(或者至少可以有意义)。
然而,在其他情况下,代码的行为相对不受数据的影响。我认为资产跟踪就是这种情况。对于资产跟踪程序,当前项目是电话,无线电还是汽车,它没有太大(如果有的话)真正的区别。您可能想要考虑的一些(通常更广泛的)课程 - 至少对于很多企业而言,资产是否被视为“房地产”,“设备”,“办公用品“等。这些分类会导致资产必须跟踪,必须支付税款等等的差异。
同时,两件属于办公用品(例如回形针和订书钉)的物品没有明显不同的行为 - 每个都有描述,成本,位置等。取决于你想要的东西当数量低于一定水平时,每个人都可能会遇到类似触发器的事情,让某人知道是时候重新订购了。
总结这种方法的一种方法可能是考虑该程序是否可以合理地处理未真正设计的数据。对于资产跟踪,几乎没有机会(或者想要)为某人可能决定跟踪的每种对象创建一个类。您需要从头开始计划它将用于您在原始设计中未明确说明的各种数据。有可能对于大多数项目,您需要设计代码以便能够直接传递数据,而无需了解(或关心)有关大多数内容的内容。
对代码中的数据进行建模主要是在程序确实需要知道数据的确切属性的情况下,如果没有它就无法合理地运行。