大道至简，把项目中的设计模式、多继承、各种抽象类全干掉了，只保留了单例，舒服了。当年年轻的时候总是想办法写的优雅，归来仍是少年。

设计模式在我看来就是解耦，为以后加新功能做准备。

单例你怎么保证上下文不被污染？如果单例能满足你的需求那只能说明你的业务不需要设计模式

可能是水平不够，现在一看到设计模式就头疼，因为总要跑到几个不同的文件里去看。比如说看 Crafting Interpreter 里用 visitor pattern 去处理多类型同一操作的问题，我就觉得换成我肯定就是一个 switch-case ，而不是先 accept()再 visit()。

怎么简单怎么来，

没有维护后续的需求就随便写吧

要不全部静态方法试试？绝大部分都是纯函数，状态控制在一个状态对象里面。

业务复杂度上去之后, 怎么写都是屎

非标项目确实这么用更舒服。

我已经把{}和; 还有类型干掉了

不应该摒弃设计模式，而是要避免过度设计

@doug #8 非常正常，没写单元测试的情况下，我自己写的代码想重构有时候都会忘记逻辑，更别说别人的代码，有个正常运行的，复制过来是最好的 更有甚者是某个客户现场 bug ，要改好直接上的那种

@SvenWong #30 看错了，是一个函数里是吧，那我干不出来这种事

马斯克说的很对 最优雅的方法往往是最简单的

@Richared 大多数情况是 为了套模板而套

然后呢？给客户/用户创造了什么价值么？这样的重构测试写好了么？

对于大多数系统，不管是.NET 还是 Spring ，还是其它语言， 只要使用框架内的依赖注入，然后自己只需要写接口+实现，甚至只写实现，按需注入容器就很稳了，没必要折腾

那你的业务太简单了

全部去掉？这是另一个“主义”。

@prosgtsr 我觉得你这个我是深表赞同的，

设计模式跟业务是相关的