简述JAVA的几种设计模式

JAVA中使用设计模式写代码能使代码重用、直观、可靠，共有23种设计模式，分别是：

我们提供的服务有：网站制作、做网站、微信公众号开发、网站优化、网站认证、南城ssl等。为上千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的南城网站制作公司

创建型模式：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式；

结构型模式：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式；

行为型模式：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式，

java中几种常见的设计模式

一共23种设计模式！

按照目的来分，设计模式可以分为创建型模式、结构型模式和行为型模式。

创建型模式用来处理对象的创建过程；结构型模式用来处理类或者对象的组合；行为型模式用来对类或对象怎样交互和怎样分配职责进行描述。

创建型模式用来处理对象的创建过程，主要包含以下5种设计模式：

 工厂方法模式（Factory Method Pattern）

 抽象工厂模式（Abstract Factory Pattern）

 建造者模式（Builder Pattern）

 原型模式（Prototype Pattern）

 单例模式（Singleton Pattern）

结构型模式用来处理类或者对象的组合，主要包含以下7种设计模式：

 适配器模式（Adapter Pattern）

 桥接模式（Bridge Pattern）

 组合模式（Composite Pattern）

 装饰者模式（Decorator Pattern）

 外观模式（Facade Pattern）

 享元模式（Flyweight Pattern）

 代理模式（Proxy Pattern）

行为型模式用来对类或对象怎样交互和怎样分配职责进行描述，主要包含以下11种设计模式：

 责任链模式（Chain of Responsibility Pattern）

 命令模式（Command Pattern）

 解释器模式（Interpreter Pattern）

 迭代器模式（Iterator Pattern）

 中介者模式（Mediator Pattern）

 备忘录模式（Memento Pattern）

 观察者模式（Observer Pattern）

 状态模式（State Pattern）

 策略模式（Strategy Pattern）

 模板方法模式（Template Method Pattern）

 访问者模式（Visitor Pattern）

推荐你一本好书：《软件秘笈：设计模式那点事》，里面讲解的23中设计模式例子很生动，容易理解，还有JDK中设计模式应用情况，看了收获挺大的！百度里面搜“设计模式”，第一条中设计模式百度百科中就有首推该图书，浏览量在20几万以上的，不会错的。好东西大家一起分享！

祝你早日学会设计模式！

责任链模式（Chain of Responsibility）

