大家来共同探讨一下这个设计模式问题吧

[cccc2002]

某基类有若干函数不知该如何放置
原因是：
对函数甲可能有几个派生类可以共用，但对其他派生类则毫无意义，而这样
的函数还比较多。而这些派生类又必须共享基类的虚接口，也就说基类本身
不能再被分割成若干基类供某些有“共性”的派生类继承了。


这样一来，至少有三种选择：
（1）将这些函数都放在基类中，这样可以达到代码共享，但缺点是造成
语义不明，更是被广泛批判的“类继承之打破封装性”之范例。

（2）将这些函数放在各个派生类中，好处是语义清晰，缺陷是代码冗余，
如果需要更改此函数，必须同时更改多处，如果漏改错改一个后果不堪
设想。

（3）设置某组合类，包含这些被共用的函数，然后将其组合进派生类中，
这样得到达到代码共享和语义清晰的好处，但如果这种共享的函数数目很多
且分散，比如派生类1、2、3共享函数1，派生类3、4、6共享函数2，则
又必然导致组合类过多且包含的“容量”太小的分散性。

各位有什么精见？ 欢迎赐教！

[anrxhzh]

请思考一下为什么STL中没有定义一个抽象容器类，list,map,set,stack,...不是存在公共的接口吗？

[goldfish]

我刚刚接触到 design patterns 不是很懂，但是强烈建议不用（3）如果作组合类，那么这些发生行为的对象是什么阿，这样作可能使你达到代码共享。。好处但是有悖于oo的思想阿，和面向过程有什么区别阿（你建了一个大的公共过程）
以上是我个人的观点 学习ing

[cccc2002]

没错，（3）在此情况下实乃下下策，其实按GoF《设计模式》的说法：
优先使用对象组合，而不是类继承
来看，这里的个别“共用函数”根本还谈不上是对象，顶多算个操作集，但如果
对一个这种小集合就来一个namespace又离谱了点，应该不适用此法则的

[cccc2002]

更何况这些函数与类的内部属性是紧密相关的，与namespace所应具有的“类无关性”更是南辕北辙

[cccc2002]

我还想过尽可能将这些有“共用函数”的“派生类”融成一个类，但实在是因为其间有不可融的特性而放弃，比如各自对虚接口的实现就大相径庭，仅仅是共用了几个非虚接口的函数而已

[LionEagle]

感觉是你类层次设计的问题，如果A的几个子类A1,A2,A3，A1，A2 有共用的函数F，可以把他们再抽象出一个基类AA，AA中含有该方法F，A1，A23再继承AA。
由于F与类属性相关，它应该属于类的行为，而行为不同的类应区分开。

如果F不体现的行为，就把F设计为单个函数；

好好考虑一下那些函数是否表现类的行为