最近在做CSDN新论坛的设计，我就走了OO设计上的死牛角了。一度头大的不知所以然。下面来看我所走的弯路，希望对大家有所帮助。
先说功能需求
我们有这样的需求：
论坛由很多具体论坛组成。对于某个具体论坛来说，它是下述功能的组合，可能是其中一个功能的组合，也可能是其中几个功能的组合，不过确定组合后，有哪些组合就很少会发生变化，这些功能包括：
积分制、勋章制、贴图、帖链接、可以发投票帖 等等......
每个具体论坛，上述功能组合都可以不同。
简单来看我走的死牛角：
以论坛帖子类的设计为例。
不论用上述那些功能组合，一个帖子类，当然会有一个基类，这个基类包含最最基本的帖子信息，比如帖子编号、标题、发帖者等等。
对于 A 论坛，它选择了使用积分制功能，则A 论坛的帖子类应该还包括一个帖子分数的字段来记录跟积分制有关的信息。
对于B论坛，它选择了使用贴图功能，则B论坛的帖子类应该还包含一个字段，来记录相关的图片链接。
对于C论坛，它选择了同时使用积分制和贴图功能，则C论坛的帖子类应该还包含上述两个字段。
………………….
我们会有很多种组合。非常非常多。
如果我们用每个论坛实现一个派生自基类帖子类的子类，问题会是：组合太多了。而且以后丰富功能的时候，每新增一个功能，需要新增的子类会不可想象。
如果使用一个超级类，把所有功能都封装到一个类来。每个功能涉及的属性都有默认值。
则会给这个类的使用者带来很多意想不到的问题：
因为这个类相关的内部逻辑可能是开发人员A设计的。而使用者会是开发人员B。
某种情况可能会需要对这个超级类的1、2、3三个属性给值。另外一种情况则….. 之前有多少种组合，这里可能就有多少种情况。
让开发人员B熟悉这么多种组合，很容易啥时候就出问题。复杂，太复杂了。
……………………………………
上面就是我陷入的死牛角。
解决方法：
一、如果OO设计上出现困惑，先不要考虑OO的设计，先考虑数据库的设计，看你数据表是如何设计的。你完全可以把数据表的结构映射到OO的设计上来。
二、如果OO设计上出现困惑，先不要考虑OO的设计，先考虑界面的设计，然后从界面的功能转到OO的设计上来。
这里不是说OO不好，而是由于还没有对这方面的抽象习惯过来，通过对整个流程的思考，会帮助你构造好的OO类。
就象模式一样，也是别人经过很多实践得出来的，一般都叫做refactor to patterns，即对自己的编码反复重构，最后这些编码就成了模式，或与模式相似。
不要硬套OO或者模式设计。
对于我这里的设计，
数据库上存储帖子信息，显然是可不管你每个论坛使用了哪些功能，而是认为所有功能你都使用了，对于没使用的功能，则认为对应的字段使用的是默认值。
不论用那种组合论坛，因为他们界面展示上完全不一样，每一套功能组合，我们都需要提供一套页面模版和接受读取参数功能来处理。这样其实组合方式并不是多得不可接受，仍然是可接受的。
想明白上述两点，设计就很简单的，就不会过度设计，钻OO设计的牛角了。