本文介绍“Principles of OOD”中的接口分隔原则：Interface Segregation Principle (ISP)。

可以从这里查看Interface Segregation Principle (ISP)的原文。
概要
Clients should not be forced to depend upon interfaces that they do not use.
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
它包含了2层意思：
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。
如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口。
- 接口的依赖（继承）原则：如果一个接口a依赖（继承）另一个接口b，则接口a相当于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包含用户不使用的方法。
反之，则说明接口a被b给污染了，应该重新设计它们的关系。
如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。这显然违反了开闭原则，也不是我们所期望的。
下面我们举例说明怎么设计接口或类之间的关系，使其不违反ISP原则。
假如有一个Door，有lock，unlock功能，另外，可以在Door上安装一个Alarm而使其具有报警功能。用户可以选择一般的Door，也可以选择具有报警功能的Door。
有以下几种设计方法：
ISP原则的违反例：
方法一：
在Door接口里定义所有的方法。图：

但这样一来，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。
方法二：
在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法，Door接口继承Alarm接口。

跟方法一一样，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。
遵循ISP原则的例：
方法三：通过多重继承实现

在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法。接口之间无继承关系。CommonDoor实现Door接口，
AlarmDoor有2种实现方案：
1），同时实现Door和Alarm接口。
2），继承CommonDoor，并实现Alarm接口。该方案是继承方式的Adapter设计模式的实现。
第2）种方案更具有实用性。
这种设计遵循了ISP设计原则。
方法四：通过委让实现

这种方法其实是委让方式的Adapter设计模式的实现。
在这种方法里，AlarmDoor实现了Alarm接口，同时把功能lock和unlock委让给CommonDoor对象完成。
这种设计遵循了ISP设计原则。
小结
Interface Segregation Principle (ISP)从对接口的使用上为我们对接口抽象的颗粒度建立了判断基准：在为系统设计接口的时候，使用多个专门的接口代替单一的胖接口。
依赖倒置原则Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍DIP：Dependency Inversion Principle – 依赖倒置原则。
有关Dependency Inversion Principle (DIP) 原文可以从这里 得到。
该文提出了依赖倒置原则的2个重要方针：
A. High level modules should not depend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
中文意思为：
A. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
B. 抽象不应该依赖于细节，细节应该依赖于抽象
概念解说：
依赖：在程序设计中，如果一个模块a使用/调用了另一个模块b，我们称模块a依赖模块b。
高层模块与低层模块：往往在一个应用程序中，我们有一些低层次的类，这些类实现了一些基本的或初级的操作，我们称之为低层模块；另外有一些高层次的类，这些类封装了某些复杂的逻辑，并且依赖于低层次的类，这些类我们称之为高层模块。
为什么叫做依赖倒置（Dependency Inversion）呢？
面向对象程序设计相对于面向过程（结构化）程序设计而言，依赖关系被倒置了。因为传统的结构化程序设计中，高层模块总是依赖于低层模块。
问题的提出：
Robert C. Martin氏在原文中给出了“Bad Design”的定义：
1. It is hard to change because every change affects too many other parts of the system.
(Rigidity)
系统很难改变，因为每个改变都会影响其他很多部分。
2. When you make a change, unexpected parts of the system break. (Fragility)
当你对某地方做一修改，系统的看似无关的其他部分都不工作了。
3. It is hard to reuse in another application because it cannot be disentangled from
the current application. (Immobility)
系统很难被另外一个应用重用，因为你很难将要重用的部分从系统中分离开来。
导致“Bad Design”的很大原因是“高层模块”过分依赖“低层模块”。
一个良好的设计应该是系统的每一部分都是可替换的。
如果“高层模块”过分依赖“低层模块”，一方面一旦“低层模块”需要替换或者修改，“高层模块”将受到影响；另一方面，高层模块很难可以重用。
比如，一个Copy模块，需要把来自Keyboard的输入复制到Print，即使对Keyboard和Print的封装已经做得非常好，但如果Copy模块里直接使用Keyboard与Print，Copy任很难被其他应用环境（比如需要输出到磁盘时）重用。
问题的解决：
为了解决上述问题，Robert C. Martin氏提出了OO设计的Dependency Inversion Principle (DIP) 原则。
DIP给出了一个解决方案：在高层模块与低层模块之间，引入一个抽象接口层。
High Level Classes（高层模块） –> Abstraction Layer（抽象接口层） –> Low Level Classes（低层模块）
抽象接口是对低层模块的抽象，低层模块继承或实现该抽象接口。
这样，高层模块不直接依赖低层模块，高层模块与低层模块都依赖抽象接口层。
当然，抽象也不依赖低层模块的实现细节，低层模块依赖（继承或实现）抽象定义。
Robert C. Martin氏给出的DIP方案的类的结构图：

