※ 引述《azoaho (历史洪流)》之铭言：
: 小弟在设计系统的功能时，时常会不知该用什么准则来判断适合的模式
: 之前曾在某个网站中看到同一个问题，拿来套进 23 个模式之中
: 当下看完后，心想：所以大部份的问题都可以任意套用模式？
: 应该不是这样子，否则四人帮就没有必要把它们分成三大类了
: 那到底该如何决择正确的模式
: 这个问题一直困扰著…
请你把clean code三本都看完
可以的话clean architecture也一起
这系列就是在讲什么时候该用什么模式的准则
我这篇也讲几个重点原则
1. 保持简单
能用最简单的写法
就用最简单的写法
初学SOLID和设计模式最常见的
就是手了拿了锤子看什么问题都是钉子
硬是要用只会过度设计
SOLID和设计模式是非到必要时刻不要使用
因为这东西是一把双面刃
SOLID和设计模式的目的在于让你未来更方便维护、扩充
但副作用是程式架构复杂化
一个弄不好反而更难维护
这就违反你当初使用这个招式的本意
2. 在有必要用的地方再用
承上题
所谓有必要用的地方
是指这个部份未来很有可能需要扩充或改动
如果你懂的基本的架构或OOP
你会自然而然把程式拆成好几个小元件
每一个小元件都可以分成三种类型
第一种是未来极少会在改动
第二种是未来极可能会常常改动
第三种是当下不确定未来会不会改动
第一种就不要再去想设计模式
第二种你可以尝试去加进设计模式
第三种比较有争议
我个人是优先用单纯的写法
在未来真的遇到有改动时
我再重构
还是一样
能不要用设计模式就不要用让设计单纯化
3. 正确模式的迷思
事实就是
没有所谓的正确的模式
一百个问题会有一百种答案
一百个人也会有一百种选择
但还是有个大原则可以依循
那就是先从最简单的模式开始下手
做到一半发现不行不符合需求
再改成其它更复杂一点的模式
很有可能做完了想一想发现怎么另一个模式更适合？
你再顺手改成另一个模式
所以迭代演进才是重点
一次一次试
一次一次改
一次一次的重构
让正确的模式在程式不断演进之下慢慢成形
这个才是真正的使用到正确模式的唯一方法
而时间一久你会累积更多经验
到时候你自然会进化成看到类似问题脑中自然出现模式的优先级
大概就这三点
其实还有很多
书就自己去看吧
要玩这个就是这样玩
会不会觉得
一定要搞这么累吗？
对就是要这么累你才会进步
不然你也可以回去写意大利面程式也没差
台湾不重视这个
写程式写了几十年一个模式也不会SOLID完全没概念的满街都是
也不会怎样啦