设计模式

简单工厂模式(Simple Factory)

添加一个工厂类, 在工厂类中添加一个创建实例的方法, 根据参数的不同, 初始化不同的实例.

代码示例

策略模式(Strategy)

简单工厂的不足

面向对象的编程,并不是类越多越好, 类的划分是为了封装, 但分类的基础是抽象, 具有相同属性和功能的对象的抽象集合才是类. 所以有些Action看起来只是行为的不同, 但是抽象分析后的算法是一样的, 所以应该抽象为一个类.

使用简单工厂模式设计的抽象基类, 其他实际操作类继承这个基类. 然后用工厂来初始化操作类的实例.

但是这种方式只能解决操作类的实例创建问题, 而且由于工厂本身包括了所有的实例创建方式. 所以每次维护和扩展都要改动这个工厂, 易导致代码需要重新部署, 面对算法的时常变动, 应该有个更合理的模式.

引入策略模式

定义了算法家族, 分别封装起来, 让他们之间可以互相替换, 此模式让算法的变化不影响使用算法的客户.

策略模式的优点

策略模式的引入使得client只需要了解context即可, 由context负责和client沟通后,对Strategy类对应的初始化操作.然后由context调用执行相应的操作类的方法, 将结果返回给client即可. 这种方式在解耦上也有很大的意义.

另外策略模式的一个好处是方便实际操作类的单元测试. 因为每个算法都有自己的类, 所以可以通过自己的接口进行单元测试.

策略模式封装了变化. 将不同的算法放入不同的实际操作类中, 分别执行抽象出来的公用方法是其最大的优势.

示例

GitLink

装饰模式(Decorator)

动态的给一个对象添加一些额外的职责, 就增加功能来说, 装饰模式比生成子类更加的灵活.

设计模式的原则

单一职责原则

对于一个类而言, 应该有且只有一个让它变化的原因.

如果一个类所承担的职责过多, 就相当于把这些职责耦合到了一起, 一个职责的变化可能会削弱或抑制完成其他职责的能力. 所以重构代码的时候要根据职责来分离类.

开放 - 封闭原则

对于软件而言, 应该可以扩展而不可以修改. 在做系统的时候也是一样, 不能指望需求一开始就会确定, 那么既然需求是变化的, 那么在面对需求的变化时, 怎么样设计的稳定的软件? 这里用到的思维是:

多扩展, 少修改. 就是在设计类的时候, 尽量让这个类做到足够好, 等新需求来, 再增加一个类就行了.

控制反转原则

又称IOC,依赖反转, 都可以.实际本质是低耦合,高内聚.

• 高层模块不应该依赖于低层模块. 两个都应该依赖于抽象.
• 抽象不应该依赖细节, 细节应该依赖抽象.

【设计模式】设计模式笔记

原文：https://www.cnblogs.com/it-dennis/p/10621216.html