代码设计模式 【转载】面向对象编程的弊端是什么？(6)

好吧，你打算怎么设计这数千个技能/效果？

或者，你就这样把这些概念用class这个筐一装，然后到处开特例、特例都解决不了就搞23个模式使劲往一块粘，管他整体结构如何，淌哪算哪？

扯淡。

有个故事说的好：

有人送几个瞎子一条鱼，瞎子们高兴坏了，决定熬鱼汤喝。鱼汤熬好了，瞎子甲尝了一口，真鲜啊；瞎子乙赶紧也喝一口，太鲜了，太好喝了。几个瞎子一边喝一边赞美——忽然瞎子丙叫了起来：鱼跳我脚上了，它不在锅里！

众瞎子大惊：这鱼都没放到锅里，汤就鲜成这样了；要是放进锅里，还不得把我们都鲜死啊！

众面向对象原教旨主义者把事情搅得一团糟，同样也会大惊：天哪，用了面向对象都复杂成这样，这要不用面向对象，这软件就不能写了吧！

想想看，假如让那些面向对象原教旨主义者来设计，会出现什么情况：

定义一个基类叫技能；然后一个继承类叫法术技能，另一个叫物理技能；然后神圣法术从法术技能继承，疾病法术也从法术技能继承；由于圣骑士一个技能同时具备物理和法术两种效果，于是必须多重继承神圣法术和物理技能；多重继承太危险，于是不得不把神圣法术搞成接口类，引入接口继承甚至带实现的纯虚函数等等高端概念；然后，活该毙的暴雪设计师又想出了让某个技能同时对目标加上神圣持续伤害效果的奇怪点子——于是不得不再加个继承层次，使得神圣法术是神圣持续伤害法术的子集：仅立刻造成一次持续伤害的DOT（damage of time）技能……

那么，点一个天赋，一个技能就会有dot，否则就没有怎么办？

设计模式是灵丹妙药，不是吗 ^_^

等到把这所有几千个技能全部搞定，起码也是一个数万个类、几十层的恐怖继承树，并且会用完23个设计模式（甚至再发明几个新模式出来，我也不会感到奇怪），精巧复杂到没有任何人愿意去碰它。

但，请注意，天杀的暴雪设计师，在最开始的设计方案里规定DOT不能暴击；后来又添加约定说某某某职业的某个dot可以暴击；另一个职业的某个dot在点天赋后可暴击；至于死亡骑士，在他穿了T9套装中的其中四件装备时，他的某个瘟疫类型的dot可以暴击——但另一个瘟疫dot永远不能暴击。

嗯嗯嗯，太好解决了——这不就是策略模式吗？

好吧，你再填几十几百个类体系，然后把旧的几十层继承树中的数万个类一个个都策略化吧。反正不是我在维护……

哎呀不好，那个毙了几百次都还没死的暴雪设计师又出馊主意了，他要求：当死亡骑士点了邪恶系的某个天赋时，不光给他增加一个新的dot、并且在这个新dot的存在期间，还要保护他的两个dot性疾病和1个debuf性疾病不被驱散！

继续补充：在WLK里面，那个脑袋都被打成筛子了的暴雪设计师又跳出来了，用他满是漏洞的脑子出了个该杀的主意：他要求添加载具概念，当玩家坐上载具时，临时删除他的所有技能，替换为载具的技能；或者当他坐在特定载具的特定位置时，防止他受到任何伤害、并且允许他释放自己的所有技能！

更该死的是，他要求，一些技能本来不允许在移动中施放；但现在，当玩家坐在载具上某个位置时，要临时允许他移动施法！

还有，为了平衡某个野外战场，他还要求，在某方人数较少时，临时根据提高他们的生命值和所有技能的攻击力和治疗能力——这个改变必须根据进入战场的人数实时进行；在一方连续在某个战场失败时，同样要给他们一定补偿！

嗯嗯，看看这些不断改变的刁钻需求吧，如果没有面向对象，没有以策略模式为首的28个设计模式(我有理由相信你们需要至少28个设计模式而不是23个)的英明领导，我们这些没接触过大项目、不懂面向对象的傻B们，就是哭的拿眼泪把长城溶解掉都没办法吧？——我当然知道搭建长城的材料极难溶与水。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-85281-6.html