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

[sentinelK]

设计的越精巧，需求变化的时候就越痛苦。

年轻的时候太容易把“术”理解成“道”。

[wanminny]

less is more ~~

[CaffreySun]

这个世界的复杂性很多时候完全是自找的，而人却不自知。

[Richared]

设计模式是要让代码更好些，更好读，别搞反了。

[sks4728]

小项目， 都是怎么简单怎么来。

[prosgtsr]

我写代码，可读性优先级最高

[vfs]

就我们 公司的代码来说，设计模式完全用不上， 单例模式对我来说，都有点儿 over kill

[doug]

@sks4728 接手过一个屎山 一个函数写了 1K+行 里面至少有三段代码是完全重复的

[chendy]

所谓设计是为了在复杂的环境中更好的应对变化
如果本身不复杂，或者写完了拉倒，那确实不需要设计，拉就完事了

[TWorldIsNButThis]

全单例 那不就是 Spring

[latifrons]

这就是我从 Java 转到 Go 之后干的事。
从此身上就没有一股 Java 味儿了

[guyeu]

全是单例为啥不直接面向过程编程？

[frayesshi1]

@doug #8 这种多了去了，没有封装，只是裸函数，一旦增加功能，就重新写一个函数，里面大部分都是粘贴之前的内容

[xdeng]

所有的模式 最终都可以拉成一条直线

[iorilu]

切忌提前设计, 过度设计, 为用设计模式而设计

[kneo]

何尝不是另一番景象的屎山。

[Betsy]

单例模式处理不好最容易出现线程不安全的问题，你充分考虑你的场景了吗🤔

[yidinghe]

经济下行，很多系统都没有什么新的需求变更了。

[qi19901212]

当你项目不是那么简单，一段时间就会有新的需求的时候，设计模式能减少很多问题 。但你已经成型不在变化的时候，你改成啥都可以，甚至不动就是最好的结果

[akaju]

舒服了

[Ipsum]

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

[tmkook]

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

[levelworm]

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

[dosmlp]

怎么简单怎么来，

[Lockroach]

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

[visper]

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

[yazinnnn0]

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

[opengps]

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

[yb2313]

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

[panlatent]

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

[SvenWong]

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

[SvenWong]

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

[clemente]

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

[clemente]

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

[fredweili]

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

[beginor]

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

[axuahui]

那你的业务太简单了

[lanisle]

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

[IUefx]

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

[pangdundun996]

设计模式跟业务是相关的

[OC0311]

刚开始业务的时候 总想用设计模式 考虑以后的各种扩展，但是时间长了就会发现 ，产品的迭代往往不在之前预留的这些槽上 即便有相关领域的业务经验每家公司的产品提出来的需求都是有很大差异的。

[EndlessMemory]

手段终究是手段，不要当成目的

[wobuhuicode]

是现在机器好了，没有经历过 OOM 毒打才会想到做到只保留单例

[doug]

@SvenWong 其实那是一个功能很简单的项目 但是接手了 5 个人 后面接的人因为是量产项目也不敢怎样大改 反正遇到有新的需求 就那样直接复制上 结果越整越恶心

[xloger]

额，这更多是出在“水平”上面，而不是“设计模式”的问题。
我说的直白了点，但不是针对楼主，你就当是我自己的感悟吧：

代码的复杂度，最少也是等同于现实里这套需求的复杂度。
好的架构设计，是拟合现实需求的，将其拆散、梳理成一个个可拆卸组装的子模块。
不好的设计，一种自然就是过度设计，也就是光套各种设计模式，反而把自己束缚了。
另一种不好的设计，就是一大个混沌系统，把“复杂度”一部分放在了开发者脑子里。

过多的单例就是一个馄饨的体现。
有几个模块，假设我们严格按照分层，是很容易遇到一些特殊场景。怎么跨层传递数据、或者类似的一些问题。
设计得不好但还要强行遵守，就是加各种传递方法，千层饼。另一种就是改成单例互相调来调去，进一步增加复杂度。
很明显的，还有一条路，就是梳理思索这些模块究竟怎么分配合理，每个地方的语义是啥，怎么做是最清晰的。

拿上面几位朋友的说法补充点我的想法：
1 、简单初步的设计模式运用，这并不是“精巧”。架构设计的目的是分层、隔离，降低复杂度。
如果只是代码层面的“解耦合”，而不是业务“解耦合”，那自然会出现：看似规范地写了接口和实现，然后频繁地接口加方法、实现类加方法，然后感觉这个接口毫无意义不如去掉。
这个的根源在于你这个接口的定义设计得不合理。
2 、看一段逻辑需要跳到不同的文件里看好几处。
这同样是一种具体写法不对导致的复杂度上升。要规避的是
fun main {
step1()
step2()
step3()
}
这种写法。而是要让一段逻辑的核心在一块。也就是更多时候问题是出现在“拆代码的方式不对”，而不是“不该拆代码”。

这些能力都是要靠锻炼出来的，我们普通人只能靠努力和多动脑才能让自己越做越好。而不是浅尝辄止，觉得这些 XX 、YY 不就是那么回事嘛。

[aweim]

我早就放弃了，越简单越好

[yunnysunny]

没有多态，硬要继承

[islaohu]

最好的代码设计就是不设计

[seansong]

明明每天只有 10 req ，却操着 10billion req 的心，从而把自己给设计进去了

[rainbowhu]

功能不复杂，代码就不用写复杂。后面功能复杂了，按需求迭代重构就完了。正确实现功能的前提下，简单，易读，bug 少就是好代码，管他有没有套路。

[horizon]

那直接写成一个文件不是更好

[zhady009]

@xloger 看到这种标题我就想要看看他们的代码, 抽象抽得四不像没有抓到点子上, 不该抽象的抽象等等一句话总结就是用错了或者不合理, 导致你后面一连串的问题又全部推给设计模式