Java设计模式
 
1.工厂模式
 
2.生成器模式
 
3.观察者模式
 
4.桥接模式
 
5.代理模式
 
6.状态模式
 
7.访问者模式
 
8.命令模式
 
9.装饰器模式
 
10.组合模式
 
 
 
1.工厂模式
 
 
工厂模式一般分为简单工厂、工厂、抽象工厂3种情况，属于创建型设计模式。
 
简单工厂（静态工厂）
 
//定义小汽车接口：ICar.java
public interface ICar{
  //由于工厂模式仅关系对象的创建，为说明方便，无需定义方法
}

//下面定义高、中、低档具体的汽车
//高档小汽车：TopCar.java
public class TopCar implements ICar{
}
//中档小汽车：MidCar.java
public class MidCar implements ICar {
}
//低档小汽车：LowCar.java
public class LowCar implements ICar {
}

//简单工厂:CarSimpleFactory.java
public class CarSimpleFactory {
    public static final String TOPTYPE = "toptype";
    public static final String MIDTYPE = "midtype";
    public static final String LOWTYPE = "lowtype";
    public static ICar create(String mark){
    ICar obj = null;
    if(mark.equals(TOPTYPE)){　//如果是高档类型
      obj = new TopCar();　　//则创建高档车对象
    }
    else if(mark.equals(MIDTYPE)){
    obj = new MidCar();
  }
    else if(mark.equals(LOWTYPE)){
    obj = new LowCar();
  }
    return obj;　　　　//返回选择的对象
  }
}

//测试程序:CarTest.java
public class CarTest {
  public static void main(String[] args) {
  //从工厂中创建对象
    ICar obj = CarSimpleFactory.create("toptype");
  }
}
 
工厂
 
//定义小汽车接口：ICar.java
public interface ICar {
//由于工厂模式仅关系对象的创建，为说明方便，无需定义方法
}
//定义高、中、低档具体的小汽车
//高档小汽车：TopCar.java
public class TopCar implements ICar {
}
//中档小汽车：MidCar.java
public class MidCar implements ICar {
}
//低档小汽车：LowCar.java
public class LowCar implements ICar {
}
//定义抽象工厂：AbstractFactory.java
public abstract class AbstractFactory {
public abstract ICar create();
}
//定义高档小汽车工厂：TopFactory.java
public class TopFactory extends AbstractFactory {
public ICar create() {
    return new TopCar(); //高档工厂生成高档小汽车对象
  }
}
//定义中档小汽车工厂：MidFactory.java
public class MidFactory extends AbstractFactory {
public ICar create() {
    return new MidCar(); //中档工厂生成中档小汽车对象
  }
}
//定义低档小汽车工厂：LowFactory.java
public class LowFactory extends AbstractFactory {
public ICar create() {
    return new LowCar(); //低档工厂生成低档小汽车对象
  }
}
//测试类：CarTest.java
public class CarTest {
public static void main(String []args){
    AbstractFactory obj = new TopFactory();//多态创建高档工厂
    ICar car = obj.create();　　　　//获得高档工厂中的小汽车对象
  }
}
 
抽象工厂
 
//小汽车接口
public interface ICar { }
public class TopCar implements ICar { }
public class MidCar implements ICar { }
public class LowCar implements ICar { }

//定义公共汽车接口、高、中、低档公共汽车类
public interface IBus { }
public class UpBus implements IBus { }
public class MidBus implements IBus { }
public class DnBus implements IBus { }

//定义抽象工厂：AbstractFactory.java
public absttract class AbstractFactory {
public abstract ICar createCar(); //产生小汽车对象
public abstract IBus createBus(); //产生公共汽车对象
}

//定义高档工厂：TopFactory.java
public class TopFactory extends AbstractFactory {
  public ICar createCar() {
    return new TopCar();　　//高档工厂生成高档小汽车对象
  }
  public IBus createBus() {
    return new UpBus();　　//高档工厂生成高档公共汽车对象
  }
}

//定义中档工厂：MidFactory.java
public class MidFactory extends AbstractFactory {
  public ICar createCar() {
    return new MidCar();　　//中档工厂生成中档小汽车对象
  }
  public IBus createBus() {
    return new MidBus();　　//中档工厂生成中档公共汽车对象
  }
}
//定义低档工厂：LowFactory.java
public class LowFactory extends AbstractFactory {
  public ICar createCar() {
    return new LowCar();　　//低档工厂生成中档小汽车对象
  }
  public IBus createBus() {
    return new DnBus();　　//低档工厂生成中档公共汽车对象
  }
}
 
 
 
2.生成器模式
 
 
生成器模式也称为建造者模式。生成器模式的意图在于将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。在软件设计中，有时候面临着一个非常复杂的对象的创建工作。这个复杂的对象通常可以分成几个较小的部分，由各个子对象组合出这个复杂对象的过程相对来说比较稳定，但是子对象的创建过程各不相同并且可能面临变化。根据OOD中的OCP原则，应该对这些子对象的创建过程进行变化封装。
 
生成器思路是产品类与创建产品的类相分离。产品类仅1个，创建产品的类有n个。
 
生成器设计模式涉及4个关键角色：产品（Product）、抽象生成器（IBuild）、具体生成器（Builder）、指挥者（Director）。
 
 
（1）定义1个产品类。
public class Unit1{……}
public class Unit2{……}
public class Unit3{……}
public class Product {
Unit1 u1;
Unit2 u2;
Unit3 u3;
}
由于不在该类完成Product类对象的创建，所以无需显示定义构造方法。

（2）定义n个生成器Build类。
根据语义，生成器是用来生成Product对象的，因此一般来说，Product是生成器类的一个成员变量；
根据语义，每创建一个Product对象，本质上都需要先创建Unit1，Unit2，…， UnitN，再把它们组合成所需的Product对象，
因此需要n个createUnit（）方法及一个组合方法composite()；由于createUnit()及composite()是共性，
因此可定义共同的生成器类接口， n个生成器类均从此接口派生即可。代码如下。
//定义生成器类接口IBuild
public interface IBuild {
public void createUnit1();
public void createUnit2();
public void createUnit3();
public Product composite();　　　　//返回值是Product对象
}
//定义3个生成器类
public class BuildProduct implements IBuild {　//生成第一种Product
Product p = new Product();　　　　　//Product是成员变量
public void createUnit1() {
//p.u1= ...　　　　　　　//创建Unit1
}
public void createUnit2() {
//p.u2 = ...　　　　　　　//创建Unit2
}
public void createUnit3() {
//p.u3 =　　//创建Unit3
}
public Product composite() {
//...　　　//关联Unit,Unit2,Unit3
return p;　　//返回Product对象p
}
}
public class BuildProduct2 implements IBuild {　　//生成第2种Product
Product p = new Product();//Product是成员变量
public void createUnit() {/*p.u = ...... */} //创建Unit
public void createUnit2(){/*p.u2 = ...... */} //创建Unit2
public void createUnit3(){/*p.u3 = ...... */} //创建Unit3
public Product composite() {
//......　　　　//关联Unit1，Unit2，Unit3
return p;　　　//返回Product对象p
}
}
public class BuildProduct3 implements IBuild {　　//生成第3种Product
Product p = new Product();//Product是成员变量
public void createUnit1() {/*p.u1 = ...... */} //创建Unit1
public void createUnit2(){/*p.u2 = ...... */} //创建Unit2
public void createUnit3(){/*p.u3 = ...... */} //创建Unit3
public Product composite() {
//......　　//关联Unit1，Unit2，Unit3
return p;　　//返回Product对象p
}
}
通过上述代码可知，若需求分析发生变化，只需增加或删除相应的生成器类即可，无需修改已有的类代码。
（3）定义1个统一调度类，也叫指挥者（Director）类，是对生成器接口IBuild的封装。该类及简单的测试代码如下。
public class Director {
private IBuild build;
public Director(IBuild build){
this.build = build;
}
public Product build(){
build.createUnit1();
build.createUnit2();
build.createUnit3();
return build.composite();
}
public static void main(String []args){
IBuild build = new BuildProduct();
Director direct = new Director(build);
Product p = direct.build();
}
}
 
 
 
