小弟在设计系统的功能时，时常会不知该用什么准则来判断适合的模式
之前曾在某个网站中看到同一个问题，拿来套进 23 个模式之中
当下看完后，心想：所以大部份的问题都可以任意套用模式？
应该不是这样子，否则四人帮就没有必要把它们分成三大类了
那到底该如何决择正确的模式
这个问题一直困扰著…
例如订单依国别计算不同费用
这问题是用工厂好？还是策略好？
恳请大大们解惑

策略吧 为啥会用工厂?其实很多时候不用为套而套吧会把简单东西复杂化

等你想怎样写你最好改也最能看得懂的时候，不知不觉就会用上了。

推楼上

你听过太极拳或独孤九剑吗 不要拘泥于招式 无招胜有招

我自称DP哥 工厂模式COMBO策略模式 很常用的

最好的方法就是你写一遍

DP 是武功 SOLID 是心法 先练心法才看得懂武功

认真说 遇到的时候问题会告诉你该用什么模式 不然就是问题还不够清楚 这时候最好别乱用可以去看旧程式码或开源专案 感受一下别人用设计模式是在干嘛 只看书上的其实你都感受不到那个规模像 visitor pattern 就可以去看看 rust serde 函式库怎么用的滥用模式跟不用模式硬要选一个 大家应该都会选后者

先重构, 重构的过程有机会发现变成某几种模式的形状但如果情境单纯, 也不用硬要重构或是找出什么模式就是

先重构+1 如果你发现一直写重复的代码就是一种征兆用工厂的情况也不少 例：多个supplier的connectio量身订作

模式是在解决你的需求 所以很常都会有一些变形或组合依据自己经验去设计 最后会发现你的东西就是某个模式的样子

你可以先挑一个来玩 builder最容易上手最好改

一开始先别想太多设计模式是要慢慢修剪的

你可以读 Refactoring to patterns首先要能辨识 smells, 然后透过重构改为设计模式不只可以学习何时该使用设计模式，也能避免过度设计

公司的东西的话 很简单 都是看薪水给多少

认真看一下书。。。我觉得你肯定没看书网络文章随便看然后整天幻想要怎么设计不如认真读书。。。

先重构 +1过程中应该会有使用哪个模式想法了刚学设计模式切忌看到什么 code 就想把它改成设计模式避免为用而用

最近看到同事为用而用 反而写出难以维护的程式码看起来很厉害 读起来很痛苦 而且还不符合solid原则

别做出ide都没办法帮你trace code就行#不然接手帮忙修BUG的人会一直问候你亲人最好是有需求、有痛点再去找解决方案，不然容易写出狗屎不然一般来说专案架构简单好维护比什么都重要

我看过太多过度设计的例子了

先写一堆烂code然后看相关书籍，然后重构烂code

设计模式的出发点都是可读可维护好扩充 掌握原则就好了

你对你的程式要有改进的热诚. do it. pattern自然出现

我觉得先有点经验再去学design pattern比较实在 一堆人连继承多型都不知道该何时用

问这个问题时，就表示哪个都不该选…XD

首先你要认知到的是模式只能当作一种指引，而不是像公式一样让你拿来套的

推滥用不如不用+1

一堆网页和书都在教坏人硬套设计模式，这个嘘是给他们的。在工作上遇到那种设计模式硬套写出来的可怕code真的让后人白多花一堆时间去理解、而且又在有人叠床架屋继续从不好的架构去发展的话，整个很惨，说真的，不套模式都还好多了

实作越多年，越觉得 DP 不用特意学/背，需要的情景自然会查到