PolicyLayer–>MechanismInterface(abstract)–MechanismLayer–>UtilityInterface(abstract)–UtilityLayer
类与类之间都通过Abstract Layer来组合关系。
里氏替换原则Robert C. Martin氏为我们总结了在面向对象的设计（OOD）中应该遵循的原则，这些原则被称为“Principles of OOD”，关于“Principles of OOD”的相关文章可以从Object Menter得到。

本文介绍“Principles of OOD”中的里氏替换原则：Liskov Substitution Principle (LSP)。

可以从这里查看Liskov Substitution Principle (LSP)的原文 。
里氏替换原则LSP的概念解说
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。也就是说，只有满足以下2个条件的OO设计才可被认为是满足了LSP原则：
- 不应该在代码中出现if/else之类对子类类型进行判断的条件。以下代码就违反了LSP定义。
if (obj typeof Class1) {
do something
} else if (obj typeof Class2) {
do something else
}
- 子类应当可以替换父类并出现在父类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的子类所代替，代码还能正常工作。
里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：
- 类的继承原则：如果一个继承类的对象可能会在基类出现的地方出现运行错误，则该子类不应该从该基类继承，或者说，应该重新设计它们之间的关系。
- 动作正确性保证：从另一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。
类的继承原则：
Robert C. Martin氏在介绍Liskov Substitution Principle (LSP)的原文里，举了Rectangle和Square的例子。这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要部分来说明 里氏替换原则 对类的继承上的约束。
代码：

这里Rectangle是基类，Square从Rectangle继承。
这种继承关系有什么问题吗？
假如已有的系统中存在以下既有的业务逻辑代码：

void g(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
if (r.getWidth() * r.getHeight() != 20) {
throw new RuntimeException();
}
}
则对应于扩展类Square，在调用既有业务逻辑时：

Rectangle square = new Square();
g(square);
时会抛出一个RuntimeException异常。这显然违反了LSP原则。
动作正确性保证：
因为LSP对子类的约束，所以为已存在的类做扩展构造一个新的子类时，根据LSP的定义，不会给已有的系统引入新的错误。
Design by Contract
根据Bertrand Meyer氏提出的Design by Contract（DBC：基于合同的设计）概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。
现在把前提条件以及后续条件应用到继承子类中，子类方法应该满足：
1）前提条件不强于基类．
2）后续条件不弱于基类．
换句话说，通过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。同样，继承类必须顺从基类的所有后续条件，亦即，继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。
这样，我们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。
在很多情况下，在设计初期我们类之间的关系不是很明确，LSP则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。
参考资料：
Liskov Substitution Principle (LSP)的原文

© 我想网 Akon 所有 , 2010. | 永久链接 | 没有评论 | 提交到 Google Reader 鲜果 抓虾

您可能会感兴趣的其他文章

• 适配器模式
• 软件开发者的软实力：沟通与协作－《程序员》官网
• 设计模式之单例模式
• 解码 Web 开发语言
• 给敏捷软件开发的26条建议
• 程序在内存中运行的奥秘
• 程序员的八种境界
• 程序员应该为这样的代码感到惭愧
• 程序员失业后应做的五件事
• 献给计算机专业的同学

Feed enhanced by Better Feed from Ozh