3.观察者模式
 
 
观察者设计模式适合解决多种对象跟踪一个对象数据变化的程序结构问题，有一个称作“主题”的对象和若干个称作“观察者”的对象。有一个主题数据——温度，3个观察者—温度日志、温度曲线、温度报警。因此观察者设计模式涉及两种角色：主题和观察者。
 观察者设计模式可以从以下递推中得出一些重要结论。
 ● 主题要知道有哪些观察者对其进行监测，因此主题类中一定有一个集合类成员变量，包含了观察者的对象集合。
 ● 既然包含了观察者的对象集合，那么，观察者一定是多态的，有共同的父类接口。
 ● 主题完成的主要功能是：可以添加观察者，可以撤销观察者，可以向观察者发消息，引起观察者响应。这三个功能是固定的，因此主题类可以从固定的接口派生。
 因此，编制观察者设计模式，要完成以下功能类的编制。
 ● 主题ISubject接口定义。
 ● 主题类编制。
 ● 观察者接口IObserver定义。
 ● 观察者类实现。
 
 
（1）观察者接口IObserver。

    public interface IObserver {
        public void refresh(String data);
    }
    
（2）主题接口ISubject。

    public interface ISubject {
        public void register(IObserver obs);       //注册观察者
        public void unregister(IObserver obs);     //撤销观察者
        public void notifyObservers();             //通知所有观察者
    }
    
（3）主题实现类Subject。

    public class Subject implements ISubject {
        private Vector<IObserver> vec = new Vector();  //观察者维护向量
        private String data;                           //主题中心数据

        public String getData() {
            return data;
        }
        public void setData(String data) {              //主题注册（添加）
            this.data = data;
        }
        public void register(IObserver obs) {           //主题注册（添加）观察者
         vec.add(obs);
        }

        public void unregister(IObserver obs) {         //主题撤销（删除）观察者
            if(vec.contains(obs))
                vec.remove(obs);
        }
        public void notifyObservers(){             //主题通知所有观察者进行数据响应
            for(int i=0; i<vec.size(); i++){
                IObserver obs = vec.get(i);
                obs.refresh(data);
            }
        }
    }
    
    主题实现类Subject是观察者设计模式中最重要的一个类，包含了观察者对象的维护向量vec以及主题中心数据data变量与具体观察者对象的关联
    方法（通过nitofyObservers()）。也就是说，从此类出发，可以更深刻地理解ISubject为什么定义了3个方法、IObserver接口为什么定义了1个方法。
    
（4）一个具体观察者类Observer。

    public class Observer implements IObserver {
        public void refresh(String data) {
            System.out.println("I have received the data:" +data);
        }
    }
    
（5）一个简单的测试类Test。

    public class Test {
        public static void main(String[] args) {
            IObserver obs = new Observer();    //定义观察者对象
            Subject subject = new Subject();
            //定义主题对象
            subject.register(obs);             //主题添加观察者
            subject.setData("hello");          //主题中心数据发生变动
            subject.notifyObservers();         //通知所有观察者进行数据响应
        }
    }
    
该段代码的含义是：当主题中心数据变化（通过setData方法）后，主题类subject要调用notifyObservers()方法，
通知所有观察者对象接收数据并进行数据响应。
 
 
 
4.桥接模式
 
 
桥接模式是关于怎样将抽象部分与它的实现部分分离，使它们都可以独立地变化的成熟模式。
 
 
（1）定义邮寄接口IPost。

    public interface IPost{   //邮局
        public void post();   //发送功能
    }
    
（2）两个具体邮寄类SimplePost、MarkPost。

    //平信邮寄类SimplePost
    class SimplePost implements IPost{     //平信
        public void post(){                //发送
            System.out.println("This is Simple post");
        }
    }
    //挂号邮寄类
    class MarkPost implements IPost{       //挂号
        public void post(){                //发送
            System.out.println("This is Mark post");
        }
    }
    
  经过（1）、（2）的论述，完成了语义的前半部分定义：邮局有发送功能；发送有两种方式，平邮和挂号。
  
（3）抽象事物类AbstractThing。

    abstract class AbstractThing{ //抽象事物

        private IPost obj;         //有抽象发送功能
        public AbstractThing(IPost obj){
            this.obj = obj;
        }
        public void post(){
            obj.post();
        }
    }
    
该类是桥接模式的核心。分析语义“信件和包裹共享平邮与挂号功能”：信件、包裹是两个不同的事物，它们有共享的功能，
也一定有相异的功能。共享的功能一定能封装到一个类中，又由于该类不能代表一个具体的事物，所以把它定义成abstract类是恰当的。
该类共享的是多态成员obj，是IPost类型的，是抽象的、泛指的，用一条语句表明了事物共享平邮和发送功能。

