回顾 SOLID 设计原则

在前面的五篇文章当中，我们提到了 SOLID 设计原则，分别为

同样让我尝试用一段话来整理这些内容之间的关系：

如果以公司部门的角度出发，「单一功能原则」确保这个部门只会对应、负责一种业务需求，也就是说，当某种业务有新的需求或旧有需求变化的时候，公司可以很明确知道找哪个部门负责，在这样的情况下，只要请该部门开始变动，而不会影响其他部门的运作，确保公司的稳定性。

「开放封闭原则」提到，当负责的部门因应新的需求时，可以快速透过「扩展」的方式来加入、整合新的资源（譬如外包厂商）来产生新的功能，而不用大幅度的更动原部门的架构（开放扩展、封闭修改）。

「依赖反转原则」提到，当负责的部门开始依赖其他资源的时候，譬如外包厂商，需要订定好「互动规则」，以避免外包厂商变动的时候（譬如更新实作方式、更新产出规格等）时，负责的部门也需要跟着变动。

「里氏替换原则」提到，从客户的角度来看，今天不管这间公司的部门做了什麽样的变动、更新，都需要提供同样的服务给客户，以避免有错误的期待或操作。

最後，「介面隔离原则」提到，从客户的角度来看，公司部门不应该提供多余的服务或功能给客户，以避免当这些服务或功能的改变，造成客户产生不必要的错误。

下一步？

以上的五点，确保了程序码在面对需求变动时的扩展性、维护性、稳定性。不过这些最终都只是「原则」。在因应不同变化的时，为了要满足这些原则，就会产生出不同的解决方案。而这些解决方案，就是我们之後要提到的「设计模式」。

设计模式就是人们根据一些常见的问题，整理出来的「解决方案」。这些解决方案其实也只是一张蓝图，实际的执行方式与内容，还是得看不同问题的细节，以及使用的程序语言为何。

所以接下来提到不同的设计模式，每一个模式都有他各自要解决的问题，而设计模式也不是万能，有其使用的范围与局限性。但如果能够认识一些常见的设计模式，未来在面对问题的时候，就会有更多的蓝图可以参考使用罗。

设计模式主要分成三大类，分别是

在接下来的日子当中，会陆续开始介绍不同的设计模式，也许不会把 GoF 提出的 23 种全部讲完，但希望能够在过程中更了解不同的设计模式在处理的问题，以及如何解决问题