假如你现在还在为自己的技术担忧，假如你现在想提升自己的工资，假如你想在职场上获得更多的话语权，假如你想顺利的度过35岁这个魔咒，假如你想体验BAT的工作环境，那么现在请我们一起开启提升技术之旅吧，详情请点击
本微博是以Head First设计模式（中文版）为蓝本写的。
设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。
什么是 GOF（四人帮，全拼 Gang of Four）？
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。
四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。
- 对接口编程而不是对实现编程。
- 优先使用对象组合而不是继承。
设计模式的使用
设计模式在软件开发中的两个主要用途。
开发人员的共同平台
设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。
最佳的实践
设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。
设计模式的类型
根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。当然，我们还会讨论另一类设计模式：J2EE 设计模式。
| 序号 | 模式 & 描述 | 包括 |
|---|---|---|
| 1 | 创建型模式这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。 |
|
| 2 | 结构型模式这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。 |
|
| 3 | 行为型模式这些设计模式特别关注对象之间的通信。 |
|
| 4 | J2EE 模式这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。 |
|
下面用一个图片来整体描述一下设计模式之间的关系：
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
一，痛点1
所有的鸭子都会呱呱的叫，所有的鸭子都会游泳，每个鸭子都有不同的外观。
1.1，代码实现鸭子父类
| package com.DesignPatterns.aa.introduction1; public class Duck { public void quack() { System.out.println("所有的鸭子都会呱呱叫quack()"); }
public void swim() { System.out.println("所有的鸭子都会游泳swim()"); }
public void display() { System.out.println("每个鸭子子类型（subtype）负责实现自己的 display() 行为在屏幕上显示其外观。"); } } |
MallardDuck类
|
/** *
|
RedheadDuck类
| package com.DesignPatterns.aa.introduction1;
/** *
|
测试
| */ public class Test { public static void main(String[] args) { // 野鸡鸭 MallardDuck mallardDuck = new MallardDuck(); // 红头鸭 RedheadDuck redheadDuck = new RedheadDuck(); mallardDuck.quack(); mallardDuck.swim(); mallardDuck.display(); System.out.println(""); redheadDuck.quack(); redheadDuck.swim(); redheadDuck.display(); } } 结果： 所有的鸭子都会呱呱叫quack() 所有的鸭子都会游泳swim() 我是野鸡鸭，我的颜色是绿色的。 所有的鸭子都会呱呱叫quack() 所有的鸭子都会游泳swim() 我是红头鸭，我的颜色是红色的。 |
这是最基本的一个继承的概念，主要为了引出后面的设计模式的原则的。
二，痛点2
我们现在新增了一个唐老鸭，要求它只会呱呱的叫，并且不会飞，注意这里只有它不会飞，其它的都会飞的。
解决问题的思路就是就是把新增的唐老鸭飞的方法设置成一个空的方法，看代码
Duck
| package com.DesignPatterns.aa.introduction3; public class Duck { public void quack() { System.out.println("所有的鸭子都会呱呱叫quack()"); }
public void swim() { System.out.println("所有的鸭子都会游泳swim()"); }
public void display() { System.out.println("每个鸭子子类型（subtype）负责实现自己的 display() 行为在屏幕上显示其外观。"); }
public void fly() { System.out.println("所有的鸭子都会飞fly()"); } } |
MallardDuck
|
/** *
|
RedheadDuck.java
| package com.DesignPatterns.aa.introduction3;
/** *
|
RubberDuck.java
| package com.DesignPatterns.aa.introduction3;
/** *
|
| */ public class RubberDuck extends Duck { public void display() { System.out.println("我是唐老鸭，我的颜色是黄色的。"); }
public void fly() { System.out.println("我是唐老鸭，我是一个空方法。"); } } |
Test.java
| package com.DesignPatterns.aa.introduction3;
/** *
*/ public class Test { public static void main(String[] args) { // 野鸡鸭 MallardDuck mallardDuck = new MallardDuck(); // 红头鸭 RedheadDuck redheadDuck = new RedheadDuck(); // 唐老鸭 RubberDuck rubberDuck = new RubberDuck(); mallardDuck.quack(); mallardDuck.swim(); mallardDuck.display(); mallardDuck.fly(); System.out.println(""); redheadDuck.quack(); redheadDuck.swim(); redheadDuck.fly(); |
| System.out.println(""); rubberDuck.quack(); rubberDuck.swim(); rubberDuck.fly(); rubberDuck.display(); } } 结果： 所有的鸭子都会呱呱叫quack() 所有的鸭子都会游泳swim() 我是野鸡鸭，我的颜色是绿色的。 所有的鸭子都会飞fly() 所有的鸭子都会呱呱叫quack() 所有的鸭子都会游泳swim() 所有的鸭子都会飞fly() 所有的鸭子都会呱呱叫quack() 所有的鸭子都会游泳swim() 我是唐老鸭，我是一个空方法。我是唐老鸭，我的颜色是黄色的。 |
这样就不会飞了，但是我们看到什么问题了吗？代码在多个子类中重复，就是这个重复的去覆盖一个fly 的方法，并且一旦运行的时候很难修改唐老鸭的行为。
三，痛点3
利用接口解决上面的问题怎么样呢。
我可以把fly()从超类中取出来，放进一个"Flyable接口"中。这么一来，只有会飞的鸭子才实现此接口。同样的方式，也可以用来设计一个"Quackable接口"，因为不是所有的鸭子都会叫。
我们还是先把代码贴上去看看再说。
Duck.java
| package com.DesignPatterns.aa.introduction5; public class Duck {
public void swim() { System.out.println("所有的鸭子都会游泳swim()"); }
public void display() { System.out.println("每个鸭子子类型（subtype）负责实现自己的 display() 行为在屏幕上显示其外观。"); }
} |
Flyable.java
| package com.DesignPatterns.aa.introduction5; public interface Flyable { public void fly(); } |
Quackable.java
| package com.DesignPatterns.aa.introduction5; public interface Quackable { public void quack() ; } |
DecoyDuck.java
1 package com.DesignPatterns.aa.introduction5; 2 3 public class DecoyDuck extends Duck implements Flyable,Quackable{ 4 public void display() { 5 System.out.println("我是诱饵鸭，我的颜色是白色的。"); 6 } 7 8 @Override 9 public void quack() {10 System.out.println("我是诱饵鸭，我会哇哇的叫。");11 }12 13 @Override14 public void fly() {15 System.out.println("我是诱饵鸭，我会飞");16 }17 18 } MallardDuck.java
1 public class MallardDuck extends Duck implements Flyable,Quackable { 2 3 4 public void display() { 5 System.out.println("我是野鸡鸭，我的颜色是绿色的。"); 6 } 7 8 @Override 9 public void quack() {10 System.out.println("我是野鸡鸭，我会呱呱的叫。");11 }12 13 @Override14 public void fly() {15 System.out.println("我是野鸡鸭，我会飞。");16 }17 }
RedheadDuck.java
| package com.DesignPatterns.aa.introduction5;
/** *
|
RubberDuck.java
| package com.DesignPatterns.aa.introduction5;
/** *
|
Test.java
| public class Test { public static void main(String[] args) { // 野鸡鸭 MallardDuck mallardDuck = new MallardDuck(); // 红头鸭 RedheadDuck redheadDuck = new RedheadDuck(); // 唐老鸭 RubberDuck rubberDuck = new RubberDuck(); // 诱饵鸭 DecoyDuck DecoyDuck = new DecoyDuck(); mallardDuck.quack(); mallardDuck.swim(); mallardDuck.display(); mallardDuck.fly(); System.out.println(""); redheadDuck.quack(); redheadDuck.swim(); redheadDuck.fly(); System.out.println(""); rubberDuck.quack(); rubberDuck.swim(); rubberDuck.fly(); rubberDuck.display(); System.out.println(""); DecoyDuck.quack(); DecoyDuck.swim(); DecoyDuck.fly(); DecoyDuck.display(); } } 结果：我是野鸡鸭，我会呱呱的叫。所有的鸭子都会游泳swim() 我是野鸡鸭，我的颜色是绿色的。我是野鸡鸭，我会飞。 |
我是红头鸭，我的会咕咕的叫。所有的鸭子都会游泳swim() 我是红头鸭，我会飞我是唐老鸭，我会戚戚的叫。所有的鸭子都会游泳swim() 我是唐老鸭，我不会飞我是唐老鸭，我的颜色是黄色的。我是诱饵鸭，我会哇哇的叫。所有的鸭子都会游泳swim() 我是诱饵鸭，我会飞我是诱饵鸭，我的颜色是白色的。
我们来看看上面的方式方法是否有问题呢。
这真是一个超笨的主意，你没发现这么一来重复的代码会变多吗？如果你认为覆盖几个方法就算是差劲，那么对于48个Duck的子类都要稍微修改一下飞行的行为，你又怎么说？!
就是我们要修改子类的fly方法，难道我们一个个去改吗。以为这个时候只要实现了接口飞的都是会飞的，而且现在飞的内容都是一模一样的，现在假如我们去修改的话就的一个子类一个子类的去修改。不符合设计模式的理念的。
四，痛点4（解决）
把问题归零……
现在我们知道使用继承并不能很好地解决问题，因为鸭子的行为在子类里不断地改变，并且让所有的子类都有这些行为是不恰当的。Flyable与Quackable接口一开始似乎还挺不错，解决了问题（只有会飞的鸭子才继承Flyable），但是Java接口不具有实现代码，所以继承接口无法达到代码的复用。这意味着：无论何时你需要修改某个行为，你必须得往下追踪并在每一个定义此行为的类中修改它，一不小心，可能会造成新的错误！幸运的是，有一个设计原则，恰好适用于此状况。
4.1，设计原则（这是我们的第一个设计原则）
设计原则1：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
把会变化的部分取出并"封装"起来，好让其他部分不会受到影响。结果如何？代码变化引起的不经意后果变少，系统变得更有弹性。
换句话说，如果每次新的需求一来，都会使某方面的代码发生变化，那么你就可以确定，这部分的代码需要被抽出来，和其他稳定的代码有所区分。
下面是这个原则的另一种思考方式："把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分"。
这样的概念很简单，几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让"系统中的某部分改变不会影响其他部分"。
好，该是把鸭子的行为从Duck类中取出的时候了！
4.2，分开变化和不会变化的部分
从哪里开始呢？就我们目前所知，除了fly()和quack()的问题之外，Duck类还算一切正常，似乎没有特别需要经常变化或修改的地方。所以，除了某些小改变之外，我们不打算对Duck类做太多处理。
现在，为了要分开"变化和不会变化的部分"，我们准备建立两组类（完全远离Duck 类），一个是"fly"相关的，一个是"quack"相关的，每一组类将实现各自的动作。比方说，我们可
能有一个类实现"呱呱叫"，另一个类实现"吱吱叫"，还有一个类实现"安静"。
我们知道Duck类内的fly()和quack()会随着鸭子的不同而改变。
为了要把这两个行为从Duck类中分开，我们将把它们从Duck类中取出来，建立一组新类来代表每个行为。
4.3，设计鸭子的行为
如何设计那组实现飞行和呱呱叫的行为的类呢？
我们希望一切能有弹性，毕竟，正是因为一开始鸭子行为没有弹性，才让我们走上现在这条路。我们还想能够"指定"行为到鸭子的实例。比方说，我们想要产生一个新的绿头鸭实例，并指定特定"类型"的飞行行为给它。干脆顺便让鸭子的行为可以动态地改变好了。换句话说，我们应该在鸭子类中包含设定行为的方法，这样就可以在"运行时"动态地"改变"绿头鸭的飞行行为。
有了这些目标要实现，接着看看第二个设计原则：
4.4，设计原则(这个是我们的第二个设计原则) 设计原则2：（针对接口编程，而不是针对实现编程。）从现在开始，鸭子的行为将被放在分开的类中，此类专门提供某行为接口的实现。
这样，鸭子类就不再需要知道行为的实现细节。
我们利用接口代表每个行为，比方说，FlyBehavior与Quack-Behavior，而行为的每个实现都将实现其中的一个接口。所以这次鸭子类不会负责实现Flying与Quacking接口，反而是由我们制造一组其他类专门实现FlyBehavior与QuackBehavior，这就称为"行为"类。
由行为类而不是Duck类来实现行为接口。这样的做法迥异于以往，以前的做法是：行为来自Duck超类的具体实现，或是继承某个接口并由子类自行实现而来。这两种做法都是依赖于"实现"，我们被实现绑得死死的，没办法更改行为（除非写更多代码）。
在我们的新设计中，鸭子的子类将使用接口（FlyBehavior与QuackBehavior）所表示的行为，所以实际的"实现"不会被绑死在鸭子的子类中。（换句话说，特定的具体行为编写在实现了
FlyBehavior与QuakcBehavior的类中）。
4.5，我不懂你为什么非要把FlyBehavior设计成接口。为何不使用抽象超类，这样不就可以使用多态了吗？
"针对接口编程"真正的意思是"针对超类型（supertype）编程"。
这里所谓的" 接口" 有多个含义， 接口是一个" 概念"，也是一种Java的interface构造。你可以在不涉及
JavaAinterface的情况下，"针对接口编程"，关键就在多态。利用多态，程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。"针对超类型编程"这句话，可以更明确地说成"变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型！"
这可能不是你第一次听到，但是请务必注意我们说的是同一件事。看看下面这个简单的多态例子：假设有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。做法如下："针对实现编程"
Dog d = new Dog();
d.bark();
但是，"针对接口/超类型编程"做法会如下：
Animal animal = new Dog(); animal.makeSound(); 更棒的是，子类实例化的动作不再需要在代码中硬编码，例如new Dog()，而是"在运行时才指定具体实现的对象"。
a = getAnimal( ); a.makeSound( );
这样的设计， 可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。
而我们可以新增一些行为， 不会影响到既有的行为类，也不会影响"使用"到飞行行为的鸭子类。
到现在为止，变化的行为和不变的行为已经完全分离开来了。
下面我们来看一下代码的实现。
这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。
而我们可以新增一些行为，不会影响到既有的行为类，也不会影响"使用"到飞行行为的鸭子类。
Duck.java（超类）
| public abstract class Duck { FlyBehavior flyBehavior; QuackBehavior quackBehavior;
public Duck() { } public abstract void display();
public void performFly() { flyBehavior.fly(); }
public void performQuack() { quackBehavior.quack(); }
public void swim() { System.out.println("All ducks float, even decoys!"); } } |
FlyBehavior.java（行为接口）
| package com.DesignPatterns.aa.introduction6; public interface FlyBehavior { public void fly(); } |
FlyNoWay.java（行为实现）
1 package com.DesignPatterns.aa.introduction6;2 3 public class FlyNoWay implements FlyBehavior {4 5 public void fly() {6 7 System.out.println("I can't fly");8 9 }
lyWithWings.java（行为实现）
1 package com.DesignPatterns.aa.introduction6; public class FlyWithWings implements FlyBehavior {2 3 public void fly() {4 5 System.out.println("I'm flying!!");6 7 }
uackBehavior.java（行为接口）
| package com.DesignPatterns.aa.introduction6; public interface QuackBehavior { public void quack(); } |
Quack.java（行为实现）
1 package com.DesignPatterns.aa.introduction6;2 3 public class Quack implements QuackBehavior {4 5 public void quack() {6 7 System.out.println("Quack");8 9 }
queak.java（行为实现）
1 package com.DesignPatterns.aa.introduction6;2 3 public class Squeak implements QuackBehavior {4 5 public void quack() {6 7 System.out.println("Squeak");8 9 }
uteQuack.java（行为实现）
1 package com.DesignPatterns.aa.introduction6; 2 3 4 5 public class MuteQuack implements QuackBehavior { 6 7 public void quack() { 8 9 System.out.println("<< Silence >>");10 11 }
allardDuck.java（鸭子类1）
| package com.DesignPatterns.aa.introduction6; public class MallardDuck extends Duck { public MallardDuck() { quackBehavior = new Quack(); flyBehavior = new FlyWithWings(); }
public void display() { System.out.println("I'm a real Mallard duck"); } } |
Test.java（测试）
1 package com.DesignPatterns.aa.introduction6; 2 /** 3 * 4 * @author qingruihappy 5 * @data 2018年9月19日 下午11:24:47 6 * @说明: 7 * 1，变化的与不变的分离开来 8 * 2，面向接口编程 9 * 3，变化的东西都去实现定义的接口10 * 4，剩下的就是如何让变化的代码和不变的代码联系起来。11 * 5，把定义好的接口（不变的）放到超类（不变的）中，也就是不变的代码，所以可以看到整个类中都是不变的。12 * 5.1，下面就是确认这个接口指向那个实例13 * 5.2，这里要确定两个地方1，确定我是谁，我是duck的那个实例，这个在调用的时候用多态就解决了，14 * 2，确定我是唐老鸭，我有什么样的行为，这个在确定了我是唐老鸭之后，会在唐老鸭的构造方法里确定我的行为，15 * 比如我会飞，我是呱呱的叫。补充：这里也可以用set方法来确定我的行为。这也就是为什么我们在spring的框架中提供set方法的原因了，提供set方法。16 * 6，在子类中（变化的），构造方法中有接口指向它的实现类（变化的）。17 * 7，当我们做测试的时候，多态超类（不变的）指向它的实现类（变化的），因为在实现类中的构造方法中已经指向了接口的实例（变化的）18 * 这个就是就确定了接口调用对象的实例了。19 * 20 * 我们来从正面捋一下思路21 * 1，首先我们秉承着变和不变分开和面向接口编程的原则，首先把变的东西抽出来而且让他们来继承统一的接口也就是我们本次实现的22 * FlyBehavior----FlyNoWay，FlyWithWings23 * QuackBehavior----Quack，Squeak，MuteQuack，24 * 2，这个时候接口是不变的，所以我们把接口FlyBehavior，QuackBehavior放到不变的Duck超类里面来。25 * 3，这个工作做好了，那么我们怎么让新实例的唐老鸭MallardDuck实例类在它们之间产生联系呢，这个是难点也是精髓。26 * 4，首先我们需要确定让超类Duck指向他的实例类唐老鸭MallardDuck，这样可以用多态Duck mallard = new MallardDuck()27 * 来实现，这样我们运行的时候就是唐老鸭的实例了。28 * 5，紧接着我们怎么来确定唐老鸭特殊的行为呢，也就是FlyBehavior，QuackBehavior，也要指向它的实现类，这个时候我们就可以在29 * 构造方法里面来实现了quackBehavior = new Quack();flyBehavior = new FlyWithWings()这个时候运行的时候执行30 * 的就是特殊的方法了。31 * 32 * 这个时候即使我们新增一个实例野鸡鸭，它有时候会飞有时候不会飞，这个时候我们就不需要来修改原来代码的逻辑，只需要新增33 * 一个有时候会飞有时候不会飞的动作的实例继承飞的接口，让后在新增一个野鸡鸭的实例就可以了。34 * 35 * 但是这里我们还有一个问题就是在构造器里面放置实例的操作是不符合面向借口编程的原理的。下面我们来看introduction736 */37 public class Test {38 public static void main(String[] args) {39 Duck mallard = new MallardDuck();40 mallard.performQuack();41 mallard.performFly();42 }43 }44 45 结果：46 Quack47 I’m flying!!
上面的我们一看到了
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
放到了构造方法里面去了。假设我们想在鸭子子类中通过"设定方法（setter method）"来设定鸭子的行为，而不是在鸭子的构造器内实例化。下面我们再来看一下代码的优化。
Duck.java
| package com.DesignPatterns.aa.introduction7; public abstract class Duck { FlyBehavior flyBehavior; QuackBehavior quackBehavior;
public Duck() { }
public abstract void display();
public void performFly() { flyBehavior.fly(); }
public void performQuack() { quackBehavior.quack(); }
public void setFlyBehavior(FlyBehavior fb) { flyBehavior = fb; }
public void setQuackBehavior(QuackBehavior qb) { quackBehavior = qb; }
|
1 public void swim() {2 3 System.out.println("All ducks float, even decoys!");4 5 }6 7 8 9 }
MallardDuck
| package com.DesignPatterns.aa.introduction7; public class MallardDuck extends Duck { public MallardDuck() { }
public void display() { System.out.println("I'm a real Mallard duck"); } } |
Test
1 package com.DesignPatterns.aa.introduction7; 2 /** 3 * 4 * @author qingruihappy 5 * @data 2018年9月19日 下午11:24:47 6 * @说明:经过这样的处理我们就可以在实例类中的构造方法也不需要实例化代码了，只需要在 7 * 超类中加一个set方法，这样就可以了。 8 * 我们还是按照思路走一遍 9 * 1，首先我们秉承着变和不变分开和面向接口编程的原则，首先把变的东西抽出来而且让他们来继承统一的接口也就是我们本次实现的10 * FlyBehavior----FlyNoWay，FlyWithWings11 * QuackBehavior----Quack，Squeak，MuteQuack，12 * 2，这个时候接口是不变的，所以我们把接口FlyBehavior，QuackBehavior放到不变的Duck超类里面来。13 * 3，这个工作做好了，那么我们怎么让新实例的唐老鸭MallardDuck实例类在它们之间产生联系呢，这个是难点也是精髓。14 * 4，首先我们需要确定让超类Duck指向他的实例类唐老鸭MallardDuck，这样可以用多态Duck mallard = new MallardDuck()15 * 来实现，这样我们运行的时候就是唐老鸭的实例了。Duck就是MallardDuck了。16 * 5，这一步和上面introduction6就不一样了，这种方法更加面向借口编程，就是在实例对象MallardDuck中也没有对行为进行操作17 * 但是我们必须要确定FlyBehavior QuackBehavior指向的是谁的实例了，现在就是在Duck中加一个set方法，当调用的时候就把set18 * 的实例放进去，这个时候就确定了，这更想我们平常用spring开发的时候注入的时候用的set的方法。19 */20 public class Test {21 public static void main(String[] args) {22 Duck mallard = new MallardDuck();23 mallard.setFlyBehavior(new FlyNoWay());24 mallard.setQuackBehavior(new Quack());25 mallard.performQuack();26 mallard.performFly();27 }28 }29 结果：30 Quack31 I can’t fly
文章的最后在附上以前自己对回调函数的理解：
回调函数既然是让系统调用的，所以你就必须按照系统给定的原型来实现程序
场景：A去调用B，其中A把一些参数穿给了B，B进行了自己的业务逻辑处理之后把返回的结果返给A，但是B怎么返给A呢，就需要B去调用A里的方法，但是B怎么知道A里面有什么方法呢，因为这一般都是两个程序员的事情，这个时候就需要定义规范了，定义一个接口，B通过这个接口去调用A里面的方法，而A也必须实现这个接口，这个实现的方法就叫做回调函数，从这里的逻辑我们不难发现，当我们当A去调用B的时候最好把自己的表示符号传过去，这个时候当B把处理完逻辑之后就可以通过标识符（对象实例）知道调用谁的（A）方法了。
假如你现在还在为自己的技术担忧，假如你现在想提升自己的工资，假如你想在职场上获得更多的话语权，假如你想顺利的度过35岁这个魔咒，假如你想体验BAT的工作环境，那么现在请我们一起开启提升技术之旅吧，详情请点击
更多代码见：https://github.com/qingruihappy/DesignPatterns