常用设计模式

工厂模式

• 意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
• 主要解决：主要解决接口选择的问题。
• 何时使用：我们明确地计划不同条件下创建不同实例时。
• 如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
• 关键代码：创建过程在其子类执行。
• 实现

  • 定义一个接口：
    public interface Shape {
    void draw();
    }

  • 然后定义子类实现这个接口，如长方形：
    public class Rectangle implements Shape {
    @Override
    public void draw() {
    System.out.println("Inside Rectangle::draw() method.");
    }
    }

  • 接着写工厂类，传入类型，利用不同的子类生成不同的实例，如：
    public class ShapeFactory {

       //使用 getShape 方法获取形状类型的对象
       public Shape getShape(String shapeType){
       if(shapeType == null){
           return null;
       }        
       if(shapeType.equalsIgnoreCase("CIRCLE")){
          return new Circle();
       } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
         return new Rectangle();
       } else if(shapeType.equalsIgnoreCase("SQUARE")){
         return new Square();
       }
       return null;
       }
    } 
    

抽象工厂模式

• 意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
• 主要解决：主要解决接口选择的问题。
• 何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
• 如何解决：在一个产品族里面，定义多个产品。
• 关键代码：在一个工厂里聚合多个同类产品。
• 实现：在工厂模式的基础上，多个抽象工厂类，依据需求，实现抽象类中不懂的工厂实例
  public abstract class AbstractFactory {
  abstract Color getColor(String color);
  abstract Shape getShape(String shape) ;
  }

单例模式

• 意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
• 主要解决：一个全局使用的类频繁地创建与销毁。
• 何时使用：当您想控制实例数目，节省系统资源的时候。
• 如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
• 关键代码：构造函数是私有的。

原型模式

• 意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
• 主要解决：在运行期建立和删除原型。
• 何时使用：
  • 1、当一个系统应该独立于它的产品创建，构成和表示时。
  • 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。
  • 3、为了避免创建一个与产品类层次平行的工厂类层次时。
  • 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
• 如何解决：利用已有的一个原型对象，快速地生成和原型对象一样的实例。

适配器模式

• 意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• 如何解决：继承或依赖（推荐）。
• 关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。

代理模式

• 意图：为其他对象提供一种代理以控制对这个对象的访问。
• 何时使用：想在访问一个类时做一些控制。
• 如何解决：增加中间层。
• 关键代码：实现与被代理类组合。分别实现两个父类的子类，一个是具有真实功能的子类，另一个作为代理类，并且利用这个代理类来生成请一个子类的对象，最后利用这个对象来调用真实功能子类的方法。

观察者模式

• 意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
• 主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
• 何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
• 如何解决：使用面向对象技术，可以将这种依赖关系弱化。
• 关键代码：在抽象类里有一个 ArrayList 存放观察者们。

状态模式

• 意图：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
• 主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
• 何时使用：代码中包含大量与对象状态有关的条件语句。
• 如何解决：将各种具体的状态类抽象出来。
• 关键代码：通常命令模式的接口中只有一个方法，而状态模式的接口中有一个或者多个方法。另外，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。

策略模式

• 意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
• 主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
• 何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。
• 如何解决：将这些算法封装成一个一个的类，任意地替换。
• 关键代码：实现同一个接口。调用时，传入不同的策略子类实例，从而实现不同的策略。

访问者模式

• 意图：主要将数据结构与数据操作分离。
• 主要解决：稳定的数据结构和易变的操作耦合问题。
• 何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。
• 如何解决：在被访问的类里面加一个对外提供接待访问者的接口。
• 关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。

MVC模式

MVC 模式代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。

• Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。
• View（视图） - 视图代表模型包含的数据的可视化。
• Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。