谈一下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的,发现文字量不少,今天先不吐先,下一篇我要吐乱用注入函数。