单例模式——对象创建型模式

引入——任务管理器:
动机:

对于一个软件系统的某些类而言,我们无须创建多个实例

举个大家都熟知的例子——Windows任务管理器:通常情况下,无论我们启动任务管理多少次,Windows系统始终只能弹出一个任务管理器窗口,也就是说在一个Windows系统中,任务管理器存在唯一性。

在实际开发中,我们也经常遇到类似的情况,为了节约系统资源,有时需要确保系统中某个类只有唯一一个实例,当这个唯一实例创建成功之后,我们无法再创建一个同类型的其他对象,所有的操作都只能基于这个唯一实例。为了确保对象的唯一性,我们可以通过单例模式来实现,这就是单例模式的动机所在。

模拟:

下面我们来模拟实现Windows任务管理器,假设任务管理器的类名为TaskManager,在TaskManager类中包含了大量的成员方法,例如构造函数TaskManager(),显示进程的方法displayProcesses(),显示服务的方法displayServices()等,该类的示意代码如下:

class TaskManager {
    public TaskManager() {……} //初始化窗口
    public void displayProcesses() {……} //显示进程
    public void displayServices() {……} //显示服务}
按照单例模式进行重构:
  1. 由于每次使用new关键字来实例化TaskManager类时都将产生一个新对象,为了确保TaskManager实例的唯一性,我们需要禁止类的外部直接使用new来创建对象,因此需要将TaskManager的构造函数的可见性改为private,如下代码所示:

    private TaskManager() {}
    
  2. 将构造函数改为private修饰后,该如何创建对象呢?不要着急,虽然类的外部无法再使用new来创建对象,但是在TaskManager的内部还是可以创建的,可见性只对类外有效。因此,我们可以在TaskManager中创建并保存这个唯一实例。为了让外界可以访问这个唯一实例,需要在TaskManager中定义一个静态的TaskManager类型的私有成员变量,如下代码所示:

    private static TaskManager tm = null;
    
  3. 为了保证成员变量的封装性,我们将TaskManager类型的tm对象的可见性设置为private,但外界该如何使用该成员变量并何时实例化该成员变量呢?答案是增加一个公有的静态方法,如下代码所示:

    public static TaskManager getInstance () {
        if (tm == null) {
            tm = new TaskManager();
        }
        return tm;
    }
    

    在getInstance()方法中首先判断tm对象是否存在,如果不存在(即tm == null),则使用new关键字创建一个新的TaskManager类型的tm对象,再返回新创建的tm对象;否则直接返回已有的tm对象。

需要注意的是getInstance()方法的修饰符,首先它应该是一个public方法,以便供外界其他对象使用,其次它使用了static关键字,即它是一个静态方法,在类外可以直接通过类名来访问,而无须创建TaskManager对象,事实上在类外也无法创建TaskManager对象,因为构造函数是私有的。

通过以上三个步骤,我们完成了一个最简单的单例类的设计,其完整代码如下:

class TaskManager {
    private static TaskManager tm = null;
    private TaskManager() {……} //初始化窗口
    public void displayProcesses() {……} //显示进程
    public void displayServices() {……} //显示服务
    public static TaskManager getInstance () {
        if (tm == null) {
            tm = new TaskManager();
        }
        return tm;
    }}

在类外我们无法直接创建新的TaskManager对象,但可以通过代码TaskManager.getInstance()来访问实例对象,第一次调用getInstance()方法时将创建唯一实例,再次调用时将返回第一次创建的实例,从而确保实例对象的唯一性。

定义:

单例模式(Singleton Pattern):确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。单例模式是一种对象创建型模式。

要点:
  • 某个类只能有一个实例
  • 它必须自行创建这个实例
  • 它必须自行向整个系统提供这个实例
结构图:

在这里插入图片描述

总结:

单例模式结构图中只包含一个单例角色——Singleton(单例):

