谈一下OOP的乱用现象

很久很久以前写了两篇设计模式乱用的文章，最近心血来潮，突然想写篇OOP乱用。

最近在移植一个旧项目，接手过程很多嘈想吐，开一篇谈一下OOP的乱用。

大多数公司用MVC是为了解耦合，但是这套代码的MVC明显是不解耦的，例如View1可以直接拿view2单例如调用里面的方法。v可以调用c,c可以随意调用v。不同人写的c和v可以随意调用。看起来写得爽，但是修改起来就各种吐了，当你修改一个v的时候，我还得读一下耦合的另一个v的相关代码。这段话说得晕晕的，下面直接说简单的OOP的乱用吧。

继承和复盖，相信写过代码的人都懂，也很简单。但是真正写代码的时候，什么情况下用继承呢？直接说反例得了。例如项目有一个加速的界面，很多模块会用到，但是各模块对这个界面的显示有一些不一样，例如A模块比B模块多一个按钮。很多人的想到的方法是在这个加速界面里面加type处理，不同模块有不同的type，然后再加一个param，处理不同模块的逻辑，想到这个方法的人面壁去吧。这个就是当前我接手的项目的最大问题了。这种做法实际上是乱用工厂模式，简单的说，问题就是去别人的加速模块加type处理自己的逻辑。当新项目想移植加速面板的时候，发现这个加速面板耦合大量模块，移植的时候，我要移A的加速面板，还得考虑B的加速逻辑。所以很多人说改别人的代码还不如自己写一个新的来得快。

既然说出了问题，我们再说说解决方案，相信有经验的人早就想到了。把加速面板做成一个基类，不同模块新建一个自己的面板继承那个基类加速板，处理逻辑如果有少量不同的地方就复盖继承处理就行了。思路很简单，下面看看好处吧，各模块写自己的加速面板时，就是自己写自己的，完全不会跟别人的加速面板有关，也不需要去改别人的模块。移植新项目的时候，移一个模块就看一个模块的代码，移植A模块的加速面板就完全不需要管B怎么写的(除非改动基类加速面板)。这样看谁还敢说自己全新写的快。

旧代码虽然用了mvc，虽然对象都继承了基础的view，基础的model，基础的ctrl，然并卵。M和C都是单例，view虽然不是单例，但是放在单例上面给其它单例调用，代码依然还是像没用oop一样，很过程式的写法。既然不做解耦，那何必花这么多码量写这么多继承做什么。直接搞全局方法不还写得快。

吐嘈完毕，本来还想吐mvc的，发现文字量不少，今天先不吐先，下一篇我要吐乱用注入函数。