什么是模式设计（我对代码架构的理解）

前提

我之所以要写这一篇文章主要是看了《什么是代码架构（我对设计模式的理解）》这片文章。
因此，我也想来谈谈我的理解，这不会互怼，只是对其中的一些不同的观点。如下：

• 不用设计模式也可以完成工作（可能是我理解偏差所致）
• 设计模式和架构的区别
• 「设计模式，这是我听过最糟糕的翻译」

我会逐步发表对上述的不同观点进行说明。

什么是架构？

架构，是一个比较广义的词汇，在技术圈子里，代指也比较多。这里单纯说说代码架构，代码架构即本身就是一种模式抽象。

不用设计模式也可以完成工作

首先，不用「设计模式」是无法完成工作的，只是从主观上没用，无论是语言本身还是开发人员技术本身，都被限制在某一个模式里面，例如，用 PHP 的面向对象，而面向对象本身的使用即在使用「模式设计」。如果真的不用「设计模式」我们只能写二进制，而内核指令也是包含「模式设计」的，换句话说，我们无论如何都避不开，只是开发人员自认为自己没有使用，何为使用？即无论那一层都包含则视为使用。

设计模式和架构的区别

设计模式和架构有着本质的区别，架构是用来解决问题的方案，模式设计是在方案之上的抽象设计。而我们常用「设计模式」均为「反例模式」这里可以参考 Laravel China 上的《PHP 设计模式全集 2018》了解，而架构，更多的是做技术评审时候的方案，用来解决实际问题而设计。且架构受到架构师自身经验等限制，是一种主观方案。而我们大多数说的「设计模式」是固有方案，需要得到广大使用者认可的，哪怕是「反例模式」。而反例模式的问题就在于存在某些方面缺陷但是目前却能较好的解决问题。

「设计模式，这是我听过最糟糕的翻译」

这是《什么是代码架构（我对设计模式的理解）》中的原文引用，更高的翻译是什么？不可能是「代码架构」。代码架构中，我还是 PHP 举例（?因为 PHP 真的是世界上最好的语言），当你使用接口类定义某个功能责任，然后你发现有些东西其实是一样的，没必要每个继承接口的类都去实现，你会想到使用抽象类去把通用的实现。而类只需要实现自身业务。这是我们常做的操作，那么这个操作是什么么？很遗憾的告诉你，这就是「架构」，亦或是「设计模式」但是这不能被正在的称之为「设计模式」，这是 PHP 本身就提供的方案，但是这算架构却不一定算「设计模式」

什么是设计模式？

观点和原文中的一些评论一致，我引用：

架构是道，设计模式是术，道恒在，而术常变。没必要拘泥于某些设计模式去写代码，合适的地方用合适的方式，设计模式的使用也不是机械的套用，领会精神，灵活使用即可。如同盖房子，如果只会搭个柴房，没必要用钢梁架构，但是如果是一个摩天大楼，那每个细节设计都需要参考前人的设计经验（设计模式），取其精华。

很多人听到架构就望而却步，但是听到设计模式却愿意一试。很多人把这两个归纳为一种东西，只是层次不一样。确实如此，却有并非如此。架构涉及的并非只是代码，而是一种方案，设计模式设计的页并非只是代码，也是一种方案。但是架构是一种主观方案，而设计模式是为了解决某一需求或问题而出现的实现方案。

总结

设计模式更多的是解决问题和实现「高可拓」，架构就像一栋建筑的设计图，架构设计更像这栋建筑电梯位置甚至房间布局设计细节图。架构负担起这栋建筑的强度，外观等。设计模式则是负责这种建筑的内部结构，如何电梯更合理。安全通道如何设计，电梯该在楼道那一侧，某一层该有几个房间等。