要点：

1． 适配器模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。

2． 适配器模式有对象适配器和类适配器两种形式的实现结构，但是类适配器采用“多继承”的实现方式，带来了不良的高耦合，所以一般不推荐使用。对象适配器采用 “对象组合”的方式，更符合松耦合精神。

实现：

类的适配器模式结构图（继承）

对象的适配器模式结构图（组合）

（对象适配器的代码实现）

Target：定义Client使用的与特定领域相关的接口

public interface Target
{
    void request();
}

Adaptee：现在需要适配的已经存在的接口

public class Adaptee
{
    public void specificRequest(){}
}

Adapter：对Adaptee 的接口与Target接口进行适配

public class Adapter implements Target
{
    public Adapter(Adaptee adaptee)
    {
        super();
        this.adaptee = adaptee;
    }

    public void request()
    {
        adaptee.specificRequest();
    }

    private Adaptee adaptee;
}

适用性：

1. 系统需要使用现有的类，而此类的接口不符合系统的需要。

2. 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。这些源类不一定有很复杂的接口。

3. （对对象适配器而言）在设计里，需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。

效果及优缺点：

对于类适配器：

1. 用一个具体的Adapter类对Adaptee和Taget进行匹配。结果是当我们想要匹配一个类以及所有它的子类时，类Adapter将不能胜任工作。

2. 使得Adapter可以override（重定义） Adaptee的部分行为，因为Adapter是Adaptee的一个子类。

对于对象适配器：

1. 允许一个Adapter与多个Adaptee，即Adaptee本身以及它的所有子类（如果有子类的话）同时工作。Adapter也可以一次给所有的 Adaptee添加功能。

2. 使得override（重定义）Adaptee的行为比较困难。如果一定要override Adaptee的方法，就只好先做一个Adaptee的子类以override Adaptee的方法，然后再把这个子类当作真正的Adaptee源进行适配。

© 我想网 Akon 所有 , 2010. | 永久链接 | 没有评论 | 提交到 Google Reader 鲜果 抓虾

您可能会感兴趣的其他文章

• 设计模式之单例模式
• 类的设计原则
• JavaScript事件设计模式

Feed enhanced by Better Feed from Ozh

我们在浏览BBS、SNS网站的时候，常常会看到“当前在线人数”这样的一项内容。对于

这样的一项功能，我们通常的做法是把当前的在线人数存放到一个内存、文件或者数据库中，每次用户登录的时候，就会马上从内存、文件或者数据库中取出，在其基础上加1后，作为当前的在线人数进行显示，然后再把它保存回内存、文件或者数据库里，这样后续登录的用户看到的就是更新后的当前在线人数；同样的道理，当用户退出后，当前在线人数进行减1的工作。所以，对于这样的一个需求，我们按照面向对象的设计思想，可以把它抽象为“在线计数器”这样一个对象，具体实现如下：

Java代码：

//在线人数计数器

class OnlineCounter {

//在线人数

private int onlineCount = 0;

//构造函数

public OnlineCounter(){

//从文件或者数据库读取数据,假如读出来的数据是100

this.onlineCount = 100;

}

//在用户登录后，在线人数加1

public void incCount(){

this.onlineCount++;

}

//在用户退出后，在线人数减1

public void decCount(){

this.onlineCount–;

}

//保存在线人数

public void saveCount(){

}

//获取在线人数

public int getCount(){

return onlineCount;

}

//测试函数

public static void main(String[] args) {

try{

OnlineCounter onlineCounter = new OnlineCounter();

System.out.println(“在线人数：” +onlineCounter.getCount());

onlineCounter.incCount();

System.out.println(“在线人数：” + onlineCounter.getCount());

onlineCounter.decCount();

System.out.println(“在线人数：” + onlineCounter.getCount());

}catch(Exception err){

}

}

}

.Net代码：

//在线人数计数器

