不应该用public static function来改善系统的抽象层次
无论是在以前的团队,还是在现在的团队,都有人主张抽象出所谓的Service层,他们认为Model只负责跟数据库沟通,不应该混杂过多的东西,而同样也不赞成在Controller的Action里面,做太多事情,那样不利于复用。而他们赞成的方案,就是『抽象』出一层所谓的Service层,从而实现代码的复用。
而我通过观察他们具体的实现的代码,发现,这是一个很糟糕的想法。因为很少有人能忍住诱惑不去滥用。
在PHP里面,public static function其实就是最最原始的函数式编程模式的全局函数而已。任何一个软件里,如果全局函数满天飞,肯定不是一个『抽象』优秀的系统。如果不是绝对克制,那程序员会忍不住在任何地方,调用全局函数,甚至,只要一能复用代码,就忍不住去调用一下全局函数,得到好处后,就会进一步把更多的东西变成全局函数,而最后发现,所有的业务逻辑都在全局函数里了。
这种做法,其实就是饮鸩止渴而已,在单人工作模式下,绝对自我控制的人,你还能采用这种方式,但是一旦到了团队合作的时候,你很难阻止同伴滥用,哪怕滥用了一次,这种做法就会无休止蔓延,就好像破窗户理论说的,整个大楼一破再破,直到崩塌。
我举个简单例子,因为在全局函数里,你可以调用任何全局作用域的对象,当你那么做了以后,任何地方哪怕能复用到一部分这个方法,你就会忍不住去调用,因为是全局函数,总是可以被调用的,所以调用点的作用域,也全局化了。最后,整个系统就遍布着全局函数了。
可能说得比较绕吧,但是有个大原则我是信奉的,也希望读者你能看懂:全局函数和全局变量是邪恶的,我们应该拼尽全力去减少全局变量和全局函数,而不是增加他们。如果你想实现一个所谓的Service层的时候,请不要使用public static function,因为那根本就是全局函数。
另外,重申一下,不是说抽象Service层有多错误,我真正反对的是,使用public static function去进行所谓的抽象,那对抽象毫无帮助,说明你的抽象能力还停留在抽象一个函数的能力。
建议继续学习:
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:Charles 来源: Becomin' Charles
- 标签: 抽象
- 发布时间:2015-11-02 22:55:06
- [66] Oracle MTS模式下 进程地址与会话信
- [66] Go Reflect 性能
- [65] 如何拿下简短的域名
- [59] android 开发入门
- [59] 图书馆的世界纪录
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则