  • 在单例类的内部实现只生成一个实例,同时它提供一个静态的 getInstance()工厂方法,让客户可以访问它的唯一实例;
  • 为了防止在外部对其实例化,将其构造函数设计为私有;
  • 在单例类内部定义了一个Singleton类型的静态对象,作为外部共享的唯一 实例。
应用——负载均衡器的设计与实现:
背景:

Sunny软件公司承接了一个服务器负载均衡(Load Balance)软件的开发工作,该软件运行在一台负载均衡服务器上,可以将并发访问和数据流量分发到服务器集群中的多台设备上进行并发处理,提高系统的整体处理能力,缩短响应时间。由于集群中的服务器需要动态删减,且客户端请求需要统一分发,因此需要确保负载均衡器的唯一性,只能有一个负载均衡器来负责服务器的管理和请求的分发,否则将会带来服务器状态的不一致以及请求分配冲突等问题。如何确保负载均衡器的唯一性是该软件成功的关键。

Sunny公司开发人员通过分析和权衡,决定使用单例模式来设计该负载均衡器,结构图如下:

在这里插入图片描述

代码实现:

将负载均衡器LoadBalancer设计为单例类,其中包含一个存储服务器信息的集合 serverList,每次在serverList中随机选择一台服务器来响应客户端的请求,实现代码如下:

package singleton;
import java.util.*;

public class LoadBalancer {
    //私有静态成员变量,存储唯一实例
    private static LoadBalancer instance = null;
    //服务器集合
    private List serverList = null;
    //私有构造函数
    private LoadBalancer() {
        serverList = new ArrayList();
    }
    //公有静态成员方法,返回唯一实例
    public static LoadBalancer getLoadBalancer() {
        if (instance == null) {
            instance = new LoadBalancer();
        }
        return instance;
    }
    //增加服务器
    public void addServer(String server) {
        serverList.add(server);
    }
    //删除服务器
    public void removeServer(String server) {
        serverList.remove(server);
    }
    //使用Random类随机获取服务器
    public String getServer() {
        Random random = new Random();
        int i = random.nextInt(serverList.size());
        return (String)serverList.get(i);
    }
}

编写如下客户端测试代码:

package singleton;

public class Client {
    public static void main (String[] args) {
        //创建四个LoadBalancer对象
        LoadBalancer balancer1,balancer2,balancer3,balancer4;
        balancer1 = LoadBalancer.getLoadBalancer();
        balancer2 = LoadBalancer.getLoadBalancer();
        balancer3 = LoadBalancer.getLoadBalancer();
        balancer4 = LoadBalancer.getLoadBalancer();
        //判断服务器负载均衡器是否相同
        if (balancer1 == balancer2 && balancer2 == balancer3 && balancer3 == balancer4) {
            System.out.println("服务器负载均衡器具有唯一性!");
        }
        //增加服务器
        balancer1.addServer("Server 1");
        balancer1.addServer("Server 2");
        balancer1.addServer("Server 3");
        balancer1.addServer("Server 4");
        balancer2.removeServer("Server 4");
        //模拟客户端请求的分发
        for (int i = 0; i < 10; i++) {
            String server = balancer1.getServer();
            System.out.println("分发请求至服务器: " + server);
        }
    }
}
输出结果:
总览:

在这里插入图片描述

结果:

在这里插入图片描述

结果分析:

虽然创建了四个LoadBalancer对象,但是它们实际上是同一个对象,因此,通过使用单例模式 可以确保LoadBalancer对象的唯一性。

实现方式1——饿汉式:

饿汉式单例类是实现起来最简单的单例类,饿汉式单例类结构图如下:

在这里插入图片描述

由于在定义静态变量的时候实例化单例类,因此在类加载的时候就已经创建了单例对象,代码如下所示:

class EagerSingleton {
    private static final EagerSingleton instance = new EagerSingleton();
    private EagerSingleton() { }
    public static EagerSingleton getInstance() {
        return instance;
    }
}

当类被加载时,静态变量instance会被初始化,此时类的私有构造函数会被调用,单例类的唯一实例将被创建。如果使用饿汉式单例来实现负载均衡器LoadBalancer类的设计,则不会出现 创建多个单例对象的情况,可确保单例对象的唯一性。

实现方式2——懒汉式:
第一种——对 getInstance() 使用 synchronized:
结构图:

在这里插入图片描述

懒汉式单例在第一次调用getInstance()方法时实例化,在类加载时并不自 行实例化,这种技术又称为延迟加载(Lazy Load)技术,即需要的时候再加载实例,为了避免 多个线程同时调用getInstance()方法,我们可以使用关键字synchronized,代码如下所示:

class LazySingleton {
    private static LazySingleton instance = null;
    private LazySingleton() { }
    synchronized public static LazySingleton getInstance() {
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}
第二种——对 “instance = new LazySingleton(); ”锁定:

上述代码虽然解决了线程安全问题,但是每次调用getInstance()时 都需要进行线程锁定判断,在多线程高并发访问环境中,将会导致系统性能大大降低。如何 既解决线程安全问题又不影响系统性能呢?我们继续对懒汉式单例进行改进。事实上,我们 无须对整个getInstance()方法进行锁定,只需对其中的代码“instance = new LazySingleton();”进行锁定即可。因此getInstance()方法可以进行如下改进:

public static LazySingleton getInstance() {
    if (instance == null) {
        synchronized (LazySingleton.class) {
            instance = new LazySingleton();
        }
    }
    return instance;
}
第三种——双重检查锁:

问题貌似得以解决,事实并非如此。如果使用以上代码来实现单例,还是会存在单例对象不唯一。

原因如下: 假如在某一瞬间线程A和线程B都在调用getInstance()方法,此时instance对象为null值,均能通 过instance == null的判断。由于实现了synchronized加锁机制,线程A进入synchronized锁定的代 码中执行实例创建代码,线程B处于排队等待状态,必须等待线程A执行完毕后才可以进入 synchronized锁定代码。但当A执行完毕时,线程B并不知道实例已经创建,将继续创建新的实例,导致产生多个单例对象,违背单例模式的设计思想,因此需要进行进一步改进,在 synchronized中再进行一次(instance == null)判断,这种方式称为双重检查锁定(Double-Check Locking)。使用双重检查锁定实现的懒汉式单例类完整代码如下所示:

class LazySingleton {
    private volatile static LazySingleton instance = null;
    private LazySingleton() { }
    public static LazySingleton getInstance() {
        //第一重判断
        if (instance == null) {
            //锁定代码块
            synchronized (LazySingleton.class) {
                //第二重判断
                if (instance == null) {
                    instance = new LazySingleton(); //创建单例实例
                }
            }
        }
        return instance;
    }
}

需要注意的是,如果使用双重检查锁定来实现懒汉式单例类,需要在静态成员变量instance之 前增加修饰符volatile,被volatile修饰的成员变量可以确保多个线程都能够正确处理,且该代 码只能在JDK 1.5及以上版本中才能正确执行。由于volatile关键字会屏蔽Java虚拟机所做的一些代码优化,可能会导致系统运行效率降低,因此即使使用双重检查锁定来实现单例模式也不是一种完美的实现方式。

饿汉式单例类与懒汉式单例类比较:

饿汉式单例类在类被加载时就将自己实例化,它的优点在于无须考虑多线程访问问题,可以 确保实例的唯一性;从调用速度和反应时间角度来讲,由于单例对象一开始就得以创建,因 此要优于懒汉式单例。但是无论系统在运行时是否需要使用该单例对象,由于在类加载时该 对象就需要创建,因此从资源利用效率角度来讲,饿汉式单例不及懒汉式单例,而且在系统 加载时由于需要创建饿汉式单例对象,加载时间可能会比较长。

懒汉式单例类在第一次使用时创建,无须一直占用系统资源,实现了延迟加载,但是必须处 理好多个线程同时访问的问题,特别是当单例类作为资源控制器,在实例化时必然涉及资源 初始化,而资源初始化很有可能耗费大量时间,这意味着出现多线程同时首次引用此类的机 率变得较大,需要通过双重检查锁定等机制进行控制,这将导致系统性能受到一定影响。

实现方式3——Initialization Demand Holder (IoDH)

在IoDH中,我们在单例类中增加一个静态(static)内部类,在该内部类中创建单例对象,再将 该单例对象通过getInstance()方法返回给外部使用,实现代码如下所示:

//Initialization on Demand Holder
class Singleton {
    private Singleton() {}
    private static class HolderClass {
        private final static Singleton instance = new Singleton();
    }
    public static Singleton getInstance() {
        return HolderClass.instance;
    }
    public static void main(String args[]) {
        Singleton s1, s2;
        s1 = Singleton.getInstance();
        s2 = Singleton.getInstance();
        System.out.println(s1==s2);
    }
}

编译并运行上述代码,运行结果为:true,即创建的单例对象s1和s2为同一对象。由于静态单 例对象没有作为Singleton的成员变量直接实例化,因此类加载时不会实例化Singleton,第一次 调用getInstance()时将加载内部类HolderClass,在该内部类中定义了一个static类型的变量 instance,此时会首先初始化这个成员变量,由Java虚拟机来保证其线程安全性,确保该成员 变量只能初始化一次。由于getInstance()方法没有任何线程锁定,因此其性能不会造成任何影 响。

通过使用IoDH,我们既可以实现延迟加载,又可以保证线程安全,不影响系统性能,不失为一种最好的Java语言单例模式实现方式(其缺点是与编程语言本身的特性相关,很多面向对象 语言不支持IoDH)。

单例模式——主要优点:
  • 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严 格控制客户怎样以及何时访问它。
  • 由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销 毁的对象单例模式无疑可以提高系统的性能。
  • 允许可变数目的实例。基于单例模式我们可以进行扩展,使用与单例控制相似的方法来获 得指定个数的对象实例,既节省系统资源,又解决了单例单例对象共享过多有损性能的问题。
单例模式——主要缺点:
  • 由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
  • 单例类的职责过重,在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角 色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的创建和产品的 本身的功能融合到一起。
  • 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,因此,如 果实例化的共享对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次 利用时又将重新实例化,这将导致共享的单例对象状态的丢失。
单例模式——适用场景:
  • 系统只需要一个实例对象,如系统要求提供一个唯一的序列号生成器或资源管理器,或者需要考虑资源消耗太大而只允许创建一个对象。
  • 客户调用类的单个实例只允许使用一个公共访问点,除了该公共访问点,不能通过其他途径访问该实例。
  • 38
    点赞
  • 40
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
书籍目录 目录 第1章基本概念 1 1.1什么是设计模式 2 1.2设计模式的作用 3 1.3GRASP模式的分类 4 1.4GoF设计模式的分类 4 1.5模式的学习阶段 6 第2章负责任地设计对象——GRASP 9 2.1InformationExpert(信息专家) 11 2.2Creator(创造者) 13 2.3LowCoupling(低耦合) 14 2.4HighCohesion(高内聚) 15 2.5Controller(控制器) 17 2.6Polymorphism(多态) 18 2.7PureFabrication(纯虚构) 19 2.8Indirection(间接) 20 2.9ProtectedVariations(受保护变化) 21 第3章GoF-CreationalDesignPatterns创建型设计模式 23 3.1SimpleFactoryPattern(简单工厂模式) 24 3.1.1定义 24 3.1.2现实例子——国旗生产厂 26 3.1.3C#实例1——电子付款系统 26 3.1.4C#实例2——学校登录系统 29 3.1.5Java实例——手机简单工厂 32 3.1.6优势和缺陷 34 3.1.7应用情景 34 3.2FactoryMethodPattern(工厂方法模式) 35 3.2.1定义 35 3.2.2现实例子——兵工厂 36 3.2.3C#实例——多文档系统 37 3.2.4Java实例——扩展了的手机工厂 41 3.2.5优势和缺陷 44 3.2.6应用情景 44 3.3AbstractFactoryPattern(抽象工厂模式) 45 3.3.1定义 45 3.3.2现实例子——扩展了的兵工厂 48 3.3.3C#实例——大陆生态系统 49 3.3.4Java实例——电脑产品 52 3.3.5优势和缺陷 57 3.3.6应用情景 57 3.4BuilderPattern(建造者模式) 58 3.4.1定义 58 3.4.2现实例子——快餐店 60 3.4.3C#实例——车间造车 61 3.4.4Java实例——建造房屋 65 3.4.5优势和缺陷 69 3.4.6应用情景 70 3.5PrototypePattern(原型模式) 70 3.5.1定义 70 3.5.2现实中的拷贝-粘贴 71 3.5.3C#实例——颜色管理器 72 3.5.4Java实例——简单ToolBar 74 3.5.5ShallowCopy与DeepCopy 76 3.5.6优势和缺陷 82 3.5.7应用情景 82 3.6SingletonPattern(单例模式) 82 3.6.1定义 82 3.6.2现?抵械牡ダ??猈indowsTaskManager 83 3.6.3C#实例——负载均衡控制器 84 3.6.4Java实例——系统日志 86 3.6.5DoubleCheckLocking(双检锁) 89 3.6.6优势和缺陷 93 3.6.7应用情景 93 第4章GoF-StructuralDesignPatterns结构型设计模式 95 4.1AdapterPattern(适配器模式) 96 4.1.1定义 96 4.1.2现实中的实例——电脑电源适配器 97 4.1.3C#实例——化学数据银行 98 4.1.4Java实例——清洁系统 102 4.1.5优势和缺陷 104 4.1.6应用情景 104 4.2BridgePattern(桥接模式) 104 4.2.1定义 104 4.2.2现实中的实例——男人的约会 106 4.2.3C#实例——商业对象与数据对象 107 4.2.4Java实例——不同系统的图像处理 112 4.2.5优势和缺陷 114 4.2.6应用情景 115 4.3CompositePattern(组合模式) 115 4.3.1定义 115 4.3.2组合模式的现实应用——资源管理器 117 4.3.3C#实例——图形树状对象结构 118 4.3.4Java实例——文档格式化 121 4.3.5优势和缺陷 124 4.3.6应用情景 125 4.4DecoratorPattern(装饰模式) 125 4.4.1定义 125 4.4.2现实中的装饰模式——相架 126 4.4.3C#实例——图书馆中的项目 127 4.4.4Java实例——自定义JButton 131 4.4.5优势和缺陷 133 4.4.6应用情景 134 4.5FacadePattern(外观模式) 134 4.5.1定义 134 4.5.2现实中的实例——顾客服务员 135 4.5.3C#实例——抵押申请审核 136 4.5.4Java实例——冲茶 139 4.5.5优势和缺陷 143 4.5.6应用情景 143 4.6FlyweightPattern(轻量级模式) 144 4.6.1定义 144 4.6.2实例——中游的四国军棋 146 4.6.3C#实例——文档编辑器 147 4.6.4Java实例——装载图像 151 4.6.5优势和缺陷 154 4.6.6应用情景 154 4.7ProxyPattern(代理模式) 154 4.7.1定义 154 4.7.2几个现实中的实例 156 4.7.3C#实例——数学代理 158 4.7.4Java实例——Socket回声 160 4.7.5优势和缺陷 165 4.7.6应用情景 165 第5章GoF-BehavioralDesignPatterns行为型设计模式 167 5.1ChainofResponsibility(责任链模式) 168 5.1.1定义 168 5.1.2现实中的实例——军情的传递 169 5.1.3C#实例——采购分级审批 170 5.1.4Java实例——智能大厦安全系统 174 5.1.5优势和缺陷 178 5.1.6应用情景 178 5.2CommandPattern(命令模式) 179 5.2.1定义 179 5.2.2现实中的实例——餐馆订菜 180 5.2.3C#实例——简单计算器 181 5.2.4Java实例——总开关 185 5.2.5优势和缺陷 189 5.2.6应用情景 189 5.3InterpreterPattern(解释器模式) 190 5.3.1定义 190 5.3.2现实示例——音乐符号 192 5.3.3C#实例——中国金钱大写转换 192 5.3.4Java实例——自定义程序解释器 197 5.3.5优势和缺陷 204 5.3.6应用情景 205 5.4IteratorPattern(迭代器模式) 205 5.4.1定义 205 5.4.2现实示例——电视节目选择器 206 5.4.3C#实例——遍历例子 207 5.4.4Java实例——两个迭代器 211 5.4.5优势和缺陷 213 5.4.6应用情景 214 5.5MediatorPattern(中介者模式) 214 5.5.1定义 214 5.5.2现实示例——机场控制塔 215 5.5.3C#实例——聊天室 216 5.5.4Java实例——多线程通信 220 5.5.5优势和缺陷 223 5.5.6应用情景 223 5.6MementoPattern(备忘录模式) 223 5.6.1定义 223 5.6.2现实示例——音响均衡器 226 5.6.3C#实例——销售目标 226 5.6.4Java实例——多次Undo(取消)操作 231 5.6.5优势和缺陷 236 5.6.6应用情景 236 5.7ObserverPattern(观察者模式) 236 5.7.1定义 236 5.7.2现实例子——拉登现身了 238 5.7.3C#实例——猫和老鼠 238 5.7.4C#实例——股票变化 241 5.7.5Java实例——监控系统 245 5.7.6优势和缺陷 248 5.7.7应用情景 248 5.8StatePattern(状态模式) 248 5.8.1定义 248 5.8.2现实例子——心情好坏 250 5.8.3C#实例——账户分类 250 5.8.4Java实例——汽车的变速档 258 5.8.5优势和缺陷 261 5.8.6应用情景 261 5.9StrategyPattern(策略模式) 261 5.9.1定义 261 5.9.2现实例子——去机场的策略 263 5.9.3C#实例——排序方法 263 5.9.4Java实例——多格式输出 266 5.9.5优势和缺陷 272 5.9.6应用情景 272 5.10TemplateMethodPattern(模板方法模式) 272 5.10.1定义 272 5.10.2现实例子——厨师烹调 274 5.10.3C#实例——数据库连接模板 274 5.10.4Java实例——冒泡排序模板 277 5.10.5优势和缺陷 280 5.10.6应用情景 280 5.11VisitorPattern(访问者模式) 280 5.11.1定义 280 5.11.2现实例子——收银员收银计费 282 5.11.3C#实例——人事评估 283 5.11.4Java实例——维修工程师检查车辆 287 5.11.5优势和缺陷 291 5.11.6应用情??291 第6章模式的综合应用 293 6.1Java实例——扩展的日志记录器 294 6.2C#实例——存储分析器 298 6.3用模式生成程序架构 316 附录1自测题 321 附录2自测题答案 331 参考文献 337
1、 FACTORY —追 MM 少不了请吃饭了, 麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西, 虽然口味有所不同, 但不管你带 MM 去麦当劳或肯德基, 只管向服务员说“来四个鸡翅”就行 了。麦当劳和肯德基就是生产鸡翅的 Factory 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消 工厂模式 费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如 何创建及如何向客户端提供。 2、BUILDER — MM 最爱听的就是“我爱你”这句话了,见到不同地方的 MM,要能够用她们的 、 方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到 MM 我只要按对应的键, 它就能够用相应的语言说出“我爱你”这句话了, 国外的 MM 也可以轻松 搞掂,这就是我的“我爱你”builder。 (这一定比美军在 伊拉克用的翻译机好卖) 建造模式: 从而使一个建造过程生成具有不 建造模式 将产品的内部表象和产品的生成过程分割开来, 同的内部表象的产品对象。 建造模式使得产品内部表象可以独立的变化, 客户不必知道产品 内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、FACTORY METHOD —请 MM 去麦当劳吃汉堡,不同的 MM 有不同的口味,要每个都记住 、 是一件烦人的事情,我一般采用 Factory Method 模式,带着 MM 到服务员那儿,说“要一个 汉堡”,具体要什么样的汉堡呢,让 MM 直接跟服务员说就行了。 工厂方法模式: 而是将具体创建的工作交给子类去做, 工厂方法模式 核心工厂类不再负责所有产品的创建, 成为一个抽象工厂角色, 仅负责给出具体工厂类必须实现的接口, 而不接触哪一个产品类应 当被实例化这种细节。 4、 、 PROTOTYPE —跟 MM 用 QQ 聊天, 一定要说些深情的话语了, 我搜集了好多肉麻的情话, 需要时只要 copy 出来放到 QQ 面就行了, 这就是我的情话 prototype 了。 (100 块钱一份, 你要不要) 原始模型模式: 原始模型模式 通过给出一个原型对象来指明所要创建对象的类型,然后用复制这个原 型对象的方法创建出更多同类型的对象。 原始模型模式允许动态的增加或减少产品类, 产品 类不需要非得有任何事先确定的等级结构, 原始模型模式适用于任何的等级结构。 缺点是每 一个类都必须配备一个克隆方法。 5、 、 SINGLETON —俺有 6 个漂亮的老婆, 她们的老公都是我, 我就是我们家的老公 Sigleton, 她们只要说道“老公”,都是指的同一个人,那就是我(刚才做了个梦啦,哪有这么好的事) 单例模式: 而且自行实例化并向整个系统提供这个实 单例模式 单例模式确保某一个类只有一个实例, 例单例模式单例模式只应在有真正的“单一实例”的需求时才可使用。 结构型模式 6、ADAPTER —在朋友聚会上碰到了一个美女 Sarah,从香港来的,可我不会说粤语,她不 、 会说普通话,只好求助于我的朋友 kent 了,他作为我和 Sarah 之间的 Adapter,让我和 Sarah 可以相互交谈了(也不知道他会不会耍我) 适配器模式: 从而使原本因接口原因不 适配器模式 把一个类的接口变换成客户端所期待的另一种接口, 匹配而无法一起工作的两个类能够一起工作。 适配类可以根据参数返还一个合适的实例给客 户端。 7、BRIDGE —早上碰到 MM,要说早上好,晚上碰到 MM,要说晚上好;碰到 MM 穿了件新 、 衣服, 要说你的衣服好漂亮哦, 碰到 MM 新做的发型, 要说你的头发好漂亮哦。 不要问我“早 上碰到 MM 新做了个发型怎么说”这种问题,自己用 BRIDGE 组合一下不就行了 桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关 桥梁模式 联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是 继承关系,从而使两者可以独立的变化。 8、COMPOSITE —Mary 今天过生日。“我过生日,你要送我一件礼物。”“嗯,好吧,去商店, 、 你自己挑。”“这件 T 恤挺漂亮,买,这条裙子好看,买,这个包也不错, 买。”“喂,买了 三件了呀,我只答应送一件礼物的哦。”“什么呀,T 恤加裙子加包包,正好配成一套呀,小 姐,麻烦你包起来。”“……”,MM 都会用 Composite 模式了,你会了没有? 合成模式:合成模式将对象组织到树结构中,可以用来描述整体与部分的关系。合成模式就 合成模式 是一个处理对象的树结构的模式。 合成模式把部分与整体的
针对23种设计模式,分别写了demo并画了类图帮助理解。 总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类:并发型模式和线程池模式。 二、设计模式的六大原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、氏代换原则(Liskov Substitution Principle) 氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则(Dependence Inversion Principle) 这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。 4、接口隔离原则(Interface Segregation Principle) 这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。 5、迪米特法则(最少知道原则)(Demeter Principle) 为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 6、合成复用原则(Composite Reuse Principle) 原则是尽量使用合成/聚合的方式,而不是使用继承。
总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 二、设计模式的六大原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、氏代换原则(Liskov Substitution Principle) 氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则(Dependence Inversion Principle) 这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。 4、接口隔离原则(Interface Segregation Principle) 这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。 5、迪米特法则(最少知道原则)(Demeter Principle) 为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 6、合成复用原则(Composite Reuse Principle) 原则是尽量使用合成/聚合的方式,而不是使用继承。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

随行佯醉

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值