『单例模式被公认为是 反面模式(Anti Pattern),建议弃用』如何理解?

原文:

THIS IS CONSIDERED TO BE AN ANTI-PATTERN! FOR BETTER TESTABILITY AND MAINTAINABILITY USE DEPENDENCY INJECTION!

这句话,感觉可以引申出不少东西了,有点难翻,不是很好理解,大家说说看法。

附上:什么是 ANTI-PATTERN —— https://learnku.com/docs/php-design-patter...

每天进步一点点

本帖已被设为精华帖!
本帖由 Summer 于 1年前 加精
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 5

自己回复一下吧,感谢summer老大的翻译,第一句话是他翻的。
我理解是这样的:单例模式就可测试性而言,在做单元测试的时候,如果想去模拟一个单例,是做不到的,因为这个单例和真实业务中的单例是同样的,并不是像通常那些可以通过mock来实例化的假数据,它本身是个“真数据”,况且不看它的具体实现方式,我们也无法知晓如何去模拟它所依赖的那些数据。就可维护性而言,它自身掌握了自己的生命周期,管理了自己的依赖关系,我们拿到它的时候,它到底和哪些数据有关联,这个也无从知晓。

1年前 评论
Summer

@wilson_yang 我改了下标题和内容哈,文意不变,就是加了点信息,方便大家讨论。

同一段话,在 多例模式(Multiton) 下也有提及

1年前 评论

单例模式本质就是“全局”的,单例类如果有状态,就和全局变量一样难以维护。

1年前 评论

抛砖引玉。从六大设计原则的角度来看,它在一定程度上违背了单一职责原则,它既提供了工厂方法来生产它自己,同时在它内部又提供了业务类的方法,供使用者使用,将创建产品和使用产品耦合在一起。

1年前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!