23种设计模式之策略模式

做编程的时候，如果讲每一个类加上各种各样的功能就意味着，无论任何需求要来，你都需要更改这个类，这样会让维护非常麻烦，复用不可能，也缺乏灵活性。如果一个类承担的职责过多，就等于把这些职责耦合起来，一个职责变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到很多意想不到的破坏。

5：接口隔离原则（Interface-Segregation-Principle）

使用多个专门的接口，而不使用单一的总接口。即客户端不应该依赖于那些它不需要的接口。

接口的设计粒度越小，系统越灵活，但是灵活的同时结构复杂性提高，开发难度也会变大，维护性降低。

6：迪米特法则（Law-Of-Demeter）

一个软件实体应当尽可能少地与其他实体发生作用。也叫最少知识原则，尽量降低类与类之间的耦合。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类之间建立直接的联系。如果有真的需要建立联系的，也希望能通过他的友元类来转达。因此，应用迪米特法则有可能造成一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互关系，这在一定程度上增加了系统的复杂度。

三：策略模式

如何理解策略？比如我们去远方旅游，需要选择交通方式，坐火车、坐飞机、自己开车等等，这些交通方式，每一种都是一个策略。

再比如淘宝搞活动，有打折、有满减、有返利的等等，这都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的，比如针对同一件商品，今天打五折、明天换返利，这些策略间是可以互换的。

不管选择哪种交通方式，最终的目的地都是一样的。不管选择哪种销售方式，最终都是为了卖商品。也就是选择不同的策略，最终的目的都是一样的。

策略模式是对算法的包装，是把使用算法的责任和算法本身分开来，委派给不同的对象管理。整体可以分为三部分：

1. Context上下文：用一个ConcreteStrategy来配置，维护一个对Strategy对象的引用。

2. Strategy抽象策略类：通常由一个接口或者抽象类实现。用于定义所有支持算法的公共接口。

3. ConcreteStrategy具体策略类：封装了具体的算法或行为，继承于Strategy。

Strategy抽象策略类

package com.nobody.strategy;

/**

• Strategy抽象策略类</