设计模式
[TOC]
单例模式
实现1个类只有1个实例化对象 & 提供一个全局访问点
实现
-
饿汉式
class Singleton { // 1. 加载该类时，单例就会自动被创建 private static Singleton ourInstance = new Singleton(); // 2. 构造函数 设置为 私有权限 // 原因：禁止他人创建实例 private Singleton() { } // 3. 通过调用静态方法获得创建的单例 public static Singleton newInstance() { return ourInstance; } } -
枚举式
public enum Singleton{ //定义1个枚举的元素，即为单例类的1个实例 INSTANCE; // 隐藏了1个空的、私有的 构造方法 // private Singleton () {} } // 获取单例的方式： Singleton singleton = Singleton.INSTANCE; -
懒汉式
class Singleton { // 1. 类加载时，先不自动创建单例 // 即，将单例的引用先赋值为 Null private static Singleton ourInstance = null； // 2. 构造函数 设置为 私有权限 // 原因：禁止他人创建实例 private Singleton() { } // 3. 需要时才手动调用 newInstance（） 创建 单例 public static Singleton newInstance() { // 先判断单例是否为空，以避免重复创建 if( ourInstance == null){ ourInstance = new Singleton(); } return ourInstance; } } -
线程安全：双重校验
class Singleton { private static Singleton ourInstance = null； private Singleton() { } public static Singleton newInstance() { // 加入双重校验锁 // 校验锁1：第1个if if( ourInstance == null){ // ① synchronized (Singleton.class){ // ② // 校验锁2：第2个 if if( ourInstance == null){ ourInstance = new Singleton(); } } } return ourInstance; } } -
静态内部类
- 在静态内部类里创建单例，在装载该内部类时才会去创建单例
- 线程安全：类是由
JVM加载，而JVM只会加载1遍，保证只有1个单例
class Singleton { // 1. 创建静态内部类 private static class Singleton2 { // 在静态内部类里创建单例 private static Singleton ourInstance = new Singleton()； } // 私有构造函数 private Singleton() { } // 延迟加载、按需创建 public static Singleton newInstance() { return Singleton2.ourInstance; } }
优点
提供了对唯一实例的受控访问；
由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能；
可以根据实际情况需要，在单例模式的基础上扩展做出双例模式，多例模式；
缺点
- 单例类的职责过重，里面的代码可能会过于复杂，在一定程度上违背了“单一职责原则”。
- 如果实例化的对象长时间不被利用，会被系统认为是垃圾而被回收，这将导致对象状态的丢失。
建造者模式
隐藏创建对象的建造过程 & 细节，使得用户在不知对象的建造过程 & 细节的情况下，就可直接创建复杂的对象
- 用户只需要给出指定复杂对象的类型和内容；
- 建造者模式负责按顺序创建复杂对象（把内部的建造过程和细节隐藏起来)
作用（解决的问题）
降低创建复杂对象的复杂度
隔离了创建对象的构建过程 & 表示
从而：
- 方便用户创建复杂的对象（不需要知道实现过程）
- 代码复用性 & 封装性（将对象构建过程和细节进行封装 & 复用）
常用Builder模式：
public class Computer {
private String cpu;
private String mainBoard;
private String HD;
private Computer(String cpu, String mainBoard, String HD) {
this.cpu = cpu;
this.mainBoard = mainBoard;
this.HD = HD;
}
public static class Builder{
private String cpu;
private String mainBoard;
private String HD;
public Builder setCpu(String cpu) {
this.cpu = cpu;
return this;
}
public Builder setMainBoard(String mainBoard) {
this.mainBoard = mainBoard;
return this;
}
public Builder setHD(String HD) {
this.HD = HD;
return this;
}
public Computer build() {
return new Computer(cpu,mainBoard,HD);
}
}
}
public static void main(String[] args) {
Computer computer = new Computer.Builder().setCpu("cpu").setMainBoard("123").setHD("HD").build();
}
实例
- 背景
小成希望去电脑城买一台组装的台式主机 - 过程
- 电脑城老板（Diretor）和小成（Client）进行需求沟通（买来打游戏？学习？看片？）
- 了解需求后，电脑城老板将小成需要的主机划分为各个部件（Builder）的建造请求（CPU、主板blabla）
- 指挥装机人员（ConcreteBuilder）去构建组件；
- 将组件组装起来成小成需要的电脑（Product）
使用步骤
步骤1：定义组装的过程（Builder）：组装电脑的过程
public abstract class Builder {
//第一步：装CPU
//声明为抽象方法，具体由子类实现
public abstract void BuildCPU()；
//第二步：装主板
//声明为抽象方法，具体由子类实现
public abstract void BuildMainboard（）；
//第三步：装硬盘
//声明为抽象方法，具体由子类实现
public abstract void BuildHD（）；
//返回产品的方法：获得组装好的电脑
public abstract Computer GetComputer（）；
}
步骤2： 电脑城老板委派任务给装机人员（Director）
public class Director{
//指挥装机人员组装电脑
public void Construct(Builder builder){
builder. BuildCPU();
builder.BuildMainboard（）;
builder. BuildHD（）;
}
}
步骤3： 创建具体的建造者（ConcreteBuilder）:装机人员
//装机人员1
public class ConcreteBuilder extend Builder{
//创建产品实例
Computer computer = new Computer();
//组装产品
@Override
public void BuildCPU(){
computer.Add("组装CPU")
}
@Override
public void BuildMainboard（）{
computer.Add("组装主板")
}
@Override
public void BuildHD（）{
computer.Add("组装主板")
}
//返回组装成功的电脑
@Override
public Computer GetComputer（）{
return computer
}
}
步骤4： 定义具体产品类（Product）：电脑
public class Computer{
//电脑组件的集合
private List parts = new ArrayList()；
//用于将组件组装到电脑里
public void Add(String part){
parts.add(part);
}
public void Show(){
for (int i = 0;i 步骤5：客户端调用-小成到电脑城找老板买电脑
public class Builder Pattern{
public static void main(String[] args){
//逛了很久终于发现一家合适的电脑店
//找到该店的老板和装机人员
Director director = new Director();
Builder builder = new ConcreteBuilder();
//沟通需求后，老板叫装机人员去装电脑
director.Construct(builder);
//装完后，组装人员搬来组装好的电脑
Computer computer = builder.GetComputer();
//组装人员展示电脑给小成看
computer.Show()；
}
}
优点
- 易于解耦
将产品本身与产品创建过程进行解耦，可以使用相同的创建过程来得到不同的产品。也就说细节依赖抽象。 - 易于精确控制对象的创建
将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰 - 易于拓展
增加新的具体建造者无需修改原有类库的代码，易于拓展，符合“开闭原则“。
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。
缺点
- 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似；如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
- 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。
简单工厂模式
- 简单工厂模式又叫静态方法模式（因为工厂类定义了一个静态方法）
- 现实生活中，工厂是负责生产产品的；同样在设计模式中，简单工厂模式我们可以理解为负责生产对象的一个类，称为“工厂类”
实现
步骤1. 创建抽象产品类，定义具体产品的公共接口
abstract class Product{
public abstract void Show();
}
步骤2. 创建具体产品类（继承抽象产品类），定义生产的具体产品
//具体产品类A
class ProductA extends Product{
@Override
public void Show() {
System.out.println("生产出了产品A");
}
}
//具体产品类B
class ProductB extends Product{
@Override
public void Show() {
System.out.println("生产出了产品C");
}
}
//具体产品类C
class ProductC extends Product{
@Override
public void Show() {
System.out.println("生产出了产品C");
}
}
步骤3. 创建工厂类，通过创建静态方法从而根据传入不同参数创建不同具体产品类的实例
class Factory {
public static Product Manufacture(String ProductName){
//工厂类里用switch语句控制生产哪种商品；
//使用者只需要调用工厂类的静态方法就可以实现产品类的实例化。
switch (ProductName){
case "A":
return new ProductA();
case "B":
return new ProductB();
case "C":
return new ProductC();
default:
return null;
}
}
}
步骤4. 外界通过调用工厂类的静态方法，传入不同参数从而创建不同具体产品类的实例
//工厂产品生产流程
public class SimpleFactoryPattern {
public static void main(String[] args){
Factory mFactory = new Factory();
//客户要产品A
try {
//调用工厂类的静态方法 & 传入不同参数从而创建产品实例
mFactory.Manufacture("A").Show();
}catch (NullPointerException e){
System.out.println("没有这一类产品");
}
//客户要产品B
try {
mFactory.Manufacture("B").Show();
}catch (NullPointerException e){
System.out.println("没有这一类产品");
}
//客户要产品C
try {
mFactory.Manufacture("C").Show();
}catch (NullPointerException e){
System.out.println("没有这一类产品");
}
//客户要产品D
try {
mFactory.Manufacture("D").Show();
}catch (NullPointerException e){
System.out.println("没有这一类产品");
}
}
}
优点
- 将创建实例的工作与使用实例的工作分开，使用者不必关心类对象如何创建，实现了解耦；
- 把初始化实例时的工作放到工厂里进行，使代码更容易维护。 更符合面向对象的原则 & 面向接口编程，而不是面向实现编程。
缺点
- 工厂类集中了所有实例（产品）的创建逻辑，一旦这个工厂不能正常工作，整个系统都会受到影响；
- 违背“开放 - 关闭原则”，一旦添加新产品就不得不修改工厂类的逻辑，这样就会造成工厂逻辑过于复杂。
- 简单工厂模式由于使用了静态工厂方法，静态方法不能被继承和重写，会造成工厂角色无法形成基于继承的等级结构。
工厂方法模式
解决简单工厂模式的缺点，将类的实例化（具体产品的创建）延迟到工厂类的子类（具体工厂）中完成，即由子类来决定应该实例化（创建）哪一个类。
步骤1： 创建抽象工厂类，定义具体工厂的公共接口
abstract class Factory{
public abstract Product Manufacture();
}
步骤2： 创建抽象产品类 ，定义具体产品的公共接口；
abstract class Product{
public abstract void Show();
}
步骤3： 创建具体产品类（继承抽象产品类）， 定义生产的具体产品；
//具体产品A类
class ProductA extends Product{
@Override
public void Show() {
System.out.println("生产出了产品A");
}
}
//具体产品B类
class ProductB extends Product{
@Override
public void Show() {
System.out.println("生产出了产品B");
}
}
步骤4：创建具体工厂类（继承抽象工厂类），定义创建对应具体产品实例的方法；
//工厂A类 - 生产A类产品
class FactoryA extends Factory{
@Override
public Product Manufacture() {
return new ProductA();
}
}
//工厂B类 - 生产B类产品
class FactoryB extends Factory{
@Override
public Product Manufacture() {
return new ProductB();
}
}
步骤5：外界通过调用具体工厂类的方法，从而创建不同具体产品类的实例
//生产工作流程
public class FactoryPattern {
public static void main(String[] args){
//客户要产品A
FactoryA mFactoryA = new FactoryA();
mFactoryA.Manufacture().Show();
//客户要产品B
FactoryB mFactoryB = new FactoryB();
mFactoryB.Manufacture().Show();
}
}
缺点
- 添加新产品时，除了增加新产品类外，还要提供与之对应的具体工厂类，系统类的个数将成对增加，在一定程度上增加了系统的复杂度；同时，有更多的类需要编译和运行，会给系统带来一些额外的开销；
- 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
- 虽然保证了工厂方法内的对修改关闭，但对于使用工厂方法的类，如果要更换另外一种产品，仍然需要修改实例化的具体工厂类；
- 一个具体工厂只能创建一种具体产品
抽象工厂模式
解决工厂方法模式的缺点，即每个工厂只能创建一类产品。
允许使用抽象的接口来创建一组相关产品，而不需要知道或关心实际生产出的具体产品是什么，这样就可以从具体产品中被解耦。
实例
- 背景：小成有两间塑料加工厂（A厂仅生产容器类产品；B厂仅生产模具类产品）；随着客户需求的变化，A厂所在地的客户需要也模具类产品，B厂所在地的客户也需要容器类产品；
- 冲突：没有资源（资金+租位）在当地分别开设多一家注塑分厂
- 解决方案：在原有的两家塑料厂里增设生产需求的功能，即A厂能生产容器+模具产品；B厂间能生产模具+容器产品。
步骤1： 创建抽象工厂类，定义具体工厂的公共接口
abstract class Factory{
public abstract Product ManufactureContainer();
public abstract Product ManufactureMould();
}
步骤2： 创建抽象产品族类 ，定义具体产品的公共接口；
abstract class AbstractProduct{
public abstract void Show();
}
步骤3： 创建抽象产品类 ，定义具体产品的公共接口；
//容器产品抽象类
abstract class ContainerProduct extends AbstractProduct{
@Override
public abstract void Show();
}
//模具产品抽象类
abstract class MouldProduct extends AbstractProduct{
@Override
public abstract void Show();
}
步骤4： 创建具体产品类（继承抽象产品类）， 定义生产的具体产品；
//容器产品A类
class ContainerProductA extends ContainerProduct{
@Override
public void Show() {
System.out.println("生产出了容器产品A");
}
}
//容器产品B类
class ContainerProductB extends ContainerProduct{
@Override
public void Show() {
System.out.println("生产出了容器产品B");
}
}
//模具产品A类
class MouldProductA extends MouldProduct{
@Override
public void Show() {
System.out.println("生产出了模具产品A");
}
}
//模具产品B类
class MouldProductB extends MouldProduct{
@Override
public void Show() {
System.out.println("生产出了模具产品B");
}
}
步骤5：创建具体工厂类（继承抽象工厂类），定义创建对应具体产品实例的方法；
//A厂 - 生产模具+容器产品
class FactoryA extends Factory{
@Override
public Product ManufactureContainer() {
return new ContainerProductA();
}
@Override
public Product ManufactureMould() {
return new MouldProductA();
}
}
//B厂 - 生产模具+容器产品
class FactoryB extends Factory{
@Override
public Product ManufactureContainer() {
return new ContainerProductB();
}
@Override
public Product ManufactureMould() {
return new MouldProductB();
}
}
步骤6：客户端通过实例化具体的工厂类，并调用其创建不同目标产品的方法创建不同具体产品类的实例
//生产工作流程
public class AbstractFactoryPattern {
public static void main(String[] args){
FactoryA mFactoryA = new FactoryA();
FactoryB mFactoryB = new FactoryB();
//A厂当地客户需要容器产品A
mFactoryA.ManufactureContainer().Show();
//A厂当地客户需要模具产品A
mFactoryA.ManufactureMould().Show();
//B厂当地客户需要容器产品B
mFactoryB.ManufactureContainer().Show();
//B厂当地客户需要模具产品B
mFactoryB.ManufactureMould().Show();
}
}
优点
降低耦合
抽象工厂模式将具体产品的创建延迟到具体工厂的子类中，这样将对象的创建封装起来，可以减少客户端与具体产品类之间的依赖，从而使系统耦合度低，这样更有利于后期的维护和扩展；-
更符合开-闭原则
新增一种产品类时，只需要增加相应的具体产品类和相应的工厂子类即可简单工厂模式需要修改工厂类的判断逻辑
-
符合单一职责原则
每个具体工厂类只负责创建对应的产品简单工厂中的工厂类存在复杂的switch逻辑判断
-
不使用静态工厂方法，可以形成基于继承的等级结构。
简单工厂模式的工厂类使用静态工厂方法
缺点
抽象工厂模式很难支持新种类产品的变化。
这是因为抽象工厂接口中已经确定了可以被创建的产品集合，如果需要添加新产品，此时就必须去修改抽象工厂的接口，这样就涉及到抽象工厂类的以及所有子类的改变，这样也就违背了“开发——封闭”原则。
对于新的产品族符合开-闭原则；对于新的产品种类不符合开-闭原则，这一特性称为开-闭原则的倾斜性。
策略模式
定义一系列算法，将每个算法封装到具有公共接口的一系列策略类中，从而使它们可以相互替换 & 让算法可在不影响客户端的情况下发生变化
实例
将算法的责任和本身进行解耦，使得：
- 算法可独立于使用外部而变化
- 客户端方便根据外部条件选择不同策略来解决不同问题
策略模式仅仅封装算法（包括添加 & 删除），但策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定
实例
- 背景：小成有一家百货公司，最近在定年度的促销活动
- 冲突：每个节日用同一个促销活动太枯燥，没吸引力
- 解决方案：针对不同节目使用不同促销活动进行促销
步骤1： 定义抽象策略角色（Strategy）：百货公司所有促销活动的共同接口
public abstract class Strategy {
public abstract void Show()；
}
步骤2：定义具体策略角色（Concrete Strategy）：每个节日具体的促销活动
//为春节准备的促销活动A
class StrategyA extends Strategy{
@Override
public void show() {
System.out.println("为春节准备的促销活动A");
}
}
//为中秋节准备的促销活动B
class StrategyB extends Strategy{
@Override
public void show() {
System.out.println("为中秋节准备的促销活动B");
}
}
//为圣诞节准备的促销活动C
class StrategyC extends Strategy{
@Override
public void show() {
System.out.println("为圣诞节准备的促销活动C");
}
}
步骤3：定义环境角色（Context）：用于连接上下文，即把促销活动推销给客户，这里可以理解为销售员
class Context_SalesMan{
//持有抽象策略角色的引用
private Strategy strategy;
//生成销售员实例时告诉销售员什么节日（构造方法）
//使得让销售员根据传入的参数（节日）选择促销活动（这里使用一个简单的工厂模式）
public SalesMan(String festival) {
switch ( festival) {
//春节就使用春节促销活动
case "A":
strategy = new StrategyA();
break;
//中秋节就使用中秋节促销活动
case "B":
strategy = new StrategyB();
break;
//圣诞节就使用圣诞节促销活动
case "C":
strategy = new StrategyC();
break;
}
}
//向客户展示促销活动
public void SalesManShow(){
strategy.show();
}
}
步骤4：客户端调用-让销售员进行促销活动的落地
public class StrategyPattern{
public static void main(String[] args){
Context_SalesMan mSalesMan ;
//春节来了，使用春节促销活动
System.out.println("对于春节：");
mSalesMan = Context_SalesMan SalesMan("A");
mSalesMan.SalesManShow();
//中秋节来了，使用中秋节促销活动
System.out.println("对于中秋节：");
mSalesMan = Context_SalesMan SalesMan("B");
mSalesMan.SalesManShow();
//圣诞节来了，使用圣诞节促销活动
System.out.println("对于圣诞节：");
mSalesMan = Context_SalesMan SalesMan("C");
mSalesMan.SalesManShow();
}
}
优点
- 策略类之间可以自由切换
由于策略类都实现同一个接口，所以使它们之间可以自由切换。 - 易于扩展
增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则“ - 避免使用多重条件选择语句（if else），充分体现面向对象设计思想。
缺点
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
- 策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。
适配器模式
定义一个包装类，用于包装不兼容接口的对象
- 包装类 = 适配器Adapter；
- 被包装对象 = 适配者Adaptee = 被适配的类
作用
把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。
适配器模式的形式分为：类的适配器模式 & 对象的适配器模式
解决问题
原本由于接口不兼容而不能一起工作的那些类可以在一起工作
优点
- 更好的复用性
系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。 - 透明、简单
客户端可以调用同一接口，因而对客户端来说是透明的。这样做更简单 & 更直接 - 更好的扩展性
在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。 - 解耦性
将目标类和适配者类解耦，通过引入一个适配器类重用现有的适配者类，而无需修改原有代码 - 符合开放-关闭原则
同一个适配器可以把适配者类和它的子类都适配到目标接口；可以为不同的目标接口实现不同的适配器，而不需要修改待适配类
缺点
- 过多的使用适配器，会让系统非常零乱，不易整体进行把握
类的适配器模式
使用步骤
步骤1： 创建Target接口；
public interface Target {
//这是源类Adapteee没有的方法
public void Request();
}
步骤2： 创建源类（Adaptee） ；
public class Adaptee {
public void SpecificRequest(){
}
}
步骤3： 创建适配器类（Adapter）
//适配器Adapter继承自Adaptee，同时又实现了目标(Target)接口。
public class Adapter extends Adaptee implements Target {
//目标接口要求调用Request()这个方法名，但源类Adaptee没有方法Request()
//因此适配器补充上这个方法名
//但实际上Request()只是调用源类Adaptee的SpecificRequest()方法的内容
//所以适配器只是将SpecificRequest()方法作了一层封装，封装成Target可以调用的Request()而已
@Override
public void Request() {
this.SpecificRequest();
}
}
步骤4：定义具体使用目标类，并通过Adapter类调用所需要的方法从而实现目标
public class AdapterPattern {
public static void main(String[] args){
Target mAdapter = new Adapter()；
mAdapter.Request（）;
}
}
优点
- 使用方便，代码简化
仅仅引入一个对象，并不需要额外的字段来引用Adaptee实例
缺点
- 高耦合，灵活性低
使用对象继承的方式，是静态的定义方式
对象的适配器模式
与类的适配器模式不同的是，对象的适配器模式不是使用继承关系连接到Adaptee类，而是使用委派关系连接到Adaptee类。
步骤1： 创建Target接口；
public interface Target {
//这是源类Adapteee没有的方法
public void Request();
}
步骤2： 创建源类（Adaptee） ；
public class Adaptee {
public void SpecificRequest(){
}
}
步骤3： 创建适配器类（Adapter）（不适用继承而是委派）
class Adapter implements Target{
// 直接关联被适配类
private Adaptee adaptee;
// 可以通过构造函数传入具体需要适配的被适配类对象
public Adapter (Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void Request() {
// 这里是使用委托的方式完成特殊功能
this.adaptee.SpecificRequest();
}
}
步骤4：定义具体使用目标类，并通过Adapter类调用所需要的方法从而实现目标
public class AdapterPattern {
public static void main(String[] args){
//需要先创建一个被适配类的对象作为参数
Target mAdapter = new Adapter(new Adaptee())；
mAdapter.Request();
}
}
优点
- 灵活性高、低耦合
采用 “对象组合”的方式，是动态组合方式
缺点
- 使用复杂
需要引入对象实例
特别是需要重新定义Adaptee行为时需要重新定义Adaptee的子类，并将适配器组合适配
代理模式
给目标对象提供一个代理对象，并由代理对象控制对目标对象的引用
- 代理对象：起到中介作用，连接客户端和目标对象
- 例子：电脑桌面的快捷方式。电脑对某个程序提供一个快捷方式（代理对象），快捷方式连接客户端和程序，客户端通过操作快捷方式就可以操作那个程序
作用
防止直接访问目标对象给系统带来的不必要复杂性。
优点
- 协调调用者和被调用者，降低了系统的耦合度
- 代理对象作为客户端和目标对象之间的中介，起到了保护目标对象的作用
缺点
- 由于在客户端和真实主题之间增加了代理对象，因此会造成请求的处理速度变慢；
- 实现代理模式需要额外的工作（有些代理模式的实现非常复杂），从而增加了系统实现的复杂度。
静态代理
静态代理：有一个类文件描述
实例
- 背景：小成希望买一台最新的顶配Mac电脑
- 冲突：国内还没上，只有美国才有
- 解决方案：寻找代购进行购买
步骤1： 创建抽象对象接口（Subject）：声明你（真实对象）需要让代购（代理对象）帮忙做的事（买Mac）
public interface Subject {
public void buyMac();
}
步骤2： 创建真实对象类（RealSubject）,即”我“
public class RealSubject implement Subject{
@Override
public void buyMac() {
System.out.println(”买一台Mac“);
}
}
步骤3：创建代理对象类（Proxy），即”代购“，并通过代理类创建真实对象实例并访问其方法
public class Proxy implements Subject{
@Override
public void buyMac{
//引用并创建真实对象实例，即”我“
RealSubject realSubject = new RealSubject()；
//调用真实对象的方法，进行代理购买Mac
realSubject.buyMac（）；
//代理对象额外做的操作
this.WrapMac()；
}
public void WrapMac(){
System.out.println(”用盒子包装好Mac“);
}
}
步骤4：客户端调用
public class ProxyPattern {
public static void main(String[] args){
Subject proxy = new Proxy（）；
proxy.buyMac()；
}
}
动态代理
动态代理：在内存中形成代理类
步骤
- 代理对象和真实对象实现相同接口
- 代理对象 = Proxy.newInstance();
- 使用代理对象执行方法
//#ProxyInterface.java
public interface ProxyInterface{
void show();
}
//#RealClass.java
public class RealClass implements ProxyInterface {
@Override
public void show() {
}
}
//#ProxyDemo.java
public class ProxyDemo {
public static void main(String[] args) {
RealClass real = new RealClass();
/***
*Proxy.newProxyInstance 参数说明
*
* @param loader 类加载器：real.getClass().getClassLoader()
* @param interfaces 实现的接口：real.getClass().getInterfaces()
* @param h ：InvocationHandler 代理类执行每个方法都会调用此接口中的invoke方法
* @return
*/
ProxyInterface proxy = (ProxyInterface) Proxy.newProxyInstance(real.getClass().getClassLoader(), real.getClass().getInterfaces(), new InvocationHandler() {
/***
*
* @param proxy 当前代理类对象
* @param method 当前代理执行的方法
* @param args 当前执行方法所传递的参数
* @return 当前方法的返回值
* @throws Throwable
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//针对参数进行操作
// ...
//针对方法逻辑操作
// ...
//真实对象执行方法
Object obj = method.invoke(real, args);
// 针对返回值的操作
// ...
return null;
}
});
}
}
模板方法模式
定义一个模板结构，将具体内容延迟到子类去实现。
作用
在不改变模板结构的前提下在子类中重新定义模板中的内容。
模板方法模式是基于”继承“的；
解决的问题
- 提高代码复用性
将相同部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中 - 实现了反向控制
通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制 & 符合“开闭原则”
实例
- 背景：小成希望学炒菜：手撕包菜 & 蒜蓉炒菜心
- 冲突：两道菜的炒菜步骤有的重复有的却差异很大，记不住
- 解决方案：利用代码记录下来
使用步骤
步骤1： 创建抽象模板结构（Abstract Class）：炒菜的步骤
public abstract class Abstract Class {
//模板方法，用来控制炒菜的流程 （炒菜的流程是一样的-复用）
//申明为final，不希望子类覆盖这个方法，防止更改流程的执行顺序
final void cookProcess(){
//第一步：倒油
this.pourOil()；
//第二步：热油
this.HeatOil();
//第三步：倒蔬菜
this.pourVegetable();
//第四步：倒调味料
this.pourSauce（）；
//第五步：翻炒
this.fry();
}
//定义结构里哪些方法是所有过程都是一样的可复用的，哪些是需要子类进行实现的
//第一步：倒油是一样的，所以直接实现
void pourOil(){
System.out.println("倒油");
}
//第二步：热油是一样的，所以直接实现
void HeatOil(){
System.out.println("热油");
}
//第三步：倒蔬菜是不一样的（一个下包菜，一个是下菜心）
//所以声明为抽象方法，具体由子类实现
abstract void pourVegetable()；
//第四步：倒调味料是不一样的（一个下辣椒，一个是下蒜蓉）
//所以声明为抽象方法，具体由子类实现
abstract void pourSauce（）；
//第五步：翻炒是一样的，所以直接实现
void fry();{
System.out.println("炒啊炒啊炒到熟啊");
}
}
步骤2： 创建具体模板（Concrete Class）,即”手撕包菜“和”蒜蓉炒菜心“的具体步骤
//炒手撕包菜的类
public class ConcreteClass_BaoCai extend Abstract Class{
@Override
public void pourVegetable(){
System.out.println(”下锅的蔬菜是包菜“);
}
@Override
public void pourSauce（）{
System.out.println(”下锅的酱料是辣椒“);
}
}
//炒蒜蓉菜心的类
public class ConcreteClass_CaiXin extend Abstract Class{
@Override
public void pourVegetable(){
System.out.println(”下锅的蔬菜是菜心“);
}
@Override
public void pourSauce（）{
System.out.println(”下锅的酱料是蒜蓉“);
}
}
**步骤3： **客户端调用-炒菜了
public class Template Method{
public static void main(String[] args){
//炒 - 手撕包菜
ConcreteClass_BaoCai BaoCai = new ConcreteClass_BaoCai（）；
BaoCai.cookProcess()；
//炒 - 蒜蓉菜心
ConcreteClass_ CaiXin = new ConcreteClass_CaiXin（）；
CaiXin.cookProcess()；
}
}
优点
- 提高代码复用性
将相同部分的代码放在抽象的父类中 - 提高了拓展性
将不同的代码放入不同的子类中，通过对子类的扩展增加新的行为 - 实现了反向控制
通过一个父类调用其子类的操作，通过对子类的扩展增加新的行为，实现了反向控制 & 符合“开闭原则”
缺点
- 引入了抽象类，每一个不同的实现都需要一个子类来实现，导致类的个数增加，从而增加了系统实现的复杂度。
外观模式
定义了一个高层、统一的接口，外部与通过这个统一的接口对子系统中的一群接口进行访问。
通过创建一个统一的外观类，用来包装子系统中一个 / 多个复杂的类，客户端可通过调用外观类的方法来调用内部子系统中所有方法
主要作用
- 实现客户类与子系统类的松耦合
- 降低原有系统的复杂度
- 提高了客户端使用的便捷性，使得客户端无须关心子系统的工作细节，通过外观角色即可调用相关功能。
- 引入外观角色之后，用户只需要与外观角色交互；
- 用户与子系统之间的复杂逻辑关系由外观角色来实现
解决的问题
- 避免了系统与系统之间的高耦合度
- 使得复杂的子系统用法变得简单
实例
- 背景：小成的爷爷已经80岁了，一个人在家生活：每次都需要打开灯、打开电视、打开空调；睡觉时关闭灯、关闭电视、关闭空调；
- 冲突：行动不方便，走过去关闭那么多电器很麻烦，代码如下：
电器类
//灯类
public class SubSystemA_Light {
public void on(){
System.out.println("打开了灯....");
}
public void off(){
System.out.println("关闭了灯....");
}
}
//电视类
public class SubSystemB_Television {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
}
//空调类
public class SubSystemC_Aircondition {
public void on(){
System.out.println("打开了电视....");
}
public void off(){
System.out.println("关闭了电视....");
}
}
小成买了一个智能家具控制器（外观对象/统一接口）给他爷爷，他爷爷只需要一键就能打开/关闭 灯、电视机、空调
- 即用外观模式来为所有子系统设计一个统一的接口
- 客户端只需要调用外观类中的方法就可以了，简化了客户端的操作
智能遥控器
public class Facade{
SubSystemA_Light light；
SubSystemB_Television television ；
SubSystemC_Aircondition aircondition；
//传参
public Facade(SubSystemA_Light light,SubSystemB_Television television,SubSystemC_Aircondition aircondition){
this.light = light;
this.television = television ;
this.aircondition =aircondition;
}
//起床后一键开电器
public void on(){
System.out.prinln("起床了")；
light.on()；
television.on();
aircondition.on()；
}
public void off(){
//睡觉时一键关电器
System.out.prinln("睡觉了")；
light.off()；
television.off();
aircondition.off()；
}
}
客户端调用：爷爷使用智能遥控器的时候
public class Facade Pattern{
public static void main(String[] args){
//实例化电器类
SubSystemA_Light light = new SubSystemA_Light();
SubSystemB_Television television = new SubSystemB_Television();
SubSystemC_Aircondition aircondition = new SubSystemC_Aircondition();
//传参
Facade facade = new Facade(light,television,aircondition);
//客户端直接与外观对象进行交互
facade.on();
System.out.prinln("可以看电视了")；
facade.off();
System.out.prinln("可以睡觉了")；
}
}
优点
- 降低了客户类与子系统类的耦合度，实现了子系统与客户之间的松耦合关系
- 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类
- 减少了与子系统的关联对象，实现了子系统与客户之间
的松耦合关系，松耦合使得子系统的组件变化不会影响到它的客户。
- 外观模式对客户屏蔽了子系统组件，从而简化了接口，减少了客户处理的对象数目并使子系统的使用更加简单。
- 引入外观角色之后，用户只需要与外观角色交互；
- 用户与子系统之间的复杂逻辑关系由外观角色来实现
- 降低原有系统的复杂度和系统中的编译依赖性，并简化了系统在不同平台之间的移植过程
因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
缺点
- 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”
- 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。