java设计模式选择

Java23种设计模式选择

建造模式

　　1. 须要生成的产品对象有复杂的内部结构，每个内部成分自己能够是对象，也能够仅仅是一个对象（即产品对象）的一个组成部分。

　　2. 须要生成的产品对象的属性相互依赖。建造模式能够强制实行一种分步骤进行的建造过程，所以，若是产品对象的一个属性必须在另外一个属性被赋值以后才能够被赋值，使用建造模式是一个很好的设计思想。

　　3. 在对象建立过程当中会使用到系统中的其余一些对象，这些对象在产品对象的建立过程当中不易获得。

抽象工厂模式

1.一个系统不该当依赖于产品类实例如何被建立、组合和表达的细节，这对于全部形态的工厂模式都是重要的。

　　2.这个系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

　　3.同属于同一个产品族的产品是在一块儿使用的，这一约束必须在系统的设计中体现出来。（好比：Intel主板必须使用Intel CPU、Intel芯片组）

　　4.系统提供一个产品类的库，全部的产品以一样的接口出现，从而使客户端不依赖于实现。

 

原型模式

 使用原型模式建立对象比直接new一个对象在性能上要好的多，由于Object类的clone方法是一个本地方法，它直接操做内存中的二进制流，特别是复制大对象时，性能的差异很是明显。

       使用原型模式的另外一个好处是简化对象的建立，使得建立对象就像咱们在编辑文档时的复制粘贴同样简单。

       由于以上优势，因此在须要重复地建立类似对象时能够考虑使用原型模式。好比须要在一个循环体内建立对象，假如对象建立过程比较复杂或者循环次数不少的话，使用原型模式不但能够简化建立过程，并且可使系统的总体性能提升不少。

 

单例模式

若是你的某个类在整个工程中只须要一个实例，就能够用单例模式。好比你的工程须要读取配置文件，通常状况下你会写个配置文件的类，而这个类在整个工程里只须要new一次，全部调用者都是用同一个实例，那么这个类就能够采用单例模式

 

工厂方法模式

如组装手机的代工厂。从手机原料工厂获取外壳、显示屏、主板、按键、电池等配件进行组装。组装手机工厂只负责手机的装配，而不负责配件的生产，也不须要关心从手机原料工厂出来的配件是否改变，只要手机各个配置衔接的接口不变就行。好比原料工厂显示屏从TFT 的换成了UFB的显示屏，对于组装手机的代工厂来讲，只要接口没变，只须要继续装配就行。

 

类适配器模式

当咱们要访问的接口A中没有咱们想要的方法 ，却在另外一个接口B中发现了合适的方法，咱们又不能改变访问接口A，在这种状况下，咱们能够定义一个适配器p来进行中转，这个适配器p要实现咱们访问的接口A，这样咱们就能继续访问当前接口A中的方法（虽然它目前不是咱们的菜），而后再继承接口B的实现类BB，这样咱们能够在适配器P中访问接口B的方法了，这时咱们在适配器P中的接口A方法中直接引用BB中的合适方法，这样就完成了一个简单的类适配器。

 

 

桥梁模式

  若是一个系统须要在构件的抽象化角色和具体化角色之间增长更多的灵活性，避免在两个层次之间创建静态的联系。

   设计要求实现化角色的任何改变不该当影响客户端，或者说实现化角色的改变对客户端是彻底透明的。 

一个构件有多于一个的抽象化角色和实现化角色，系统须要它们之间进行动态耦合。

   虽然在系统中使用继承是没有问题的，可是因为抽象化角色和具体化角色须要独立变化，设计要求须要独立管理这二者。 

 

装饰器模式

装饰模式(Decorate)也叫包装模式(Wrapper)

装饰模式下降系统的耦合度，能够动态的增长或删除对象的责任，并使得须要装饰的具体构建类和具体装饰类能够独立变化，以便增长新的具体构建类和具体装饰类。

 

组合模式

 引用大话设计模式的片断：“当发现需求中是体现部分与总体层次结构时，以及你但愿用户能够忽略组合对象与单个对象的不一样，统一地使用组合结构中的全部对象时，就应该考虑组合模式了。”

 

外观模式（门面模式）

1- 为复杂的模块或子系统提供外界访问的模块；

2- 子系统相互独立；

3- 在层析结构中，可使用外观模式定义系统的每一层的入口。

 

 

享元模式

享元模式因为其共享的特征，能够在任何“池”中操做，好比：线程池，数据库链接池。

String类的设计也是享元模式。

 

代理模式

当咱们想要隐藏某个类时，能够为其提供代理类。

当一个类须要对不一样的调用者提供不一样的调用权限时，可使用代理类来实现（代理类不必定只有一个，咱们能够创建多个代理类来实现，也能够在一个代理类中金进行权限判断来进行不一样权限的功能调用）。

当咱们要扩展某个类的某个功能时，可使用代理模式，在代理类中进行简单扩展（只针对简单扩展，可在引用委托类的语句以前与以后进行）。

 

责任链模式

来考虑这样一个功能:申请聚餐费用的管理。

　　不少公司都是这样的福利，就是项目组或者是部门能够向公司申请一些聚餐费用，用于组织项目组成员或者是部门成员进行聚餐活动。

　　申请聚餐费用的大体流程通常是：由申请人先填写申请单，而后交给领导审批，若是申请批准下来，领导会通知申请人审批经过，而后申请人去财务领取费用，若是没有批准下来，领导会通知申请人审批未经过，此事也就此做罢。

