u014627852的博客

学校 OA系统的采购审批项目需求是采购一批教材如果金额小于等于 5000,由教学主任审批（0<=x<=5000)。如果金额小于等于 10000,由院长审批 (5000<x<=10000)。如果金额小于等于 30000,由副校长审批 (10000<x<=30000)。如果金额超过 30000以上，有校长审批 ( 30000<x)。传统方案解决 OA系统审批，传统的设计方案(类图)问题分析传统方式

编写鸭子项目，具体要求如下:有各种鸭子(比如野鸭、北京鸭、水鸭等，鸭子有各种行为，比如叫、飞行等)。显示鸭子的信息。传统方案解决鸭子问题的分析和代码实现传统的设计方案(类图)代码演示package com.jinxu.strategy;public abstract class Duck { public Duck() { } public abstract void display();//显示鸭子信息 public void quack() { Syst

APP抽奖活动问题请编写程序完成 APP抽奖活动具体要求如下:假如每参加一次这个活动要扣除用户 50积分，中奖概率是 10%。奖品数量固定，抽完就不能抽奖。活动有四个状态:可以抽奖、不能抽奖、发放奖品和奖品领完。活动的四个状态转换关系图：状态模式基本介绍状态模式（State Pattern）：它主要用来解决对象在多种状态转换时，需要对外输出不同的行为的问题。状态和行为是一一对应的，状态之间可以相互转换。当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变

四则运算问题通过解释器模式来实现四则运算，如计算 a+b-c的值，具体要求：先输入表达式的形式，比如 a+b+c-d+e,要求表达式的字母不能重复。在分别输入 a ,b, c, d, e的值。最后求出结果：如图传统方案解决四则运算问题分析编写一个方法，接收表达式的形式，然后根据用户输入的数值进行解析，得到结果。问题分析：如果加入新的运算符，比如 * / (等等，不利于扩展，另外让一个方法来解析会造成程序结构混乱，不够清晰。解决方案：可以考虑使用解释器模式，即：表

游戏角色状态恢复问题游戏角色有攻击力和防御力，在大战 Boss前保存自身的状态(攻击力和防御)，当大战 Boss后攻击力和防御力下降，从备忘录对象恢复到大战前的状态。传统方案解决游戏角色恢复传统的方式的问题分析一个对象，就对应一个保存对象状态的对象，这样当我们游戏的对象很多时，不利于管理，开销也很大。传统的方式是简单地做备份，new出另外一个对象出来，再把需要备份的数据放到这个新对象，但这就暴露了对象内部的细节。解决方案： =>备忘录模式备忘录模式基本介绍备忘录模式（

智能家庭项目智能家庭包括各种设备，闹钟、咖啡机、电视机、窗帘等。2)要看电视时，各个设备可以协同工作，自动完成看电视的准备工作，比如流程为：闹铃响起->咖啡机开始做咖啡->窗帘自动落下->电视机开始播放。传统方案解决智能家庭管理问题传统的方式的问题分析当各电器对象有多种状态改变时，相互之间的调用关系会比较复杂。各个电器对象彼此联系，你中有我，我中有你，不利于松耦合。各个电器对象之间所传递的消息(参数)，容易混乱。当系统增加一个新的电器对象时，或者执行流程改变时，代码

天气预报项目需求,具体要求如下气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去(比如发布到自己的网站或第三方)。需要设计开放型 API，便于其他第三方也能接入气象站获取数据。提供温度、气压和湿度的接口。测量数据更新时，要能实时的通知给第三方。天气预报设计方案 1-普通方案传统的设计方案通过getxxx()方法，可以让第三方接入，并得到相关信息。当数据有更新时，调用dataChange（）方法去更新数据，当第三方再次获取时，就能得到最新数据，当前，也可以

看一个具体的需求编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系。如图：传统的设计方案(类图)传统的方式的问题分析将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的。实际上我们的要求是：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系，因此这种方案，不能很好实现的遍历的操作。3)解决方案：=>迭代器模式。迭代器模式基本介绍迭代器模式（Iterator Pa

测评系统的需求将观众分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价( 评价有不同的种类，比如成功、失败等)。传统解决方案：传统方式的问题分析如果系统比较小，还是 ok的，但是考虑系统增加越来越多新的功能时，对代码改动较大，违反了 ocp 原则，不利于维护。扩展性不好，比如增加了新的人员类型，或者管理方法，都不好做。引出我们会使用新的设计模式–访问者模式。访问者模式基本介绍访问者模式（Visitor Pattern），封装一些作用

