软件设计模式目标原则
软件架构设计的原则和实践
软件架构设计的原则和实践软件架构设计是指为了实现软件系统所需的各种功能，将程序分解为不同部分，并定义各个部分之间的协作和交互方式的过程。
在软件开发中，软件架构设计是非常关键的一步，也是软件设计中的基础性工作。
一个好的软件架构设计应该具备以下原则和实践。
一、单一职责原则单一职责原则是指一个类或方法只负责一个功能，不要包含太多的职责。
在软件设计中，过多的职责会导致程序复杂度大、维护难度大、代码可读性差等问题。
因此，在软件架构设计中，我们要尽可能地让每个部件只负责一个职责，这样才能使程序简单、易于维护。
二、开放封闭原则开放封闭原则是指软件系统的设计应该是对扩展开放的，但是对修改封闭的。
也就是说，我们在软件架构设计中要尽可能地预见未来可能的需求，并且为未来的可能性预留接口和扩展点。
在软件更新时，将新功能添加到已有的代码中，而不是修改已有的代码。
这样可以避免对现有功能的破坏。
三、依赖倒置原则依赖倒置原则是指高层模块不依赖低层模块，而是依赖其抽象。
也就是说，任何类都应该依赖于抽象接口，而不是具体实现。
在软件架构设计中，我们需要将高层模块和底层模块进行解耦，将它们之间的通信通过接口进行沟通，使得系统更加灵活和可扩展。
四、接口隔离原则接口隔离原则是指一个类不应该强制性地依赖于另一个类的方法和属性。
也就是说，在软件架构设计中，我们需要将类的接口进行拆分，将不同的方法和属性分别封装在不同的接口中，从而避免了类之间的耦合性。
五、迪米特法则迪米特法则是指一个对象应该知道其他对象的最少信息，也就是所谓的“最少知道原则”。
在软件架构设计中，我们需要尽量减少不必要的通信，使得每个对象的职责尽量单一。
这样不仅可以提高软件的性能，也可以降低软件的复杂度。
六、面向对象设计思想在软件架构设计中，面向对象设计思想是非常重要的。
它是一种将复杂系统分解成简单、可维护和可扩展的部分的过程。
面向对象设计思想将系统分解为许多对象，每个对象都包含其自身的数据和处理逻辑。
软件技术方案设计原则
软件技术方案设计原则1. 简洁性原则在软件技术方案设计中，简洁性原则是指尽量保持方案的简单和清晰，避免过度设计和冗余的功能。
简洁的方案不仅能减少代码量和维护成本，还能提高系统的性能和用户体验。
实践方法：•消除重复：避免出现相同或类似的功能实现方式，通过抽象和重用来减少代码重复。
•遵循KISS原则（Keep It Simple, Stupid）：尽量保持方案的简单和直观，避免引入复杂的逻辑和处理。
•保持模块化：将系统划分为独立的模块，每个模块负责一个明确的功能，以降低耦合度，提高可维护性。
2. 可扩展性原则可扩展性原则是指在软件技术方案设计中考虑到未来变化和需求的变动，保证系统能够方便地扩展和修改。
通过良好的可扩展性设计，可以避免代码重构和系统重建的成本。
实践方法：•利用设计模式：使用设计模式来抽象和隔离变化，例如工厂模式、策略模式等。
•分层设计：将系统划分为不同的层次，每个层次负责不同的功能，通过接口和抽象来定义层与层之间的交互。
•松耦合设计：通过使用消息队列、事件驱动等方式来降低模块之间的耦合度，使得系统的功能模块可以独立地进行扩展和修改。
3. 可维护性原则可维护性原则是指在软件技术方案设计中考虑到系统的可维护性，使得开发人员能够方便地阅读、理解、修改和扩展代码。
良好的可维护性设计可以减少错误和改进系统的质量。
实践方法：•遵循编码规范：统一的编码规范可以增加代码的可读性和可维护性，例如使用有意义的变量和函数命名、正确的缩进等。
•注释和文档：为代码添加必要的注释和文档，解释代码的逻辑和用法，方便后续的维护和开发。
•单元测试：编写良好的单元测试用例，保证代码的正确性和稳定性，并提供一个安全的修改环境。
4. 性能优化原则性能优化原则是指在软件技术方案设计中考虑到系统的性能问题，通过合理的设计和算法选择来提高系统的运行效率和响应速度。
实践方法：•选择合适的数据结构和算法：根据系统的需求和特性，选择合适的数据结构和算法来提高系统的性能。
软件设计模式六大原则
软件设计模式六⼤原则⽬录：设计模式六⼤原则（1）：单⼀职责原则定义：不要存在多于⼀个导致类变更的原因。
通俗的说，即⼀个类只负责⼀项职责。
问题由来：类T负责两个不同的职责：职责P1，职责P2。
当由于职责P1需求发⽣改变⽽需要修改类T时，有可能会导致原本运⾏正常的职责P2功能发⽣故障。
解决⽅案：遵循单⼀职责原则。
分别建⽴两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。
这样，当修改类T1时，不会使职责P2发⽣故障风险；同理，当修改T2时，也不会使职责P1发⽣故障风险。
说到单⼀职责原则，很多⼈都会不屑⼀顾。
因为它太简单了。
稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单⼀职责原则，在设计软件时也会⾃觉的遵守这⼀重要原则，因为这是常识。
在软件编程中，谁也不希望因为修改了⼀个功能导致其他的功能发⽣故障。
⽽避免出现这⼀问题的⽅法便是遵循单⼀职责原则。
虽然单⼀职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这⼀原则的代码存在。
为什么会出现这种现象呢？因为有职责扩散。
所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。
⽐如：类T只负责⼀个职责P，这样设计是符合单⼀职责原则的。
后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提⾼了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单⼀职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。
但是在程序已经写好的情况下，这样做简直太费时间了。
所以，简单的修改类T，⽤它来负责两个职责是⼀个⽐较不错的选择，虽然这样做有悖于单⼀职责原则。
（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。
所以记住，在职责扩散到我们⽆法控制的程度之前，⽴刻对代码进⾏重构。
）举例说明，⽤⼀个类描述动物呼吸这个场景：class Animal{public void breathe(String animal){System.out.println(animal+"呼吸空⽓");}}public class Client{public static void main(String[] args){Animal animal = new Animal();animal.breathe("⽜");animal.breathe("⽺");animal.breathe("猪");}}运⾏结果：⽜呼吸空⽓⽺呼吸空⽓猪呼吸空⽓程序上线后，发现问题了，并不是所有的动物都呼吸空⽓的，⽐如鱼就是呼吸⽔的。
软件架构设计的规范与准则
软件架构设计的规范与准则知识点：软件架构设计的规范与准则一、软件架构的定义1. 软件架构的概念2. 软件架构的组成要素3. 软件架构与系统架构的关系二、软件架构设计的目标1. 可靠性2. 可维护性3. 可扩展性4. 性能5. 安全性三、软件架构设计的原则1. 模块化原则2. 分层原则3. 抽象原则4. 松耦合原则5. 重用原则四、软件架构设计的过程1. 需求分析2. 架构风格选择3. 架构设计4. 架构评估5. 架构优化五、常见的软件架构风格1. 管道-过滤器风格2. 数据抽象和面向对象风格3. 层次化风格4. 事件驱动风格5. 微服务风格六、软件架构设计的关键技术1. 组件技术2. 服务技术3. 中间件技术4. 分布式技术5. 云计算技术七、软件架构设计的模式1. 创建型模式2. 结构型模式3. 行为型模式八、软件架构设计中的非功能性需求1. 性能需求2. 可用性需求3. 安全性需求4. 可移植性需求5. 兼容性需求九、软件架构设计的评估方法1. 定性评估方法2. 定量评估方法3. 模型检查方法4. 形式化验证方法十、软件架构设计的最佳实践1. 代码规范2. 设计模式3. 架构重构4. 架构演进5. 架构师角色十一、软件架构设计的前沿技术与发展趋势1. 人工智能与软件架构2. 物联网与软件架构3. 边缘计算与软件架构4. 云原生与软件架构5. 开源软件架构十二、软件架构设计的教育意义1. 培养学生的抽象思维能力2. 培养学生的系统观3. 培养学生的创新意识4. 培养学生的团队协作能力习题及方法：一、选择题1. 以下哪个选项不是软件架构设计的目标？答案：B. 可定制性解题思路：根据知识点“软件架构设计的目标”，可定制性并非软件架构设计的主要目标，而可靠性、可维护性、可扩展性、性能和安全性是软件架构设计的主要目标。
2. 以下哪种方法不属于软件架构设计的评估方法？答案：D. 用户体验评估解题思路：根据知识点“软件架构设计的评估方法”，用户体验评估并不属于软件架构设计的评估方法，而定性评估方法、定量评估方法、模型检查方法和形式化验证方法是软件架构设计的主要评估方法。
软件设计标准
软件设计标准1. 引言本文档旨在定义软件设计的标准和最佳实践，以确保软件的质量和可维护性。
在软件的设计阶段，遵循这些标准将有助于提高开发效率，并减少潜在的问题和错误。
2. 设计原则2.1 单一职责原则 (Single Responsibility Principle)每个软件组件或类应该有一个单一的责任，并且只负责一件事情。
这将使得代码的理解和维护更加容易。
2.2 开放封闭原则 (Open-Closed Principle)软件设计应该是可扩展的，对于新的要求或功能的添加，应该通过扩展而不是修改已有的代码来实现。
2.3 依赖倒置原则 (Dependency Inversion Principle)高层模块不应该直接依赖于低层模块，而应该依赖于抽象。
这将使得系统更加灵活和易于测试。
3. 设计模式3.1 单例模式 (Singleton)单例模式保证在整个应用程序中只有一个实例对象。
这在某些情况下是非常有用的，例如需要共享资源或需要限制对象数量的场景。
3.2 工厂模式 (Factory)工厂模式用于创建对象，将对象的创建逻辑封装起来。
这可以使得系统更加灵活，且易于扩展。
4. 代码规范4.1 命名规范使用有意义的变量和函数命名，遵循驼峰命名法。
避免使用缩写和不明确的命名。
4.2 代码结构代码应该有良好的结构和层次。
使用合适的缩进和空格来增加可读性。
4.3 注释在代码中使用适当的注释来解释代码的意图和功能，这将有助于其他开发人员理解代码。
5. 测试要求软件设计应该具备易测试的特性。
为每个功能和模块编写单元测试，并确保测试覆盖率达到预期水平。
6. 总结本文档定义了软件设计的标准和最佳实践，包括设计原则、设计模式、代码规范和测试要求。
遵循这些标准将有助于提高软件的质量和可维护性，从而提高开发效率。
软件架构设计的原则及模式
软件架构设计的原则及模式随着信息技术的迅速发展，软件系统在人们的生产生活中发挥着越来越重要的作用。
而软件架构设计作为软件开发过程的关键部分，不仅影响着软件系统的性能、可靠性和安全性等诸多方面，也影响着软件开发过程的可维护性和可扩展性。
所以，在软件开发过程中，如何进行良好的软件架构设计成为了一个非常重要的问题。
软件架构设计的原则软件架构设计的原则是指在进行软件架构设计时所遵循的准则和规范。
下面我们来介绍几个常见的软件架构设计原则：1. 单一职责原则单一职责原则就是指一个类只负责一个功能。
这个原则的优点是可以提高代码的可维护性和复用性，让代码更加清晰易懂。
2. 开闭原则开闭原则就是指一个软件实体应该对扩展开放，对修改关闭。
即通过扩展现有代码，在不修改原有代码的情况下实现新的功能。
3. 里氏替换原则里氏替换原则就是指，任何基类可以出现的地方，子类一定可以出现。
这个原则可以提高代码的可读性和可扩展性。
4. 接口分离原则接口分离原则就是指接口要尽可能的小和单一，避免过度耦合。
这个原则可以让代码具有更高的灵活性和可扩展性。
5. 依赖倒置原则依赖倒置原则就是指要通过抽象来打破高层模块对低层模块的依赖。
这个原则可以提高代码的可维护性和灵活性。
软件架构设计的模式软件架构设计的模式是指根据某种目标和特定情况，结合大量的实践经验总结出的一种软件架构解决方案。
下面我们来介绍几种常见的软件架构设计模式：1. 分层架构分层架构是一种将系统划分为多个层次，并且层与层之间有明确的接口，从而实现系统的松耦合的架构。
这种架构通常包括表现层、业务逻辑层、数据访问层等。
2. MVC架构MVC架构是一种将系统分为三个部分：模型、视图、控制器，并且在这些部分之间有明确的分工。
控制器负责接收和分配请求，模型实现业务逻辑，视图负责呈现页面。
这种架构可以实现代码的分离和重用。
3. SOA架构SOA架构是一种将系统中的不同功能拆分为服务，通过这些服务来实现不同模块之间的通信和协作。
软件设计师考试笔记
软件设计师考试笔记作为软件设计师，你需要掌握以下内容：1. 软件设计原则：- 单一职责原则（SRP）：每个类应该只有一个变化的原因。
- 开放封闭原则（OCP）：软件实体（类、模块、函数等）应该是可扩展的，而不是可修改的。
- 依赖倒转原则（DIP）：高层模块不应依赖于低层模块，二者都应该依赖于抽象。
- 接口隔离原则（ISP）：客户端不应该依赖它不需要的接口。
- 迪米特法则（LoD）：一个对象应该尽可能少地与其他对象发生相互作用。
2. 软件设计模式：- 单例模式：确保一个类只有一个实例，并提供一个全局访问点。
- 工厂模式：通过一个工厂类来创建对象，而不是直接调用构造函数。
- 观察者模式：定义了对象之间的一对多依赖关系，当一个对象的状态发生变化时，它的所有依赖者都会收到通知并自动更新。
- 装饰器模式：通过动态地给一个对象添加一些额外的职责，而不需要修改原始对象的结构。
- 策略模式：定义了一系列的算法，并使它们可以互相替换，使得算法可以独立于客户端而变化。
3. UML建模：- 类图：描述了类之间的关系、属性和方法。
- 时序图：描述了对象之间的交互顺序。
- 用例图：描述了系统和外部实体之间的交互。
- 状态图：描述了对象在不同状态下的行为。
4. 数据库设计：- 根据需求分析设计数据库表结构。
- 设计合适的主键、外键和索引。
- 优化数据库查询性能，避免冗余数据和复杂的关联查询。
5. 软件架构设计：- 划分系统模块，确定各个模块之间的关系和接口。
- 选择合适的架构风格，如客户端-服务器、分层、微服务等。
- 考虑系统的可伸缩性、灵活性和可维护性。
除了以上内容，还需要了解编程语言（如Java、C++、Python等）的基础知识、数据结构和算法、网络通信和安全等方面的知识。
考试前，建议多做练习题和项目实战，加深对知识的理解和应用能力。
设计模式七大原则
设计模式七⼤原则1. 设计模式的⽬的编写软件过程中，程序员⾯临着来⾃耦合性，内聚性以及可维护性，可扩展性，重⽤性，灵活性等多⽅⾯的挑战，设计模式是为了让程序(软件)，具有更好的 1) 代码重⽤性 (即:相同功能的代码，不⽤多次编写) 2) 可读性 (即:编程规范性, 便于其他程序员的阅读和理解) 3) 可扩展性 (即:当需要增加新的功能时，⾮常的⽅便，称为可维护) 4) 可靠性 (即:当我们增加新的功能后，对原来的功能没有影响) 5) 使程序呈现⾼内聚，低耦合的特性分享⾦句: 设计模式包含了⾯向对象的精髓，“懂了设计模式，你就懂了⾯向对象分析和设计(OOA/D)的精要” Scott Mayers 在其巨著《Effective C++》就曾经说过:C++⽼⼿和 C++新⼿的区别就是前者⼿背上有很多伤疤2. 设计模式七⼤原则设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础（即：设计模式为什么这样设计的依据）设计模式常⽤的七⼤原则有:1. 单⼀职责原则2. 接⼝隔离原则3. 依赖倒转（倒置）原则4. ⾥⽒替换原则5. 开闭原则6. 迪⽶特法则7. 合成复⽤原则3. 单⼀职责原则（SingleResponsibility）基本介绍 对类来说的，即⼀个类应该只负责⼀项职责。
如类 A 负责两个不同职责：职责 1，职责 2。
当职责 1 需求变更⽽改变 A 时，可能造成职责 2 执⾏错误，所以需要将类 A 的粒度分解为 A1，A2应⽤实例 以交通⼯具案例讲解package com.atguigu.principle.singleresponsibility;public class SingleResponsibility1 {public static void main(String[] args) {Vehicle vehicle = new Vehicle();vehicle.run("摩托车");vehicle.run("汽车");vehicle.run("飞机");}}/*** 交通⼯具类* ⽅式⼀* 1. 在⽅式⼀的 run ⽅法中，违反了单⼀职责原则* 2. 解决的⽅案⾮常的简单，根据交通⼯具运⾏⽅法不同，分解成不同类即可*/class Vehicle{public void run(String vehicle){System.out.println(vehicle + "在公路上运⾏...");}}⽅案⼀package com.atguigu.principle.singleresponsibility;public class SingleResponsibility2 {public static void main(String[] args) {RoadVehicle roadVehicle = new RoadVehicle();roadVehicle.run("摩托车");roadVehicle.run("汽车");AirVehicle airVehicle = new AirVehicle();airVehicle.run("飞机");}}/*** ⽅案⼆的分析* 1. 遵守单⼀职责原则* 2. 这样做的改动很⼤，即将类分解，同时修改客户端* 3. 改进：直接修改 Vehicle 类，改动的代码会⽐较少 => ⽅案三*/class RoadVehicle{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏");}}class AirVehicle{public void run(String vehicle){System.out.println(vehicle + "在天空运⾏");}}class WaterVehicle{public void run(String vehicle){System.out.println(vehicle + "在⽔中运⾏");}}⽅案⼆package com.atguigu.principle.singleresponsibility;public class SingleResponsibility3 {public static void main(String[] args) {Vehicle2 vehicle2 = new Vehicle2();vehicle2.run("摩托车");vehicle2.runAir("飞机");vehicle2.runWater("轮船");}}/*** ⽅式三的分析* 1. 这种修改⽅法没有对原来的类做⼤的修改，只是增加⽅法* 2. 这⾥虽然没有在类这个级别上遵守单⼀职责原则，但是在⽅法级别上，仍然是遵守单⼀职责 */class Vehicle2{public void run(String vehicle){System.out.println(vehicle + "在公路运⾏...");}public void runAir(String vehicle){System.out.println(vehicle + "在天空运⾏...");}public void runWater(String vehicle){System.out.println(vehicle + "在⽔中运⾏...");}}⽅案三单⼀职责原则注意事项和细节1. 降低类的复杂度，⼀个类只负责⼀项职责2. 提⾼类的可读性，可维护性3. 降低变更引起的风险4. 通常情况下，我们应当遵守单⼀职责原则，只有逻辑⾜够简单，才可以在代码级违反单⼀职责原则; 只有类中⽅法数量⾜够少，可以在⽅法级别保持单⼀职责原则4. 接⼝隔离原则(Interface Segregation Principle)基本介绍 1. 客户端不应该依赖它不需要的接⼝，即⼀个类对另⼀个类的依赖应该建⽴在最⼩的接⼝上 2. 看图： 3. 类A通过接⼝ Interface1 依赖类B，类C通过接⼝ Interface1 依赖类D，如果接⼝ Interface1 对于类A和类C来说不是最⼩接⼝，那么类B 和类 D 必须去实现他们不需要的⽅法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件设计模式目标原则 Revised by BLUE on the afternoon of December 12,2020.
软件设计模式、目标、原则
软件设计模式
一、设计目标：
⑴、软件设计目标：正确性、健壮性、灵活性、可重用性、高效性
1、正确性：也就是满足应用程序的需求。
2、健壮性：是指软件对于规范要求以外的输入情况的处理能力。
也就是说，在异常情况下，软件能够正常运行的能力。
3、灵活性：就是可以允许代码修改平稳地发生，而不会波及到很多其他的模块。
4、可重用性：也就是重复使用的意思。
5、高效性：一般指两个方面，一是执行效率，二是存储效率。
⑵、良好设计的特征：可扩展性、灵活性、可插入性
1、可扩展性：新功能容易加入，而且不会影响已有功能，即不“僵硬”
2、灵活性：修改一个地方，不会影响其他，即不“脆弱”
3、可插入性：用一个容易替换另一个类，只要它们实现相同接口即可，即低“黏度”
⑶、面向对象的三大特征：继承性、封装性、多态性
1、继承性：特殊类的对象具有其一般类的对象的全部属性和行为，即称特殊类对一般类的继承。
2、封装性：把对象的属性和行为组合成为一个独立的单位或部件，并尽可能隐蔽对象的内
部细节，而只保留必要的对外接口，使之与外部发生联系。
3、多态性：是指不同类型的对象接收相同的消息时，产生不同的行为
二、设计原则：
⑴、软件设计原则：单一职责原则、开闭原则、里氏替换原则、接口
分离原则、依赖倒置原则
1、单一职责原则（SRP）：一个类应该有且只有一个改变的理由，它要求“一个设计元素只做一件事”。
2、开闭原则（OCP）：不修改原有类就能扩展一个类的行为。
也就是说，一个软件实体应当对扩展开放，对修改关闭。
3、里氏替换原则（LSP）：子类能替换其超类（is-a 关系），也就是说子类型（subtype）必须能替换其基类型（base type）。
4、接口分离原则（ISP）：使用多个专门的接口比使用单一的总接口更好；换言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小的接口之上的；不应该强迫客户程序依赖于它们不用的接口
5、依赖倒置原则（DIP）：要依赖于抽象，不要依赖于具体：也就是说，抽象不应当依赖
于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程。
三、设计模式：
⑴、软件设计模式的定义：
1、模式：是做事的一种方法，也即是实现某个目标的途径，或者技术。
2、设计模式：描述了软件设计过程中某一类常见问题的一般性的解决方案
3、设计模式：是类的联合体以及与之相伴的算法，这些算法能够实现共同的设计目标。
设计模式表达了一种思想而不仅仅是固定的类联合体，相伴的算法表示模式的基本操作。
⑵、面向对象设计模式的定义：
1、面向对象设计模式：描述了面向对象设计过程中，特定场景下，类与相互通信的对象之间常见的组织关系。
2、面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达
⑶、设计模式的分类：
①、依据设计模式的行为方式，也即其目的，将设计模式分为三种类型：创建型
模式、结构型模式、行为型模式：
a、创建型模式：以灵活的方式创建对象的集合，如：工厂模式、抽象工厂模式、建造者模式、单件模式、原型模式等。
B、结构型模式：代表相关对象的集合，如：适配器模式、装饰模式、桥接模式、享元模式、外观模式、代理模式、组合模式。
C、行为型模式：在对象集合中捕获行为，如：模板方法模式、观察者模式、迭代子模式、
责任链模式、备忘录模式、命令模式、状态模式、访问者模式、中介者模式、策略模式。
②、根据设计意图可分为五类：接口型设计模式、责任型设计模式、构造型设计
模式、操作型设计模式、扩展型设计模式。
⑷、设计模式的主要职责（意图）：
1、简单工厂设计模式：一个工厂类处于对产品类实例化的中心位置上，它知道每一个产品，它决定哪一个产品类应当被实例化。
这个模式的优点是允许客户端相对独立于产品创建
的过程，并且在系统引入新产品的时候无需修改客户端，也就是说，它在某种程度上支
持“开-闭”原则。
2、工厂方法设计模式：是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。
在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象
经常面临着剧烈的变化，但是它却拥有比较稳定的接口。
3抽象工厂设计模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们
具体的泪。
抽象工厂模式主要是用于创建一个产品族，而不是一个一个具体的产品。
4建造者模式：将产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程
生成具有不同的内部表象的产品对象。
也就是说，它将一个复杂的构建与其表示相分离，
使得同样的构建过程可以创建不同的表示。
5单件模式：一个类仅有一个实例，并提供一个访问它的全局访问点。
也就是说，单件模
式的要点是：某个类只能有一个实例；它必须自行创建这个实例；它必须自行向整个系
统提供这个实例。
6原型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型
对象的办法创建出更多类型的对象。
7适配器设计模式：将接口不同而功能相同或相近的两个接口加以转换。
8装饰模式：装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任。
换言之，
客户端并不会觉得对象在装饰前和装饰后有什么不同。
装饰模式可以在不使用创造更多
子类的情况下，将对象的功能加以扩展。
9桥接模式：将抽象化与实现化脱耦，使得二者可以独立地变化。
实现系统可能有多角度
分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少
它们之间的耦合。
10组合模式：当需求中是体现部分与整体层次的结构时，以及你希望用户可以忽略组合对
象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑到组合模式了。
11模板方法模式：当我们要完成某一细节层次一致的一个过程或一系列步骤，但其个别步
骤在更详细的层次上的实现可能不同时，我们通常考虑用模板方法模式来处理。
12观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对
象。
这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新
自己。
13迭代子模式：通过设计一个迭代器，这个迭代器提供一种方法，可以顺序访问聚合对象
中的各个元素，但又不暴露该对象的内部表示。
14责任链模式：为解除请求者和接受者之间的耦合，而使多个对象都有机会处理这个请求。
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
15备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保
存这个状态。
这样以后就可以将该对象恢复到原先保存的状态。
16命令模式：目的是解除命令发出者和接收者之间的耦合关系，是二者相对独立，有利于
程序的并行开发和代码的维护。
命令模式的核心思想是将请求封装一个对象，将其作为
命令发起者和接受者的中介，而抽象出来的命令对象又使我们能够对一些列请求进行某
些操作。
17状态模式：核心思想是允许一个对象在它的内部状态改变时改变它的行为，即不同的状
态对应不同的行为，这需要将状态单独抽象为一个对象。
⑸、设计模式结构图：
这里不详细叙述，参见帮助手册----Java设计模式-类图大全(.chm)精解、UML类图解析。