m0_55759099的博客

状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。本质：根据状态来分离和选择行为。实现了状态逻辑和动态实现的分离。就举个例子来说明该模式的作用：当快到期末考试周了，你（实际上是我）还有一堆科门没复习完，你要整天的复习，但是你的学习状态会根据每天的时间段的不同而变化，要求根据不同的时间段输出对应时间段的状态。什么嘛，这简单到掉牙了啊，啊sir，有没有搞错啊。你看，写完了吧确实可以，但是如果当我们给每天定制了一个任务，规定完成不了任务就要一直学。又或者今天晚上6点要和女朋友

组合模式（部分-整体模式）：将对象组合成树形结构以表示 ‘ 部分-整体 ’ 的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。以淘宝首页为例，假设服装节点下包含男装和女装，而男装作为节点又包含了夹克和衬衣，女装包含了裙子和套装，怎么使用代码体现呢？这种类似于树的结构，可以使用组合模式来实现。先来看一下以该例子写的组合模式的UML类图其中clothes作为抽象类存在，定义了节点的删除增加和展示的方法。composite继承了Component组件类，用来表示非叶子节点。leaf同样继承

抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。本质：选择产品，族的实现。为了方便理解，我们先来举个例子，在之前讲设计模式的六大原则的依赖倒转原则的时候提到了类似的情况。例如，在我们做项目的时候，对不同数据库的相同操作，如对Access数据库和Sqlserver数据库都进行查询或插入的操作，虽然操作一样，但是对于不同的数据库的操作，代码就不一样。可以从依赖倒转原则知道，高层模块不应该依赖底层模块。两个都应该依赖对象。抽象不应该依赖细节。细节应该依赖抽象。说白了就是要

观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。本质：触发联动。观察者模式UML类图其中Subject是抽象的主题类，也叫做抽象的通知者类。Observer是抽象的观察者类。Concrete分别是具体的实现。比如这样一个情景，公司里老板不在，小王小张小李都在摸鱼，可是老板突然回来了，前台首先发现了老板回来了，那么他需要通知公司的员工停止摸鱼，继续工作。这时前台做的就是具体的通知者类。但是如果前

外观模式：为子系统中的一组接口提供一个一致的页面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。本质：封装交互，简化调用。外观模式在我们生活中比较典型的例子就是基金的买入和卖出。与基金进行对比的就是股票的买入和卖出。在炒股时，有可能一个人买多份股票，卖出的时候也可能一块卖出多份股票，每个人和每份股票之间都有联系，这在设计模式中就可以称之为耦合性过高。但基金就不一样了，买入基金相当于买入了几十支好的股票，不会因为某个股票大跌而影响收益，同时也降低了客户与股票之间的耦合度，客户不必直接与股票

建造者模式建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。本质：分离整体，构建算法和部件构造。伙伴们聚在一起要画一个小人，这个小人有头、胳膊、身体和腿组成，小明喜欢先头，而张三喜欢先画身子，而每个人画出来的小人又不相同，如果用代码实现有什么好的办法吗？先看建造者模式的UML图其实这里一共有三个角色，分别是指挥者、建造者和产品。指挥者是指挥建造者建造产品的，建造者类作为抽象类存在，有许多具体的建造者类，这些具体的建造者类中包含了建造产品所需要的部件（一般都是

最近实在是太忙了…原型模式原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式就是从一个对象再创建另一个可定制的对象，而且不需要知道任何创建的细节。在Java中，内置了Cloneable接口，其中唯一一个方法就时clone（），所以只需要实现这个接口就可以完成原型模式了。为什么要使用原型模式呢？一般在初始化的信息不发生变化的情况下，克隆时最好的办法。这既隐藏了对象的创建细节，又对性能是大大的提高。但是要注意的是，在实现克隆方法的时候，如果字段是之类型的，则对该字段

工厂方法模式工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。了解过简单工厂模式的小伙伴都知道，简单工厂模式的一个致命缺点就是违背了开放封闭原则，不了解的可以看一下我之前对简单工厂模式的介绍。以之前讲过的计算器类为例，简单工厂模式每增加一个运算方法就需要对简单工厂类进行修改，违背了开放封闭原则。先来对比分析一下两个模式的UML图：简单工厂模式：工厂方法模式：package caculator;//运算器父类public abstr

最近忙于算法和选修课的的结课考试，web的课程设计，计组的期中考试（还要算期末的平时分…），最近比较少写博客，今天抽空写一篇代理模式，代理模式在设计模式里面算比较简单的一个模式，也算是复习一下设计模式。代理模式代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。本质：客户端和真实解决之间加了一个间接层继续举例子，假如你想去追求她（他），她却不认识你，所以不太好意思自己送礼物，但是你的朋友认识她，于是你让你的朋友代替你送，试试写出代码。先上UML图：只看代码就能很好的理解代

装饰模式装饰模式（Decorator）：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更灵活。本质：动态组合。动态是手段，组合是目的继续用例子来阐述该模式大家伙小时候都玩过（或者见别人玩过）一些换装游戏吧，今天就以穿衣服为例来举例。游戏开局，你的衣柜的衣服有：T恤，西装，领带，垮裤，球鞋，皮鞋，你的任务是给你的角色搭配两套衣服，并进行展示。看起来也没什么难得，我直接用简单工厂模式或者策略模式，弄一个抽象的穿衣工厂，然后给每一个衣服都弄一个具体的穿衣类，继承自抽象的穿衣

简单工厂模式写一个计算器程序，要求输入两个数和运算符号，得到结果。如果看到要求直接写代码，可能会把所有代码都写到一个类里面，对于初学编程的小白来说，只要实现功能就可以，不会去想完成要求的功能之后，这段代码将来会怎么用，怎么维护，怎么增加删除和修改代码。而如果以后做软件开发，实际的以后用到的代码都要有可维护，可复用，可扩展，灵活性好的特征，这也就需要学习设计模式。如果需要新增一个取余运算，只写一个类的代码，显然需要在繁琐的代码里面找到需要修改的地方，然后再进行修改，这样的代码的可维护性、可复用性、可扩

一、单一职责原则单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。我们在编程的时候，很自然的就会给一个类增加各种各样的功能，比如一个Fun类中，可能包含了各种各样的代码，像一些运算的算法、数据库访问的SQL语句什么的，但如果这样做就意味着，无论任何需求的改变，都需要对Fun类进行更改，维护麻烦，复用不可能，也缺乏灵活性。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到

策略模式策略模式：它定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。我们继续以例子来阐述该模式假如商场搞促销，有多种促销方式，促销方式包括：满300送80，打8折，满500送150等等，现在要求写出一个商场收银软件的的逻辑代码其实这个要求用前面说过的简单工厂模式也一样可以实现，直白的说，简单工厂模式和策略模式的差别很小，而策略模式和简单工厂模式结合起来与简单工厂模式自身比较的话，差距一般人看不出来…如果用简单工厂模式来写，很简单，跟写计算器差不