具有超过100个属性的类的设计模式

您在设计一个拥有超过100个房产的班级时会提供哪些建议/建议/指导？

背景

该类描述了发票.发票可以有超过100个描述它的属性,即日期,金额,代码等......

我们提交发票的系统使用100个属性中的每一个,并作为单个实体提交(与在不同时间提交的各个部分相对).

描述发票的属性是业务流程的一部分.业务流程无法更改.

建议？

在面对设计具有100个属性的类时,其他人做了什么？即,用100个属性中的每一个创建类？

以某种方式打破它(如果是这样,如何)？

或者这在您的经历中是否相当正常？

编辑 在阅读了一些很好的回答并进一步思考之后,我认为这个问题确实没有任何单一答案.然而,由于我们最终根据LBrushkin的答案对我们的设计进行了建模,我给了他信任.尽管不是最受欢迎的答案,但LBrushkin的回答帮助我们定义了几个界面,我们在整个应用程序中聚合和重用这些界面,并推动我们调查一些可能有用的模式.

1> Philip Walla..：

---

您可以尝试像数据库表一样"规范化"它.也许把在所有的地址相关的属性Address,例如类-然后有一个BillingAddress和MailingAddress类型的财产Address在你的Invoice班级.这些类也可以在以后重用.

---

我同意.尝试将数据分解为更小的部分.一个班级的100个属性失控.

2> Daniel Brück..：

---

糟糕的设计显然在您提交的系统中 - 没有发票有100多个属性无法分组到子结构中.例如,发票将拥有客户,而客户将拥有ID和地址.地址反过来将有一条街道,一个邮政编码,还有其他什么.但所有这些属性不应直接属于发票 - 发票没有客户ID或邮政编码.

如果你必须建立一个发票类,所有这些属性直接附加到发票上,我建议为客户,地址和所有其他所需的东西制作一个包含多个类的简洁设计,然后将这个设计良好的对象图包装起来使用胖发票类没有存储和逻辑本身只是将所有操作传递给后面的对象图.

---

@Metro:这并不意味着你的对象模型必须受到影响,只是将它提交给内部系统的部分*需要*变得丑陋.

---

听起来像是一个类似于适配器的东西 - 你有自己的对象模型,很好地分成小类,还有一个丑陋的类,你把它们推到一起,这样它就可以把内部系统视为一个拥有100个属性的巨型类......

3> LBushkin..：

---

我想这些属性中的一些可能彼此相关.我可以想象,可能有一组属性定义了Invoice的独立方面,这些方面作为一个组有意义.

您可能需要考虑创建模拟发票不同方面的单个界面.这可能有助于以更连贯,易于理解的方式定义在这些方面上运行的方法和属性.

您还可以选择将具有特定含义的属性(地址,位置,范围等)组合到您聚合的对象中,而不是单个大类的单个属性.

请记住,您选择对问题进行建模的抽象以及与其他系统(或业务流程)进行通信所需的抽象不必相同.实际上,应用桥接模式以允许单独的抽象独立发展通常是有效的.

4> 3Dave..：

---

嗯...是所有那些真正相关的明确,并且只给发票？通常我看到的是:

class Customer:
.ID
.Name

class Address
.ID 
.Street1
.Street2
.City
.State
.Zip

class CustomerAddress
.CustomerID
.AddressID
.AddressDescription ("ship","bill",etc)

class Order
.ID
.CustomerID
.DatePlaced
.DateShipped
.SubTotal

class OrderDetails
.OrderID
.ItemID
.ItemName
.ItemDescription
.Quantity
.UnitPrice

把它们捆绑在一起:

class Invoice
.OrderID
.CustomerID
.DateInvoiced

打印发票时,将所有这些记录连接在一起.

如果你真的必须拥有100多个属性的单个类,那么使用字典可能会更好

Dictionary d = new Dictionary();
d.Add("CustomerName","Bob");
d.Add("ShipAddress","1600 Pennsylvania Ave, Suite 0, Washington, DC 00001");
d.Add("ShipDate",DateTime.Now);
....

这里的想法是将你分成逻辑单位.在上面的示例中,每个类对应于数据库中的表.您可以将其中的每一个加载到数据访问层中的专用类中,或者在生成报表(发票)时从存储它们的表中选择一个联接.