（4）具体事物类Letter、Parcel。

    //信件类Letter
    class Letter extends AbstractThing{
        public Letter(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    //包裹类Parcel
    class Parcel extends AbstractThing{
        public Parcel(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    
    //编制一个简单的测试类
    public class Test {
        public static void main(String[] args) {
            IPost p = new SimplePost();

            Letter letter = new Letter(p);
            letter.post();
        }
    }
    
第一种情况：若增加了新的事物，则只需从Abstract派生一个类即可，其他无需改变。

    class NewThing extends AbstractThing{
        public NewThing(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    
第二种情况：若增加了新的邮寄类别，比如特快专递，则只需从IPost接口派生一个类即可，其他无需改变。

    class EMSPost implements IPost{        //特快专递
    public void post(){                //发送
            System.out.println("This is EMS post");
        }
    }
 
 
 
5.代理模式
 
 
代理对象可以在客户端和目标对象之间起到中介的作用，并且可以通过代理对象去掉客户不能看到的内容和服务或者添加客户需要的额外服务。代理模式则是一种可以很好实现客户对象与代理对象分离的策略。
 
代理模式的定义如下：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文叫作Proxy或Surrogate，它是一种对象结构型模式。其抽象UML图如图所示
 
 代理模式包含如下角色
 ● ISubject：抽象主题角色，是一个接口。该接口是对象和它的代理共用的接口。
 ● RealSubject：真实主题角色，是实现抽象主题接口的类。
 ● Proxy：代理角色，内部含有对真实对象RealSubject的引用，从而可以操作真实对象。代理对象提供与真实对象相同的接口，以便在任何时刻都能代替真实对象。同时，代理对象可以在执行真实对象操作时，附加其他的操作，相当于对真实对象进行封装。以买电视为例，其代码如下。
 （1）定义抽象主题——买电视。
 
interface ITV{
        public void buyTV();
    }
 
（2）定义实际主题——买电视过程。
 
class Buyer implements ITV{
    public void buyTV(){
        System.out.println("I have bought the TV by buyer proxy");
    }
}
 
真正的付费是由购买者完成的。
 （3）定义代理。
 
class BuyerProxy implements ITV{
    private Buyer buyer;
    public BuyerProxy(Buyer buyer){
        this.buyer = buyer;
    }
    public void buyTV(){
        preProcess();
        buyer.buyTV();
        postProcess();
    }
    public void preProcess(){
        //询问客户需要电视类型、价位等信息
    }
    public void postProcess(){
        //负责把电视送到客户家
    }
}
 
电视代理商BuyerProxy与购买者Buyer都实现了相同的接口ITV，是对Buyer对象的进一步封装。着重理解buyTV()方法：首先代理商要通过preProcess()询问客户买电视的类型、价位等信息，然后购买者通过buyer.buyTV()自己付费完成电视购买，最后代理商通过postProcess()协商具体的送货服务、产品三包等。
 
代理模式最突出的特点是：代理角色与实际主题角色有相同的父类接口。常用的代理方式有4类：虚拟代理、远程代理、计数代理、动态代理
 
虚拟代理
 虚拟代理的关键思想是：如果需要创建一个资源消耗较大的对象，先创建一个消耗相对较小的对象来表示，真实对象只在需要时才会被真正创建。当用户请求一个“大”对象时，虚拟代理在该对象真正被创建出来之前扮演着替身的角色；当该对象被创建出来之后，虚拟代理就将用户的请求直接委托给该对象。
 
远程代理
 远程代理的含义是：为一个位于不同的地址空间的对象提供一个本地的代理对象，这个不同的地址空间可以在同一台主机中，也可在另一台主机中。也就是说，远程对象驻留于服务器上，客户机请求调用远程对象调用相应方法，执行完毕后，结果由服务器返回给客户端。
 
 计数代理
 当客户程序需要在调用服务提供者对象的方法之前或之后执行日志或计数的额外功能时，就可以使用计数代理模式。计数代理模式并不是把这些额外操作的代码直接添加到源服务中，而是把它们封装成一个单独的对象，这就是计数代理。
 
动态代理
 对代理模式而言，一个主题类与一个代理类一一对应，这也是静态代理模式的特点。
 
 但是，也常存在这样的情况，有n个主题类，但是代理类中的“前处理、后处理”都是一样的，仅调用主题不同，需要编制如图所示的程序框架。
 
 也就是说，多个主题类对应一个代理类，共享“前处理、后处理”功能，动态调用所需主题，大大减小了程序规模，这就是动态代理模式的特点。实现动态代理的关键技术是反射。
 
 
 
6.状态模式
 
 
状态模式为研究各种状态以及状态间相互转化的实现方式提出了一种较好的设计思路。
 
● 状态类有共同的父接口（或抽象类）, n个不同的状态实现类。
 ● 事物类中包含状态类父接口成员变量声明，用以反映语义“事物有n个状态”。
 ● 事物类中一定有方法选择分支，判断事物当前处于何种状态。
 
状态模式必须完成如下内容的编制：
 ● State：状态接口，封装特定状态所对应的行为。
 ● ConcreteState：具体实现状态处理的类。
 ● Context：事物类，也称上下文类，通常用来定义多态状态接口，同时维护一个用来具体处理当前状态的示例对象。
 
状态模式的UML抽象类图如图所示
 
 状态模式的具体抽象代码如下。
 （1）定义状态抽象接口IState。
 
interface IState{
    public void goState();
}
 
（2）定义状态实现类。
 
class ConcreteStateA implements IState{//定义状态A类
    public void goState(){
        System.out.println("This is ConcreteStateA");
    }
}
class ConcreteStateB implements IState{//定义状态B类
    public void goState(){
        System.out.println("This is ConcreteStateB");
    }
}
 
（3）定义状态上下文维护类Context。
 
class Context{            //上下文有n种状态
    private IState state;
    public void setState(IState state){
        this.state = state;
    }
    public void manage(){
        //此处代码根据条件选择某种状态
        state.goState(); //执行某种状态功能
    }
}
 
Context类是实现状态模式的关键，本部分仅列出了状态模式的基本代码
 
 
 
7.访问者模式
 
 
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式，且可以在不修改原有系统的情况下增加新的操作方式，这就是访问者模式的模式动机。
 
访问者模式抽象类图
 
 访问者模式主要涉及以下四种角色：
 ● IElement：抽象的事物元素功能接口，定义了固定功能方法及可变功能方法接口。
 ● Element：具体功能的实现类。
 ● IVisitor：访问者接口，为所有访问者对象声明一个visit方法，用来代表为对象结构添加的功能，原则上可以代表任意的功能。
 ● Visitor：具体访问者实现类，实现要真正被添加到对象结构中的功能。
 
考虑这样一个应用：已知三点坐标，编写功能类，求该三角形的面积和周长。
 
如果采用访问者模式，应当这样思考：目前已确定的需求分析是求面积和周长功能，但有可能将来求三角形的重心、垂心坐标，内切、外界圆的半径等，因此，在设计时必须考虑如何屏蔽这些不确定情况。具体代码如下。
 
1．定义抽象需求分析接口IShape
 
interface IShape{
    float getArea();             //明确的需求分析
    float getLength();           //明确的需求分析
    Object accept(IVisitor v);   //可扩展的需求分析
}
 
着重理解可扩展的需求分析方法accept()，它在形式上仅是一个方法，但是按访问者模式而言，它却可以表示将来可以求重心、垂心坐标等功能，是一对多的关系，因此IVisitor一般来说是接口或抽象类，“多”项功能一定是由IVisitor的子类来实现的。那么为什么返回值是Object类型呢？可以这样理解，例如重心坐标由两个浮点数表示，外接圆半径由一个浮点数表示，为了屏蔽返回值差异，返回值定义成Object，表明可以返回任意对象类型。
 
2．定义具体功能实现类Triangle
 
class Triangle implements IShape{
    float x1, y1, x2, y2, x3, y3;           //三角形三点坐标
    public Triangle(float x1, float y1, float x2, float y2, float x3, float y3){

        this.x1=x1; this.y1=y1;
        this.x2=x2; this.y2=y2;
        this.x3=x3; this.y3=y3;
    }
    public float getDist(float u1, float v1, float u2, float v2){   //求任意两点距离
        return (float)Math.sqrt((u1-u2)*(u1-u2)+(v1-v2)*(v1-v2));
    }
    public float getArea(){            //固定需求分析求面积
        float a = getDist(x1, y1, x2, y2);
        float b = getDist(x1, y1, x3, y3);
        float c = getDist(x2, y2, x3, y3);
        float s = (a+b+c)/2;
        return (float)Math.sqrt(s*(s-a)*(s-b)*(s-c)); //海伦公式求面积
    }
    public float getLength(){          //固定需求分析求周长
        float a = getDist(x1, y1, x2, y2);
        float b = getDist(x1, y1, x3, y3);
        float c = getDist(x2, y2, x3, y3);
        return a+b+c;
    }
    public Object accept(IVisitor v){  //可扩展需求分析
        return v.visit(this);
    }
}
 
着重理解accept()方法，可以看出IVisitor接口中一定定义了多态方法visit()，那为什么把this引用传过去呢？可以这样理解：例如求三角形重心坐标，它的功能一定是在IVisitor的子类实现的，那么该子类一定得知道三角形的三个顶点坐标，因此把this引用传过去，相当于IVisitor的子类可访问Triangle类的成员变量，编制求重心坐标就容易了。
 
3．定义访问者接口IVisitor
 
interface IVisitor{
    Object visit(Triangle t);
}
 
至此为止，有了1、2、3的代码，访问者模式的代码框架就已经构建起来了。如果需求分析没有变化，那么程序一直应用即可；如果需求分析发生变化，则基础功能类不用变化，只要定义IVisitor接口的具体功能实现类就可以了，例如求三角形重心坐标代码如下。
 4．定义重心坐标实现类CenterVisitor
 
class Point{
    float x, y;
}
class CenterVisitor implements IVisitor{
    public Object visit(Triangle t){
        Point pt = new Point();
        pt.x = (t.x1+t.x2+t.x3)/3;
        pt.y = (t.y1+t.y2+t.y3)/3;
        return pt;
    }
}
 
一个简单的测试类如下。
 
public class Test3 {
    public static void main(String[] args) {
        IVisitor v = new CenterVisitor();        //定义求重心具体访问者对象
        Triangle t = new Triangle(0,0,2,0,0,2);  //定义三角形对象
        Point pt = (Point)t.accept(v);           //通过访问者对象求三角形重心坐标
        System.out.println(pt.x+"\t"+pt.y);
    }
}
 
可以知道，如果再想增加一个求三角形外接圆半径功能，只需再定义一个新类实现IVisitor接口，在该类中完成求外接圆半径功能即可。
 
 
 
8.命令模式
 
 
顾名思义，命令模式一定是有命令发送者、命令接收者。命令发送者负责发送命令，命令接收者负责接收命令并完成具体的工作。
 
命令模式主要针对需要执行的任务或用户提出的请求进行封装与抽象。抽象的命令接口描述了任务或请求的共同特征，而实现则交由不同的具体命令对象完成。每个命令对象都是独立的，它负责完成需要执行的任务，却并不关心是谁调用它。
 
命令模式抽象UML类图
 
 命令模式一般有4种角色，如下所示。
 ● ICommander：抽象命令者，是一个接口，规定了用来封装请求的若干个方法。
 ● ConcreteCommander：具体命令发送者，即命令源。它是实现命令接口的类的示例，如上文中的Teacher类。
 ● Invoker：请求者，具体命令的管理与维护类。请求者是一个包含“命令接口”变量的类的示例。请求者中的“命令”接口的变量可以存放任何具体命令的引用，请求者负责调用具体命令，让具体命令执行那些封装了请求的方法。
 ● Receiver：命令接收者，是一个类的示例。该示例负责执行与请求相关的操作，如上文中的Student类。
 
考虑老师通知学生打扫卫生的程序描述，具体代码如下。
 1．抽象命令接口ICommand
 
interface ICommand{
    public void sweep();
}
 
2．命令接收者Student
 
class Student{
    public void sweeping(){
        System.out.println("we are sweeping the floor");
    }
}
 
在命令模式中，具体工作一定是在接收者中完成的，这一点非常重要。示例中“清扫”工作是由sweeping()方法完成的。
 3．命令发送者Teacher
 
class Teacher implements ICommand{
    private Student receiver = null;
    public Teacher(Student receiver){
        this.receiver = receiver;
    }
    public void sweep(){  //发送sweep清扫命令
        receiver.sweeping();
    }
}
 
命令发送者类中，一般来说包含命令接收者的引用，表明发送命令的目的地址。所以Teacher类中定义了接收者Student类对象的引用。而实现的抽象接口方法中表明发送命令的具体过程，sweep()中利用方法转发说明具体的清扫工作是由接收者Student对象完成的。
 4．命令请求者类Invoke
 
class Invoke{
    ICommand command;
    public Invoke(ICommand command){
        this.command = command;
    }
    public void execute(){
        command.sweep();  //启动命令
    }
}    
 

 
 普通思路是命令发送者直接作用命令接收者，而命令模式思路是在两者之间增加一个请求者类，命令发送者与请求者作用，请求者再与命令接收者作用，请求者起到了一个桥梁的作用
 
5．一个简单的测试类
 
public class Test {
    public static void main(String[] args)
    {
        Student s = new Student();         //定义接收者
        Teacher t = new Teacher(s);        //定义命令发送者
        Invoke invoke = new Invoke(t);     //将命令请求加到请求者对象中
        invoke.execute();                  //由请求者发送命令
    }
}
 
 
 
9.装饰器模式
 
 
装饰器模式利用包含代替继承，动态地给一个对象添加一些额外的功能。以消息日志功能为例，其装饰器模式UML类图如图所示
 
 装饰器模式主要有如下4种角色。
 ● 抽象构件角色（Component）：
 它是一个接口，封装了将要实现的方法，如ILogger。
 ● 具体构件角色（ConcreteComponent）：
 它是多个类，该类实现了Component接口，如FileLogger、ConsoleLogger。
 ● 装饰角色（Decorator）：
 它是一个抽象类，该类也实现了Component接口，同时也必须持有接口Component的对象的引用，如事例中Decorator。
 ● 具体的装饰角色（Decorator类的子类，可以有一个，也可以有多个）：
 这些类继承了类Decorator，实现了Component接口，描述了具体的装饰过程，如UpLogger、XMLLogger。
 
1．抽象装饰器基类Decorator
 
abstract class Decorator implements ILogger{
    protected ILogger logger;
    public Decorator(ILogger logger){
        this.logger = logger;
    }
}
 
2．具体装饰类
 
//信息大写装饰类UpLogger
class UpLogger extends Decorator{
    public UpLogger(ILogger logger){
        super(logger);
    }
    public void log(String msg) {
        msg = msg.toUpperCase();     //对字符串进行大写装饰
        logger.log(msg);             //再执行已有的日志功能
    }
}
 
    //XML格式化装饰类XMLLogger
    class XMLLogger extends Decorator{
          public XMLLogger(ILogger logger){
              super(logger);
          }
          public void log(String msg) {
              String s = "<msg>\r\n" +
                       "<content>"+msg+"</content>\r\n"+
                        "<time>" + new Date().toString()+ "</time>\r\n"+
                        "</msg>\r\n";
              logger.log(s);
         }
     }
 
3．一个简单的测试类
 
public class Test {
    public static void main(String[] args)throws Exception {
        ILogger existobj = new FileLogger();     //已有的日志功能
        ILogger newobj= new XMLLogger(existobj); //新的日志装饰类，对existobj装饰
        String s[] = {"how", "are", "you"};        //仿真传送的字符串信息数组
        for(int i=0; i<s.length; i++){
            newobj.log(s[i]);
            Thread.sleep(1000);                  //每隔1 s传送一个新的字符串
        }
        System.out.println("End");
    }
}
 
 
 
10.组合模式
 
 
文件树型结构示例图
 
 根目录是由两个子目录组成的，第一级子目录由两个文件组成，第二级子目录由两个文件组成，因此树型形式也可以称作组合形式。把叶子节点与目录节点都看成相同性质的节点，只不过目录节点后继节点不为空，而叶子节点后继节点为null。这样就能够对树型结构的所有节点执行相同的操作，这也是组合模式的最大特点。采用组合模式实现文件树型结构的功能，具体代码如下。
 
1．定义抽象节点类Node
 
abstract class Node{
    protected String name;
    public Node(String name){
        this.name = name;
    }
    public void addNode(Node node)throws Exception{
        throw new Exception("Invalid exception");
    }
    abstract void display();
}
 
该类是叶子节点与目录节点的父类，节点名称是name。其主要包括两类方法：一类方法是所有节点具有相同形式、不同内容的方法，这类方法要定义成抽象方法，如display()；另一类方法是目录节点必须重写，叶子节点无需重写的方法，相当于为叶子节点提供了默认实现，如addNode()方法，因为叶子对象没有该功能，所以可以通过抛出异常防止叶子节点无效调用该方法。
 
2．文件叶子节点类FileNode
 
class FileNode extends Node{
    public FileNode(String name){
        super(name);
    }
    public void display(){
        System.out.println(name);
    }
}
 
该类是Node的派生类，仅重写display()方法即可。
 
3．目录节点类DirectNode
 
class DirectNode extends Node{
    ArrayList<Node> nodeList = new ArrayList();
    public DirectNode(String name){
        super(name);
    }
    public void addNode(Node node)throws Exception{
        nodeList.add(node);
    }
    public void display(){

        System.out.println(name);
        for(int i=0; i<nodeList.size(); i++){
            nodeList.get(i).display();
        }
    }
}
 
该类从Node抽象类派生后，与原DirectNode类相比，主要有以下不同：①由定义两个集合类成员变量转为定义一个集合类成员变量nodeList; ②由定义两个添加方法转为定义一个添加方法addNode(); ③display()方法中，由两个不同元素的循环转为一个对相同性质节点Node的循环。也就是说，原DirectNode中不论是定义成员变量、成员方法，还是方法内部的功能，都要实时考虑叶子节点、目录节点的不同性，因此它的各种定义一定是双份的。而组合模式中认为叶子节点、目录节点是同一性质的节点，因此与原DirectNode类对比，它的各种定义工作一定是减半的，也易于扩充。
 
4．一个简单的测试类
 
public class Test {
    public static void createTree(Node node)throws Exception{
        File f = new File(node.name);
        File f2[] = f.listFiles();
        for(int i=0; i<f2.length; i++){
            if(f2[i].isFile()){
                Node node2 = new FileNode(f2[i].getAbsolutePath());
                node.addNode(node2);
            }
            if(f2[i].isDirectory()){
                Node node2 = new DirectNode(f2[i].getAbsolutePath());
                node.addNode(node2);
                createTree(node2);
            }
        }
    }
    public static void main(String[] args)throws Exception {
        Node start = new DirectNode("d://data");
        createTree(start);
        start.display();
    }
}
 
通过该示例，可得组合模式更一般的UML类图，如图所示。共包括以下三种角色。
 
 ● 抽象节点：Node，是一个抽象类（或接口），定义了个体对象和组合对象需要实现的关于操作其子节点的方法，如add()、remove()、display()等。
 ● 叶节点：Leaf，从抽象节点Node派生，由于本身无后继节点，其add()等方法利用Node抽象类中相应的默认实现即可，只需实现与自身相关的remove()、display()等方法即可。
 ● 组合节点：Component，从抽象节点Node派生，包含其他Composite节点或Leaf节点的引用。
 总之，若某应用可形成树型结构，而且形成树型结构后可对叶节点及中间节点进行统一的操作，那么采用组合模式构建应用功能是一个比较好的选择。
 
资料来自《Java设计模式深入研究》

 
 

 

 

 

 

 

 
今天分享一部设计模式相关的视频，好好复习帮助还是很大的。
 

 
课程介绍
 
1) 优秀的程序应该是这样的：阅读时，感觉很优雅；新增功能时，感觉很轻松；运行时，感觉很快速,这就需要设计模式支撑
 
2) 设计模式包含了大量的编程思想，讲授和真正掌握并不容易，网上的设计模式课程不少，大多讲解的比较晦涩，没有真实的应用场景和框架源码支撑，学习后，只知其形，不知其神。就会造成这样结果: 知道各种设计模式，但是不知道怎么使用到真实项目。本课程针对上述问题，有针对性的进行了升级 (1) 授课方式采用 图解+框架源码分析的方式，让课程生动有趣好理解 (2) 系统全面的讲解了设计模式,包括 设计模式七大原则、UML类图-类的六大关系、23种设计模式及其分类,比如 单例模式的8种实现方式、工厂模式的3种实现方式、适配器模式的3种实现、代理模式的3种方式、深拷贝等
 
3) 如果你想写出规范、漂亮的程序,就花时间来学习下设计模式吧
 

 
课程内容和目标
 
本课程是使用Java来讲解设计模式，考虑到设计模式比较抽象，授课采用 图解+框架源码分析的方式
 
1) 内容包括：设计模式七大原则(单一职责、接口隔离、依赖倒转、里氏替换、开闭原则、迪米特法则、合成复用)、UML类图(类的依赖、泛化和实现、类的关联、聚合和组合) 23种设计模式包括：创建型模式：单例模式(8种实现)、抽象工厂模式、原型模式、建造者模式、工厂模式。结构型模式：适配器模式(3种实现)、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式(3种实现)。行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)。
 
2) 学习目标：通过学习，学员能掌握主流设计模式,规范编程风格，提高优化程序结构和效率的能力。
 

 

 
视频目录
 
