To the beyond and infinity!

应用设计模式的终极目标：管理变化，提高复用设计模式实现的两种手段：分解，抽象设计模式的八大原则：面向对象设计八大原则代码重构技巧/技术：静态->动态早绑定->晚绑定(见template method模式)继承->组合编译时依赖->运行时依赖运行时装配->编译时装配(Generic Programming)紧耦合->松耦合从封装变化角度对GOF的23种设计模式进行分类：设计模式之“组件协作“模式：Template Method、Strat

文章目录1. 重新认识面向对象2. 面向对象设计原则2.1 设计模式的六大原则(SOLID)2.2 单列面向对象设计原则1. 重新认识面向对象理解隔离变化• 从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小；各司其职• 从微观层面来看，面向对象的方式更强调各个类的“责任”；• 由于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责；对象是什么• 从语言实现层面来看，对象封装了代码和数据；• 从规格层面讲，对象是一系列可被使用的公共接口；•

文章目录1. Template Method1.1 动机1.2 模式定义1.3 要点总结  现代软件专业分工之后的第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。(早期和晚期是对应于开发过程而言的，对于一个基类而言，其派生类与基类就为晚期绑定关系，对于由应用实现库中所调用函数的设计方式，则库和流程函数(一般是main函数，即程序/流程入口)为早期绑定关系)。1. Template Method1.1 动机在软件构

文章目录1. Decorator 装饰模式1.1 Decorator 装饰模式动机1.2 模式定义1.3 示例代码1.4 要点总结2. Bridge 桥模式2.1 Bridge 桥模式动机2.2 模式定义2.3 示例代码2.4 要点总结在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。

文章目录★1. Factory Method 工厂模式1.1 Factory Method 工厂模式动机1.2 模式定义1.3 示例代码1.4 要点总结★2. Abstract Factory 抽象工厂模式2.1 Abstract Factory 抽象工厂模式动机2.2 模式定义2.3 示例代码2.4 要点总结3. Prototype 原型模式3.1 Prototype 原型模式动机3.2 模式定义3.3 示例代码3.4 要点总结4. Builder 构建器模式4.

文章目录1. Singleton 单例模式1.1 Singleton 单例模式动机1.2 模式定义1.3 示例代码1.4 要点总结2. Flyweight 享元模式2.1 Flyweight 享元模式动机2.2 模式定义2.3 示例代码2.4 要点总结  面向对象很好地解决了“抽象” 的问题，但是必不可免地要付出一定的代价。 对于通常情况来讲，面向对象的成本大都可以忽略不计。 但是某些情况，面向对象所带来的成本必须谨慎处理。1. Singleton 单例模式1.1 Singleton 单例模式动

文章目录1. Façade 门面模式1.1 Façade 门面模式动机1.2 模式定义1.3 要点总结2. Proxy 代理模式2.1 Proxy 代理模式动机2.2 模式定义2.3 实例代码2.4 要点总结3. Adapter 适配器模式3.1 Adapter 适配器模式动机3.2 模式定义3.3 实例代码3.4 要点总结4. Mediator 中介者模式4.1 Mediator 中介者模式动机4.2 模式定义4.3 要点总结  在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法

文章目录1. State 状态模式1.1 State 状态模式动机1.2 模式定义1.3 实例代码1.4 要点总结2. Memento 备忘录模式2.1 Memento 备忘录模式动机2.2 模式定义2.3 实例代码2.4 要点总结  在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？状态变化为解决该问题提供了一解决方案。1. State 状态模式1.1 State 状态模式动机在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生

文章目录1. Composite 组合模式1.1 Composite 组合模式动机1.2 模式定义1.3 实例代码1.4 要点总结2. Iterator 迭代器模式2.1 Iterator 迭代器模式动机2.2  常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定的数据结构封装在内部，向外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案。1. Composite 组合模式1.1 Composite

文章目录1. Command 命令模式1.1 Command 命令模式动机1.2 模式定义1.3 实例代码1.4 要点总结2. Visitor 访问器模式2.1 Visitor 访问器模式动机2.2 模式定义2.3 实例代码2.4 要点总结  在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。1. Command 命令模式该模式将命令代码转换为命令对象，从而给予命令以拓展性和多态性，同时保证

文章目录1. Interpreter 解释器模式1.1 Interpreter 解释器模式动机1.2 模式定义1.3 实例代码1.4 要点总结  在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。1. Interpreter 解释器模式1.1 Interpreter 解释器模式动机在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方法来实现将面临非常频繁的变化。在这