Java教程

读书笔记----软件设计原则、设计模式

本文主要是介绍读书笔记----软件设计原则、设计模式,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
所属课程 2022软件代码开发技术
作业要求 读书笔记----软件设计原则、设计模式
作业目标 1. 熟悉掌握软件设计原则、设计模式
2. 熟悉掌握markdown语法及中文排版
3. 实际运用相关技术进行实践

一、书籍详情

书名 软件秘笈:设计模式那点事
作者 郑阿奇
出版社 电子工业出版社
出版时间 2011-11
ISBN 9787121147821

二、读书笔记

1. 主要内容

此书讲述了三大类设计模式,分别为创造型模式、结构型模式及行为型模式,共计23种模式。

I. 创造型模式
创造型模式 设计原则 使用场合
工厂方法模式:定义一个创建产品对象的工厂接口,让子类决定实例化哪一种实例对象,也就是将实际创建实例对象的工作推迟到子类当中,核心工厂类不再负责具体产品的创建。 (1)“开-闭”原则:一个软件实体应对扩展开放,对修改关闭。我们在设计软件模块的时候应该使这个模块可以在不被修改的前提下被扩展。
(2) 依赖倒置原则:不论工厂还是产品都应该依赖于抽象,而不是具体的实现类。
(1)当子类型可能会有很多,以后需要不断增添不同的子类实现时;
(2)当一个系统尚在框架设计阶段,还不知道将来需要实例化哪些具体类时;
(3)系统设计之初不需要具体对象的概念(或者说没有具体对象的概念)。
抽象工厂模式:提供一个接口,用于创建相关或者依赖对象的家族,而不需要指定具体的实现类。 “开-闭”原则;多用对象组合,少用继承(不是不用);针对抽象编程,不针对实现编程;产品对象通过抽象工厂暴露的方法创建,具体工厂创建具体产品。 (1)创建产品家族,相关产品集合在一起使用的时候;
(2)想要提供一个产品类库,并只想显示其接口而不是实现时;
(3)通过组合的方式使用工厂时。
建造者模式:建造者模式将复杂对象的创建与表示分离,使得同样的构建过程可以创建不同的表示。 (1)分步骤创建复杂对象,使构建复杂对象变得不那么复杂;
(2)构建和表示分离,更好地适应外部需求的变化;
(3)单一职责原则,提高软件内部的聚合度,降低模块之间的耦合度。
(1)当生成的产品对象内部具有复杂的结构时;
(2)当复杂对象需要与表示分离,可能需要创建不同的表示时;
(3)当需要向客户隐藏产品内部结构的表现时。
原型模式:用原型实例指定创建对象的种类,并且通过复制这些原型创建新的对象。 (1)考虑产生对象的复杂度和类复用;
(2)结合系统结构考虑使用浅复制还是深复制。
(1)产生对象过程比较复杂,初始化需要许多资源时;
(2)希望框架原型和产生对象分开时;
(3)同一个对象可能会供其他调用者同时调用访问时。
单例模式:确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。 当在系统中某个特定的类对象实例只需要有一个的时候,可以使用单例设计模式。需要注意的是,只有真正有“单一实例”的需求时才可使用。
II. 结构型模式
结构型模式 设计原则 使用场合
适配器模式:把一个类的接口转换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。 (1)使用对象组合,面向接口和抽象编程;
(2)“开-闭”原则。
(1)软件系统结构需要升级或扩展,又不想影响原有系统的稳定运行的时候;
(2)转换类之间的差别不是太大的时候;
(3)想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类协同工作的时候。
桥接模式:在软件系统中,某些类型由于自身的逻辑,具有两个或多个维度的变化,如何应对这种“多维度的变化”?桥接模式使得软件系统能够轻松地沿着多个方向变化,而又不引入额外的复杂度。桥接模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化”。 (1)使用聚合关联,不使用继承关联;
(2)抽象化层次和实现化层次脱耦。
(1)不希望在抽象类和它的实现部分之间有一个固定的绑定关系;
(2)类的抽象及实现都应该可以通过生成子类的方法加以扩充;
(3)对一个抽象的实现部分的修改应对客户不产生影响,即客户的代码不必重新编译。
组合模式:将对象组合成树形结构以表示“部分-整体”的层次结构就是组合模式。组合模式使得用户对单个对象和组合对象的使用具有一致性。组合模式模糊了简单元素和复杂元素的概念,使客户程序可以像处理简单元素一样来处理复杂元素,从而使客户程序与复杂元素的内部结构解耦。 (1)统一对待个别对象和组合对象;
(2)面向抽象编程。
(1)想表示对象的“部分-整体”层次结构的时候;
(2)希望用户忽略组合对象与单个对象的不同,用户将统一使用组合结构中的所有对象的时候。
装饰者模式:装饰者模式是在不改变原类文件和使用继承的情况下,动态地扩展一个对象的功能。它是通过创建一个包装对象,也就是装饰来包裹真实的对象。 (1)封装变化部分。
(2)对扩展开放,对修改关闭。
(3)面向抽象编程,不要面向实现编程。
(4)优先使用对象组合,而非类继承。
(1)当我们需要为某个现有的对象动态地增加一个新的功能或职责时,可以考虑使用装饰模式;
(2)当某个对象的职责经常发生变化或者经常需要动态地增加职责,避免为了适应这样的变化而增加继承子类扩展的方式,因为这种方式会造成子类膨胀的速度过快,难以控制,此时可以使用装饰者模式。
外观模式:外观模式为子系统中的一组接口提供一个统一的高层接口,使子系统更容易使用。外观模式通过一个外观接口读/写子系统中各接口的数据资源,而客户可以通过外观接口读取内部资源库,不与子系统产生交互。 (1)迪米特法则——最少知识原则:一个软件实体应当尽可能少地与其他实体发生相互作用,即“只和你的密友谈话”。
(2)封装变化部分:将系统中可能发生变化的部分独立出来,进行封装。这对外部应用是完全透明的,外部应用根本感觉不到内部发生的变化。
(1)一个软件系统的复杂度比较高,需要一个更高级别的简单接口简化对子系统的操作时;
(2)当使用端与实现类之间有太多的相依性,需要降低使用端与子系统或子系统间的耦合性,增加子系统的独立性时;
(3)当子系统是相互依存的,需要层级化子系统,简化子系统之间的相依性的时候,可以使用外观模式。
享元模式:享元模式以共享的方式高效地支持大量的细粒度对象。通过复用内存中已存在的对象,降低系统创建对象实例的性能消耗。 (1)共享细粒度对象,降低内存空间;
(2)有效地隔离系统中的变化部分和不变部分。
(1)当系统中某个对象类型的实例较多的时候;
(2)在系统设计中,对象实例进行分类后,发现真正有区别的分类很少的时候。
代理模式:两个对象参与处理同一请求,接收的请求由代理对象委托给真实对象处理,代理对象控制请求的访问,它在客户端应用程序与真实目标对象之间起到一个中介桥梁的作用。 (1)延迟加载,提高系统效率;
(2)单一职责原则。
(1)远程代理(RemoteProxy)为一个对象在不同的地址空间提供局部代理。
(2)虚拟代理(VirtualProxy)中,若一个对象的创建非常耗时,可通过代理对象去调用,在真实对象创建前,返回一个假的调用,等真实对象创建好了,这时返回给客户端的就是一个真实对象的相应方法调用。
(3)保护代理(ProtectionProxy)控制对原始对象的访问。
(4)智能指引(SmartReference)取代了简单的指针,它在访问对象时执行一些附加操作。
III.行为型模式
行为型模式 设计原则 使用场合
责任链模式: 责任链模式是一种对象的行为模式。在责任链模式中,很多对象由每一个对象对其下家的引用而连接起来形成一条链。客户端应用请求在这个链上传递,直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求,这使系统可以在不影响客户端的情况下动态地重新组织链和分配责任。 (1)“开-闭”原则:责任链当中的处理节点可以动态地进行扩展。
(2)单一职责原则:每个处理节点功能单一,专注完成自身的处理行为。
(1)有多个对象处理同一个请求,具体由哪一个来处理还不确定,只有在运行时才能确定哪个对象处理的情况。
(2)消息具有多个接收者,而接收对象又是不明确的情况。只需要向其中的一个对象发出消息,由其内部具体处理。
(3)同一个消息的多个处理对象可能会动态增加或者减少,需要动态地指定的情况。
命令模式:命令模式将一个请求封装为一个对象,从而使用户可用不同的请求对客户进行参数化;将请求排队或记录请求日志,支持可撤销的操作。命令模式的根本目的在于将“请求者”与“实现者”之间解耦。 (1)“开-闭”原则。
(2)最少知识原则:在命令模式中,请求的启动者发送命令请求给具体命令,由具体命令负责发送命令消息给命令的接收者。
(1)抽象出待执行的动作以参数化某对象。类似于过程设计中的回调机制,而命令模式正是回调机制的一个面向对象的替代品。
(2)在不同的时刻指定、排列和执行请求。
(3)需要支持可撤销的操作。
(4)需要支持修改日志功能。这样当系统崩溃时,这些修改可以被重做一遍。
(5)需要支持事务系统。
解释器模式:解释器模式就是给定一个语言的文法表示,并且定义一个解释器,用来解释语言中的句子。 (1)“开-闭”原则。
(2)封装变化部分。
(1)一种特定类型的问题发生的频率足够高,并且业务规则频繁变化,不断重复出现类似情况。
(2)业务规则不是过于复杂烦琐,比较容易抽象出语法规则。
(3)效率不是软件系统中主要考虑的因素。
迭代器模式:提供了一种模式顺序访问一个集合对象中的各个元素功能,而又不暴露其内部的表示。 (1)“开-闭”原则。
(2)单一职责原则。
(1)访问一个集合对象的内容,而无须暴露它的内部表示;
(2)支持对集合对象的多种遍历方式;
(3)为遍历不同的集合对象结构提供一个统一的接口。
中介者模式:用一个中介对象来封装一系列对象之间的交互,使各个对象中不需要显式地引用其他对象实例,从而降低各个对象之间的耦合度,并且可以独立地改变对象间的交互关系。 (1)一对多的对象依赖转化为一对一依赖;
(2)集中控制提高类的复用性。
(1)一组对象以定义良好但是复杂的方式进行通信,产生的相互依赖关系结构混乱且难以理解。注意是多个对象之间相互依赖。
(2)想定制一个分布在多个类中的行为,而不想生成太多的子类的场合。
(3)产品架构的研发,更需要易于扩展的场合。
备忘录模式:备忘录模式是在不破坏封闭的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。 (1)封装边界的保持;
(2)双重接口实现,保证安全性。
(1)需要在某一时刻恢复一个对象先前的状态时;
(2)需要在外部保存对象某一时刻的状态,但如果用一个接口来让其他对象直接得到这些状态,将会暴露对象的实现细节并破坏对象的封装性。
观察者模式:观察者模式又称为发布/订阅模式,它是软件设计模式中的一种。观察者模式定义了对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。 (1)“开-闭”原则。
(2)单一职责原则。
(3)依赖倒置原则。
(1)当一个抽象模型有两个方面,其中一个方面依赖于另一个方面,需要将这两个方面分别封装到独立的对象中,彼此独立地改变和复用的时候;
(2)当一个系统中一个对象的改变需要同时改变其他对象内容,但是又不知道待改变的对象到底有多少个的时候;
(3)当一个对象的改变必须通知其他对象做出相应的变化,但是不能确定通知的对象是谁的时候。
状态模式:当一个对象的内在状态改变时允许改变其行为,这个对象看起来就像是改变了其类。 (1)“开-闭”原则。
(2)单一职责原则。
(1)一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变其行为;
(2)一个操作中含有庞大的多分支结构,并且这些分支决定于对象的状态。
策略模式:定义一系列的算法,将每一种算法封装起来并可以相互替换使用,策略模式让算法独立于使用它的客户应用而独立变化。 (1)“开-闭”原则。
(2)单一职责原则。
(1)当多个类的表现行为不同,需要在运行时动态选择具体要执行的行为的时候;
(2)需要在不同情况下使用不同的策略(算法),或者策略还可能在未来用其他方式实现的时候;
(3)需要隐藏具体策略(算法)的实现细节,各个具体策略(算法)彼此独立的时候;
(4)当一个类中出现了多种行为,而且在一个操作中使用多个条件分支来判断使用多种行为的时候,可以使用策略模式将各个条件分支的动作植入具体策略中实现。
模板方法模式:定义一个操作中的算法骨架,而将一些实现步骤延迟到子类当中。模板方法模式使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。 (1)“开-闭”原则。
(2)好莱坞原则:允许低层组件将自己挂钩到高层组件的算法过程中,什么时候去调用,则按照高层的处理逻辑决定。有效避免了系统环状依赖。
(1)一次性实现一个算法不变的部分,并将可变的行为留给子类来实现;
(2)各子类中具有公共行为的时候,应被提取出来并集中到一个公共父类中以避免代码重复;
(3)当需要控制子类扩展的时候。模板方法在特定点调用钩子操作,这样就只允许在这些点进行扩展。
访问者模式:访问者模式是表示一个作用于某对象结构中的各元素的操作,它使用户可以在不改变各元素类的前提下定义作用于这些元素的新操作。 (1)“开-闭”原则。
(2)单一职责原则。
(1)如果在一个对象结构中包含很多不同类型对象,它们有不同的接口,而想对这些不同对象实施一些依赖于其具体类的操作。
(2)需要对一个对象结构中的对象进行很多不同的并且不相关的操作,而想避免让这些操作与这些对象的类关联起来。访问者模式使得可以将相关的操作集中起来,单独定义在一个类中。
(3)当该对象结构被很多应用共享时,用访问者模式让每个应用仅包含需要用到的操作。
(4)定义对象结构的类很少改变,但经常需要在此结构上定义新的操作。

2. 实际运用

实际开发中,笔者使用过工厂方法模式,工厂方法设计模式在很多场合都有应用,使用得非常广泛,如在Java SDK中就存在工厂方法设计模式的影子。例如:java.util.List、java.util.LinkedList、java.util.ArrayList就应用了工厂方法设计模式。DAO模式中也使用了工厂方法模式。

3. 心得体会

《软件秘笈:设计模式那点事》使用了通俗的语言讲述了软件设计原则及设计模式,并且图文并茂,让读者阅读起来,不觉得乏味。通过对软件设计原则、设计模式的学习,笔者对软件开发有了进一步的了解,在今后的软件开发中,我将使用这些方法进行设计,软件系统的结构也会更清晰,管理也更方便。

三、截图

这篇关于读书笔记----软件设计原则、设计模式的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!