001.尚硅谷_图解Java设计模式-设计模式面试题(1)
 
002.尚硅谷_图解Java设计模式-设计模式面试题(2)
 
003.尚硅谷_图解Java设计模式-何时会用到设计模式
 
004.尚硅谷_图解Java设计模式-内容和授课方式
 
005.尚硅谷_图解Java设计模式-七大设计原则介绍
 
006.尚硅谷_图解Java设计模式-单一职责原则
 
007.尚硅谷_图解Java设计模式-单一职责原则小结
 
008.尚硅谷_图解Java设计模式-接口隔离原则(1)
 
009.尚硅谷_图解Java设计模式-接口隔离原则(2)
 
010.尚硅谷_图解Java设计模式-接口隔离原则小结
 
011.尚硅谷_图解Java设计模式-依赖倒转原则(1)
 
012.尚硅谷_图解Java设计模式-依赖倒转原则(2)
 
013.尚硅谷_图解Java设计模式-依赖倒转原则小结
 
014.尚硅谷_图解Java设计模式-里氏替换原则(1)
 
015.尚硅谷_图解Java设计模式-里氏替换原则(2)
 
016.尚硅谷_图解Java设计模式-开闭原则(1)
 
017.尚硅谷_图解Java设计模式-开闭原则(2)
 
