第四周作业
结构型
1. Adapter 适配器
定义：“适配”即转换，在不改变原有实现的基础上，将不兼容的接口改为兼容的接口。
动机：将一个类的接口转换为客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
意图：将一个接口转换成客户希望的另一个接口。Adapter模式使得原本接口不兼容而不能在一起工作的那些可以一起工作。
角色：适配器中的几种角色：
- 目标接口（Target）： 当前系统业务所期待的接口，可以是抽象类或者接口
- 适配源类（Adaptee）： 它是被访问和适配的现存组件库中的组件接口
- 适配者类（Adapter）： 它是一个转换器，通过集成或引用适配者的对象，把适配源接口转换成目标接口，让客户按目标接口的格式访问适配者
要点：
- 这个模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁徙等方面非常有用。
- 对象适配器和类适配器。但类适配器采用“多继承”的实现方式，带来不良的高耦合性所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。
- Adapter模式非常灵活。
- Adapter模式本身要求我们尽可能地使用“面向接口的编程”风格，这样才能在后期很方便地适配。
2.Bridge桥接
定义：桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
意图：将抽象部分与现实部分分离，使它们都可以独立地变化
要点：
- Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使抽象（Tank的型号）和实现（不同的平台）可以沿着各自的维度来变化。
- Bridge模式有时候类似于多继承方案，但是多继承方案往往违 背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
- Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使 有两个变化的维度，但是某个方向的变化维度并不剧烈——换 言之两个变化不会导致纵横交错的结果，并不一定要使用 Bridge模式。
3.Composite组合模式
定义：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。
动机：客户代码过多地依赖于对象容 器复杂的内部实现结构，对象容器内部实现结构（而非抽 象接口）的变化将引起客户代码的频繁变化，带来了代码 的维护性、扩展性等弊端。
意图：将对象组合成树形结构以表示“部分-整体”的层次结 构。Composite使得用户对单个对象和组合对象的使 用具有一致性。
要点
- Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一 对多”的关系转化为“一对一”的关系，无需关心处理的是单个的对象，还是组合的对象容器。
- 将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思 想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的复 内部实现结构——发生依赖关系，从而更能“应对变化”。
- Composite模式在具体实现中，可以让父对象中的子对象反向追溯； 如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。
- Composite模式中，是将“Add和Remove等和对象容器相关的方法”定 义在“表示抽象对象的Component类”中，还是将其定义在“表示对象容 器的Composite类。
4.Decorator装饰者模式
定义：装饰者模式能够完美实现“对修改关闭，对扩展开放”的原则，也就是说我们可以在不修改被装饰者的前提下，扩展被装饰者的功能。
动机：过度上的使用继承来扩展对象的功能，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性，并且还会导致更多子类膨胀。
意图：动态地给一个对象增加一些额外的职责。就增加功 能而言，Decorator模式比生成子类更为灵活。
要点：
- 通过采用组合、而非继承的手法， Decorator模式实现了在运行时动 态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了 单独使用继承带来的“灵活性差”和“多子类衍生问题”。
- Decorator模式并非解决“多子类衍生的多继承”问题，Decorator模式 应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰” 的含义。
5.Facade外观模式
定义：外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这 些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具 体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。
动机：外观模式是一个要改变接口的模式，它改变接口的原因是为了简化接口。
意图：为一个子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这 一子系统更加容易使用。
要点
- 从客户程序的角度来看， Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客 户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Façade 接口的变化。
- Façade模式注重简化接口
- Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种 架构设计模式。
外观模式
外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客 户端可以通过它访问各个子系统的功能。
外观（Facade）模式包含以下主要角色。
- 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
- 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
- 客户（Client）角色：通过一个外观角色访问各个子系统的功能。
6.Flyweight享元模式
定义：运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经 存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。
动机：采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代
意图：通过共享技术支持大量的细粒度的对象。
要点
1.Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
2.Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。
3.对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应 用情况进行评估，而不能凭空臆断。
优缺点
优点是：相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒 度对象给内存带来的压力。
缺点是：
- 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。
- 读取享元模式的外部状态会使得运行时间稍微变长。
7.Proxy代理模式
定义：由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不 适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。
动机：实现间接访问使用者或系统结构。
意图：为其他对象提供一种代理以控制对这个对象的访问。
要点
- 增强了一层阶层，来间接访问某些对象。
- 具体proxy设计模式的实现方法、实现粒度都相差 很大，有些可能对单个对象做细粒度的控制
- 不一定要求保持接口的一致性，只要能够 实现间接控制，有时候损及一些透明性是可以接
受的。
物理视图
概述
许多系统模型是为了独立于最终的实现，显示系统的逻辑和设计。UML包括了两种视图来表现实现单元：实现视图和配置视图。
实现试图显示了将可用的系统片段物理打包成可替代的单元，称为构件。
配置视图显示了运行时段运算资源的物理分配，如计算机和它们之间的互连。它们被称为结点。
构件
构件是作为系统可替换部分，具有良好定义的接口的物理实现单元。
结点
结点是代表运行资源的运行时的物理对象，它们至少拥有内存且常常具有运算能力。结点可能带有区别不同的资源的版型，结点可以容纳对象和构件实例。
模型管理试图
概述
模型管理包括包和包之间的依赖关系。
包
包是一部分模型。模型的每个部分必须属于某个包。包包含了顶层模型元素，如类、类之间的关系、状态机、用例图、交互、协作—任何没有被包括在其它元素中的事物。
包的依赖
依赖由单独的元素所引发，但对于任何规模的系统，它们必须在较高的层次观察。包之间的依赖总结了包元素之间的依赖—即包的依赖从元素个体之间的依赖派生而来。
访问和引入依赖
通常包不能访问其他包的内容。包是不透明的，除非被访问和引入依赖所打开。访问依赖直接应用于包和其他容器。注意访问依赖不会修改客户的名字空间或以任何其他的方式自动的创建引用。引入依赖用于在客户包的名字空间增加名字，作为全路径的别名。
模型和子系统
模型是包含了系统特殊视图完整描述的包。它从某个视点为系统提供很接近的描述。
模型通常是树状结构。根包包含了组成给定视点下所有系统细节的内嵌包。
子系统是具有独立的说明和实现部分的包。它代表了与系统其它部分具有整洁接口的清晰单元。它通常代表了系统在功能或实现范围上的划分。
浙公网安备 33010602011771号