类爆炸问题，对维护也是恶梦?

losting 2010-02-25 06:37:38

原意在ERP项目中有设计一个工序类用來描述工序：
public Process
{

public string ProcessNo
{
get{}
set{}
}
public string ProcessDesc
{
get{}
set{}
}
//宽Size2 属性
public virtual float GetSize2();
public virtual void SetSize2(float _size2);

}

如下图：
----------------------------------------------------------------
工序号工序名称 Size2求法说明
----------------------------------------------------------------
91 包裝 F_GetPack(Productobj obj,int X) 成品尺寸宽
95 粘合 F_GetSize2(layoutobj obj) 排版尺寸的宽
2A 过油 F_GetSize(int size1,int size2) 用户输入的值得到
.......................
99 XX F_PA() ...........

但是发现实际情况下是公司有几百个不同的工序，最主要有些工序同样的属性如（宽），不同的名字或在不同的产品时会有不同的方法求得（但不是所有的都不同）。我的问题是：
如不同的工序用继承的方法，不同的子类重写不同的方案，会产生上百个工序类，而且将来工序会因需要自动增加，显然会产生类爆炸问题，对维护也是恶梦！
如不用继承的方法，转而只用写成一个类中，用不同的函数名不同的方式，显多也是太多函数，且一样不能维护。

请问各位有什么好的设计类的方案？

...全文

373 24 打赏收藏转发到动态举报

写回复

用AI写文章

24 条回复

切换为时间正序

请发表友善的回复…

发表回复

wushibin 2011-11-30

打赏
举报

设计模式精解这本书取的那个例子可能和你所要设计的东西很接近，它做的是一个CAD系统，存在不同的算法画不同的东西（矩形，不规则图像等）。它使用brige模式分离调用与实现，避免了类爆炸的问题。可参考。

tsoukw 2010-03-06

打赏
举报

ERP这样的软件，直接数据建模来得快得多

wanghui0380 2010-03-02

打赏
举报

这样的做法，对于调用者来说代码都是一样，无须更改

但是对于单步工序实现代码编写人员来说，那个委托还是要去写代码的。代码增长也是必须的

好在都在统一的机制下，编写还算简单（实际上codedom或j#引擎可以完成动态编译或动态运行，但是比较麻烦，不过微软已经考虑到了所以C#4.0已经加入相关动态代码功能）

如果想在目前的机制下完成，我的建议是调用管控部分，不妨使用ironPython或j#来处理，这样的还算有部分代码可以临时添加而不必编译dll并重新配置文件

wanghui0380 2010-03-02

打赏
举报

你可以参考下面这个简单的管理机制

Dictionary<string, Action<object>> list = new Dictionary<string, Action<object>>();

            list.Add("工序1", delegate(object i) { Response.Write("我想传入int i 并打印i值，i=" + i.ToString()); });

            list["工序1"].Invoke(1);

代码很简单，但不妨可以看做你考虑这个问题的起点

缪军 2010-03-02

打赏
举报

你如果正在使用13楼的方案的话，至少是一种可行的低技术依赖的方案，
只是：
1、你可能需要通过一系列的而不是个别table来描述公式；
2、既然公式很多很复杂，不应该手工维护，既然公式是业务逻辑，就应该让懂业务的来维护，而懂业务的可能并不了解这个项目的技术细节（也许他根本不懂开发），
所以应该提供公式编辑器，把公式维护跟软件开发工作分离；

BlueTrees 2010-03-02

打赏
举报

工序-类

某个具体的工序-类的实例

具体的问题：工序的名称由于不同的实例有不同的计算方法，产生了问题。你可以这样做，把产生名称的方法变成一个委托，在创建工序实例的时候传入名称产生委托的方法。你再建立一个类管理名称产生方法，不同工序和产生名称的委托是多对一的关系。

我这么说，你明白伐？不明白赶紧回帖，我一会儿就闪了

wanghui0380 2010-03-02

打赏
举报

