UML第二部分（2）和创建模式的总结
物理视图
许多系统模型是为了独立于最终的实现 显示系统的逻辑和设计 系统实现方面在重用 性和性能考虑上是非常重要的。UML包括了两种视图来表现实现单元：实现视图和配置视图。
实现视图显示了将可重用的系统片段物理打包成可替代的单元，称为构件。实现视图显 示采用构件、接口以及构件间依赖，对设计元素(如类)的实现，构件是用于构造系统的高层次的可重用片段。
配置视图显示了运行时段运算资源的物理分布，如计算机和它们之间的互连。它们被称 为结点。在运行时，结点可以容纳构件和对象。构件和对象在结点上的分布可以是静态的，也可在结点中转移。如果构件实例及依赖被放置在不同的结点，配置视图可以显示性能上 的瓶颈。
构件
构件具有它们所支持的接口和所需要其它构件的接口。接口是由硬件和软件块支持的操 作列表。命名接口的使用允许构件之间的直接依赖被避免，使新构件的替代更加容易。构件视图显示了构件之间依赖的网络。它具有两种形式：一种显示了一系列有效构件(构件库)以及它们的依赖性，系统从它们中被建造。它还可显示为已配置的系统，连同用于建造该系统的构件(从构件库中选取)。该形式下，每个构件与服务被使用的其它构件相连，这些连接必须与构件的接口相一致。
结点
结点是代表运行资源的运行时的物理对象，它们至少拥有内存且常常具有运算能力。结 点可能带有区别不同的资源的版型，如 CPU、设备和内存。结点可以容纳对象和构件实例。
模型管理视图
任何大系统必须被划分为较小的单元，以使人们可以在某一时刻与有限的信息工作，使 团队中的工作不相互影响。模型管理包括包(包含了特殊种类的包)和包之间的依赖关系。
包
包是一部分模型。模型的每个部分必须属于某个包。
包包含了顶层模型元素，如类、类之间的关系、状态机、用例图、交互、协作--任何没有被包括在其它元素中的事物，如属性、操作、状态、生命线、消息等包含与其它元素中的元素不直接作为包的内容。每个顶层元素在包中声明，该包是元素的“home”包。它可以被其它包引用，但它的元素内容仅由它所有。在以配置控制的系统中，建模人员必须访问home
包来修改元素内容。这为大型模型提供了访问控制机制。包也是任何版本控制机制的单元。
包的依赖
依赖由单独的元素所引发，但对于任何规模的系统，它们必须在较高的层次观察。包之 间的依赖总结了包元素之间的依赖--即包的依赖从元素个体之间的依赖派生而来。
包之间依赖的出现暗示着在自底向上的路径 (存在的声明) 中，或者允许在自顶向下的 路径 (限制了其它关系的约束) 中稍后存在着，在相应包内的元素个体间至少存在一个给 定依赖类型的关系元素。
元素个体之间的同种类的多个依赖被聚集成单个的包级别的依赖。如果元素个体间的依
赖包括版型 (如不同的用法), 该版型在包级别的依赖中被忽略以产生单一的高级别依赖。
创建型模式分为：
1.Singleton单件模式（创建型模式）：
基本动机是：由类的设计者来规范，来负责，使程序绕过常规的构造器，提供一种机制来保证一个类只有一个实例。
意图是：保证一个类仅有一个实例，并提供一个该实例的全局访问点。
代码的实现的话。。我网上查阅了一下JAVA语言的实现方法，其大致步骤都一样：
- 将该类的构造方法定义为私有方法，这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例；
- 在该类内提供一个静态方法，当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。
这里参考JAVA中实现单例模式的八种方式https://www.cnblogs.com/zhaosq/p/10135362.html
在单例模式使用中要注意：
- 可以设置protected，以允许子类派生。
- 不要支持序列化，反序列化会导致出现新的对象，与单例模式原则相违背。
- 对对象的创建与销毁要注意一下，当对象被指明要生成时再生成，不要求时可不生成。对于垃圾回收，可以交给语言机制处理。
- 对于多线程的实现要稍作变化。
单例模式的多线程实现：
- 使用静态构造器，因为静态构造器只会被执行一次。
- 同时写静态构造方法和私有构造方法。但缺点是当构造方法有参数传入时，不适用。
单例模式的拓展：
- 将一个实例扩展到n个实例，例如对象池的实现。
- 将new构造器的调用转移到其他类中，例如多个类协同工作环境中，某个局部环境只需要拥有某个类的一个实例。
- 理解和扩展Singleton模式的核心是"如何控制用户使用new对一个类的实例构造器的任意调用"。
2.Abstract Factory 抽象工厂（创建型模式）：
面临的问题是：时下你来，不能应对“具体实例化类型”的变化
解决的办法是：封装变化点——哪里变化，封装哪里。（如果没有变化则不需要额外的封装。）
工厂模式的缘起：变化点在“对象创建”，因此就封装“对象创建”，要求面向接口编程——依赖接口，而非依赖实现。
基本动机是：为了解决“一系列相互依赖的对象的创建工作”，以及多系列对象的创建工作。绕过窗轨的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。
意图是：提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定他们具体的类。
要点在于：
- 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂 完全可以。
- “系列对象”指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
- Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
- Abstract Factory模式经常和Factory Method模式共同组合 来应对“对象创建”的需求变化。
3.Builder模式（创建型模式）：
缘起：假设黄建一个房屋House设施，该房屋的构建有几个部分组成，且各个部分要富于变化。
动机：在软件系统中，有时候面临着”一个复杂对象“的创建工作，其通常由各个部分的子对象用一定算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。如何应对这种变化？如何提供一种”封装机制“来隔离出”复杂对象的各个部分“的变化。
意图：将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
要点在于：
- Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
- 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
- Abstract Factory模式解决“系列对象”的需求变 化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。
4.Factory Method 工厂方法（创建型模式）：
在软件开发过程中，要先划分模块，主模块相对稳定，也是高层部分、抽象部分，其他细节部分依赖于高层。耦合关系直接决定着软件面对变化时的行为。要做到高内聚，低耦合。
动机：在软件系统中，经常面临着”某个对象“的创建工作；由于需求的变化，这个对象经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化；如何提供一种”封装机制“来隔离出”这个易变化对象“的变化，从而保持系统中”其他以来该对象的对象“不随着需求改变而改变？
意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。
要点：
- Factory Method模式主要用于隔离类对象的使用者和具体类型之间的几个耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。
- Factory Method模式通过面向对象的手法，将索要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
- Factory Method模式解决"单个对象"的需求变化，Abstract Factory模式解决"系列对象"的需求变化，Builder模式解决"对象部分"的需求变化。
5.Prototype原型（创建型模式）：
动机：在软件系统中，经常面临着”某些结构复杂的对象“的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向”客户程序（使用这些对象的程序）“隔离出”这些易变对象“，从而使得”以来这些易变对象的客户程序“不随着需求改变而改变？
意图：使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。
Prototype模式的几个要点：
- Prototype模式同样用于隔离类对象的使用者和具 体类型（易变类）之间的耦合关系，它同样要求 这些“易变类”拥有“稳定的接口”。
- Prototype模式对于“如何创建易变类的实体对象” 采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone。
- Prototype模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或者序列化 来实现深拷贝。
