最新采用面向对象的方法设计了一个系统，发现有一个很令人头痛的有关问题。欢迎大家来讨论
最新采用面向对象的方法设计了一个系统，发现有一个很令人头痛的问题。欢迎大家来讨论
以前都是采用面向过程的方法设计，最近半年读了很多关于OOD和设计模式的书，所以在项目中实践OOD。当用面向对象的方法来设计系统的时候，会出现大量的类（主要考虑类职责的单一，和提高模块的独立性）。在一般人看来是类爆炸。
想请大家来讨论一下，有没有什么好的办法来解决这一个问题？
------解决方案--------------------
类爆炸？那是设计有问题，去学习下设计模式
------解决方案--------------------
职责过于单一的话的确会产生类爆炸，如果职责的关联度比较大的话完全可以设计到一个类中。
设计即要会将大类分为小类，也要学会将若干小类合成一个大类。
------解决方案--------------------
职责单一是一个相对的概念，关键看你从什么角度出发，比如业务模块，通用性。
建议重构一下，把模块之间通用的合并到一个组工具类中。 模块内部关联较紧密的合并。采用一些模式，抽象出新的接口。
------解决方案--------------------
采用一些模式，抽象出新的接口，屏蔽一些基础的类直接访问。
------解决方案--------------------
你在用结构化的思想分析类。
oo里面的类有不同的层次，分析层面上类是子模块，直到设计的最底层类才是具体语言实现上的类。
设计模式并不能解决你的问题。
类的数量多不是问题，关键是有序的归类，清晰的模块接口。
------解决方案--------------------
慢慢就好了,才学都是这样.楼主可能滥用了设计模式 和OO
设计模式其中重要一点是为了需求变化才产生的
因此有些地方不用考虑那么多的模式什么的.
回归到本质 直接解决问题就行了.
------解决方案--------------------
OOD的设计原则只是建议你这么做，不是一定要遵守的。
解决业务问题，要建立业务模型。
解决性能、稳定等系统问题，要建立数据模型。
解决扩展性、易维护等设计问题，要用设计方法。
看类是否多余，就是看类的设计有没有模型和设计方法作为根据，没有就是多余的了。
------解决方案--------------------
方法是死的.人是活的...能解决实际问题,实际中好用的才是好的..
模式,OOD,什么规则,掌握了精髓才是好的..死套规则是烂的..
最高境界,无招胜有招..
太极生两仪,两仪生四像....生生生,,最后无穷无尽.....
会生否???
不会,找个女人试试!!!
武术,设计,ML,...万象归一!!!!!!!!!!!!!!!!!!!!!111
归到底,,就那么一点!!!!
那一点!!
就上面两点,下面一点的那一点!!!!
两手抓,两手都要硬,要挺!!!!
多多指教!!!
------解决方案--------------------
佛祖保佑？
佛祖可能不会保佑，版主保有差不多！哈哈哈哈
不闲扯了。
zijcai说得的确有点离题了，但是，也不是完全没有关系。
关于类爆炸，其实是他没有看过设计模式或者不了解模式才造成的问题，不属于对模式的滥用。
建议楼主，看了OO，然后去看看MVC，这是个OO设计中最基础的模式，也是应用最广泛的模式，很多模式都是在这个模式的基础上派生出来的，而只看了OO就直接进行系统设计的确是个非常危险的事情，因为，你还不知道OO中的对象和类到底应该如何关联，而你只是知道了要产生对象和类。
从过程走向对象，分人，有些人会走得十分艰难。这些都是可以理解的。
建议你按照我的说法，进行了mvc的学习以后，再来看看你的系统，或者直接在系统中进行重新设计。
------解决方案--------------------
复杂系统的类多，也不是什么太大的问题，分包管理，打包成不同层次的 namespace 就可以了。
不知道楼主讲的类爆炸是什么概念，一般大型系统4、5百个类也是很正常的事。你看到网上许多开源系统，做小规模的1M、2M 的软件，上4、5十个类也是很常有的事情。按照我的理解，“类爆炸”的概念，是中型系统系统上1000个类以上，大型系统上3000个类以上。
楼主你的系统“爆炸”到什么程度了？
------解决方案--------------------
对于类爆炸的“量定义”，不同背景的人认识不一样。
对于习惯过程式的程序员来说，就容易把一个较低的量当作爆炸。
对于习惯甚至唯一只会对象式开发的程序员来说，类的数量再多也可能天经地义，学JAVA的名言就是一切都是类和对象。
任何考量的标准和原则都不能单独存在，要和其它因素统一考量，权衡轻重，找到至少能让自己满意的平衡点就可以了。
------解决方案--------------------
比如我如果设计一个企业管理信息系统的短信网关，假设财务系统的短信网关与公文传递系统的短信网关稍有不同但是都是从同样网关继承的，那么这就被划分为3个子系统来设计。同样，一个订餐管理系统中的记账部分是从通用帐务系统继承的，订餐确认事务是记账凭证的子类，同时收款确认事务也是记账凭证的子类，顾客是权限系统中一个类型的子类，同时也是帐务系统中“往来单位”的子类......（不包括非常次要的业务系统，排除所有非业务领域的、纯粹计算机领域的类型、排除所谓的“设计模式中”莫名其妙生硬发明的类型）小型系统只有10几个主要类型，中型系统只有20几个类型，大型系统的类型也不应该多于50个。
将类型分层，不是把类型横切，而是纵切，子类继承父类的概念和操作协议的逻辑意义，并且可以对操作细节各自有所创新。由于纵切，100个类型之间的上万种关系可以简化为几个子系统，每一个子系统中只有10几个类型和40、50种关系。抽象可以组织组合爆炸的发生。
------解决方案--------------------
抽象可以组织组合爆炸的发生 --> 抽象可以阻止组合爆炸的发生
对概念进行重构只能改变一些BUG，并不能从根本上减少组合爆炸。只是教你如何给类型分档管理，不是解决问题的方法，因为没有说清楚如何真正有效地进行抽象。即使一本书给你把全世界上所有的混凝土都煞有介事地描述一遍，你也没有学到建筑设计之道。
以前都是采用面向过程的方法设计，最近半年读了很多关于OOD和设计模式的书，所以在项目中实践OOD。当用面向对象的方法来设计系统的时候，会出现大量的类（主要考虑类职责的单一，和提高模块的独立性）。在一般人看来是类爆炸。
想请大家来讨论一下，有没有什么好的办法来解决这一个问题？
------解决方案--------------------
类爆炸？那是设计有问题，去学习下设计模式
------解决方案--------------------
职责过于单一的话的确会产生类爆炸，如果职责的关联度比较大的话完全可以设计到一个类中。
设计即要会将大类分为小类，也要学会将若干小类合成一个大类。
------解决方案--------------------
职责单一是一个相对的概念，关键看你从什么角度出发，比如业务模块，通用性。
建议重构一下，把模块之间通用的合并到一个组工具类中。 模块内部关联较紧密的合并。采用一些模式，抽象出新的接口。
------解决方案--------------------
采用一些模式，抽象出新的接口，屏蔽一些基础的类直接访问。
------解决方案--------------------
你在用结构化的思想分析类。
oo里面的类有不同的层次，分析层面上类是子模块，直到设计的最底层类才是具体语言实现上的类。
设计模式并不能解决你的问题。
类的数量多不是问题，关键是有序的归类，清晰的模块接口。
------解决方案--------------------
慢慢就好了,才学都是这样.楼主可能滥用了设计模式 和OO
设计模式其中重要一点是为了需求变化才产生的
因此有些地方不用考虑那么多的模式什么的.
回归到本质 直接解决问题就行了.
------解决方案--------------------
OOD的设计原则只是建议你这么做，不是一定要遵守的。
解决业务问题，要建立业务模型。
解决性能、稳定等系统问题，要建立数据模型。
解决扩展性、易维护等设计问题，要用设计方法。
看类是否多余，就是看类的设计有没有模型和设计方法作为根据，没有就是多余的了。
------解决方案--------------------
方法是死的.人是活的...能解决实际问题,实际中好用的才是好的..
模式,OOD,什么规则,掌握了精髓才是好的..死套规则是烂的..
最高境界,无招胜有招..
太极生两仪,两仪生四像....生生生,,最后无穷无尽.....
会生否???
不会,找个女人试试!!!
武术,设计,ML,...万象归一!!!!!!!!!!!!!!!!!!!!!111
归到底,,就那么一点!!!!
那一点!!
就上面两点,下面一点的那一点!!!!
两手抓,两手都要硬,要挺!!!!
多多指教!!!
------解决方案--------------------
佛祖保佑？
佛祖可能不会保佑，版主保有差不多！哈哈哈哈
不闲扯了。
zijcai说得的确有点离题了，但是，也不是完全没有关系。
关于类爆炸，其实是他没有看过设计模式或者不了解模式才造成的问题，不属于对模式的滥用。
建议楼主，看了OO，然后去看看MVC，这是个OO设计中最基础的模式，也是应用最广泛的模式，很多模式都是在这个模式的基础上派生出来的，而只看了OO就直接进行系统设计的确是个非常危险的事情，因为，你还不知道OO中的对象和类到底应该如何关联，而你只是知道了要产生对象和类。
从过程走向对象，分人，有些人会走得十分艰难。这些都是可以理解的。
建议你按照我的说法，进行了mvc的学习以后，再来看看你的系统，或者直接在系统中进行重新设计。
------解决方案--------------------
复杂系统的类多，也不是什么太大的问题，分包管理，打包成不同层次的 namespace 就可以了。
不知道楼主讲的类爆炸是什么概念，一般大型系统4、5百个类也是很正常的事。你看到网上许多开源系统，做小规模的1M、2M 的软件，上4、5十个类也是很常有的事情。按照我的理解，“类爆炸”的概念，是中型系统系统上1000个类以上，大型系统上3000个类以上。
楼主你的系统“爆炸”到什么程度了？
------解决方案--------------------
对于类爆炸的“量定义”，不同背景的人认识不一样。
对于习惯过程式的程序员来说，就容易把一个较低的量当作爆炸。
对于习惯甚至唯一只会对象式开发的程序员来说，类的数量再多也可能天经地义，学JAVA的名言就是一切都是类和对象。
任何考量的标准和原则都不能单独存在，要和其它因素统一考量，权衡轻重，找到至少能让自己满意的平衡点就可以了。
------解决方案--------------------
比如我如果设计一个企业管理信息系统的短信网关，假设财务系统的短信网关与公文传递系统的短信网关稍有不同但是都是从同样网关继承的，那么这就被划分为3个子系统来设计。同样，一个订餐管理系统中的记账部分是从通用帐务系统继承的，订餐确认事务是记账凭证的子类，同时收款确认事务也是记账凭证的子类，顾客是权限系统中一个类型的子类，同时也是帐务系统中“往来单位”的子类......（不包括非常次要的业务系统，排除所有非业务领域的、纯粹计算机领域的类型、排除所谓的“设计模式中”莫名其妙生硬发明的类型）小型系统只有10几个主要类型，中型系统只有20几个类型，大型系统的类型也不应该多于50个。
将类型分层，不是把类型横切，而是纵切，子类继承父类的概念和操作协议的逻辑意义，并且可以对操作细节各自有所创新。由于纵切，100个类型之间的上万种关系可以简化为几个子系统，每一个子系统中只有10几个类型和40、50种关系。抽象可以组织组合爆炸的发生。
------解决方案--------------------
抽象可以组织组合爆炸的发生 --> 抽象可以阻止组合爆炸的发生
对概念进行重构只能改变一些BUG，并不能从根本上减少组合爆炸。只是教你如何给类型分档管理，不是解决问题的方法，因为没有说清楚如何真正有效地进行抽象。即使一本书给你把全世界上所有的混凝土都煞有介事地描述一遍，你也没有学到建筑设计之道。