class OnlineCounter{

//在线人数

private int onlineCount = 0;

//构造函数

public OnlineCounter(){

//从文件或者数据库读取数据,假如读出来的数据是100

this.onlineCount = 100;

}

//在用户登录后，在线人数加1

public void incCount(){

this.onlineCount++;

}

//在用户退出后，在线人数减1

public void decCount(){

this.onlineCount–;

}

//保存在线人数

public void saveCount(){

return onlineCount;

}

//获取在线人数

public int getCount(){

return onlineCount;

}

//测试函数

public static void Main(string[] args) {

OnlineCounter onlineCounter = new OnlineCounter();

Console.WriteLine(“在线人数：” + onlineCounter.getCount());

onlineCounter.incCount();

Console.WriteLine(“在线人数：” + onlineCounter.getCount());

onlineCounter.decCount();

Console.WriteLine(“在线人数：” + onlineCounter.getCount());

}

}

Php代码：

//在线人数计数器

class OnlineCounter {

//在线人数

private $onlineCount = 0;

//构造函数

public function __construct(){

//从文件或者数据库读取数据,假如读出来的数据是100

$this->onlineCount = 100;

}

//在用户登录后，在线人数加1

public function incCount(){

$this->onlineCount++;

}

//在用户退出后，在线人数减1

public function decCount(){

$this->onlineCount–;

}

//保存在线人数

public function saveCount(){

}

//获取在线人数

public function getCount(){

return $this->onlineCount;

}

//测试函数

public static function execute() {

$onlineCounter = new OnlineCounter();

echo “在线人数：” . $onlineCounter->getCount();

$onlineCounter->incCount();

echo “在线人数：” . $onlineCounter->getCount();

$onlineCounter->decCount();

echo “在线人数：” . $onlineCounter->getCount();

}

}

OnlineCounter::execute();

?>

运行结果如下：

在线人数：100

在线人数：101

在线人数：100

网站代码中凡是用到计数器的地方，只要new一个计数器对象，然后就可以获取、保存、增加或者减少在线人数的数量。不过，我们的代码实际的使用效果并不好。假如有多个用户同时登录,那么在这个时刻，通过计数器取到的在线人数是相同的，于是他们使用各自的计数器加1后存入文件或者数据库。这样操作后续登陆的用户得到的在线人数，与实际的在线人数并不一致。所以，把这个计数器设计为一个全局对象，所有人都共用同一份数据，就可以避免类似的问题，这就是我们所说的单例模式的其中的一种应用。
2 什么是单例模式

单例模式能够保证一个类仅有唯一的实例，并提供一个全局访问点。

我们是不是可以通过一个全局变量来实现单例模式的要求呢？我们只要仔细地想想看，全局变量确实可以提供一个全局访问点，但是它不能防止别人实例化多个对象。通过外部程序来控制的对象的产生的个数，势必会系统的增加管理成本，增大模块之间的耦合度。所以，最好的解决办法就是让类自己负责保存它的唯一实例，并且让这个类保证不会产生第二个实例，同时提供一个让外部对象访问该实例的方法。自己的事情自己办，而不是由别人代办，这非常符合面向对象的封装原则。

按照以上的思路，我们可以这样来设计单例类：

Java代码:

class Singleton {

// 私有的静态对象

private static Singleton instance = null;

//私有的构造方法

private Singleton (){

}

// 公开的静态工厂方法,返回此类的唯一实例

public static Singleton getInstance(){

if(instance == null){

instance = new Singleton();

}

return instance;

}

}

.Net代码：

class Singleton{

// 私有的静态对象

private static Singleton instance = null;

//私有的构造方法

private Singleton(){

}

//公开的静态工厂方法,返回此类的唯一实例

public static Singleton getInstance(){

if (instance == null){

instance = new Singleton();

}

return instance;

}

}

Php代码：

class Singleton {

// 私有的静态对象

private static $instance = null;

//私有的构造方法

private function __construct(){

}

// 公开的静态工厂方法,返回此类的唯一实例

public static function getInstance(){

if(self::$instance == null){

self::$instance = new Singleton();

}

return self::$instance;

}

}

?>