018.尚硅谷_图解Java设计模式-开闭原则小结
 
019.尚硅谷_图解Java设计模式-迪米特法则(1)
 
020.尚硅谷_图解Java设计模式-迪米特法则(2)
 
021.尚硅谷_图解Java设计模式-迪米特法则注意事项
 
022.尚硅谷_图解Java设计模式-合成复用原则及小结
 
023.尚硅谷_图解Java设计模式-UML基本介绍
 
024.尚硅谷_图解Java设计模式-UML类图
 
025.尚硅谷_图解Java设计模式-类的依赖、泛化和实现
 
026.尚硅谷_图解Java设计模式-类的关联、聚合和组合
 
027.尚硅谷_图解Java设计模式-类图六大关系总结
 
028.尚硅谷_图解Java设计模式-设计模式概述和分类
 
029.尚硅谷_图解Java设计模式-单例(静态常量饿汉式)
 
030.尚硅谷_图解Java设计模式-单例(静态代码块饿汉式)
 
031.尚硅谷_图解Java设计模式-单例(线程不安全懒汉式)
 
032.尚硅谷_图解Java设计模式-单例(线程安全懒汉式)
 
033.尚硅谷_图解Java设计模式-单例(同步代码块懒汉式)
 
034.尚硅谷_图解Java设计模式-单例(DoubleCheck)
 
