Guus

迪米特法则：(Law of Demeter, LoD)，也称最少知识原则（Least Knowledge Principle, LKP）理解：     如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个放发的话，可以通过第三者转发这个调用。  只和朋友交流（更准确来讲是：直接的朋友）每个对象都必然会与其

什么是外观模式？外观模式（Facade），为子系统中的一组接口提供一个一致的界面，定义一个高层接口，这个接口使得这一子系统更加容易使用。  简单点说：外观模式是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合度，且客户端调用非常方便。概述 ：在真实的应用系统中，一个子系统可能由很

什么是观察者模式？     定义了 一种一对多的关系，让多个观察对象（公司员工）同时监听一个主题对象（秘书），主题对象状态发生变化时，会通知所有的观察者，使它们能够更新自己。   解决什么问题？     将一个系统分割成一个一些类相互协作的类有一个不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。观察者就是

什么是备忘录模式？    在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样就可以将以后的对象状态恢复到先前保存的状态。     我们在编程的时候，经常需要保存对象的中间状态，当需要的时候，可以恢复到这个状态。比如，我们使用Eclipse进行编程时，假如编写失误（例如不小心误删除了几行代码），我们希望返回删除前的状态，便可以使用Ctrl+Z来进行返回。这时

装饰模式(Decorator) : 动态的给一个对象添加一些额外的职能，就增加功能来说，装饰模式比生成子类更为灵活。实例：ConcreteComponent：让Decorator对象为自己添加功能。有时候使用ConcreteComponent的派生类提供核心功能，在这种情况就是用ConcreteComponent替代了Component的功能，而且装饰者是继承于Concrete

单一职责原则简单来说就是功能单一。 打个比方，手机有很多功能，可是摄像不如摄影机，音乐不如MP3，定位不如专用的GPS。意思是说一件产品简单一些，责任单一一些或许是更好的选择。 就编程而言：单一职责原则（SRP）就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的的变化可能消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发

特点：对于扩展是开发的，对于修改是封闭的。 打个比方：比如弹性工作，每天必须保证8个小时的工作时间，但是何时上班何时下班确可变话。 简单的说，设计的时候要考虑让类足够好，写好了就不要去改动，如果有新需求增加一些类，原来的类能不动则不动。（不可能完全封闭） 样的设计才能面对需求的改变却可以保持相对稳定，从而使系统可以在第一个版本以后不推出新版 ？何时应对变化？ 无论模块多么的‘封闭’，都会纯在

依赖倒转原则又称依赖倒置原则：抽象不应该依赖细节，细节应该依赖于抽象。说白了，就是针对接口编程，不要针对实现编程。依赖倒置原则包含三层含义：1)高层模块不应该依赖低层模块，两者都应该依赖其抽象；2)抽象不应该依赖细节;3)细节应该依赖抽象。看了上面的解释相信大家会和我一样会有一些疑问在脑海里，下面来详细说一说吧：1)为什么

代理模式(Proxy) ： 为其他对象提供一种代理以控制对这个对象的访问。下面实例说明：//公共的抽象类public abstract class Subject { public abstract void Request();}//真实实体public class RealSubject extends Subject{ @Override public void

什么是适配器模式？     Adapter模式使的原本由于接口不兼容而不能一起工作的那些类可以一起工作。     简单的说，就是需要的东西就在面前，确不能使用，而短时间又无法改造它，于是我们就想办法适配它。     适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。代码示例：/// /// 定义客户端期待的接口 ///