摘要：
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类C来说不是最小接口，则类B和类D必须去实现他们不需要的方法。 解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的 阅读全文
摘要：
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带 阅读全文
摘要：
肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对 阅读全文
摘要：
定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能 阅读全文
摘要：
概述： 运用共享技术有效地支持大量细粒度的对象。 类型：结构型模式。 类图： 适用性： 当都具备下列情况时，使用Flyweight模式： 1.一个应用程序使用了大量的对象。 2.完全由于使用大量的对象，造成很大的存储开销。 3.对象的大多数状态都可变为外部状态。 4.如果删除对象的外部状态，那么可以 阅读全文
摘要：
概述： 为其他对象提供一种代理以控制对这个对象的访问。 类型：结构型模式。 类图： 适用性： 1.远程代理（RemoteProxy）为一个对象在不同的地址空间提供局部代表。 2.虚代理（VirtualProxy）根据需要创建开销很大的对象。 3.保护代理（ProtectionProxy）控制对原始对 阅读全文
摘要：
概述： 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 类型：结构型模式。 类图： 1.当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性， 阅读全文
摘要：
概述： 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。 类型：结构型模式。 类图： 适用性： 1.在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 2.处理那些可以撤消的职责。 3.当不能采用生成子类的方法进行扩充时。 参与者： 1. 阅读全文
摘要：
概述： 将对象组合成树形结构以表示“部分-整体”的层次结构。“Composite使得用户对单个对象和组合对象的使用具有一致性。” 类型：结构型模式。 类图： 适用性： 1.你想表示对象的部分-整体层次结构。 2.你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。 参与者： 阅读全文
摘要：
概述： 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 类型：结构型模式。 类图： 适用性： 1.你不希望在抽象和它的实现部分之间有一个固定的绑定关系。 例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。 2.类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。 这时 阅读全文