一、模式定义
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
二、所体现出的设计原则
这里重新归纳一下软件设计中的几个原则：
1.OCP法则：开闭法则（Open-Closed Principle）一个软件系统应当对扩展开放，对修改关闭。
描述：通过扩展已有软件系统，可以提供新的行为，以满足对软件的新的需求，使变化中的软件有一定的适应性和灵活性。同时已有软件模块，特别是最重要的抽象层模块不能再修改，这使变化中的软件系统有一定的稳定性和延续性。
实现原则：把抽象接口和实现分离。
2.LSP法则： Liskov Substitution Principle（里氏代换原则）
描述：这是继承的特征，子类型(subtype)必须能够替换它们的基类型。
3.DIP法则： 依赖倒置（Dependence Inversion Principle）
表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。具体讲就是 要依赖于抽象，不要依赖于具体。
实现原则：传递参数时，或者在组合聚合关系中，尽量引用层次高的类。
4.ISP原则：接口隔离原则（Interface Segregation Principle）
描述：每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。这类似编码原则中的最小权限法则。
5.CARP法则: 合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）也叫做合成复用（CRP）原则（Composite Reuse Principle
描述：要尽量使用合成/聚合，尽量不要使用继承。这就是has a和is a的的问题
6. 迪米特法则（LoD）迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP）
描述：一个对象应当对其它对象有尽可能少的了解。其它表述：这实际上就是设计高内聚低耦合的要求，有人形象地称谓“不要和陌生人讲话”。
似乎找不到单件模式符合的哪一项，>_<
三、UML图示
简单反而画不出来了。。。
四、应用场景
单件模式常用来代表系统中的某种唯一的资源，比如说文件系统，资源管理器等等。
五、注意事项
单件模式有几种实现，比如说：直接将本对象的引用定义成static final类型，然后在全局唯一访问接口中返回此引用。
private static final MySingleton _instance = new MySingleton();
public MySingleton getinstance() {
return _instance;
}
这种写法简单易记，并且没有线程安全的问题。但缺点是不能继承。
还有一种做法可以满足继承的需要：全局统一访问接口仍在父类中定义，同时父类中维护一张映射表，key为子类名称，value为子类实例的引用。
但我觉得单件模式还是不要继承的好，继承单例总感觉不对劲。
六、举例说明
比如说做一个FTP工具，需要设计一个FTP Session的管理者对象，来实现诸如FTP Session的创建，销毁，存储等等。此时这个管理者对象就是全局唯一的访问FTP Session的点，所以设计成单件模式就比较适合了。
七、代码示例
维基百科：http://zh.wikipedia.org/wiki/%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F