如何在创建新类型时处理多个对象类型

Question

负责编写一些资产跟踪软件......想要尝试以正确的方式做到这一点.所以我认为很多资产都有共同的领域.例如,计算机具有移动电话也具有的型号和制造商.

我想存储计算机,显示器,移动电话等.所以我认为使用抽象基类可以考虑常见的东西.彼此不相关的其他属性将存储在实际的类本身中.

例如,

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字段应该在基本抽象类中声明为某种枚举吗？

谢谢

Answer 1

我的建议是完全避免这种一般设计.根本不要使用继承.当不同类型的对象具有不同的行为时,面向对象很有效.对于资产跟踪,没有任何对象真的有任何行为 - 你存储相对"愚蠢"的数据,其中没有一个(或应该)真正做任何事情.

现在,您似乎正在接近这个面向对象的程序,数据库作为后备存储(可以这么说).我反过来说:它是一个前端的数据库,它是(或者至少可能是)面向对象的.

然后,除非您在资产跟踪中有一些非常具体和不寻常的需求,否则您可能根本不应该这样做.市场上已经有数十种完全合理的资产跟踪软件包.除非你的需求真的很不寻常,否则重新发明这个特殊的车轮将无法取得多大成就.

编辑:我不打算建议不要在应用程序本身中使用OOP.恰恰相反,MVC(例如)工作得很好,我几乎肯定会将它用于几乎任何类似的任务.

我避免使用OOP的方法是设计存储的数据.在这里,您可以通过OLE DB,ODBC或JDBC之类的东西从基于SQL的数据库中获益更多.

为此使用半标准组件几乎可以自动为您提供可伸缩性和增量备份等功能,并且可能会使未来的需求(例如与其他系统的集成)变得相当容易,因为您将拥有一个标准化,易于理解的访问层对数据.

编辑2:至于何时使用(或不使用)继承,一个提示(虽然我承认它不会更多)是查看行为,以及您正在考虑的层次结构是否真正反映了对你的计划.在某些情况下,您使用的数据在程序中相对"活跃" - 即程序本身的行为围绕数据的行为.在这种情况下,在数据和代码之间建立相对紧密的关系是有意义的(或至少可以有意义).

但是,在其他情况下,代码的行为相对不受数据的影响.我认为资产跟踪就是这种情况.对于资产跟踪程序,当前项目是电话,无线电还是汽车,它没有太大(如果有的话)真正的区别.您可能需要考虑一些(通常更广泛的)课程- 至少对于很多企业而言,资产是否被视为"房地产","设备","办公用品"等都很重要.分类导致诸如资产必须如何被跟踪,必须在其上支付的税等等之间的差异.

同时,办公用品中的两件物品(例如回形针和订书钉)没有明显不同的行为 - 每一件都有描述,成本,位置等.根据你想要完成的任务,当数量低于一定水平时,可能会有类似触发器的东西,让某人知道是时候重新订购了.

总结这种方法的一种方法可能是考虑该程序是否可以合理地处理未真正设计的数据.对于资产跟踪,几乎没有机会(或者想要)为某人可能决定跟踪的每种对象创建一个类.您需要从头开始计划它将用于您在原始设计中未明确说明的各种数据.机会是,对于大多数项目,你需要设计你的代码能够只通过数据,不知道(或关心)不多大部分内容.

对代码中的数据进行建模主要是在程序确实需要知道数据的确切属性的情况下,如果没有它就无法合理地运行.