Singleton类含有一个instance的私有静态变量,用来保存该类唯一的实例对象，它对于外部对象是不可见的，只能通过getInstance方法才能获得。

Singleton类的构造器是private私有的，外部对象无法通过它的构造器生成实例，也就是说外部程序试图通过new操作符来创建实例是行不通的，因此，getInstance方法成为获得Singleton类实例的唯一途径。

getInstance方法的设计非常简单，它首先检测instance变量是否已经初始化，如果没有被初始化，就创建一个实例保存到instance变量，最后返回这个实例；如果这个实例已经被初始化，那么就直接返回这个实例。

getInstance方法的设计非常简单，它首先检测instance变量是否已经初始化，如果没有被初始化，就创建一个实例保存到instance变量，最后返回这个实例；如果这个实例已经被初始化，那么就直接返回这个实例。

单例模式的类图

单例模式主要有3个特点，：

1、单例类确保自己只有一个实例。

2、单例类必须自己创建自己的实例。

3、单例类必须为其他对象提供唯一的实例。
3 安全的单例模式：双重检查锁定机制

我们虽然实现了单例模式，但是目前的解决办法并不安全，依然存在着一定的缺陷：

class Singleton {

private static Singleton instance = null;

private Singleton (){

}

public static Singleton getInstance(){

if(instance == null){

instance = new Singleton();

}

return instance;

}

}

这段代码意图通过检查if (instance == null)这个条件，来保证只创建一个Singleton实例。事实上，它运行在单线程环境中，得到的结果是正确的，没有问题，但是运行在多线程的环境中，它就会出现错误，可能有多个Singleton实例被创建出来。

我们分析一下，在多线程环境中，可能会出现这样的情形：线程A 和线程B几乎同时到达if (instance == null)语句，假设线程A 比线程B 早一点点，那么：

（1）A 会首先进入if (instance == null)块的内部，并开始执行new Singleton () 语句。此时，instance变量仍然是null，直到线程A 的new Singleton () 语句返回，并给instance变量赋值为止。

（2） 但是，此时的线程B 并不会在if (instance == null)语句的外面等待，因为此时(instance == null)是成立的，它会马上进入if (instance == null)语句块的内部。这样，线程B 会不可避免地执行instance=new Singleton()语句，从而创建出第二个实例来。

（3）线程A 的instance=new Singleton()语句执行完毕后，instance变量得到了真实的对象引用，(instance == null)不再为真。所以，后来的线程就不会再进入if (instance == null) 语句块的内部了。

（4）线程B 的instance=new Singleton()语句也执行完毕后，instance变量的值被覆盖。但是第一个instance对象被线程A 引用的事实已经无法改变了。这时候的线程A和B各自拥有一个独立的Singleton对象。

为了实现线程安全，我们对代码进行了一定的改造：

Java代码：

class Singleton{

private static Singleton instance = null;

private Singleton() {

}

public static Singleton getInstance(){

//位置1，第1次检查instance

if (instance == null)

{

//位置2，某一时刻可能有n个线程到达

synchronized (this)

{

//位置3，任何时间只能有1个线程到达

if (instance == null) //位置4，第2次检查instance

{

instance = new Singleton();

}

}

}

return instance;

}

}

.Net代码：

class Singleton {

private static Singleton instance = null;

private static readonly object syncObj = new object();

private Singleton (){

}

public static Singleton getInstance(){

//位置1，第1次检查instance

if( instance == null ){

//位置2，某一时刻可能有n个线程到达

lock(syncObj)

{

//位置3，任何时间只能有1个线程到达

if (instance == null) //位置4，第2次检查instance

{

instance = new Singleton();

}

}

}

return instance;

}

}

我们通过引入了Java的synchronized或者.Net的lock同步化限制，各个线程到达临界区时，就会按照线性方式逐个执行。

我们再来分析一下：

（1）在多线程环境中，线程A 和B同时或几乎同时到达位置1。

（2）假设线程A 会首先到达位置2，并进入synchronized(this) 到达位置3。这时，由于synchronized(this) 的同步化限制，线程B 无法到达位置3，而只能在位置2 等候。

