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