1.工序本身可以使用职责链模式（也可以使用多播委托，另外加工工序应该也有状态保持，所以需要序列化持久机制）
2.各个工序所使用的参数可以继承同一个基类，这样你可以使用同一个方法签名去调用
3.有关类爆炸问题，的确存在（因为c#是编译型语言，而非动态解析语言，所以对象必须是事先就有代码才能执行的）所以这类问题我们通常是用依赖注入的手段，使用配置文件来完成

whb147 2010-03-02

打赏
举报

仔细参阅设计模式
上面专门对付这个问题的

losting 2010-03-02

打赏
举报

谢谢楼上，实际上，我们原来就是这样写的---将PB代码公式直接存起来，再动态解析公式。但发现记录多了，非常难维护，且多个地方会出现交叉引用的情况，时间一长，没人能动其中的代码。因此，我想找个方法来改造它。

另：microtry网友能不能具体给点意见？正是不足，才希望有人能知会具体的方案。Thanks,

wxhysoftsodc 2010-03-02

打赏
举报

有意思 mark以后来学习

加油馒头 2010-03-02

打赏
举报

这问题是个长久话题

lijunfeng 2010-03-01

打赏
举报

你的Size2计算方法可以用公式表示并且存在工序表内,然后你只需设计一个函数来解析公式就好了.
我在解决类似问题的时候都是这么干的,就是算法复杂了点.

缪军 2010-02-28

打赏
举报

楼主，你不是已经给出了一张表格了吗，
在这张表格中，你已经找到了工序的统一描述了，
你试着跳出“面向类”的思维，再想想，你其实离真相只有一步之遥了；

我早就说过，只要你能跳出编程的技术细节，以建模的的角度分析问题，
剩下来的技术实现不成问题

我再强调一遍：“面向对象”不是“面向类”，明明是变化的、不稳定的东西，却偏偏要把他们固定下来，这恰恰是反“面向对象的”。

开发中楼主碰到的情况类似的数不胜数，
随便举个例子，如果有100个表（这不多吧），是不是要设计100个class啊？字段呢？100个表的字段就更多了，岂止是“类爆炸”，完全是“代码爆炸”。

losting 2010-02-26

打赏
举报

谢谢了!

最大的问题在于找不到一个合理的方案进行工序类设计(粒度控制)。每行都设计一个类，显然是太多了(一个几百个，还是一直维护)! 我知道每行都有不同的变化算法，如这样封装变化，变成每行都是一个类!

原来我们用的是面向过程的方法---每行求法写成N多的FUNCTION，动态解析。看来我们只能回到老路？

vrhero 2010-02-26

打赏
举报

这不是类爆炸问题，这是伪OO问题...

工序是什么？工序是一组过程或计划，是一个或多个对象的状态变化或行为过程...将这个过程视为一个对象是基于对象而不是面向对象的伪OOAD思维，这表示你尚未理解类的意义...

createhebe 2010-02-26

打赏
举报

使用抽象工厂模式管理若干的类。

这是第一步，如果按照理论来是使用组合方式，使用类似策略模式来处理，把不同的处理方法封装好，然后创建类的时候动态的组合这些封装好的策略，但是这仅仅是理论。

如果你的每个类对应的工序的处理过程并不是这种原料般的组合过程那就不能用这种模式。

如果在.Net环境下我推经用Hashtable把“工序名字”和“类类型名称”组合的存入。
如果在一般环境下我推荐写一个类，这个类负责管理“工序名称”到“工序处理过程”的映射，即String和函数指针的关系。

更简单的是把函数指针们用宏写入一个初始化的数组，然后用枚举。

如果完全用OO方法，我认为这种情况下你的抽象粒度是不合理的，每个工序都抽象为类是不是有点过于细，你可以考虑以后从更高的层次抽象。如果必须这么做，也可以丰富一下抽象工厂，让抽象工厂来做更多事情，比如注册一个类型，等等操作。

嗯嗯，欢迎继续讨论！

losting 2010-02-26