（3）线程A 执行instance = new Singleton()语句，instance变量得到赋值，此时，线程B 还只能继续在位置2 等候。

（4）线程A 退出synchronized(this) 块，并返回instance对象。

（5）线程B 进入synchronized(this)块，到达位置3，进而到达位置4。由于instance变量已经不是null 了，因此线程B 退出synchronized(this)，并返回instance，这时候的instance只有一个。

我们通过两次检查instance是否被实例化来解决线程安全问题，这种处理方式称为双重检查锁定机制（Double-checked locking）。还有另外一种解决线程安全的方法，就是把getInstance方法整体作为同步区，比如声明为public static synchronized Singleton getInstance()，这种方式由于锁定的区域过大，特殊情况下会造成系统性能的下降，成为系统的性能瓶颈。

双重检查锁定机制不仅解决了线程安全问题，而且把性能也处理得很不错，看起来非常完美。不幸的是我们应该注意不要在java中使用双重检查锁定机制，由于Java编译器和 JIT 的优化的原因，系统无法保证我们期望的执行次序。虽然Java语法中的volatile修饰符可以强制屏蔽编译器和 JIT 的优化工作，但它是一种非常脆弱的同步机制，比较难以控制，所以建议尽量减少使用。我们后面还提供了其它的一种实现方式。
4 单例模式的实现方式：懒汉单例类和饿汉单例类

单例模式的实现有多种方法，常见的就有懒汉式单例类和饿汉式单例类。我们前面介绍的实现方法就属于懒汉式单例类。

l 懒汉式单例类

对于懒汉模式，我们可以这样理解：该单例类非常懒，只有在自身需要的时候才会行动，从来不知道及早做好准备。它在需要对象的时候，才判断是否已有对象，如果没有就立即创建一个对象，然后返回，如果已有对象就不再创建，立即返回。

懒汉模式只在外部对象第一次请求实例的时候才去创建。

l 饿汉式单例

对于饿汉模式，我们可以这样理解：该单例类非常饿，迫切需要吃东西，所以它在类加载的时候就立即创建对象。

Java代码：

final class Singleton {

//私有的唯一实例成员,在类加载的时候就创建好了单例对象

private static final Singleton instance = new Singleton();

//私有的构造方法,避免外部创建类实例

private Singleton() {

}

//静态工厂方法,返回此类的唯一实例

public static Singleton getInstance() {

return instance;

}

}

.Net代码：

sealed class Singleton {

//私有的唯一实例成员,在类加载的时候就创建好了单例对象

private static readonly Singleton instance = new Singleton();

//私有的构造方法,避免外部创建类实例

private Singleton() {

}

//静态工厂方法,返回此类的唯一实例

public static Singleton getInstance() {

return instance;

}

}

使用Java中的final关键字和.Net中sealed关键字去修饰class，目的是阻止派生子类，而派生子类可能会导致实例不唯一。使用Java中的final关键字和.Net中readonly关键字去修饰变量，就意味着只能在类初始化时或者在构造器中分配该变量。

我们对比一下懒汉模式和饿汉模式的优缺点：

懒汉模式，它的特点是运行时获得对象的速度比较慢，但加载类的时候比较快。它在整个应用的生命周期只有一部分时间在占用资源。

饿汉模式，它的特点是加载类的时候比较慢，但运行时获得对象的速度比较快。它从加载到应用结束会一直占用资源。

这两种模式对于初始化较快，占用资源少的对象来说，没有多大的性能差异，但是对于初始化慢，占用资源多的对象来说就会有比较明显的差别了。所以，对重量级对象应用饿汉模式，在类加载时需要较长时间，但运行时会有明显的时间效率的提升。对重量级对象应用懒汉模式，在类加载时很快，但至少第一次获得对象时需要等待很长时间。

从用户体验的角度来说，我们应该首选饿汉模式。我们愿意等待某个程序花较长的时间初始化，却不喜欢在程序运行时等待太久，给人一种反应迟钝的感觉，所以对于有重量级对象参与的单例模式，我们推荐使用饿汉模式。