035.尚硅谷_图解Java设计模式-单例(静态内部类)
 
036.尚硅谷_图解Java设计模式-单例(枚举方式)
 
037.尚硅谷_图解Java设计模式-单例模式JKD源码分析
 
038.尚硅谷_图解Java设计模式-单例模式注意事项
 
039.尚硅谷_图解Java设计模式-简单工厂模式(1)-披萨订购
 
040.尚硅谷_图解Java设计模式-简单工厂模式(2)-披萨订购
 
041.尚硅谷_图解Java设计模式-简单工厂模式(3)-披萨订购
 
042.尚硅谷_图解Java设计模式-简单工厂模式(4)-披萨订购
 
043.尚硅谷_图解Java设计模式-工厂方法模式(1)-披萨订购
 
044.尚硅谷_图解Java设计模式-工厂方法模式(2)-披萨订购
 
045.尚硅谷_图解Java设计模式-抽象工厂模式(1)-披萨订购
 
046.尚硅谷_图解Java设计模式-抽象工厂模式(2)-披萨订购
 
047.尚硅谷_图解Java设计模式-工厂模式-JDK源码分析
 
048.尚硅谷_图解Java设计模式-工厂模式-小结
 
049.尚硅谷_图解Java设计模式-原型模式(1)-克隆羊
 
050.尚硅谷_图解Java设计模式-原型模式(2)-克隆羊
 
051.尚硅谷_图解Java设计模式-原型模式(3)-Spring源码分析
 
052.尚硅谷_图解Java设计模式-原型模式(4)-深拷贝
 
053.尚硅谷_图解Java设计模式-原型模式(5)-深拷贝
 
054.尚硅谷_图解Java设计模式-原型模式(6)-内容梳理
 
055.尚硅谷_图解Java设计模式-建造者模式(1)-盖房子
 
056.尚硅谷_图解Java设计模式-建造者模式(2)-原理类图
 
057.尚硅谷_图解Java设计模式-建造者模式(3)-盖房子
 
058.尚硅谷_图解Java设计模式-建造者模式(4)-StringBuilder源码
 
059.尚硅谷_图解Java设计模式-建造者模式(5)-内容梳理
 
060.尚硅谷_图解Java设计模式-适配器模式-工作原理
 
061.尚硅谷_图解Java设计模式-类适配器-电压问题
 
062.尚硅谷_图解Java设计模式-对象适配器-电压问题
 
063.尚硅谷_图解Java设计模式-接口适配器-电压问题
 
064.尚硅谷_图解Java设计模式-适配器模式-Dispatcher源码
 
065.尚硅谷_图解Java设计模式-适配器模式-内容梳理
 
066.尚硅谷_图解Java设计模式-桥接模式(1)-手机问题
 
067.尚硅谷_图解Java设计模式-桥接模式(2)-原理类图
 
068.尚硅谷_图解Java设计模式-桥接模式(3)-手机问题
 
069.尚硅谷_图解Java设计模式-桥接模式(4)-JDBC源码
 
070.尚硅谷_图解Java设计模式-桥接模式(5)-内容梳理
 
071.尚硅谷_图解Java设计模式-装饰者模式(1)-星巴克咖啡
 
072.尚硅谷_图解Java设计模式-装饰者模式(2)-星巴克咖啡
 
073.尚硅谷_图解Java设计模式-装饰者模式(3)-工作原理
 
074.尚硅谷_图解Java设计模式-装饰者模式(4)-星巴克咖啡
 
075.尚硅谷_图解Java设计模式-装饰者模式(5)-IO源码
 
076.尚硅谷_图解Java设计模式-装饰者模式(6)-内容梳理
 
077.尚硅谷_图解Java设计模式-组合模式(1)-院校展示
 
078.尚硅谷_图解Java设计模式-组合模式(2)-院校展示
 
079.尚硅谷_图解Java设计模式-组合模式(3)-HashMap源码
 
080.尚硅谷_图解Java设计模式-组合模式(4)-内容梳理
 
081.尚硅谷_图解Java设计模式-外观模式(1)-影院管理
 
082.尚硅谷_图解Java设计模式-外观模式(2)-工作原理
 
083.尚硅谷_图解Java设计模式-外观模式(3)-影院管理
 
084.尚硅谷_图解Java设计模式-外观模式(4)-MyBatis源码
 
085.尚硅谷_图解Java设计模式-外观模式(5)-注意事项
 
086.尚硅谷_图解Java设计模式-享元模式(1)-网站外包
 
087.尚硅谷_图解Java设计模式-享元模式(2)-工作原理
 
088.尚硅谷_图解Java设计模式-享元模式(3)-网站外包
 
089.尚硅谷_图解Java设计模式-享元模式(4)-Integer源码
 
090.尚硅谷_图解Java设计模式-享元模式(5)-内容梳理
 
091.尚硅谷_图解Java设计模式-代理模式(1)-基本介绍
 
092.尚硅谷_图解Java设计模式-代理模式(2)-静态代理
 
093.尚硅谷_图解Java设计模式-代理模式(3)-动态代理
 
094.尚硅谷_图解Java设计模式-代理模式(4)-Cglib代理
 
095.尚硅谷_图解Java设计模式-代理模式(5)-几种变体
 
096.尚硅谷_图解Java设计模式-模板模式(1)-工作原理
 
097.尚硅谷_图解Java设计模式-模板模式(2)-豆浆制作
 
098.尚硅谷_图解Java设计模式-模板模式(3)-钩子方法
 
099.尚硅谷_图解Java设计模式-模板模式(4)-IOC源码
 
100.尚硅谷_图解Java设计模式-模板模式(5)-细节说明
 
101.尚硅谷_图解Java设计模式-命令模式(1)-工作原理
 
102.尚硅谷_图解Java设计模式-命令模式(2)-遥控器
 
103.尚硅谷_图解Java设计模式-命令模式(3)-遥控器
 
104.尚硅谷_图解Java设计模式-命令模式(4)-JdbcTml源码
 
105.尚硅谷_图解Java设计模式-命令模式(5)-内容梳理
 
106.尚硅谷_图解Java设计模式-访问者模式(1)-歌手评分
 
107.尚硅谷_图解Java设计模式-访问者模式(2)-原理类图
 
108.尚硅谷_图解Java设计模式-访问者模式(3)-歌手评分
 
