=单例模式=
单例模式需要考虑的重要问题是其生存周期问题,一种是不死鸟,永远不销毁,最为简单,但是占用了资源
另一种是有生存周期, 但是又要考虑其引用可能无效的问题
* Lifetime: Dead reference
* Double check locking
=工厂模式=
工厂模式是很常用的模式, 常见的有
*简单工厂
*抽象工厂
*工厂方法
=生成器模式=
=原型模式=
这里只是简单地用相应类图来表示, 个中滋味, 在应用中自己慢慢体会吧
相似的一点是抽象的东西有具体的实现, 至于到底用哪个具体的实现, 交给工厂来创建吧
至于这个工厂, 视问题域的复杂性,可以是抽象的, 也可以是具体的,工厂模式大体如此
General Responsibility Assignment
Software Patterns 通用职责分配软件模式
|
模式名称
|
描述（问题/解决方案)
|
|
信息专家模式Information Expert
|
问题：对象设计和职责分配的一般原则是什么？
解决方案：将职责分配给拥有履行一个职责所必需信息的类－－即信息专家。（也就是将职责分配给一个类，这个类必须拥有履行这个职责所需要的信息。）
|
|
创建者模式Creator
|
问题：谁应该负责产生类的实例（对应于GoF设计模式系列里的“工厂模式”）
解决方案：如果符合下面的一个或多个条件，则将创建类A实例的职责分配给类B.
.类B聚合类A的对象。
.类B包含类A的对象。
.类B记录类A对象的实例。
.类B密切使用类A的对象。
.类B初始化数据并在创建类A的实例时传递给类A（类B是创建类A实例的一个专家)。
在以上情况下，类B是类A对象的创建者。
|
|
控制器模式
Controller
|
问题：谁处理一个系统事件？
解决方案：当类代表下列一种情况时，为它分配处理系统事件消息的职责。
.代表整个系统、设备或子系统（外观控制器）。
.代表系统事件发生的用例场景（用例或回话控制器）。
|
|
低耦合Low Coupling
|
问题：如何支持低依赖性以及增加重用性？
解决方案：分配职责时使（不必要的）耦合保持为最低。
|
|
高内聚High Cohesion
|
问题：如何让复杂性可管理？
解决方案：分配职责时使内聚保持为最高。
|
|
多态模式Polymorphism
|
问题：当行为随类型变化而变化时谁来负责处理这些变化？
解决方案：当类型变化导致另一个行为或导致行为变化时，应用多态操作将行为的职责分配到引起行为变化的类型。
|
|
纯虚构模式Pure Fabrication
|
问题：当不想破坏高内聚和低耦合的设计原则时，谁来负责处理这些变化？
解决方案：将一组高内聚的职责分配给一个虚构的或处理方便的“行为”类，它并不是问题域中的概念，而是虚构的事务，以达到支持高内聚、低耦合和重用的目的。
|
|
中介模式Indirection
|
问题：如何分配职责以避免直接耦合？
解决方案：分配职责给中间对象以协调组件或服务之间的操作，使得它们不直接耦合。
|
|
受保护变化模式Protected Variations
|
问题：如何分配职责给对象、子系统和系统，使得这些元素中的变化或不稳定的点不会对其他元素产生不利影响？
解决方案：找出预计有变化或不稳定的元素，为其创建稳定的“接口”而分配职责。
|
这些更象是一些OOD的原则, 模式会有很多, 但是万变不离其宗, 大都遵循着一些基本的原则
-
OCP(Open-Closed Principle)
- DIP(Dependency Inversion
Principle)
-
LSP(Liskov Substitution
Principle)
- ISP(Interface Insolation
Principle)
- SRP(Single Resposibility
Principle)
- CARP(Composite/Aggregate Reuse
Principle)
- LoD(Law Of Demeter):don't talk
to stranger
之后我们来详细讨论这些原则