UML第二部分和创建型模式的总结

UML

物理视图

　　概述：UML包括了两种视图来表现实现单元：实现视图和配置视图，实现视图显示了将可重用的系统片段物理打包成可替代的单元，称为构件。配置视图显示了运行时段运算资源的物理分布，如计算机和它们之间的互连，它们被称为结点。

　　构件：构件是作为系统可替换部分，具有良好定义的接口的物理实现单元。

　　结点：结点是代表运行资源的运行时的物理对象，它们至少拥有内存且常常具有运算能力。

 

模型管理视图

　　概述：任何大系统必须被划分为较小的单元以使人们可以在某一时刻与有限的信息工作，使团队中的工作不相互影响，模型管理包括包（包含了特殊种类的包）和包之间的依赖关系。

　　包：包是一部分模型，模型的每个部分必须属于某个包。包包含了顶层模型元素。包可以包含其它的包，存在一个根包间接的包含了整个系统的模型。

　　包的依赖：依赖由单独的元素所引发，但对于任何规模的系统，它们必须在较高的层次观察，包之间的依赖总结了包元素之间的依赖，即包的依赖从元素个体之间的依赖派生而来。包之间依赖的出现暗示着在自底向上的路径中，或者允许在自顶向下的路径中稍后存在着，在相应包内的元素个体间至少存在一个给定依赖类型的关系元素。

　　访问和引入依赖：通常包不能访问其它包的内容，包是不透明的，除非被访问和引入依赖所打开。访问依赖直接应用于包和其它容器。引入依赖用于在客户包的名字空间增加名字，作为全路径的别名。

　　模型和子系统：模型是包含了系统特殊视图完整描述的包，子系统是具有独立的说明和实现部分的包。

创建型模式

　　模式分类从目的来看：

　　　　– 创建型（Creational）模式：负责对象创建。

　　　　– 结构型（Structural）模式：处理类与对象间的组合。

　　　　– 行为型（Behavioral）模式：类与对象交互中的职责分配。

　　从范围来看：　

　　　　– 类模式处理类与子类的静态关系。

　　　　– 对象模式处理对象间的动态关系。

　　单线程Singleton模式的几个要点•

　　Singleton模式中的实例构造器可以设置为protected以允 许子类派生。

　　　　• Singleton模式一般不要支持ICloneable接口，因为这可能 会导致多个对象实例，与Singleton模式的初衷违背。

　　　　• Singleton模式一般不要支持序列化，因为这也有可能导致 多个对象实例，同样与Singleton模式的初衷违背。

　　　　• Singletom模式只考虑到了对象创建的管理，没有考虑对 象销毁的管理。就支持垃圾回收的平台和对象的开销来讲，我　　　　　　　　 们一般没有必要对其销毁进行特殊的管理。

　　　　• 不能应对多线程环境：在多线程环境下，使用Singleton模 式仍然有可能得到Singleton类的多个实例对象。

 

　　Abstract Factory 抽象工厂（创建型模式）

　　　　Abstract Factory模式的几个要点•

　　　　　　如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂 完　　 全可以。

　　　　　　• Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

　　　　　　• Abstract Factory模式经常和Factory Method模式共同组合 来应对“对象创建”的需求变化。

Prototype 原型

依赖关系的倒置– 抽象A直接依赖于实现细节b抽象不应该依赖于实现细节。

　　Prototype模式的几个要点

• Prototype模式同样用于隔离类对象的使用者和具 体类型（易变类）之间的耦合关系，它同样要求 这些“易变类”拥有“稳定的接口”。

• Prototype模式对于“如何创建易变类的实体对象” 采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone。

• Prototype模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或者序列化 来实现深拷贝