109.尚硅谷_图解Java设计模式-访问者模式(4)-双分派
 
110.尚硅谷_图解Java设计模式-访问者模式(5)-使用细节
 
111.尚硅谷_图解Java设计模式-迭代器模式(1)-统一遍历问题
 
112.尚硅谷_图解Java设计模式-迭代器模式(2)-原理类图
 
113.尚硅谷_图解Java设计模式-迭代器模式(3)-统一遍历问题
 
114.尚硅谷_图解Java设计模式-迭代器模式(4)-统一遍历问题
 
115.尚硅谷_图解Java设计模式-迭代器模式(5)-JDK源码
 
116.尚硅谷_图解Java设计模式-迭代器模式(6)-使用细节
 
117.尚硅谷_图解Java设计模式-观察者模式(1)-天气预报
 
118.尚硅谷_图解Java设计模式-观察者模式(2)-天气预报
 
119.尚硅谷_图解Java设计模式-观察者模式(3)-工作原理
 
120.尚硅谷_图解Java设计模式-观察者模式(4)-天气预报
 
121.尚硅谷_图解Java设计模式-观察者模式(5)-Observable源码
 
122.尚硅谷_图解Java设计模式-观察者模式(6)-内容梳理
 
123.尚硅谷_图解Java设计模式-中介者模式(1)-智能家庭
 
124.尚硅谷_图解Java设计模式-中介者模式(2)-工作原理
 
125.尚硅谷_图解Java设计模式-中介者模式(3)-智能家庭
 
126.尚硅谷_图解Java设计模式-中介者模式(4)-内容梳理
 
127.尚硅谷_图解Java设计模式-备忘录模式(1)-游戏角色
 
128.尚硅谷_图解Java设计模式-备忘录模式(2)-工作原理
 
129.尚硅谷_图解Java设计模式-备忘录模式(3)-游戏角色
 
130.尚硅谷_图解Java设计模式-备忘录模式(4)-注意事项
 
131.尚硅谷_图解Java设计模式-解释器模式(1)-计算式求值
 
132.尚硅谷_图解Java设计模式-解释器模式(2)-原理类图
 
133.尚硅谷_图解Java设计模式-解释器模式(3)-计算式求值
 
134.尚硅谷_图解Java设计模式-解释器模式(4)-SpelExp源码
 
135.尚硅谷_图解Java设计模式-解释器模式(5)-总结
 
136.尚硅谷_图解Java设计模式-状态模式(1)-工作原理图
 
137.尚硅谷_图解Java设计模式-状态模式(2)-抽奖活动
 
138.尚硅谷_图解Java设计模式-状态模式(3)-借贷平台源码
 
139.尚硅谷_图解Java设计模式-状态模式(4)-注意事项
 
140.尚硅谷_图解Java设计模式-策略模式(1)-鸭子问题
 
141.尚硅谷_图解Java设计模式-策略模式(2)-工作原理
 
142.尚硅谷_图解Java设计模式-策略模式(3)-鸭子问题
 
143.尚硅谷_图解Java设计模式-策略模式(4)-Arrays源码
 
144.尚硅谷_图解Java设计模式-策略模式(5)-内容梳理
 
145.尚硅谷_图解Java设计模式-职责链模式(1)-采购审批
 
146.尚硅谷_图解Java设计模式-职责链模式(2)-工作原理
 
147.尚硅谷_图解Java设计模式-职责链模式(3)-采购审批
 
148.尚硅谷_图解Java设计模式-职责链模式(4)-SpringMVC源码
 
149.尚硅谷_图解Java设计模式-职责链模式(5)-内容梳理
 
150.尚硅谷_图解Java设计模式-结束语 陆游和卖油翁
 

 
老规矩在公众号(java2Learn)回复关键字：设计模式
 
即可获取下载链接（注意大小写别错）
 

 
谢谢支持啦 ✧(≖ ◡ ≖✿)~ ，赞赏是对嘟嘟最棒的支持~ 星星之火可以燎原
 

 
更多精彩文章，尽在「嘟爷java超神学堂」！
 

 
推荐阅读
 

 

 

 

 
视频资源汇总帖
2019年公众号运营计划
福利，原来这才是购物的最佳省钱打开方式
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
你点的每个“在看”，我都认真当成了喜欢
 

 
Java设计模式PDF下载
 
PDF简述
下载链接
PDF图片
 

 
PDF简述
 
全PDF共分27章，内容包括统一建模语言基础知识、面向对象设计原则、设计模式概述、简单工厂模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式、适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式、职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式。
 本书结合大量实例介绍GoF设计模式，针对每个设计模式均提供了一或两个实例，并对每个模式进行了详尽的讲解，每章最后均配有一定量的习题。
 
下载链接
 
下面我为大家提供该PDF的下载路径：
 
链接: https://pan.baidu.com/s/18as70I14-aOLuHZLzS208A .
 提取码：vzg5
 
PDF图片
 

 

 作者：小傅哥
 博客：https://bugstack.cn
 
 
 
沉淀、分享、成长，让自己和他人都能有所收获！😄
 
 


 
文章目录
 
一、前言
二、简介
1. 谁发明了设计模式？
2. 我怎么学不会设计模式？
3. 适合人群
4. 我能学到什么
5. 阅读建议
   
三、书中目录
1. 创建型模式
2. 结构型模式
3. 行为模式
   
四、PDF📚下载
1. 可获得内容包括
2. 获取方式
   
五、收个尾🎉
 

 
一、前言
 
我膨胀了💥，在编写完上一本PDF《字节码编程》被下载了2000份以后，蠢蠢欲动开始计划第二本。于是从🌹5月20日那天投身实战型设计模式打磨，通过模拟互联网业务开发实际需求作为学习场景，讲解设计模式。
 
全书共计22个真实业务场景对应59组案例工程、编写了18万字271页的PDF、从5月20日开始耗时50天打造完成。
 
 
💋鉴于作者水平有限，如果书中含有不易理解的内容，一定是作者在编写的过程中缺少必要的描述和严格的校准，感谢把你的意见或者疑问提交给我，也欢迎与我多一些交互，互相进步共同成长。
 
二、简介
 
 
欢迎来到这里，很高兴你将拿到这本电子书，如果你能坚持看完并按照书中的例子进行实践，那么在编程开发的世界里，就又多了一个可以写出良好代码的人，同时也为架构师培养储备了一个人才。
 
可能在此之前你也多少了解过设计模式，但在实际的业务开发中使用却不多，多数时候都是大面积堆积ifelse组装业务流程，对于一次次的需求迭代和逻辑补充，只能东拼西凑Ctrl+C、Ctrl+V。
 
所以为了能让更多的程序员👨‍💻‍更好的接受设计思想和架构思维，并能运用到实际的业务场景。本书的作者小傅哥，投入50天时间，从互联网实际业务开发中抽离出，交易、营销、秒杀、中间件、源码等22个真实场景，来学习设计模式实践使用的应用可上手技能。
 
1. 谁发明了设计模式？
 
