在开始学习实际的设计模式前，让我们先来看看软件架构的设计过程，了解一下需要达成的目标与需要尽量避免的陷阱
代码复用
无论开发何种软件产品，成本和时间都是最重要的两个维度。较短的开发时间意味着可比竞争对手更早进入市场；较低的开发成本意味着能够留出更多营销资金，因此能更广泛地覆盖潜在客户
代码复用是减少开发成本最常用的方式之一。其意图非常明显：与其反复从头开发，不如站在巨人的肩膀之上，重用已有代码
可扩展性
变化是程序员生命中唯一不变的事情，因此在设计程序架构时，有经验的开发者会尽量选择支持未来任何可能变更的方式
设计原则
-
封装变化的内容
找到程序中的变化部分将其放入单独的模块中，保护其他代码不受负面影响。最终，开发者只需要花较少的时间来维护变化部分的程序即可
该原则的主要目的是将变更造成的影响最小化。在修改程序上所花的时间越少，就会有更多时间来实现功能
-
面向接口进行开发，而不是面向实现
在系统设计和编程中，应该关注接口的定义和使用，而不是过多关注具体的实现细节。强调将程序的不同部分解耦，通过定义清晰的接口来实现模块间的交互。这种方式可以提高代码的可维护性、可扩展性
该原则的主要目的是降低代码之间的耦合度，提高系统的灵活性和可扩展性，从而更好地适应需求变化和维护要求
-
组合优于继承
虽然继承在某些情况下仍然是有用且合理的，但使用组合可以提供更大的灵活性，减少代码之间的耦合，更好地满足需求变化和代码维护的要求
该原则的主要目的是鼓励我们在设计和组织类之间的关系时，更多地考虑使用组合，以提高灵活性、可维护性和封装性
SOLID 原则
-
S：单一职责原则（Single Responsibility Principle）
该原则的核心思想是将一个复杂的任务分解成多个单一职责的模块或者类，从而使得代码更加灵活、可维护和易于理解
如果一个模块或者类承担了过多的职责，那么它就变得难以理解和修改，也会导致系统的耦合度增加，从而降低了系统的可维护性和可扩展性
-
O：开闭原则（Open-Closed Principle）
该原则指出软件实体（类、模块、函数等）应该对扩展开放，对修改关闭
当需求发生变化时，应该通过添加新的代码来扩展系统的功能，而不是修改已有的代码。通过遵循开闭原则，可以保持现有代码的稳定性，减少引入错误的风险，并提高代码的可复用性
-
L：里氏替换原则（Liskov Substitution Principle）
该原则要求在设计类的时候，保证子类能够完全符合父类的行为约定，而且还可以在不破坏父类行为的情况下进行扩展，以确保代码的可靠性、稳定性和可维护性
-
I：接口隔离原则（Interface Segregation Principle）
该原则的核心思想是将单一臃肿的总接口拆分为专门化的更小、更具体的接口，从而降低使用类的耦合性，提高系统的灵活性和可维护性
-
D：依赖倒置原则（Dependency Inversion Principle）
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。通过定义抽象接口，高层模块和低层模块可以通过接口进行通信，使得系统更加灵活和可扩展
在面向对象编程中，高层模块通常指的是实现系统业务逻辑、处理核心功能的模块。这些模块通常处于系统的顶层，负责调用和协调较低层次的模块以完成具体的任务
相对应的，低层模块则是提供基础服务、实现基本功能的模块，如文件操作、网络通信等