智能生活项目需求我们买了一套智能家电，有照明灯、风扇、冰箱、洗衣机，我们只要在手机上安装app就可以控制对这些家电工作。这些智能家电来自不同的厂家，我们不想针对每一种家电都安装一个App，分别控制，我们希望只要一个 app就可以控制全部智能家电。要实现一个 app控制所有智能家电的需要，则每个智能家电厂家都要提供一个统一的接口给 app调用，这时就可以考虑使用命令模式。命令模式可将“动作的请求者”从“动作的执行者”对象中解耦出来。在我们的例子中，动作的请求者是手机app，动作的执行者是

豆浆制作问题编写制作豆浆的程序，说明如下:制作豆浆的流程选材—>添加配料—>浸泡—>放到豆浆机打碎。通过添加不同的配料，可以制作出不同口味的豆浆。选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的。请使用模板方法模式完成 。模板方法模式基本介绍模板方法模式（Template Method Pattern），又叫模板模式(Template Pattern)，在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重写方法实现，但调用将以抽象

代理模式(Proxy)基本介绍代理模式：为一个对象提供一个替身，以控制对这个对象的访问。即通过代理对象访问目标对象.这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能。被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象代理模式有不同的形式,主要有三种静态代理、动态代理 (JDK代理、接口代理)和 Cglib代理 (可以在内存动态的创建对象，而不需要实现接口，他是属于动态代理的范畴)。代理模式示意图静态代理静态代理在使用时,需要定义接口

展示网站项目需求小型的外包项目，给客户 A做一个产品展示网站，客户 A的朋友感觉效果不错，也希望做这样的产品展示网站，但是要求都有些不同：有客户要求以新闻的形式发布。有客户人要求以博客的形式发布。有客户希望以微信公众号的形式发布。传统方案解决网站展现项目直接复制粘贴一份，然后根据客户不同要求，进行定制修改。给每个网站租用一个空间。方案设计示意图：传统方案解决网站展现项目-问题分析需要的网站结构相似度很高，而且都不是高访问量网站，如果分成多个虚拟空间来处理，相当于一个相同网站

影院管理项目组建一个家庭影院：DVD播放器、投影仪、自动屏幕、环绕立体声、爆米花机,要求完成使用家庭影院的功能，其过程为：直接用遥控器：统筹各设备开关开爆米花机放下屏幕开投影仪开音响开 DVD，选 dvd去拿爆米花调暗灯光播放观影结束后，关闭各种设备传统方式解决影院管理在 ClientTest的 main方法中，创建各个子系统的对象，并直接去调用子系统(对象)相关方法，会造成调用过程混乱，没有清晰的过程。不利于在 ClientTest中，去维护对子系统的操作。解决思路

看一个学校院系展示需求编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系。如图：传统方案解决学校院系展示(类图)传统方案解决学校院系展示存在的问题分析将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的。实际上我们的要求是：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系，因此这种方案，不能很好实现的管理的操作，比如对学院、系的添加，删除，遍历等。3)解决方案：把学校、院、系都看

星巴克咖啡订单项目（咖啡馆）1)咖啡种类/单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)2)调料：Milk、Soy(豆浆)、Chocolate3)要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便4)使用 OO的来计算不同种类咖啡的费用:客户可以点单品咖啡，也可以单品咖啡+调料组合。方案 1-解决星巴克咖啡订单项目方案 1-解决星巴克咖啡订单问题分析Drink是一个抽象类，表示饮料。des就是对咖

手机操作问题现在对不同手机类型的不同品牌实现操作编程(比如:开机、关机、上网，打电话等)，如图:传统方案解决手机操作问题传统方法对应的类图传统方案解决手机操作问题分析扩展性问题(类爆炸)，如果我们再增加手机的样式(旋转式)，就需要增加各个品牌手机的类，同样如果我们增加 一个手机品牌，也要在各个手机样式类下增加。违反了单一职责原则，当我们增加手机样式时，要同时增加所有品牌的手机，这样增加了代码维护成本.。解决方案-使用桥接模式桥接模式(Bridge)-基本介绍基本介绍桥接模式(B

基本介绍适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本 因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)。适配器模式属于结构型模式。主要分为三类：类适配器模式、对象适配器模式、接口适配器模式。工作原理适配器模式：将一个类的接口转换成另一种接口.让原本接口不兼容的类可以兼容。从用户的角度看不到被适配者，是解耦的。用户调用适配器转化出来的目标接口方法，适配器再调用被适配者的相关接口方法。用户