设计模式的概念最早是由 克里斯托佛·亚历山大 在其著作 《建筑模式语言》 中首次提出的。 本书介绍了城市设计的 “语言”，提供了253个描述城镇、邻里、住宅、花园、房间及西部构造的模式， 而此类 “语言” 的基本单元就是模式。后来，埃里希·伽玛、 约翰·弗利赛德斯、 拉尔夫·约翰逊 和 理查德·赫尔姆 这四位作者接受了模式的概念。 1994 年， 他们出版了 《设计模式： 可复用面向对象软件的基础》 一书， 将设计模式的概念应用到程序开发领域中。
 
其实有一部分人并没有仔细阅读过设计模式的相关书籍和资料，但依旧可以编写出优秀的代码。这主要是由于在经过众多项目的锤炼和对程序设计的不断追求，从而在多年编程历程上提炼出来的心得体会。而这份经验最终会与设计模式提到的内容几乎一致，同样会要求高内聚、低耦合、可扩展、可复用。你可能也遇到类似的经历，在学习一些框架的源码时，发现它里的某些设计和你在做开发时一样。
 
2. 我怎么学不会设计模式？
 
钱也花了，书也买了。代码还是一坨一坨的！设计模式是由多年的经验提炼出来开发指导思想。就像我告诉你自行车怎么骑、汽车怎么开，但只要你没跑过几千公里，你能记住的只是理论，想上道依旧很慌！
 
所以，本设计模式专题系列开始，会带着你使用设计模式的思想去优化代码。从而学习设计模式的心得并融入给自己。当然这里还需要多加练习，一定是人车合一，才能站在设计模式的基础上构建出更加合理的代码。
 
3. 适合人群
 
具备一定编程基础在工作1-3年的研发人员
希望通过此书提升编码思维，剔除到代码中的坏味道
有意愿成为架构师，但还处在一定瓶颈期
学习过设计模式，可是一直想找到一本可以落地真实场景参照的书籍
 
4. 我能学到什么
 
优化平时开发中的ifelse语句，让代码更加整洁
看设计模式不再是用理论生搬硬套，这次可以有点用
站在更高的角度去看待编程开发，学会更多的面向对象的思维，尤其是；接口、抽象类、多态等使用
升职、加薪，良好的代码是效能提升的基础，成为本组编码最靓的精神小伙
 
5. 阅读建议
 
本书属于实战型而不是理论介绍类书籍，每一章节都有对应的完整代码，学习的过程需要参考书中的章节与代码一起学习，同时在学习的过程中需要了解并运行代码。学习完成后进行知识点的总结，以及思考🤔这样的设计模式在自己的业务场景中需要如何使用。
 
三、书中目录
 
设计模式遵循六大原则；单一职责(一个类和方法只做一件事)、里氏替换(多态，子类可扩展父类)、依赖倒置(细节依赖抽象，下层依赖上层)、接口隔离(建立单一接口)、迪米特原则(最少知道，降低耦合)、开闭原则(抽象架构，扩展实现)，会在具体的设计模式章节中，进行体现。
 
1. 创建型模式
 
这类模式提供创建对象的机制， 能够提升已有代码的灵活性和可复用性。
 
序号
类型
图稿
业务场景
实现要点
1
工厂方法
多种类型商品不同接口，统一发奖服务搭建场景
定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
2
抽象工厂
替换Redis双集群升级，代理类抽象场景
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
3
生成器
各项装修物料组合套餐选配场景
将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
4
原型
上机考试多套试，每人题目和答案乱序排列场景
用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
5
单例
7种单例模式案例，Effective Java 作者推荐枚举单例模式
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
2. 结构型模式
 
这类模式介绍如何将对象和类组装成较大的结构， 并同时保持结构的灵活和高效。
 
序号
类型
图稿
业务场景
实现要点
1
适配器
从多个MQ消息体中，抽取指定字段值场景
将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
2
桥接
多支付渠道(微信、支付宝)与多支付模式(刷脸、指纹)场景
将抽象部分与实现部分分离，使它们都可以独立的变化。
3
组合
营销差异化人群发券，决策树引擎搭建场景
将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
4
装饰
SSO单点登录功能扩展，增加拦截用户访问方法范围场景
动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
5
外观
基于SpringBoot开发门面模式中间件，统一控制接口白名单场景
为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
6
享元
基于Redis秒杀，提供活动与库存信息查询场景
运用共享技术有效地支持大量细粒度的对象。
7
代理
模拟mybatis-spring中定义DAO接口，使用代理类方式操作数据库原理实现场景
为其他对象提供一种代理以控制对这个对象的访问。
3. 行为模式
 
这类模式负责对象间的高效沟通和职责委派。
 
序号
类型
图稿
业务场景
实现要点
1
责任链
模拟618电商大促期间，项目上线流程多级负责人审批场景
避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
2
命令
模拟高档餐厅八大菜系，小二点单厨师烹饪场景
将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
3
迭代器
模拟公司组织架构树结构关系，深度迭代遍历人员信息输出场景
提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
4
中介者
按照Mybatis原理手写ORM框架，给JDBC方式操作数据库增加中介者场景
用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
5
备忘录
模拟互联网系统上线过程中，配置文件回滚场景
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
6
观察者
模拟类似小客车指标摇号过程，监听消息通知用户中签场景
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
7
状态
模拟系统营销活动，状态流程审核发布上线场景
允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
8
策略
模拟多种营销类型优惠券，折扣金额计算策略场景
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
9
模板方法
模拟爬虫各类电商商品，生成营销推广海报场景
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
10
访问者
模拟家长与校长，对学生和老师的不同视角信息的访问场景
主要将数据结构与数据操作分离。
以上图稿和部分描述参考；https://refactoringguru.cn、https://www.runoob.com/design-pattern/visitor-pattern.html
 
四、PDF📚下载
 
下载前，一点对原创作者的支持请求😬，点赞、在看、分享、留言、赞赏，完成任何一样都可以获得🉐这本PDF书籍。
 
1. 可获得内容包括
 
《重学 Java 设计模式》PDF 书籍一本
59个对应的工程案例源码一套
在线阅读版学习了资料
 
2. 获取方式
 
扫描下方二维码加专栏学习群，凡进群者都送书籍一本
添加小傅哥微信(fustack)获取PDF书籍
公众号内回复PDF下载，你会获得一个连接，打开后右侧菜单 -> 精选 -> 值得一看的好书，里面对应也有这本书籍📚
 
 
五、收个尾🎉
 
👣走过的路会留下足迹，👨‍💻‍码过的文会盛满四季。
 
有时候真的很感谢自己还能坚持做原创技术输出，即使再忙再累也给自己一个当下的交代，在写文章的过程中甚至几乎没有过周末，也没有过半夜。但当自己完成每一篇文章后，那份给自己的努力也传播给其他人技术知识。也希望读者们能给多多点点在看分享和留言，这几乎是支撑我写作的最大动力回馈
 
本书是设计模式实战型书籍📚，编写的过程中常常为找到一个合适并易于理解的场景而抓头发，甚至睡觉中梦到的合适的内容，也要用语音发给自己记录下来。好在50天的坚持终于把这22个设计模式场景写完。如果书中有一些不易于理解的内容，不要担心一定是作者没有描述清楚或找到的案例不适合。可以添加作者小傅哥(fustack)微信，交流相应的技术内容，共同进步。
 
最后，我想说：能力，是你前行的最大保障。哪怕你是兢兢业业的工作者，也是拥有能留下的本事和跳出去的能力，才会相对安稳度过动荡。