IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

不应该用public static function来改善系统的抽象层次

Becomin' Charles 2015-11-02 22:55:06 累计浏览 3,225 次
本机暂存

   无论是在以前的团队,还是在现在的团队,都有人主张抽象出所谓的Service层,他们认为Model只负责跟数据库沟通,不应该混杂过多的东西,而同样也不赞成在Controller的Action里面,做太多事情,那样不利于复用。而他们赞成的方案,就是『抽象』出一层所谓的Service层,从而实现代码的复用。

   而我通过观察他们具体的实现的代码,发现,这是一个很糟糕的想法。因为很少有人能忍住诱惑不去滥用。

   在PHP里面,public static function其实就是最最原始的函数式编程模式的全局函数而已。任何一个软件里,如果全局函数满天飞,肯定不是一个『抽象』优秀的系统。如果不是绝对克制,那程序员会忍不住在任何地方,调用全局函数,甚至,只要一能复用代码,就忍不住去调用一下全局函数,得到好处后,就会进一步把更多的东西变成全局函数,而最后发现,所有的业务逻辑都在全局函数里了。

   这种做法,其实就是饮鸩止渴而已,在单人工作模式下,绝对自我控制的人,你还能采用这种方式,但是一旦到了团队合作的时候,你很难阻止同伴滥用,哪怕滥用了一次,这种做法就会无休止蔓延,就好像破窗户理论说的,整个大楼一破再破,直到崩塌。

   我举个简单例子,因为在全局函数里,你可以调用任何全局作用域的对象,当你那么做了以后,任何地方哪怕能复用到一部分这个方法,你就会忍不住去调用,因为是全局函数,总是可以被调用的,所以调用点的作用域,也全局化了。最后,整个系统就遍布着全局函数了。

   可能说得比较绕吧,但是有个大原则我是信奉的,也希望读者你能看懂:全局函数和全局变量是邪恶的,我们应该拼尽全力去减少全局变量和全局函数,而不是增加他们。如果你想实现一个所谓的Service层的时候,请不要使用public static function,因为那根本就是全局函数。

   另外,重申一下,不是说抽象Service层有多错误,我真正反对的是,使用public static function去进行所谓的抽象,那对抽象毫无帮助,说明你的抽象能力还停留在抽象一个函数的能力。

同分类推荐文章

  1. 等了十年的 Go 链式管道,终于来了:seq 让你像写 Scala 一样写 Go (2026-06-25 18:38:18)
  2. Go 实验特性详解 (2026-06-21 10:05:27)
  3. amd64 微架构级别对 Go 程序性能提升多少? (2026-06-21 09:38:49)

查看更多 后端 文章 →

建议继续学习

  1. 到底什么是MVC? (累计阅读 11,869)
  2. MVC之父对“模型-视图-控制器”的最初定义 (累计阅读 6,146)
  3. PHP最佳实践 (累计阅读 5,999)
  4. MVC演化史 (累计阅读 5,539)
  5. 高性能JavaScript模板引擎原理解析 (累计阅读 4,076)
  6. 编程语言介绍之Ruby on Rails (累计阅读 3,895)
  7. perl的HTML::Template模板技术 (累计阅读 3,690)
  8. android开发入门2:概念建立 (累计阅读 3,425)
  9. 从 if else 到 switch case 再到抽象 (累计阅读 3,396)
  10. Catalyst 框架学习 (累计阅读 3,240)