描述 责任链模式（CoR）建议发出请求的对象与可能处理这个请求的对象集合之间是低耦合的（set of potential request handler objects） 在有不止一个对象可以处理或实现（fulfill）客户请求的时候 责任链模式（CoR）认为顺序地给每一个对象一次处理请求的机会 在这种情况下应用责任链模式（CoR） 把每一个可能处理请求的对象以链表的形式组织起来 在链表中 每一个对象有一个指向下一个对象的指针(Pointer) 在链表中的第一个对象接受请求并且决定是否处理它 或者把它传递给下一个对象 请求一个接一个地遍历（flow through）链表中的所有对象 直到请求被其中的一个对象处理或者因到达链表尾而没有被处理 例如 如果A?〉B?〉C都可以处理请求 按照这个顺序 A处理请求或者在不知B是否可以处理这个请求的情况下递给B 接受到请求的B可以处理这个请求或者传递给C 当C收到请求时 这个请求可以被C处理或者没有经过任何处理而结束 换句话说 提交的处理链表中的请求在到达链表尾前 可以不被任何处理 下面是责任链模式（CoR）一些重要的特征 （ ）可能处理请求的对象集合（set of potential request handler objects）以及它们在链表中的顺序是由客户端根据现应用的状态在运行时动态决定的 （ ）客户端根据现在的状态 对于不同的请求类型 可以拥有不同的可能处理请求的对象集合（set of potential request handler objects） 一个处理请求的对象也可以根据客户应用的状态和请求类型 把请求传递给不同的处理对象 为了使这些交互简单 所有的可能处理请求的对象应提供一致的接口 在JAVA中 不同处理对象可以实现一个共同的接口或者继承同一个抽象的父类来实现 （ ）客户对象初始化请求 或者在不知道这些对象是否能处理这个请求的情况下初始化任何可能处理请求的对象 也就是说 客户对象和在处理链表中的处理对象都不需要知道到底哪个对象去处理这个请求 （ ）请求不能保证被处理 也就是 在没有处理的情况下 请求已经到达了处理链表尾 下面的这个情景展示了一个购买请求传递到处理链表中 但是在到达链表尾时 并没有被接受 例子 让我们模拟一个在特定组织里的购买请求（PR）授权过程的应用 通常 在确立订单并发到卖方前 一个购买请求是需要不同的管理代表授权的 我们假定一个组织中在购买请求金额限制上分为四个授权管理层次 如下面的列表 Table : Levels of PR AuthorizationManagement Level Authorization LimitBranch Manager$ Regional Director$ Vice President$ President and COO$ 　 我们可以定义不同的类 来对应上面列表中的不同管理层次 Listing : Classes Representing Different Management Levelsclass BranchManager {static double LIMIT = ;……}//End of classclass RegionalDirector {static double LIMIT = ;……}//End of classclass VicePresident {static double LIMIT = ;……}//End of classclass PresidentCOO {static double LIMIT = ;……}//End of class让我们定义一个PurchaseRequest类 它代表购买请求 PurchaseRequestID:intdescription:Stringamount:doublegetAmount():double 　 Figure : PurchaseRequest Class RepresentationListing : PurchaseRequest Classclass PurchaseRequest {private int ID;private String description;private double amount;public PurchaseRequest(int id String desc double amt) {ID = id;description = desc;amount = amt;}public double getAmount() {return amount;}public String toString() {return ID + : + description;}}一个给定的购买请求（PR）被上面的管理代表所授权或处理 换句话说 代表不同管理层次的四个类都是处理给定购买请求的可能处理者（授权者） 因此 不建议PurchaseRequest实例榜定到任何的一个授权者 通过使用责任链模式（CoR） 实现了PurchaseRequest对象和可能授权请求的对象集合之间关联的低耦合 利用责任链模式（CoR） 让我们定义一个抽象类PRHandler 它定义这些可能授权购买请求对象的统一接口 Listing : Abstract PRHandler Classpublic abstract class PRHandler {private PRHandler nextHandler;private String handlerName;public PRHandler(String name) {handlerName = name;}public String getName() {return handlerName;}public abstract boolean authorize(PurchaseRequest request);public PRHandler getNextHandler() {return nextHandler;}public void setNextHandler(PRHandler handler) {nextHandler = handler;};} 　 Figure : Purchase Request Approver Hierarchy现在 每一个授权者被重新定义为抽象类PRHandler的子类 每一个授权对象把购买请求的金额和它所在的管理层次所授权的金额进行比较 如果请求的金额小于授权的金额 它就可以授权购买 如果大于 它传递购买请求到链表中的下一个授权者 Listing : PRHandler Concrete Subclassesclass BranchManager extends PRHandler {static double LIMIT = ;public BranchManager(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( Branch Manager + getName() + has authorized the PR ? + request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass RegionalDirector extends PRHandler {static double LIMIT = ;public RegionalDirector(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( Regional Director + getName() + has authorized the PR ? +request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass VicePresident extends PRHandler {static double LIMIT = ;public VicePresident(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( V P + getName() + has authorized the PR ? + request);return true;} else {//forward the request to the next handlerreturn getNextHandler() authorize(request);}}}//End of classclass PresidentCOO extends PRHandler {static double LIMIT = ;public PresidentCOO(String name) {super(name);}public boolean authorize(PurchaseRequest request) {double amount = request getAmount();if (amount = LIMIT) {System out println( President COO + getName() + has authorized the PR ? + request);return true;} else {System out println( PR ? + request + couldn t be authorized \n + Executive Board needs to be + consulted for approval \n + reason: Amount too large );return false;}}}//End of class为了授权购买请求 客户端需要 （ ）创建一个可能接受购买请求的授权对象集合 把他们按照授权金额升序进行排列 使用setNextHandler(PRHandler)方法 连接每一个授权者 下面是可能的授权购买请求的授权链表: 　 Figure lishixinzhi/Article/program/Java/gj/201311/27453