而对于初始化较快的轻量级对象来说，选用哪种方法都可以。如果一个应用中使用了大量单例模式，我们就应该权衡两种方法了。轻量级对象的单例采用懒汉模式，减轻加载时的负担，缩短加载时间，提高加载效率；同时由于是轻量级对象，把这些对象的创建放在使用时进行，实际就是把创建单例对象所消耗的时间分摊到整个应用中去了，对于整个应用的运行效率没有太大影响。
5 什么情况下使用单例模式

单例模式也是一种比较常见的设计模式，它到底能带给我们什么好处呢？其实无非是三个方面的作用：

第一、控制资源的使用，通过线程同步来控制资源的并发访问；

第二、控制实例产生的数量，达到节约资源的目的。

第三、作为通信媒介使用，也就是数据共享，它可以在不建立直接关联的条件下，让多个不相关的两个线程或者进程之间实现通信。

比如，数据库连接池的设计一般采用单例模式，数据库连接是一种数据库资源。软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的。当然，使用数据库连接池还有很多其它的好处，可以屏蔽不同数据数据库之间的差异，实现系统对数据库的低度耦合，也可以被多个系统同时使用，具有高可复用性，还能方便对数据库连接的管理等等。数据库连接池属于重量级资源，一个应用中只需要保留一份即可，既节省了资源又方便管理。所以数据库连接池采用单例模式进行设计会是一个非常好的选择。

在我们日常使用的在Windows中也有不少单例模式设计的组件，象常用的文件管理器。由于Windows操作系统是一个典型的多进程多线程系统，那么在创建或者删除某个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象。采用单例模式设计的文件管理器就可以完美的解决这个问题，所有的文件操作都必须通过唯一的实例进行，这样就不会产生混乱的现象。

再比如，每台计算机可以有若干个打印机，如果每一个进程或者线程都独立地使用打印机资源的话，那么我们打印出来的结果就有可能既包含这个打印任务的一部分，又包含另外一个打印任务的一部分。所以，大多数的操作系统最终为打印任务设计了一个单例模式的假脱机服务Printer Spooler，所有的打印任务都需要通过假脱机服务进行。

实际上，配置信息类、管理类、控制类、门面类、代理类通常被设计为单例类。像Java的Struts、Spring框架，.Net的Spring.Net框架，以及Php的Zend框架都大量使用了单例模式。

© 我想网 Akon 所有 , 2009. | 永久链接 | 没有评论 | 提交到 Google Reader 鲜果 抓虾

您可能会感兴趣的其他文章

• PHP开发者有了通往.net的新桥梁
• 适配器模式
• 论述PHP开发框架: What, When, Why and Which?
• 腾讯PHP程序员面试题目
• 类的设计原则
• 简易Wordpress模板代码帮助手册中文版
• 用PHP数组对百万数据进行排重
• 用 PHP 读取和编写 XML DOM
• 深入理解PHP之匿名函数
• 最快的 PHP 模板引擎 Blitz Templates

Feed enhanced by Better Feed from Ozh

1. 事件设计概述

事件机制可以是程序逻辑更加清晰可见，在JavaScript中很多对象都有自己的事件，如：button有onclick事件，selcet有 onchange事件。对于我们自己设计的类，是否也可以有事件机制呢？答案是肯定的。我们可以通过事件机制，将类设计为独立的模块，从而使其可以通过事 件与外通信，提高程序的开发效率。

2. 不带参数的事件设计模式

最简单的一种模式是将一个类的方法成员定义为事件，可以借助JavaScript的基本语法来实现，通常是一个空的方法。例如：

<script language="javascript" type="text/javascript" >

function User(){
}
User.prototype={
	show:function(){
		this.onShow();//触发onShow事件
	},
	onShow:function(){}//定义事件接口
}
var obj = new User();
//创建obj的onShow事件处理程序
obj.onShow = function(){
	alert("事件触发了");
}
//调用obj的show方法
obj.show();
</script>