　　不一样级别的领导，对于审批的额度是不同的，好比，项目经理只能审批500元之内的申请；部门经理能审批1000元之内的申请；而总经理能够审核任意额度的申请。

　　也就是说，当某人提出聚餐费用申请的请求后，该请求会经由项目经理、部门经理、总经理之中的某一位领导来进行相应的处理，可是提出申请的人并不知道最终会由谁来处理他的请求，通常申请人是把本身的申请提交给项目经理，或许最后是由总经理来处理他的请求。

　　

　　可使用责任链模式来实现上述功能：当某人提出聚餐费用申请的请求后，该请求会在 项目经理—〉部门经理—〉总经理 这样一条领导处理链上进行传递，发出请求的人并不知道谁会来处理他的请求，每一个领导会根据本身的职责范围，来判断是处理请求仍是把请求交给更高级别的领导，只要有领导处理了，传递就结束了。

　　须要把每位领导的处理独立出来，实现成单独的职责处理对象，而后为它们提供一个公共的、抽象的父职责对象，这样就能够在客户端来动态地组合职责链，实现不一样的功能要求了。

 

应用模式

在下面的状况下应当考虑使用命令模式：

1）使用命令模式做为"CallBack"在面向对象系统中的替代。"CallBack"讲的即是先将一个函数登记上，而后在之后调用此函数。

2）须要在不一样的时间指定请求、将请求排队。一个命令对象和原先的请求发出者能够有不一样的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象自己仍然是活动的。这时命令的接收者能够是在本地，也能够在网络的另一个地址。命令对象能够在串形化以后传送到另一台机器上去。

3）系统须要支持命令的撤消(undo)。命令对象能够把状态存储起来，等到客户端须要撤销命令所产生的效果时，能够调用undo()方法，把命令所产生的效果撤销掉。命令对象还能够提供redo()方法，以供客户端在须要时，再从新实施命令效果。

4）若是一个系统要将系统中全部的数据更新到日志里，以便在系统崩溃时，能够根据日志里读回全部的数据更新命令，从新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所作的数据更新。

 

命令模式

1.系统须要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。

2.系统须要在不一样的时间指定请求、将请求排队和执行请求。

3.系统须要支持命令的撤销(Undo)操做和恢复(Redo)操做。

4.系统须要将一组操做组合在一块儿，即支持宏命令。

 

解释器模式

1.某个简单的语言须要解释执行而且能够将该语言中的语句表示为一个抽象语法树的时候.

2.在某些特定的领域出现不断重复的问题时,能够将该领域的问题转化为一种语法规则下的语句,并构建解释器来解释该语句.

 

 

迭代模式

1.访问一个聚合对象的内容而无需暴露它的内部表示

2.支持对聚合对象的多种遍历

3.为遍历不一样的聚合结构提供一个统一的接口

 

 

中介者模式

在面向对象编程中，一个类必然会与其余的类发生依赖关系，彻底独立的类是没有意义的。一个类同时依赖多个类的状况也至关广泛，既然存在这样的状况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可使本来凌乱的对象关系清晰，可是若是滥用，则可能会带来反的效果。通常来讲，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。能够将网状结构变为星状结构，使同事类之间的关系变的清晰一些。

       中介者模式是一种比较经常使用的模式，也是一种比较容易被滥用的模式。对于大多数的状况，同事类之间的关系不会复杂到混乱不堪的网状结构，所以，大多数状况下，将对象间的依赖关系封装的同事类内部就能够的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。

 

 

备忘录模式

适合功能比较复杂的，但须要维护或记录属性历史的功能。

数据库事务管理中的回滚操做

文本编译器中的Ctrl+z回退操做

 

观察者模式

一、 对一个对象状态的更新，须要其余对象同步更新，并且其余对象的数量动态可变。

二、 对象仅须要将本身的更新通知给其余对象而不须要知道其余对象的细节。

 

 

状态模式

State模式在实际使用中比较多，适合"状态的切换"。由于咱们常常会使用If elseif else 进行状态切换， 若是针对状态的这样判断切换反复出现，咱们就要联想到是否能够采起State模式了。

不仅是根据状态，也有根据属性。若是某个对象的属性不一样，对象的行为就不同，这点在数据库系统中出现频率比较高，咱们常常会在一个数据表的尾部，加上property属性含义的字段，用以标识记录中一些特殊性质的记录，这种属性的改变(切换)又是随时可能发生的，就有可能要使用State。

在实际使用，相似开关同样的状态切换是不少的，但有时并非那么明显，取决于你的经验和对系统的理解深度。

 

 

策略模式

许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统须要动态地在几种算法中选择一种。

当一个应用程序须要实现一种特定的服务或者功能，并且该程序有多种实现方式时使用。

一个类定义了多种行为 , 而且这些行为在这个类的操做中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

 

 

模板方法模式

在某些类的算法中，用了相同的方法，形成代码的重复。

控制子类扩展，子类必须遵照算法规则。

 在多个子类拥有相同的方法，而且这些方法逻辑相同时，能够考虑使用模版方法模式。在程序的主框架相同，细节不一样的场合下，也比较适合使用这种模式

 

访问者模式

假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操做，为了不这些操做污染这个对象，则可使用访问者模式来把这些操做封装到访问者中去。

假如一组对象中，存在着类似的操做，为了不出现大量重复的代码，也能够将这些重复的操做封装到访问者中去。