盖房项目需求需要建房子：这一过程为打桩、砌墙、封顶。房子有各种各样的，比如普通房，高楼，别墅，各种房子的过程虽然一样，但是要求不要相同的。请编写程序，完成需求传统方式解决盖房需求思路分析(图解)代码实现：package com.jinxu.builder;public abstract class AbstractHouse { //打地基 public abstract void buildBasic(); //砌墙 public abstract void bui

克隆羊问题现在有一只羊 tom，姓名为: tom, 年龄为：1，颜色为：白色，请编写程序创建和 tom 羊 属性完全相同的 10 只羊。传统方式解决克隆羊问题思路分析(图解)代码演示package com.jinxu.prototype;public class Sheep { private String name; private int age; private String color; public Sheep(String name, int age, String

简单工厂模式看一个披萨的项目：要便于披萨种类的扩展，要便于维护披萨的种类很多(比如 GreekPizz、CheesePizz 等)。披萨的制作有 prepare，bake, cut, box。完成披萨店订购功能。使用传统的方式来完成思路分析(类图) 编写 OrderPizza.java 去订购需要的各种 Pizza。2.代码演示：public class OrderPizza { // 构造器// public OrderPizza() {// Pizza pizza =

单例设计模式介绍所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例， 并且该类只提供一个取得其对象实例的方法(静态方法)。比如 Hibernate 的 SessionFactory，它充当数据存储源的代理，并负责创建 Session 对象。SessionFactory 并不是 轻量级的，一般情况下，一个项目通常只需要一个 SessionFactory 就够，这是就会使用到单例模式。单例模式八种实现方式饿汉式(静态常量)饿汉式（静态代码块）懒汉式(线程不

从本篇开始就正式给大家介绍设计模式，学之前建议了解一下设计模式的原则，有助于理解每种设计模式的运用。设计模式原则回顾：设计模式原则demo示例下载1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则5.java设计模式原则——里氏替换原则6.java设计模式原则——开闭原则7.java设计模式原则——迪米特法则8.java设计模式原则——合成复用原则当我们做设计时，不仅是站在功能方面思考问题，而是站

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则5.java设计模式原则——里氏替换原则6.java设计模式原则——开闭原则7.java设计模式原则——迪米特法则8.java设计模式原则——合成复用原则设计模式demo示例下载学习完设计模式原则后，发现，很多的原则都类似，比如说单一职责原则和接口隔离原则，其实，本质上来讲，设计模式原则就是找出应用中可能需要变化之处，把它们独立出来，不

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则5.java设计模式原则——里氏替换原则6.java设计模式原则——开闭原则7.java设计模式原则——迪米特法则设计模式demo示例下载基本介绍原则是尽量使用合成/聚合的方式，而不是使用继承。图中所示，AB两个类，B类要使用A类中的三个方法，我们可以选择让B去继承A类，但是这样做有一个问题，会让A和B的耦合性增强，不利于程序的扩展

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则5.java设计模式原则——里氏替换原则6.java设计模式原则——开闭原则设计模式demo示例下载基本介绍一个对象应该对其他对象保持最少的了解。类与类关系越密切，耦合度越大。迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于 被依赖的类不管多么复杂，都尽量将逻辑封

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则5.java设计模式原则——里氏替换原则设计模式demo示例下载基本介绍开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则。一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则4.java设计模式原则——依赖倒置原则设计模式demo示例下载OO 中的继承性的思考和说明继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有 的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低

设计模式回顾：1.java设计模式2.java设计模式原则——单一职责原则3.java设计模式原则——接口隔离原则基本介绍：高层模块不应该依赖低层模块，二者都应该依赖其抽象 。抽象不应该依赖细节，细节应该依赖抽象 。依赖倒置的中心思想是面向接口编程 。依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架 构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类。使用接口或抽象类的目的是制定好规范，而不涉及

设计模式回顾：1.java设计模式2.java设计模式原则之单一职责原则接口隔离原则介绍客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。举例说明一下：类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。接口隔离原则处理方法：将接口 Interface1 拆分为独立的几个接口(这里我们拆

设计模式回顾：1.java设计模式前面介绍了java设计模式的目的和必要性，接下来就聊聊设计模式中的单一模式。基本介绍对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更 而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2。代码示例：package com.jinxu.principle.singleresponsibility;public class SingleResponsibility1 {

软件工程中，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。拿实际工作经历来说，当一个项目开发完后，如果客户提出新增功能，怎么办？如果项目开发完后，原来的工程师离职，你接手维护项目怎么办？以上两个问题，都要求我们的代码有可扩展性、维护性（可读性、规范性）特性。如果想成为合格软件工程师，研究下设计模式是非常必要的。