obj.onShow 方法在类的外部被定义，在类的内部方法 show() 中被调用，这就实现了事件机制。

此设计模式应用起来简单，但有其有以下缺点：

• 不能够给事件处理程序传递参数，原因是我们是在 show() 这个内部方法中调用事件处理程序的，无法知道外部的参数。
• 每个事件接口只能绑定一个事件处理程序，而内部方法则可以使用 attachEvent 或 addEventListener 方法绑定多个处理程序。

3. 给事件处理程序传递参数

给事件处理程序传递参数不仅是自定义事件中存在的问题，也是系统内部对象的事件机制中存在的问题，因为事件机制仅传递一个函数名称，不带有任何参数信息，所以无法传递参数进去。例如：

<script language="javascript" type="text/javascript" >
function User(){
}
User.prototype={
	show:function(){
		this.onShow();//触发onShow事件
	},
	onShow:function(){}//定义事件接口
}
var obj = new User();
//创建obj的onshow事件处理程序
function objOnShow(userName){
	alert("hello,"+userName);
}
//定义username变量
var userName = "plkong";
//绑定obj的onshow事件
obj.onShow = objOnShow;//无法将userName这个变量传递进去
obj.show();
</script>

上面的程序是无法传递参数进去的，为了解决这个问题，我们可以从相反的思维方式去考虑问题。不考虑怎么把参数传递进去，而是考虑如何构建一个无需参数的事件处理程序。我们看看先看看下面的函数：

/* 将参数的函数封装为无参数的函数 */
function createFunction(obj, strFunc){
	var args = [];//定义args用于存储传递给事件处理程序的参数
	if(!obj) obj = window;//如果是全局函数则obj = window;
	//得到传递给事件处理程序的参数
	for( var i = 2; i<arguments.length; i++)
		args.push(arguments[i]);
	//用无参函数封装事件处理程序的调用
	/*
	JavaScript为函数对象定义了两个方法：apply 和 call， 它们的作用都是函数绑定到另外一个对象上运行。
	*/
	return function(){
		obj[strFunc].apply(obj, args);//将参数传递给指定的事件处理程序
	}
}

该方法将一个有参数的函数封装为一个无参数的函数，不仅对全局函数适用，作为 对象方法存在的函数也是适用的。该方法首先接收两个参数：obj 和 strFunc ，obj 表示事件处理程序所在的对象； strFunc 表示事件处理程序的名称。程序中还利用了arguments对象（arguments是传递给函数的隐含参数，arguments对象存储的是实际传递给 函数的参数，而且不局限与函数声明所定义的形参列表。关于arguments对象可以参考其他资料）处理第二个参数以后的隐式参数，即未定义为形参的参 数，

例如：事件处理程序

someObject.eventHandler = function(_arg1, _arg2){

//事件处理代码

}

应该调用：creatFunction(someObject, “eventHander”, arg1, arg2);

这样就返回一个无参数的函数，在返回的函数中已经包括了传递进去的参数。如果是全局函数作为事件处理程序，事实上它是window 对象的一个方法，所以可以传递window对象作为obj参数，为了更清晰一点，也可以指定obj为null， creatFunction函数内部会自动认为该函数是全局函数，从而自动吧obj赋值为window。最后完成的代码如下：

© 我想网 Akon 所有 , 2009. | 永久链接 | 没有评论 | 提交到 Google Reader 鲜果 抓虾

您可能会感兴趣的其他文章

• 页面输出时一些常用的小技巧
• 适配器模式
• 设计模式之单例模式
• 表单元素：40个CSS/JS风格和功能技术处理
• 网页打开新窗口的解决方案,拒绝屏蔽
• 类的设计原则
• 相见恨晚的一些 JavaScript 技巧
• 用JS制作的网页版NES模拟器 IE8直接出局
• 用css+js控制图片大小的方法
• 有关 JavaScript 的 10 件让人费解的事情

Feed enhanced by Better Feed from Ozh