xloger
4 天前
额，这更多是出在“水平”上面，而不是“设计模式”的问题。
我说的直白了点，但不是针对楼主，你就当是我自己的感悟吧：
代码的复杂度，最少也是等同于现实里这套需求的复杂度。
好的架构设计，是拟合现实需求的，将其拆散、梳理成一个个可拆卸组装的子模块。
不好的设计，一种自然就是过度设计，也就是光套各种设计模式，反而把自己束缚了。
另一种不好的设计，就是一大个混沌系统，把“复杂度”一部分放在了开发者脑子里。
过多的单例就是一个馄饨的体现。
有几个模块，假设我们严格按照分层，是很容易遇到一些特殊场景。怎么跨层传递数据、或者类似的一些问题。
设计得不好但还要强行遵守，就是加各种传递方法，千层饼。另一种就是改成单例互相调来调去，进一步增加复杂度。
很明显的，还有一条路，就是梳理思索这些模块究竟怎么分配合理，每个地方的语义是啥，怎么做是最清晰的。
拿上面几位朋友的说法补充点我的想法：
1 、简单初步的设计模式运用，这并不是“精巧”。架构设计的目的是分层、隔离，降低复杂度。
如果只是代码层面的“解耦合”，而不是业务“解耦合”，那自然会出现：看似规范地写了接口和实现，然后频繁地接口加方法、实现类加方法，然后感觉这个接口毫无意义不如去掉。
这个的根源在于你这个接口的定义设计得不合理。
2 、看一段逻辑需要跳到不同的文件里看好几处。
这同样是一种具体写法不对导致的复杂度上升。要规避的是
fun main {
step1()
step2()
step3()
}
这种写法。而是要让一段逻辑的核心在一块。也就是更多时候问题是出现在“拆代码的方式不对”，而不是“不该拆代码”。
这些能力都是要靠锻炼出来的，我们普通人只能靠努力和多动脑才能让自己越做越好。而不是浅尝辄止，觉得这些 XX 、YY 不就是那么回事嘛。