Java23种设计模式6大原则总结.docx

精品名师归纳总结设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计体会的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。 设计模式分类：创建型、结构型、行为型。创建型模式功能： 1.统所使用的详细类的信息封装起来。2. 类的实例是如何被创建和组织的。创建型模式作用： 1.封装创建规律,不仅仅是new 一个对象那么简洁。2. 封装创建规律变化,客户代码尽量不修改,或尽量少修改。常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。 常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观看者模式、备忘录模式、拜访者模式、状态模式、说明器模式。单一职责原就： 一个类应当只有一个职责。优点 ： 降低类的复杂性。提高类的可读性。提高代码的可爱护性和复用性。降低因变更引起的风险。里氏替换原就：优点：代码共享,削减创建类的工作量,每个子类都拥有父类的方法和属性。提高代码的可重用性。提高代码的可扩展性。提高产品或项目的开放性。缺点： 1. 继承是入侵式的。只要继承,就必需拥有父类全部属性和方法。2. 降低代码的敏捷性。子类必需拥有父类的属性和方法,使子类收到限制。3. 增强了耦合性。当父类的常量、变量和方法修改时,必需考虑子类的修改,这种修改可能造成大片的代码需要重构。可编辑资料 - - - 欢迎下载精品名师归纳总结依靠倒置原就 ：高层模块不应当依靠低层模块,两者都依靠其抽象。抽象不依靠细节。细节应当依靠于抽象。在 Java 中的表现：模块间的依靠通过抽象发生,实现类之间不发生直接的依靠关系,其依靠关系是通过接口或抽象类产生的。接口或抽象类不依靠于是实现类。 实现类依靠于接口或抽象类。接口隔离原就： 1. 一个类对另外一个类的依靠性应当是建立在最小的接口上的2. 一个接口代表一个角色,不应当将不同的角色交给一个接口。3. 不应当强迫客户使用它们的不同方法。如下列图的电子商务系统在三个的方会使用到订单类：一个是门户,只能有查询方法。一个是外部系统, 有添加订单的方法。一个是治理后台, 添加、 删除、 修改、 查询都要用到。“ 原子” 在实践中的衡量规章：1. 一个接口只对一个子模块或者业务规律进行分类。2. 只保留接口中业务规律需要的public 方法。3. 尽量修改污染了的接口,如修改的风险较大,就可采纳适配器模式进行转化处理。4. 接口设计应因项目而异,因环境而异,不能照搬教条。迪米特法就： （表述）只与你直接的伴侣们通信。不要跟“生疏人”说话。每一个软件单位对其他的单位都只有最少的明白,这些明白仅局限于那些与本单位亲密相关的软件单位。对迪米特法就进行模式设计有两个：外观模式、中介者模式。开闭原就 ：一个软件实体应当对扩绽开放,对修改关闭。重要性表达：提高复用性。提高爱护性。提高敏捷性。易于测试可编辑资料 - - - 欢迎下载精品名师归纳总结单例模式： 单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统供应这个实例单例模式。优点： 1. 在内存中只有一个实例,削减了内存的开支。2. 只生成一个实例,削减了系统的性能开销。3. 防止对资源的多重占用。4. 可以在系统设置全局的拜访点,优化和共享资源拜访。缺点： 1.无法创建子类, 扩展困难, 如要扩展, 除修改代码基本上没有其次种途径可以实现。2. 对测试不利。 3. 与单一职责原就有冲突。饿汉式单例类与懒汉式单例类之间的区分：1. 饿汉式单例类在被加载时实例化,而懒汉式单例类在第一次引用时实例化。2. 从资源利用效率上说, 饿汉式单例类要差一点,但从速度和反应时间的角度来讲, 饿汉式单例类就比懒汉式单例类稍好些。3. 饿汉式单例类可以在Java 中实现,但不易在C+ 中实现。单例模式的使用场景：1. 要求生成唯独的序列号环境。2. 在整个项目中需要一个共享拜访点或共享数据。3. 创建一个对象需要消耗的资源过多。4. 需要定义大量的静态方法的环境。使用单例模式的留意事项：1. 在使用任何 EJB 、RMI 和 JINI 的分布式系统中, 应当防止使用有状态的单例类。2. 同一个 JVM 中会有多个类加载器,当两个类加载器同时加载一个类时,会显现两个实例,此时也应当尽量防止使用有状态的单例类。可编辑资料 - - - 欢迎下载精品名师归纳总结工厂方法模式： 定义一个用于创建对象的接口,让子类打算实例化那个类。优点：良好的封装性,代码结构清楚。优秀的可扩展性。屏蔽产品类。典型的解耦框架。使用场景： 1. 工厂方法模式是new一个对象的替代品,故在全部需要生成对象的的方都可以使用, 但是需要谨慎考虑是否需要增加一个工厂类进行治理,增加代码的复杂度。2 需要敏捷的、可扩展的框架时。3. 可以用在异构项目中。4. 可以使用在测试驱动开发的框架下。抽象工厂模式： 为创建一组相关或相互依靠的对象供应一个接口,且无需指定它们的详细类。优点： 1. 产品族内的约束为非公开状态,在不同的工厂中,各种产品可能具有不同的相互依靠关系,这些依靠关系由工厂封装在其内部,对于工厂的使用者是不行见的。2. 生产线的扩展特别简洁,假如要针对同一产品族建立新的生产线,只需要实现产品族中的全部产品接口并建立新的工厂类即可。缺点： 产品族本身的扩展特别困难,假如需要在产品族中增加一个新的产品类型,就需要修改多个接口,并且会影响已有的工厂类。使用场景：当一个对象族（或是一组没有任何关系的对象）都有相同的约束。建造者 将一个复杂对象的构建与它的表示分别,使得同样的构建过程可以创建不同的表示。优点： 1. 封装性,可以使客户端不必知道产品内部组成的细节。2. 建造者独立,简洁扩3. 便于掌握细节风险。使用场景： 1. 相同的方法,不同的执行次序,产生不同的结果。2. 多个部件或零件, 都可以装配到一个对象中, 但是产生的运行结果又不相同时。3. 产品类特别复杂,或者产品类中的方法调用次序不同产生了不同的效能。4. 在对象创建过程中会使用到系统的一些其他对象,这些对象在产品对象的创建可编辑资料 - - - 欢迎下载精品名师归纳总结过程中不易得到时。原型模式： 用原型实例制定创建对象的种类,并且通过复制这些原型创建新的对象。优点：性能优良。躲避构造函数的约束。使用场景：资源优化场景。性能和安全要求场景。一个对象多个修改者的场景。结构型模式：为其他对象供应一种代理以掌握对这个对象的拜访。种类：远程代理、虚拟代理、爱护代理、缓存代理、同步代理、智能引用代理优点： 1. 职责清楚：真实的角色实现实际的业务规律,不用关怀其他非本职的事务,通过后期的代理完成附加的事务,附带的结果就是编程简洁清楚。2. 高扩展性：详细主题角色随需求不同可能有许多种,但只要实现了接口,代理类就完全可以在不做任何修改的情形下代理各种真实主题角色。3. 智能化：代理类可以在运行时才确定要去代理的真实主题,这是一种强大的功能。使用场景：代理模式的应用特别广泛,大到一个系统框架、企业平台,小到事务处理、代码片段,随处可见代理模式的使用,例如,JavaRMI的远程调用和 AOP 。装饰模式： 动态的给一个对象添加一些额外的职责。优点： 装饰类和被装饰类都可以独立进展,而不会相互耦合。 装饰模式是继承关系的一个替代方案。装饰模式可以动态的扩展一个实现类的功能。使用场景： 1. 需要扩展一个类的功能,或给一个类增加附加功能。2. 需要动态的给一个对象增加功能,这些功能可以再动态的撤销。3. 需要为一批类进行改装或加装功能。适配器模式： 将一个类的接口变换成客户端所期望的的另一种接口,从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。优点： 可以让两个没有任何关系的类在一起运行。增加了类的透亮度。提高类的复用度。增可编辑资料 - - - 欢迎下载精品名师归纳总结强代码的敏捷性。使用场景： 修改一个已经投产中的系统时,需要对系统进行扩展。此时使用一个已有类,但这个类不符合系统中的接口,这是使用适配器模式是最合适的,它可以将不符合系统接口的类进行转换,转换成符合系统接口的、可以使用的类。组合模式 ：将组合成树形结构以表示“部分-整体”的层次结构, 使得用户对单个对象和组合对象的使用具有一样性。优点：高层模块调用简洁。节点自由增加。缺点：不易掌握树枝构件的类型。不易使用继承的方法来增加新的行为。使用场景： 1. 需要描述对象的部分和整体的等级结构,如树形菜单、文件和文件夹治理。2. 需要客户端忽视个体构件和组合构件的区分,公平对待全部的构件。桥梁模式： 将抽象和现实解耦,使得两者可以独立的变化。优点： 1. 抽象和现实的分别是桥梁模式的主要特点,是为明白决继承的缺点而提出的设计模式。在该模式下,实现可以不受抽象的约束,不用绑定在一个固定的抽象层次上。2. 实现对客户的透亮,客户端不用关怀细节的实现,它已经由抽象层通过聚合关系完成了封装。使用场合： 1. 假如一个系统需要在构件的抽象化角色和详细角色之间增加更多的敏捷性,防止在两个层次之间建立静态的联系。2. 设计要求实现化角色的任何转变不应当影响客户端,或者说实现化及角色的转变对客户端是完全透亮的。3. 一个构件有多于一个抽象化角色和实现化角色,系统需要它们之间进行动态耦合。4. 不期望或不适合使用继承的场合。可编辑资料 - - - 欢迎下载精品名师归纳总结外观模式： 要求一个子系统的外部与其内部的通信必需通过一个统一的对象进行。优点： 1. 削减系统的相互依靠,全部的依靠都是对Fa .ade 对象的依靠,与子系统无关。2. 提高敏捷性,不管子系统系统内部如何变化,只要不影响Fa .ade 对象,任何活动都是自由的。3. 提高安全性, Fa.ade 中未供应的方法,外界就无法拜访,提高系统的安全性。使用场景： 1. 为一个复杂的模块或子系统供应一个供外界拜访的接口。2. 子系统相对独立,外界子系统的拜访只要黑箱操作即可。3. 预防风险扩散,使用Fa .ade 进行拜访操作掌握。享元模式： 使用共享对象可有效的支持大量的细粒度的对象。优点：大幅削减内存中对象的数量,降低程序内存的占用,提高性能。缺点：1. 增加了系统的复杂性,需要分出外部状态和内部状态,而且内部状态具有固化特性, 不应当随外部状态转变而转变,这使得程序的规律复杂化。2. 将享元对象的状态外部化,而读取外部状态使得运行时间变长。使用场景： 1. 系统中有大量的相像对象,这些对象耗费大量的内存。2. 细粒度的对象都具备较接近的外部状态,而且内部状态与环境无关,即对象没有特定身份。3. 需要缓冲池的场景。模板方法模式： 定义一个操作中的算法的框架,而将一些步骤推迟到子类中。使得子类可以不转变一个算法的结构即可重定义该算法的某些特定步骤。优点： 封装不变的部分, 扩展可变的部分。 提取公共部分代码,便于爱护。 行为由父类掌握, 子类实现。可编辑资料 - - - 欢迎下载精品名师归纳总结应用场景： 1. 多个子类有公共方法,并且规律基本相同。2. 可以把重要的、复杂的、核心算法设计为模板方法,周边的相关细节功能就由各个子类实现。3. 重构时,模板方法模式是一个常常使用的模式,将相同的代码抽取到父类中。命令模式： 将一个恳求封装成一个对象,从而让你使用不同的恳求把客户端参数化,对恳求排队或者记录恳求日志,可以供应命令的撤销和复原功能。优点：类间解耦。可扩展性。命令模式结合其他模式会更优秀。缺点：可能会导致系统中显现过多的详细命令类,因此需要在项目中谨慎考虑使用。应用场景： 1. 使用命令模式作为“回调”在面对对象系统中的替代。2. 需要在不同的时间指令恳求、将恳求排队。3. 系统需要支持的撤销（undo ）。4. 需要将系统中全部的数据更新操作储存到日志里,以便在系统崩溃时,可以根据日志读回全部的数据更新命令,重新调用execute （）方法一条一条执行这些命令,从而复原系统在崩溃前所做的数据更新。5. 一个系统需要支持交易（transaction ）。责任链模式： 使多个对象都有机会处理恳求,从而防止恳求的发送者和接受者之间的耦合关 系。将这些对象连成一条链,并沿着这条链传递该恳求, 知道有对象处理它为止。优点： 责任链模式将恳求和处理分开,恳求者不知道是谁处理的,处理者可以不用知道恳求的全貌。提高系统的敏捷性。缺点： 1.降低程序的性能, 每个恳求都是从链头遍历到链尾,当链比较长时, 性能大幅下降。2. 不易于调试,由于采纳了类似递归的方式,调试的时候规律比较复杂。应用场景：一个恳求需要一系列的处理工作。业务流的处理,例如,文件审批。对系统进行可编辑资料 - - - 欢迎下载精品名师归纳总结补充扩展。策略模式： 定义一组算法,将每个算法都封装起来,并且使他们之间可以互换。优点： 供应了治理相关算法族的方法。供应了可以替换继承关系的方法。可以防止使用多重条件转换语句。缺点： 客户端必需知道全部的策略类,并自行打算使用哪一个策略类。策略模式造成许多的策略类。应用场景： 多个类只是在算法或行为上稍有不同的场景。算法需要自由切换的场景。需要屏蔽算法规章的场景。迭代器模式： 供应一种方法拜访一个容器对象中各个元素,又不需要暴露该对象的内部细节。优点： 1. 迭代器模式简化了拜访容器元素的操作,具备一个统一的遍历接口。2. 封装遍历算法,使算法独立于集合角色。缺点： 1. 迭代器模式给使用者一个序列化的错觉,从而产生错觉。2. 迭代器的元素都是Object类型,没有类型特点。中介者模式： 用一个中介对象封装一系列对象（同事）的交互,中介者使对象不需要显式的相互作用,从而使其耦合松散,而且可以独立的转变他们之间的交互。优点： 1. 削减类间的依靠,将原有的一对多的依靠变成一对一的依靠,使得对象之间的关系更以爱护和懂得。2. 防止同事对象之间过度耦合,同事类只依靠于中介者,使同事类更易被复用,中介类和同事类可以相互独立的演化。3. 中介者模式将对象的行为和协作抽象化,将对象在小尺度的行为上与其他对象的相互作用分开处理。缺点： 1. 中介者模式降低了同事对象的复杂性,但增加了中介者类的复杂性。可编辑资料 - - - 欢迎下载精品名师归纳总结2. 中介者类常常布满了各个详细同事类的关系和谐代码,这种代码是不能复用的。留意事项：不应当在责任划分纷乱时使用。不应当对数据类和方法类使用。正确懂得封装。观看者模式： 定义对象间一种一对多的依靠关系,使得每当一个对象转变状态,就全部依靠于它的对象都会得到通知并被自动更新。优点：观看者和被观看者之间是抽象耦合。支持广播通信。缺点：1. 假如一个主题有多个直接或者间接的观看者,就通知全部的观看者会花费许多时间, 且开发和调试都比较复杂。2. 假如在主题之间有循环依靠,被观看者会触发他们间进行循环调用,导致系统崩溃。3. 假如对观看者的通知是通过另外线程进行异步投递,系统必需保证投递的顺当执行。4. 虽然观看者模式可以随时使观看者知道所观看的对象发生了变化,但是观看者模式没有供应相应的机制使观看者知道所观看的对象是如何发生变化。应用场景：关联行为场景。大事多级触发场景。跨系统的消息交换场景。留意事项：广播链的问题。异步处理的问题。备忘录模式： 在不破坏封装性的前提下,捕捉一个对象的内部状态,并在该对象之外储存这个状态。这样,以后就可以将该对象复原到原先储存的状态。应用场景： 需要储存和复原数据的相关场景状态。供应一个可回滚的操作。需要监控副本的场景。数据库连接的事务治理使用的就是备忘录模式。留意事项： 1. 备忘录的生命周期。备忘录创建出来就要在最近的代码中使用,要主动治理它的生命周期, 建立就要使用, 不使用就要马上删除其引用,等待垃圾回收器对它的回收处理。2 备忘录的性能。不要频繁建立备份的场景中使用备忘录模式。可编辑资料 - - - 欢迎下载精品名师归纳总结拜访者模式： 封装一些作用于某种数据结构中的各元素的操作,它可以在不转变数据结构的前提下定义作用于这些元素的新的操作。优点： 1. 使得增加新的操作变得很简洁,增加新的操作只需要增加新的拜访类。2. 将有关的行为集中到一个拜访者对象中,而不是分散到一个个元素类中。3. 拜访者模式可以跨过几个类的等级结构拜访属于不同等级结构的成员类。4积存状态。缺点：增加新的元素类变得困难。破坏封装。违反依靠倒置原就。应用场景： 1. 一个对象结构类有许多类对象,它们有不同的接口,当这些对象实施依靠于详细类的操作时,即使用迭代器模式不能胜任的场景下,可以采纳拜访者模式。2. 需要对一个对象结构中的对象进行许多不同且无关的操作,防止操作污染类。3. 业务要求遍历多个不同的对象, 这本身也是拜访者模式的动身点, 迭代器模式只能拜访同类或同接口的数据, 而拜访者模式是对迭代器模式的扩充, 可以遍历不同的对象,执行不同的操作。状态模式： 当一个对象内在状态转变时答应转变行为,这个对象看起来像转变了其类型优点：结构清楚。遵循设计原就。封装性特别好。缺点：子类太多,不易治理。成效： 1. 状态模式需要对每一个系统可能取得的状态创建一个状态类的子类。2. 由于每一个状态都被包装到了类里面,就可以不必采纳过程性的处理方式,使长篇累牍的条件转移语句。3. 可以在系统的不同部分使用相同的一些状态类的对象。4. 状态模式会造成大量的小状态类,但是可以使程序免于大量的条件转移语句,使程可编辑资料 - - - 欢迎下载精品名师归纳总结序实际上更易爱护。5. 系统所选的状态子类均是从一个抽象状态类或借口继承而来,JAVA 语言的特性使得在 Java 语言中使用状态模式较为完全,多态性原就是状态模式的核心。使用场景： 对象的行为依靠于它所处的状态,即行为随状态转变而转变的场景。对象在某个方法里依靠于一重或多重条件分支语句。说明器模式：给定一门语言,定义它的文法的一种表示,并定义一个说明器,该说明器使用该表示来说明语言中的句子。优点：简洁的语法分析工具。扩展性,修改语法规章只要修改相应的非终结符表达式即可, 如扩展语法,就只要增加非终结符类即可。缺点：说明器模式会引起类膨胀。采纳递归调用的方法。使用场景：重复发生的问题可以使用说明器模式。一个简洁语法需要说明的场景。可编辑资料 - - - 欢迎下载精品名师归纳总结Welcome ToDownload .欢迎您的下载,资料仅供参考！可编辑资料 - - - 欢迎下载