精华内容
下载资源
问答
  • 【《软件设计模式与体系结构》学习笔记】软件设计模式的概念软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人...

    【《软件设计模式与体系结构》学习笔记】

    软件设计模式的概念


    软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人经过大量的实践而摸索出来的,用于帮助后来者快速高效且高质从事软件开发的。

    软件设计模式的要素


    软件设计模式一般会包含四个基本要素:

    • 模式名称:此种设计模式的名字;
    • 问题:是设计者所面临的设计场景,也就是此种设计模式所适用的情况;
    • 解决方案:描述设计细节,通常会采取UML等图示的方式来进行设计模式的详细描述;
    • 效果:描述适用此设计模式的优势与劣势,包括面向软件的质量属性等。

    软件设计模式的分层


    软件设计模式根据问题的规模可以分为三个层次
    架构模式 -> 设计模式 -> 习惯用法

    1. 架构模式:描述系统级的结构组成、相互关系及相关约束,如MVC模式;
    2. 设计模式:针对系统局部设计问题给出的解决方案,一般情况下,设计模式指的就是这一层次的;
    3. 习惯用法:与具体编程语言相关的一种底层模式。

    软件设计模式的分类


    《软件设计模式与体系结构》一书中将设计模式归类如下:

    面向对象 分布式计算 企业应用软件 面向服务的体系结构(SOA)
    创建型模式 从混沌到结构 领域逻辑模式 服务设计模式
    结构型模式 分布式基础设施 数据源结构模式 服务库设计模式
    行为型模式 事件分离与分发 对象——关系行为模式 服务组合设计模式
    接口划分 对象——关系结构模式
    组件划分 对象——关系元数据映射模式
    应用控制 Web表现模式
    并发 分布模式
    同步 离线并发模式
    对象交互 会话状态模式
    适配与扩展 基本模式
    模态行为
    资源管理
    数据库访问

    感悟

    在我们日常学习中,有些时候不知不觉的应用到某些设计模式,但我们很难意识到这可以抽象为一种思想方法,并且是可以被他人当为一种模式的设计方法。所以,在以后我们又碰到类似问题时,又会重新将以前的思路再来一次,等到脑中的设计思想快成型的时候,才会恍然大悟,一拍脑门道:“哦,这个东西我好像上一次做过。”

    设计模式是前人经过验证的成功的解决方案,我们应该要善于学习,学会运用,别辜负了前辈们的心血。站在巨人的肩膀上,我们会看得更远。

    展开全文
  • 软件设计模式与体系结构 期末课后题 目录 软件设计模式与体系结构 期末课后题 第一题 金鱼缸水质、水温水位高度的软件系统 第二题 设计一个机场信息系统 第三题 说明设计与其选择原因 第四题 简答 第一题 ...

    软件设计模式与体系结构 期末课后题

    目录

    软件设计模式与体系结构 期末课后题

    第一题  金鱼缸水质、水温与水位高度的软件系统

    第二题  设计一个机场信息系统

    第三题  说明设计与其选择原因

    第四题  简答


    第一题  金鱼缸水质、水温与水位高度的软件系统

    答:

    1:设计类图如下:(若看不清原图可联系本人 )

     

    2:解释关系与功能:

          其中,Observable与Observer两个是接口类。

          鱼缸类FishbowlGUI为被观察类,它实现了接口类Observable;

          FishbowlGUI 有3个私有变量quality、temperature 和level。分别代表鱼缸的水质、水温和水位高度,同时有每个私有变量的get和set方法,来获取属性或者设置属性。

          三个观察者ChemistryGUI、TemperatureGUI和LevelGUI实现观察者接口Observer.观察者接口中,有一个方法takeAction(s:Observable)必须实现。

          各个实现接口的类在该方法中实现各自的功能:

          当quality 超过某种范围时,化学传感器ChemistryGUI排除鱼缸部分废水,补充新水;

          当temperature 低于某温度,或者超过某温度值时,TemperatureGUl开启加热设备或者冷却设备调整水温;

          当level 高于或低于特定高度时,LevelGUI 开启排水设备,排除部分水或者添加新鲜的水。

          该方法由参数传入-一个被观察者对象,一旦得到通知以后,将对被观察者类FishbowlGUI的某些方法进行调用,以便获取变化的状态。

    第二题  设计一个机场信息系统

    答:

    1:设计类图如下:

    2:

         AddObserver(Observer:Observer)方法, 将多个观察者添加到被观察者的一个list数据结构中,以便在通知观察者的时候使用; setChanged()和 notifyObservers(),通知观察者被观察者对象的状态已经改变了,同时会让观察者对象的update()方法自动运行。注意,以上两个语句的顺序是setChanged()在前,notifyObservers()在后。

    3:

        第一个参数是 Observable类型,代表被观察者对象。

        第二个参数是Object类型,代表所发生的事件,Object为被观察者的一种状态值,提供给update方法,以便更新观察者。

    4:

        VoiceInfo 类的update 完成的工作是从AiportInfo类自动获取语音机场信息,然后将这些信息传送给乘客。DisplayInfo 类的update则是负责从AirportInfo类自动获取文字机场信息,然后将这些信息显示在屏幕上。

    5:

        被观察者AirportInfo保持一个数据结构,如Java ArrayList,用于记载动态添加的观察者。

        对被观察者状态感兴趣的对象(观察者)VoiceInfo和DisplayInfo,应该调用被观察者addObserver()方法方法将自己注册为它的一个观察者。

       每当AiportInfo的状态发生改变的时候,它将使用方法setChanged0方法和notifyObservers(通知已经注册的观察者VoiceInfo 和DisplayInfo。

       当接到通知以后,VoiceInfo 和DisplayInfo都将查询AirportInfo的状态,以便保持状态同步。根据新的状态,VoiceInfo 和DisplayInfo分别执行update0方法进行相关操作。

    第三题  说明设计与其选择原因

         答:

         1.选择三层客户端-服务器(网格软件)体系结构。

         2.网格计算强调资源整合、性能、服务质量和安全性等的问题,适合需要高度的资源整理与控制能力的项目。相比之下,该项目更加强调资源的整合,相比P2P体系结构的传输速度并没有那么重要。所以选择网格软件体系结构更合适。

    第四题  简答

          1.假设已经利用结构化设计产生了一个程序结构图,现在要增加一项新的功能,结构图会有什么变化?

            答:在已经利用结构化设计产生的程序结构图中增加一-项新的功能,结构图整体并不会有多大的变化,整体仍呈现出原本的自顶向下的结构。

         2.假设已经利用面向对象设计产生了一个程序设计类图,现在要增加- -项新的功能,程序设计类图会有什么变化?

            答:由于在面向对象设计中,对象之间的交互实现困难,所以在原本的程序设计类图上增加一个新的功能,可能会打乱原有的结构图,并出现更多错综复杂的关系。

     

     

     

    展开全文
  • 软件设计模式与体系结构 课后练习1 习题如下: 解:第一题 画出该模式的设计类图: 如图1所示: 图1 设计类图 2. 解释为什么自己的设计符合开闭原则? 答:因为设计的类、模块和函数对扩展开放,对...

    软件设计模式与体系结构 课后练习1

    习题如下:

         

    解:第一题

    1. 画出该模式的设计类图:

     

    如图1所示:

                               图1 设计类图

    2.  解释为什么自己的设计符合开闭原则?

    答:因为设计的类、模块和函数对扩展开放,对修改关闭.即可以通过扩展来实现变化,而不是通过修改已有的代码来实现变化.具体为通过接口或抽象类约束扩展,对扩展进行边界限定,并且不会出现在接口或抽象类中不存在的public方法,参数类型、引用对象使用的接口或抽象类,而不是实现类,抽象层保持稳定,一旦确定不允许修改接口或抽象类一旦定义,应立即执行,不能有修改接口的想法,除非是彻底的大返工。

    解第二题

     

    1.为什么要使用策略模式?

    答:因为此软件有多种优惠收费包,不同的收费包有不同的计算方式,所以也就是说有多个条件,每个条件都要进行判断,相当于每个if条件都可以理解为一个策略,此正符合策略模式定义(即把算法的责任和算法本身分割开来,委派给不同的对象管理,最终实现解决多重if判断问题。)

    2.画出该模式的设计类图:

    如图2所示:

                                                                                      图2 设计类图

    3.解释为什么自己的设计符合开闭原则?

    答:因为设计的类、模块和函数对扩展开放,对修改关闭.即可以通过扩展来实现变化,而不是通过修改已有的代码来实现变化.具体为通过接口或抽象类约束扩展,对扩展进行边界限定,并且不会出现在接口或抽象类中不存在的public方法,参数类型、引用对象使用的接口或抽象类,而不是实现类,抽象层保持稳定,一旦确定不允许修改接口或抽象类一旦定义,应立即执行,不能有修改接口的想法,除非是彻底的大返工。

     

     

    展开全文
  • 软件体系结构与设计模式笔记

    千次阅读 2012-12-26 22:35:35
    软件体系结构与设计模式笔记 第1章软件体系结构概述 ü SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。 ü Mary Shaw和David ...

    软件体系结构与设计模式笔记

    第1章软件体系结构概述

    ü  SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。

    ü  Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。

    ü  软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。

    ü  国内普遍接受的定义:软件体系结构包括构件、连接件和约束,它是可预制和可重构的软件框架结构。

    ü 构件是可预制和可重用的软件部件,是组成体系结构的基本计算单元或数据存储单元

    ü 连接件也是可预制和可重用的软件部件,是构件之间的连接单元

    ü 构件和连接件之间的关系用约束来描述

    ü  软件体系结构 = 构件 + 连接件 + 约束

    软件体系结构的优势容易理解、重用、控制成本、可分析性

    第2章软件体系结构风格

    w  软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

    w  体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。

    w  体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。

    w  数据流风格: 批处理序列; 管道/过滤器。

    w  调用/返回风格:主程序/子程序;面向对象风格;层次结构。

    w  独立构件风格:进程通讯;事件系统。

    w  虚拟机风格:解释器;基于规则的系统。

    w  仓库风格:数据库系统;超文本系统;黑板系统。

    w  过程控制环路

    C/S风格体系结构有三个主要组成部分:数据库服务器、客户应用程序和网络。

    B/S风格浏览器/Web服务器/数据库服务器。

    优点:C/S体系结构具有强大的数据操作和事务处理能力,模型思想简单,易于人们理解和接受。将大的应用处理任务分布到许多通过网络连接的低成本计算机上,以节约大量费用。

    缺点:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一,使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用

    优点:基于B/S体系结构的软件,系统安装、修改和维护全在服务器端解决。

    缺点:B/S体系结构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能。

    B/S体系结构的系统扩展能力差,安全性难以控制。

    采用B/S体系结构的应用系统,在数据查询等响应速度上,要远远低于C/S体系结构。

    B/S体系结构的数据提交一般以页面为单位,数据的动态交互性不强,不利于在线事务处理(OLTP)应用。

    第3章软件需求与架构

    w  需求的基本概念

    ü  IEEE (1997)

    Ø (1)  用户解决问题或达到目标所需的条件或能力

    Ø (2)  系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力

    Ø (3)  一种反映上面(1)或(2)所描述的条件或能力的文档说明

    w  业务需求

    ü  反映组织机构或客户对系统、产品高层次的目标要求,通常问题定义本身就是业务需求

    w  用户需求

    ü  描述用户使用产品必须要完成什么任务,怎么完成的需求,通常是在问题定义的基础上进用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    w  系统需求

    ü  从系统的角度来说明软件的需求,包括用特性说明的功能需求、质量属性,以及其他非功能需求,还有设计约束等。

    w  非功能需求

    ü  指产品必须具备的属性或品质,如正确性、可靠性、性能、容错性和可扩展性等。

    w  功能需求

    ü  需求的主体,需求的本质

    ü  功能需求定义:系统必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作

    w  设计约束

    获取需求的方法

    ü  面谈(访谈)

    ü  问卷调查

    ü  会议(需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会)

    ü  文档研究

    ü  任务示范(观察)

    ü  用例与角色扮演

    ü  原型设计(小规模试验)研究类似公司

    需求的层次化

    ü  业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。

    ü  用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?

    ü  开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?

    需求分类

    ü  功能需求:更多体现各级直接目标要求

    ü  质量属性:运行期质量 + 开发期质量

    ü  约束需求:业务环境因素 +使用环境因素 + 构建环境因素+ 技术环境因素

    ü  功能模型——如UC

    ü  业务流程模型——如DFD

    ü  数据建模模型——如ER

    w  用例建模(Use CaseModeling)是使用用例的方法来描述系统的功能需求的过程,用例建模促进并鼓励了用户参与,这是确保项目成功的关键因素之一。

    粒度原则:

           用例要有路径,路径要有步骤。而这一切都是“可观测”的。

    ü  需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。

    w  外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。

    w  内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等

    ü  依赖注入

    w 构造注入(Constructor Injection):通过构造函数注入实例变量。

    w 设值注入(Setter Injection):通过Setter方法注入实例变量。

    w 接口注入(Interface Injection):通过接口方法注入实例变量。

    1.        用例文档

    用例编号

    用例名

    执行者

    前置条件

    后置条件

    涉众利益

    基本路径      

    ü  1…..××××

    ü  2……××××

    ü  3…..××××

    2.        需求规格说明书

     

    第1章_统一建模语言基础知识

    a)        视图(View)

                            i.             用户视图:以用户的观点表示系统的目标,它是所有视图的核心,该视图描述系统的需求。

                          ii.             结构视图:表示系统的静态行为,描述系统的静态元素,如包、类与对象,以及它们之间的关系。

                         iii.             行为视图:表示系统的动态行为,描述系统的组成元素如对象在系统运行时的交互关系。

                         iv.             实现视图:表示系统中逻辑元素的分布,描述系统中物理文件以及它们之间的关系。

                          v.             环境视图:表示系统中物理元素的分布,描述系统中硬件设备以及它们之间的关系。

    用例图(Use Case Diagram): 又称为用况图,对应于用户视图。在用例图中,使用用例来表示系统的功能需求,用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具,也称之为用例建模。

    类图(Class Diagram):对应于结构视图。类图使用类来描述系统的静态结构,类图包含类和它们之间的关系,它描述系统内所声明的类,但它没有描述系统运行时类的行为。

    w  类之间的关系

    ü  关联关系

    •      关联关系(Association)是类与类之间最常用的一种关系,它是一种结构化关系,用于表示一类对象与另一类对象之间有联系。

    •      双向关联

    •      单向关联

    •      自关联

    •      重数性关联

    ü  聚合关系

    •      聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后,再去分析这个整体类的组成结构,从而找出一些成员类,该整体类和成员类之间就形成了聚合关系。

    ü  组合关系

    •      组合关系(Composition)也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在,部分对象也将不存在,部分对象与整体对象之间具有同生共死的关系。

    ü  依赖关系

    •      依赖关系(Dependency)是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

    ü  泛化关系

    •      泛化关系(Generalization)也就是继承关系,也称为“is-a-kind-of”关系,泛化关系用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。在UML中,泛化关系用带空心三角形的直线来表示。

    ü  接口与实现关系

    •      接口之间也可以有与类之间关系类似的继承关系和依赖关系,但是接口和类之间还存在一种实现关系(Realization),在这种关系中,类实现了接口,类中的操作实现了接口中所声明的操作。在UML中,类与接口之间的实现关系用带空心三角形的虚线来表示。

    w  顺序图定义

    ü  顺序图(SequenceDiagram)是一种强调对象间消息传递次序的交互图,又称为时序图或序列图。

    w  状态图定义

    ü  状态图(StatechartDiagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

     

    第2章_面向对象设计原则

    w  单一职责原则要求在软件系统中,一个类只负责一个功能领域中的相应职责。

    w  开闭原则要求一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上扩展一个系统的行为。

    w  里氏代换原则可以通俗表述为在软件中如果能够使用基类对象,那么一定能够使用其子类对象。

    w  依赖倒转原则要求抽象不应该依赖于细节,细节应该依赖于抽象;要针对接口编程,不要针对实现编程。

    w  接口隔离原则要求客户端不应该依赖那些它不需要的接口,即将一些大的接口细化成一些小的接口供客户端使用。

    w  合成复用原则要求复用时尽量使用对象组合,而不使用继承。

    w  迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。

    第3章_设计模式概述

    w  设计模式的定义

    ü  设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

    ü  设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以下四个方面:

    w 模式名称(Pattern name)

    w 问题(Problem)

    w 解决方案(Solution)

    w 效果(Consequences)

     

    范围\目的

    创建型模式

    结构型模式

    行为型模式

    类模式

    工厂方法模式

    (类)适配器模式

    解释器模式

    模板方法模式

    对象模式

    抽象工厂模式

    建造者模式

    原型模式

    单例模式

    (对象)适配器模式

    桥接模式

    组合模式

    装饰模式

    外观模式

    享元模式

    代理模式

    职责链模式

    命令模式

    迭代器模式

    中介者模式

    备忘录模式

    观察者模式

    状态模式

    策略模式

    访问者模式

     

     

    第4章_简单工厂模式

    ü  简单工厂模式(SimpleFactory Pattern):又称为静态工厂方法(Static Factory Method)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

    ü  重构后的代码:

    public abstract class AbstractPay

    {

      public abstract void pay();

    }

    public class CashPay extends AbstractPay

    {

       public void pay()

        {

           //现金支付处理代码

        }

    }

    public class PayMethodFactory

    {

       public static AbstractPay getPayMethod(String type)

        {

           if(type.equalsIgnoreCase("cash"))

           {

               return new CashPay();       //根据参数创建具体产品

            }

            elseif(type.equalsIgnoreCase("creditcard"))

           {

               return new CreditcardPay();   //根据参数创建具体产品

           }

           ……

        }

    }

    ü  简单工厂模式最大的缺点是当有新产品要加入到系统中时,必须修改工厂类,加入必要的处理逻辑,这违背了“开闭原则”。

    ü  简单工厂模式最大的优点在于实现对象的创建和对象的使用分离,将对象的创建交给专门的工厂类负责,但是其最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码,而且产品较多时,工厂方法代码将会非常复杂。

    ü  简单工厂模式适用情况包括:工厂类负责创建的对象比较少;客户端只知道传入工厂类的参数,对于如何创建对象不关心。

     

    第5章_工厂方法模式

    ü  工厂方法模式(FactoryMethod Pattern)又称为工厂模式,也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(PolymorphicFactory)模式,它属于类创建型模式。在工厂方法模式中,工厂父类负责定义创建产品对象的公共接口,而工厂子类则负责生成具体的产品对象,这样做的目的是将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

    ü  抽象工厂类代码:

    public abstract class PayMethodFactory

    {

       public abstract AbstractPay getPayMethod();

    }

    ü  具体工厂类代码:

    public class CashPayFactory extendsPayMethodFactory

    {

       public AbstractPay getPayMethod()

        {

           return new CashPay();

        }

    }

    ü  客户类代码片段:

    PayMethodFactory factory;

    AbstractPay payMethod;

    factory=new CashPayFactory();

    payMethod =factory.getPayMethod();

    payMethod.pay();

    ü  工厂方法模式的主要优点是增加新的产品类时无须修改现有系统,并封装了产品对象的创建细节,系统具有良好的灵活性和可扩展性;其缺点在于增加新产品的同时需要增加新的工厂,导致系统类的个数成对增加,在一定程度上增加了系统的复杂性。符合开闭原则。

    ü  工厂方法模式适用情况包括:一个类不知道它所需要的对象的类;一个类通过其子类来指定创建哪个对象;将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定。

     

    第6章_抽象工厂模式

    ü  抽象工厂模式(AbstractFactory Pattern):提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。抽象工厂模式又称为Kit模式,属于对象创建型模式。

    ü  具体工厂类的典型代码如下:

    public class ConcreteFactory1 extendsAbstractFactory

    {

       public AbstractProductA createProductA()

        {

           return new ConcreteProductA1();

        }

       public AbstractProductB createProductB()

        {

           return new ConcreteProductB1();

        }

    }

    ü  抽象工厂模式的主要优点是隔离了具体类的生成,使得客户并不需要知道什么被创建,而且每次可以通过具体工厂类创建一个产品族中的多个对象,增加或者替换产品族比较方便,增加新的具体工厂和产品族很方便;主要缺点在于增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。

    ü  抽象工厂模式适用情况包括:一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节;系统中有多于一个的产品族,而每次只使用其中某一产品族;属于同一个产品族的产品将在一起使用;系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。

     

    第9章_单例模式

    ü  单例模式(SingletonPattern):单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。

    ü  单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。

     

    ü  单例模式的实现代码如下所示:

    public class Singleton

    {

             privatestatic Singleton instance=null;  //静态私有成员变量

             //私有构造函数

             privateSingleton()

             {       

             }

            

          //静态公有工厂方法,返回唯一实例

             publicstatic Singleton getInstance()

             {

                       if(instance==null)

                           instance=new Singleton();      

                       returninstance;

             }

    }

    ü  单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源;其主要缺点在于因为缺少抽象层而难以扩展,且单例类职责过重。

    ü  单例模式适用情况包括:系统只需要一个实例对象;客户调用类的单个实例只允许使用一个公共访问点。

    ü  饿汉式单例与懒汉式单例类比较

    ü 饿汉式单例类在自己被加载时就将自己实例化。单从资源利用效率角度来讲,这个比懒汉式单例类稍差些。从速度和反应时间角度来讲,则比懒汉式单例类稍好些。

    ü 懒汉式单例类在实例化时,必须处理好在多个线程同时首次引用此类时的访问限制问题,特别是当单例类作为资源控制器,在实例化时必然涉及资源初始化,而资源初始化很有可能耗费大量时间,这意味着出现多线程同时首次引用此类的机率变得较大,需要通过同步化机制进行控制。

     

     

    第10章_适配器模式

    ü  适配器模式(AdapterPattern) :将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式,也可以作为对象结构型模式。

    ü  典型的类适配器代码:

    public class Adapter extendsAdaptee implements Target

    {

             publicvoid request()

             {

                       specificRequest();

             }

    }

    ü  典型的对象适配器代码:

    public class Adapter extends Target

    {

             privateAdaptee adaptee;

            

             publicAdapter(Adaptee adaptee)

             {

                       this.adaptee=adaptee;

             }

            

             publicvoid request()

             {

                       adaptee.specificRequest();

             }

    }

    类适配器

    对象适配器

    ü  适配器模式的主要优点是将目标类和适配者类解耦,增加了类的透明性和复用性,同时系统的灵活性和扩展性都非常好,更换适配器或者增加新的适配器都非常方便,符合“开闭原则”;类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类,对象适配器模式的缺点是很难置换适配者类的方法。

    ü  适配器模式适用情况包括:系统需要使用现有的类,而这些类的接口不符合系统的需要;想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类一起工作。

     

    第14章_外观模式

    ü  外观模式(FacadePattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式又称为门面模式,它是一种对象结构型模式。

    外观模式也是“迪米特法则”

    ü  典型的外观角色代码:

    public class Facade

    {

        private SubSystemA obj1 =new SubSystemA();

        private SubSystemB obj2 =new SubSystemB();

        private SubSystemC obj3 =new SubSystemC();

        public void method()

        {

            obj1.method();

            obj2.method();

            obj3.method();

        }

    }

    w  外观模式主要优点在于对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易,它实现了子系统与客户之间的松耦合关系,并降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程;其缺点在于不能很好地限制客户使用子系统类,而且在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

    w  外观模式适用情况包括:要为一个复杂子系统提供一个简单接口;客户程序与多个子系统之间存在很大的依赖性;在层次化结构中,需要定义系统中每一层的入口,使得层与层之间不直接产生联系。

     

    第16章_代理模式

    ü  代理模式(ProxyPattern) :给某一个对象提供一个代理,并由代理对象控制对原对象的引用。代理模式的英文叫做Proxy或Surrogate,它是一种对象结构型模式。

     

    ü  典型的代理类实现代码:

    public class Proxy implements Subject

    {

        private RealSubjectrealSubject = new RealSubject();

        public void preRequest()

        {…...}

        public void request()

        {

            preRequest();

            realSubject.request();

            postRequest();

        }

        public void postRequest()

        {……}

    }

    ü  代理模式的优点在于能够协调调用者和被调用者,在一定程度上降低了系统的耦合度;其缺点在于由于在客户端和真实主题之间增加了代理对象,因此有些类型的代理模式可能会造成请求的处理速度变慢,并且实现代理模式需要额外的工作,有些代理模式的实现非常复杂。

    ü  模式适用环境

    ü  根据代理模式的使用目的,代理模式有以下几种类型(续):

    ü 保护(Protect or Access)代理:控制对一个对象的访问,可以给不同的用户提供不同级别的使用权限。

    ü 缓冲(Cache)代理:为某一个目标操作的结果提供临时的存储空间,以便多个客户端可以共享这些结果。

    ü 防火墙(Firewall)代理:保护目标不让恶意用户接近。

    ü 同步化(Synchronization)代理:使几个用户能够同时使用一个对象而没有冲突。

    ü 智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,如将此对象被调用的次数记录下来等。

     

    第23章_观察者模式

    ü  观察者模式(ObserverPattern):定义对象间的一种一对多依赖关系,使得每当一个对象状态发生改变时,其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。观察者模式是一种对象行为型模式。

     

    ü  典型的抽象目标类代码如下所示:

    import java.util.*;

    public abstract class Subject

    {

        protectedArrayList observers = new ArrayList();

             publicabstract void attach(Observer observer);

             publicabstract void detach(Observer observer);

             publicabstract void notify();

    }

    ü  典型的具体目标类代码如下所示:

    public class ConcreteSubject extendsSubject

    {

             publicvoid attach(Observer observer)

             {

                       observers.add(observer);

             }

            

             publicvoid detach(Observer observer)

             {

                       observers.remove(observer);

             }

            

             publicvoid notify()

             {

                       for(Objectobs:observers)

                       {

                                ((Observer)obs).update();

                       }

             }       

    }

    ü  典型的抽象观察者代码如下所示:

    public interface Observer

    {

             publicvoid update();

    }

    ü  典型的具体观察者代码如下所示:

    public class ConcreteObserver implementsObserver

    {

             publicvoid update()

             {

                       //具体更新代码

             }

    }

    ü  客户端代码片段如下所示:

    Subject subject = new ConcreteSubject();

    Observer observer = new ConcreteObserver();

    subject.attach(observer);

    subject.notify();

    w  观察者模式的主要优点在于可以实现表示层和数据逻辑层的分离,并在观察目标和观察者之间建立一个抽象的耦合,支持广播通信;其主要缺点在于如果一个观察目标对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间,而且如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。

    w  观察者模式适用情况包括:一个抽象模型有两个方面,其中一个方面依赖于另一个方面;一个对象的改变将导致其他一个或多个对象也发生改变,而不知道具体有多少对象将发生改变;一个对象必须通知其他对象,而并不知道这些对象是谁;需要在系统中创建一个触发链。

     

     

    ü  组合模式(CompositePattern):组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对象(即叶子对象)和组合对象(即容器对象)的使用具有一致性。

    ü  Composite Pattern: Compose objects into tree structures to representpart-whole hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.

    ü  组合模式的主要优点在于可以方便地对层次结构进行控制,客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关心自己处理的是单个对象还是整个组合结构,简化了客户端代码;其缺点在于使设计变得更加抽象,且增加新构件时可能会产生一些问题,而且很难对容器中的构件类型进行限制。

    ü  组合模式适用情况包括:需要表示一个对象整体或部分层次;让客户能够忽略不同对象层次的变化,客户端可以针对抽象构件编程,无须关心对象层次结构的细节;对象的结构是动态的并且复杂程度不一样,但客户需要一致地处理它们。

    ü  命令模式(CommandPattern):将一个请求封装为一个对象,从而使我们可用不同的请求对客户进行参数化;对请求排队或者记录请求日志,以及支持可撤销的操作。命令模式是一种对象行为型模式,其别名为动作(Action)模式或事务(Transaction)模式。

    ü  Command Pattern: Encapsulate a request as an object, thereby lettingyou parameterize clients with different requests, queue or log requests, andsupport undoable operations.

    ü  命令模式的主要优点在于降低系统的耦合度,增加新的命令很方便,而且可以比较容易地设计一个命令队列和宏命令,并方便地实现对请求的撤销和恢复;其主要缺点在于可能会导致某些系统有过多的具体命令类。

    ü  命令模式适用情况包括:需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互;需要在不同的时间指定请求、将请求排队和执行请求;需要支持命令的撤销操作和恢复操作;需要将一组操作组合在一起,即支持宏命令。

     

    ü  迭代器模式(IteratorPattern) :提供一种方法来访问聚合对象,而不用暴露这个对象的内部表示,其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。

    ü  Iterator Pattern: Provide a way to access the elements of an aggregateobject sequentially without exposing its underlying representation.

    ü  迭代器模式的主要优点在于它支持以不同的方式遍历一个聚合对象,还简化了聚合类,而且在同一个聚合上可以有多个遍历;其缺点在于增加新的聚合类需要对应增加新的迭代器类,类的个数成对增加,这在一定程度上增加了系统的复杂性。

    ü  迭代器模式适用情况包括:访问一个聚合对象的内容而无须暴露它的内部表示;需要为聚合对象提供多种遍历方式;为遍历不同的聚合结构提供一个统一的接口。

     

    ü  模板方法模式(TemplateMethod Pattern):定义一个操作中算法的骨架,而将一些步骤延迟到子类中,模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式。

    ü  Template Method Pattern: Define the skeleton of an algorithm in anoperation, deferring some steps to subclasses. Template Method lets subclassesredefine certain steps of an algorithm without changing the algorithm'sstructure.

    ü  模板方法模式的优点在于在子类定义详细的处理算法时不会改变算法的结构,实现了代码的复用,通过对子类的扩展可以增加新的行为,符合“开闭原则”;其缺点在于需要为每个不同的实现都定义一个子类,这会导致类的个数增加,系统更加庞大,设计也更加抽象

    ü  模板方法模式适用情况包括:一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现;各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复;对一些复杂的算法进行分割,将其算法中固定不变的部分设计为模板方法,而一些可以改变的细节由其子类来实现;通过模板方法模式还可以控制子类的扩展。

    ü  桥接模式(BridgePattern):将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(Interface)模式。

    ü  Bridge Pattern: Decouple an abstraction from its implementation sothat the two can vary independently.

    ü  桥接模式的主要优点是分离抽象接口及其实现部分,是比多继承方案更好的解决方法,桥接模式还提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,实现细节对客户透明,可以对用户隐藏实现细节;其主要缺点是增加系统的理解与设计难度,且识别出系统中两个独立变化的维度并不是一件容易的事情。

    ü  桥接模式适用情况包括:需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系;抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响;一个类存在两个独立变化的维度,且这两个维度都需要进行扩展;设计要求需要独立管理抽象化角色和具体化角色;不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。

     

    展开全文
  • 软件体系结构与架构五大设计模式

    千次阅读 2019-11-28 20:22:50
    五大设计模式 最关键的软件开发工具是受过良好设计原则训练的思维 一、单例模式 Singleton类定义一个个getInstance()操作,允许客户端访问他的唯一实例,getInstance()是一个静态的方法,主要创建自己的一个唯一...
  • MVC设计模式 模型层: 数据对象封装 model.bean/domain 数据库操作类 model.dao 数据库 model.db 视图层: 相关工具类 view.utils 自定义view view.ui 控制层 应用界面相关 controller.activity ...
  • 软件设计与体系结构

    千次阅读 2017-04-06 10:44:04
    学习归纳了关于软件设计与体系结构方面的知识,设计模式由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四人组(Gang of Four,Gof)在20世纪90...可复用面向对象软件的基础》,归纳了23个软件设计模式
  • 设计模式与软件体系结构【期末全整理答案】

    万次阅读 多人点赞 2020-07-13 19:01:19
    若本文对你有帮助,请点赞、关注我呦! 期末试题基本出自这些题,请提前复制黏贴到word文档里,方便考试时直接查找。 单选题汇总 ...2、常用的基本设计模式可分为(A)。 A.创建型、结构型和行为型 ...
  • 关于软件体系结构设计模式的总结

    千次阅读 2014-05-28 22:27:56
    因为软件体系结构设计模式太多了,如果用的不多,shi
  • 4、常见设计模式 5、常见JAVA框架 1、软件框架 定义 面向某领域(包括业务领域,如ERP,和计算领域,如GUI)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供一系列定义良好的可变点以保证...
  • 软件工程设计概念与体系结构设计

    千次阅读 2020-04-15 11:46:39
    软件设计和编码有什么不同? 我在编写程序是并不会设计软件,编写程序和设计软件是不同的概念。当软件质量被确定好时才会设计软件。在设计软件的时候,首要需求必须是被分析和被具体指定了。 在软件设计的过程中,...
  • 仅供参考,以下是个人的课堂笔记,只有设计模式部分,这门课的sk老师非常负责,在学生中口碑很好,如果认真听课,课后及时总结,最后会更易读懂代码的架构以及为何这样设计的原因,对编程也有很大的帮助。...
  • 设计模式 创建型设计模式是解决对象创建机制的设计模式。该类设计模式试图根据具体情况,以适当方式...结构设计模式 适配器模式 桥接模式 行为型设计模式 策略模式 状态模式 访问者模式 中介者模式 观察者模式 ...
  • 设计模式 模式的分类: 结构化分解:整体-部分模式 工作的组织:主控-从属模式 访问控制:代理模式 管理:命令处理器模式、视图处理程序模式 通信:转发器-接收器模式、 客户机-分配器-服务器模式、出版者-订阅...
  • 软件体系结构与设计-1

    千次阅读 2019-02-19 17:55:16
    软件体系结构与设计-1声明引言教材成绩设计工具案例 声明 《软件体系结构与设计》课程笔记 授课老师 周立新 引言 教材 设计模式 黑皮书 **软件构架实践 第三版 ** 参考 软件构架编档 Paul Clelments 软件体系结构 M....
  • 10个常见软件体系结构模式

    万次阅读 2018-05-07 14:06:04
    有没有想过如何设计大型企业级系统? 在开始主要软件开发之前,我们必须选择一个合适...架构模式类似于软件设计模式,但具有更广的范围。在本文中,我将简要地解释以下10种常见架构模式及其用法,优缺点。分层模式...
  • 一、软件体系结构和框架的定义软件体系结构的... 《设计模式》中对框架的定义是框架就是一组相互协作的类,对于特定的一类软件,框架构成了一种可重用的设计。软件框架是项目软件开发过程中提取特定领域软件的共性部
  • 软件体系结构基础

    千次阅读 2020-12-27 12:57:33
    体系结构的模式选择设计模式做阐述,风格选择典型的三种体系结构风格做阐述,框架选择MVC、J2EE、PCMEFPCBMER框架做阐述,同时也对特定领域的软件体系结构的类属模型、参考模型,分布式系统结构的多处理机结构、...
  • 分层体系结构模式是n层模式,其中组件被组织在水平层中。这是设计大多数软件的传统方法,并且具有独立性。这意味着所有组件都是互连的,但彼此之间不依赖。 图1:分层架构 在此体系结构中有四层,其中...
  • 1. 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能够达到体系结构级的复用。 2. 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式体系结构风格定义了一个系统家族,即一个...
  • 设计模式-结构软件设计模式(三)

    千次阅读 2017-07-14 12:37:45
    外观模式简介外观模式用来隐藏一个软件系统的所有内部细节,只提供给客户类一个外观类,或者叫做接口类。客户类直接调用该外观类的方法即可,而不必担心这些方法对其他类的调用的内部细节。外观模式角色(1)外观...
  • 软件体系结构--观察者模式

    千次阅读 2019-05-13 00:09:15
    观察者模式是对象的行为模式,又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。 观察者模式一般是一种一对多的关系,可以有...
  • 软件体系结构

    千次阅读 2014-10-30 20:28:50
    软件体系结构笔记 L1.pdf 课程简介源起... 现状系统分析员遇到的困境解决之道 基于软件体系结构的开发 示意图软件体系结构的生命周期 体系结构的非形式化描述 通常使用自然语言描述概念和...
  • 本书介绍了三种模式:体系结构模式、设计模式、惯用法。体系结构模式主要用在系统整体框架设计阶段;设计模式主要用在模块设计阶段;惯用法主要用在实际的编码阶段。体系结构模式又分成8种:分层、管道和过滤器、...
  • 软件体系结构期末考试总结

    千次阅读 多人点赞 2019-12-30 23:19:35
    对了我们的教材是《软件工程体系结构原理、方法实践(第2版)》张友生 编著的 第一章 1. 软件危机的表现: 软件成本日益增长。开发进度难以控制。软件质量差。软件维护困难 2. 软件危机的原因: 用户需求不明确。...
  • 软件体系结构风格

    千次阅读 2013-05-22 15:04:32
     软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能否达到体系结构级的软件重用。也就是说,能否在不同的软件系统中,使用同一体系结构。基于这个目的,学者们开始研究和实践软件体系结构的风格和...
  • 软件体系结构期末复习总结

    千次阅读 多人点赞 2020-08-18 21:14:41
    软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+连接件+约束 组件:...
  • 软件体系结构课程

    千次阅读 2012-11-20 17:00:52
    1.2软件体系结构风格、模式和框架 1.3软件结构的基本元素和连接 1.4软件体系结构设计的基本原则   1.1 软件体系结构的基本概念 软件体系结构软件工程的重要研究领域,软件体系结构并没有统一的定义。 90...
  • 开始复习《软件体系结构》,虽然为了考试要背诵的内容比较多,但是从软件工程到软件测试,我发现这样的课程,总可以增强自己的理解能力,更重要的是对于“软件工程”的认识。天气炎热,能静下心来复习也是一件美好的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 132,283
精华内容 52,913
关键字:

软件设计模式与体系结构