设计模式
gof————四人帮 其中一个人是junit的作者。
设计模式：解决特定问题的总结
简单工厂：隐藏了类的实现，返回的类不确定的时候，是jdbc或者Ibatis的时候用简单工厂。
隐藏了new关键字，降低了偶尔度，把对象的设计和实现分隔开来，提高了扩展性。//*/-*//*-*/
单例：在类里面只有一个对象。解决了java虚拟机不管怎么操作，只有一个对象。
特征：
1.空的构造方法并且是私有的：这样就能保证只有本类才能创建这个类是实例。
2.声明一个私有的静态的当前类的属性，
3.公共的同步静态的方法：这个方法是必要的，因为该类的构造方法是私有的话，别的类要创建这个类的实例，只能通过这个方法来得到。 如果创建自己的实例有一段时间间隔的话，那么别的类就有可能同时进来创建实例，为了保证我们只能创建一个实例，所以我们把方法要加上synchronized，
4.判断本类对象是否为空：如果为空的话，创建一个本类的对象，不为空的话就直接返回该类。
设计模式（23种）：
一.策略模式：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换，本模式使得算法可独立于使用它的客 户而变化。
二.模板模式：父类定义流程，子类实现，解决子类之间的重复问题。
三.观察者模式：
1.定义：观察者模式定义了一种一对多的依赖关系，
2.举例：①观察者模式（Observer）完美的将观察者和被观察的对象分离开。一个对象发生变化时，所有依赖它的对象都得到通知并被自动更新。举个例子，用户界面可以作为一个观察者，业务数据是被观察者，用户界面观察业务数据的变化，发现数据变化后，就显示在界面上。
②猫跟狗去抓老鼠，老鼠是被观察者，猫跟狗就是观察者，猫跟狗守在老鼠洞旁边，一旦老鼠出洞，猫跟狗就去捕捉。
3.使用场合
A．当一个抽象模型有两个方面，其中一个方面依赖开另一方面，将这二者封装在独立的对象中以使它们可以独立的改变和复用，降低它们之间的耦合性。
B．改变一个对象需要同时改变其它对象，但不知道有多少个对象有待改变。
C：在事件驱动的时候经常用到观察者模式。
四、组合模式：
将对象以树形结构组织起来。以达成“部分－整体” 的层次结构.
树形是由树枝和树叶组成。
老板是一个根节点，主管是一个树枝，员工是树叶。
优点：
1.使用组合模式的优点就是客户不用关心自己处理的是单个模式还是组合结构,这就简化了客户端的代码。
2.每个叶子都是独立的，不存在任何的耦合度，这里就体现了开关原则，用户需要增加一个对象的时候不用修改原来的代码。
五、命令模式
以前把对象的创建封装起来，命令模式是把行为封装起来，菜单就是一个命令。
好处：只关心行为,不关心具体执行类或者实现.
举例：比如有一个领导身在国外，他需要象的不同部门发出不同的工作要求（我们称为命令），再假设他没有方便的通讯工具，只能通过信件来传达他的要求，那么他将会把给不同部门的要求写成一封信，这样所有的命令都具有了信件的共同特征，而邮递员并不了解信件的内容是什么，他的任务只是负责传递命令，而每个部门的负责人都知道如何打开这个信件和执行信中所表达的任务要求。我们把这样一个类似问题进行抽象，就成了我们这里所提到的命令模式。
命令模式的使用：
有一种简单的方法能够动态的增加新动作或者修改存在的动作，客户端不需要知道处理一个特定需求具体细节
描述一下命令模式解决如上问题的方法：
1、首先我们把所有的命令调用过程都抽象成一个接口叫Command，这个接口中定义一个调用方法叫execute。
2、把每一个要执行的动作都设计成为一个类，让这个类实现Command的接口，实现接口中定义的名为execute的方法。
3、当客户端需要执行具体的命令的时候，由客户端创建具体的命令对象（比如说：SpecificCommand），然后把这个对象传递给一个调用者对象（比如说：Invoker）。
4、对于调用者对象（Invoker）而言，它不需要知道某个具体命令的细节，它的任务只是简单的调用命令对象的execute方法就可以了。
优点：
解耦了发送者和接受者之间联系。
六、门面模式
为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
举例：Facade 一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访问,都要进行以下操作：先得到connect 实例，然后打开connect获得连接,得到一个statement，执行sql语句进行查询，得到查询结果集。 我们可以将这些步骤提取出来，封装在一个类里面。这样，每次执行数据库访问只需要将必要的参数传递到这个类中就可以了。
七、装饰器模式
动态的给一个对象添加一些额外的职责，例如增加的时候装饰器生成子类更为灵活。
以前我们为了扩展功能通过继承，当多个子类继承的时候提高了系统的复杂性，装饰模式由用户动态决定加入的方式和时机即插即用，在运行期决定何时增加何种功能。
项目运用，报表
如果类中的某种行为在将来可能发生变化，而你又懒得去改变
原来的类，那么就可以考虑使用装饰器模式了。
八、状态模式
定义：不同的状态有不同的行为。
代替大量的if..else，
每个人的心情有喜怒哀乐，在这种状况下，做同一件事情就有不同的结果。
，一些收费网站的用户就有
很多状态，比如普通用户，普通会员，VIP 会员
以前我们使用if..else,这些分支依赖于该对象的状态，有多个操作包含这相同的条件结果，状态模式把每个条件分支放入一个单独类中，这些对象可以不依赖于其他对象而可以独立变化。权限，跟银行卡。
九、职责链模式：
对一个对象经过多次复杂的处理，对这一系列的处理放在链上。主要用来降低耦合度，创建action。创建form都的通过这个链。
优点：
1.降低请求者和接受者之间的耦合度，使得一个对象不需要知道是其他哪个对象来处理这个请求，对象只需要知道该请求会被正确的处理，接受者和请求者可以不需要知道对方的具体信息，链中的对象也可以不用知道整条链的结构。
2.增加了灵活性，在链运行的时候可以动态的增加或者修改某个执行链的职责。
缺点：因为一个请求没有明确的接收者，那么就不能保证他一定会被处理，该请求可能一直到链接的末端都得不到处理，一个请求也可能因为该链没有被正确配置而得不到处理，所以请求就不能保证一定会被处理。
优点：
1，责任的分担。每个类只需要处理自己该处理的工作（不该处理的传递给下一个对象完成），明确各类的责任范围，符合类的最小封装原则。
2，可以根据需要自由组合工作流程。如工作流程发生变化，可以通过重新分配对象链便可适应新的工作流程。
3，类与类之间可以以松耦合的形式加以组织。
缺点：
因为处理时以链的形式在对象间传递消息，根据实现方式不同，有可能会影响处理的速度。
十、抽象工厂
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
抽象工厂类和工厂类的原理相同，只不过工厂类返回的是普通类的实例；而抽象工厂类返回的是一个工厂类的实例
比如说工厂可以生产鼠标和键盘。
那么抽象工厂的实现类（它的某个具体子类）的对象都可以生产鼠标和键盘，但可能工厂A生产的是罗技的键盘和鼠标，工厂B是微软的。
这样A和B就是工厂，对应于抽象工厂；
每个工厂生产的鼠标和键盘就是产品，对应于工厂方法；
用了工厂方法模式，你替换生成键盘的工厂方法，就可以把键盘从罗技换到微软。但是用了抽象工厂模式，你只要换家工厂，就可以同时替换鼠标和键盘一套。如果你要的产品有几十个，当然用抽象工厂模式一次替换全部最方便（这个工厂会替你用相应的工厂方法）
十一、适配器模式
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
为什么使用：我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。
一种叫类适配器模式，另一种叫对象适配器模式。其中类适配器模式是以继承的方式(多继承)来实现，而对象适配器模式是以组合的方式（建立对象的事例）实现．
但继承增加了模块间的耦合程度，而组合降低了耦合程度，所以在项目开发中往往建议多使用对象适配器模式
十二、建造模式
复杂对象的构建与他的表示分割开来，比如我们天天使用的这个显示器，他的内部实现原理可能很复杂，我们只会用他，也不知道他内部是怎么实现的。
十三、代理模式
为其他对象提供一种代理以控制对这个对象的访问。
当一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
十四、中介者模式：使用中介对象来封装一系列的对象交互。中介者使各对象不需要显示相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
通俗点说将原来两个直接引用或者依赖的对象拆开，在中间加入一个“中介”对象，使得两头的对象分别和“中介”对象引用。
它把多对多的交互变成了一对多的交互，从而简化了交互，理清了思路。
举例：
像我们买房子的时候，要办理一系列的复杂的手续，像讲价钱，到银行借贷款，这些复杂的手续我们可以交给房屋买卖中介。
使用的情况：
一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱并且难以理解。
一个对象引用其他很多对象并且直接与这些对象通信，导致难以复用该对象。
想定制一个分布在多个类中的行为，而又不想生成太多的子类。
单一职责原则（SRP）：一个类，最好只做一件事，只有一个引起它变化的原因。
在构造对象时，将对象的不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个。可以有效降低耦合，减少对不必要资源的引用。
单一职责原则可以有效降低耦合，减少对不必要资源的引用。但后果是造成源文件增多，给管理带来不便，所以在实际应用中，可以对经常使用或经常需要改动的模块应用该原则。
对于违反这一原则的类应该进行重构，例如以Fa?ade模式或Proxy模式分离职责，通过基本的方法Extract Interface、Extract Class和Extract Method进行梳理。
策略模式
开放-封闭原则(OCP)：
"对于扩展是开放的"（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模 块的功能。"对于更改是封闭的"（Close for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。
带来的好处：提高灵活性、可重用性、可维护性。
职责链模式
里斯替换原则(LSP)：在实现继承时，子类型（subtype）必须能替换掉它们的基类型（base type）。 子类必须能够替换掉它们的基类。 也就是说，代码中基类出现的地方都能用子类来替换，就跟汽车能用的地方都能用轿车一样。但是，如果设计不合理，就会违反这个原则
举个例子，正方 形和矩形，矩形可以做为正方形的基类，因为正方形也是一种矩形，但对于正方形来说，setWidth()和setHeight()是冗余的，且容易引起错 误，这样的设计就违反了LSP原则。如果有两个具体类A和B之间的关系违反了LSP，可以在以下两种重构方案中选择一种：1 .创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。 2 .从B到A的继承关系改写为委派关系。
依赖倒置原则(DIP)：A .高层模块不应该依赖于低层模块。二者都应该依赖于抽象。B .抽象不应该依赖于细节。细节应 该依赖于抽象。
模板模式
接口分离原则(ISP)：不要强迫客户依赖于它们不用的方法。
应用：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。
结论：使用多个专门的接口比使用单一的接口要好。
命令模式，构建模式.
迪米特法则(Law of Demeter)：就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
迪米特法则在类的设计上的体现：
优先考虑将一个类设置成不变类。
尽量降低一个类的访问权限。
谨慎使用Serializable。
尽量降低成员的访问权限。
代理模式，门面模式，中介模式就是迪米特法则的应用。
1.观察者模式
2.策略模式
3.组合模式
4.模板模式
5.命令模式
6.门面模式
7.装饰器模式
8.职责链模式
9.状态模式:不同的状态的就有不同的行为
10.抽象工厂模式:创建一系列相互依赖对象的接口，而不需要指定具体的类。
11.适配器模式:使得两个互不兼容的接口的对象能够一起使用。
12.建造模式:
13.简单工厂模式:
14.单例模式:
15.代理模式:
16.中介者模式:
xwork-webwork-struts2
面向对象原则
1.单一职责原则
2.开发-封闭原则
3.替换原则
4.依赖倒置原则
5.接口分离原则
6.迪米特法则
1992610123DAN
设计模式：解决特定问题的总结
简单工厂：隐藏了类的实现，返回的类不确定的时候，是jdbc或者Ibatis的时候用简单工厂。
隐藏了new关键字，降低了偶尔度，把对象的设计和实现分隔开来，提高了扩展性。//*/-*//*-*/
单例：在类里面只有一个对象。解决了java虚拟机不管怎么操作，只有一个对象。
特征：
1.空的构造方法并且是私有的：这样就能保证只有本类才能创建这个类是实例。
2.声明一个私有的静态的当前类的属性，
3.公共的同步静态的方法：这个方法是必要的，因为该类的构造方法是私有的话，别的类要创建这个类的实例，只能通过这个方法来得到。 如果创建自己的实例有一段时间间隔的话，那么别的类就有可能同时进来创建实例，为了保证我们只能创建一个实例，所以我们把方法要加上synchronized，
4.判断本类对象是否为空：如果为空的话，创建一个本类的对象，不为空的话就直接返回该类。
设计模式（23种）：
一.策略模式：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换，本模式使得算法可独立于使用它的客 户而变化。
二.模板模式：父类定义流程，子类实现，解决子类之间的重复问题。
三.观察者模式：
1.定义：观察者模式定义了一种一对多的依赖关系，
2.举例：①观察者模式（Observer）完美的将观察者和被观察的对象分离开。一个对象发生变化时，所有依赖它的对象都得到通知并被自动更新。举个例子，用户界面可以作为一个观察者，业务数据是被观察者，用户界面观察业务数据的变化，发现数据变化后，就显示在界面上。
②猫跟狗去抓老鼠，老鼠是被观察者，猫跟狗就是观察者，猫跟狗守在老鼠洞旁边，一旦老鼠出洞，猫跟狗就去捕捉。
3.使用场合
A．当一个抽象模型有两个方面，其中一个方面依赖开另一方面，将这二者封装在独立的对象中以使它们可以独立的改变和复用，降低它们之间的耦合性。
B．改变一个对象需要同时改变其它对象，但不知道有多少个对象有待改变。
C：在事件驱动的时候经常用到观察者模式。
四、组合模式：
将对象以树形结构组织起来。以达成“部分－整体” 的层次结构.
树形是由树枝和树叶组成。
老板是一个根节点，主管是一个树枝，员工是树叶。
优点：
1.使用组合模式的优点就是客户不用关心自己处理的是单个模式还是组合结构,这就简化了客户端的代码。
2.每个叶子都是独立的，不存在任何的耦合度，这里就体现了开关原则，用户需要增加一个对象的时候不用修改原来的代码。
五、命令模式
以前把对象的创建封装起来，命令模式是把行为封装起来，菜单就是一个命令。
好处：只关心行为,不关心具体执行类或者实现.
举例：比如有一个领导身在国外，他需要象的不同部门发出不同的工作要求（我们称为命令），再假设他没有方便的通讯工具，只能通过信件来传达他的要求，那么他将会把给不同部门的要求写成一封信，这样所有的命令都具有了信件的共同特征，而邮递员并不了解信件的内容是什么，他的任务只是负责传递命令，而每个部门的负责人都知道如何打开这个信件和执行信中所表达的任务要求。我们把这样一个类似问题进行抽象，就成了我们这里所提到的命令模式。
命令模式的使用：
有一种简单的方法能够动态的增加新动作或者修改存在的动作，客户端不需要知道处理一个特定需求具体细节
描述一下命令模式解决如上问题的方法：
1、首先我们把所有的命令调用过程都抽象成一个接口叫Command，这个接口中定义一个调用方法叫execute。
2、把每一个要执行的动作都设计成为一个类，让这个类实现Command的接口，实现接口中定义的名为execute的方法。
3、当客户端需要执行具体的命令的时候，由客户端创建具体的命令对象（比如说：SpecificCommand），然后把这个对象传递给一个调用者对象（比如说：Invoker）。
4、对于调用者对象（Invoker）而言，它不需要知道某个具体命令的细节，它的任务只是简单的调用命令对象的execute方法就可以了。
优点：
解耦了发送者和接受者之间联系。
六、门面模式
为子系统中的一组接口提供一个一致的界面，Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
举例：Facade 一个典型应用就是进行数据库连接。一般我们在每一次对数据库进行访问,都要进行以下操作：先得到connect 实例，然后打开connect获得连接,得到一个statement，执行sql语句进行查询，得到查询结果集。 我们可以将这些步骤提取出来，封装在一个类里面。这样，每次执行数据库访问只需要将必要的参数传递到这个类中就可以了。
七、装饰器模式
动态的给一个对象添加一些额外的职责，例如增加的时候装饰器生成子类更为灵活。
以前我们为了扩展功能通过继承，当多个子类继承的时候提高了系统的复杂性，装饰模式由用户动态决定加入的方式和时机即插即用，在运行期决定何时增加何种功能。
项目运用，报表
如果类中的某种行为在将来可能发生变化，而你又懒得去改变
原来的类，那么就可以考虑使用装饰器模式了。
八、状态模式
定义：不同的状态有不同的行为。
代替大量的if..else，
每个人的心情有喜怒哀乐，在这种状况下，做同一件事情就有不同的结果。
，一些收费网站的用户就有
很多状态，比如普通用户，普通会员，VIP 会员
以前我们使用if..else,这些分支依赖于该对象的状态，有多个操作包含这相同的条件结果，状态模式把每个条件分支放入一个单独类中，这些对象可以不依赖于其他对象而可以独立变化。权限，跟银行卡。
九、职责链模式：
对一个对象经过多次复杂的处理，对这一系列的处理放在链上。主要用来降低耦合度，创建action。创建form都的通过这个链。
优点：
1.降低请求者和接受者之间的耦合度，使得一个对象不需要知道是其他哪个对象来处理这个请求，对象只需要知道该请求会被正确的处理，接受者和请求者可以不需要知道对方的具体信息，链中的对象也可以不用知道整条链的结构。
2.增加了灵活性，在链运行的时候可以动态的增加或者修改某个执行链的职责。
缺点：因为一个请求没有明确的接收者，那么就不能保证他一定会被处理，该请求可能一直到链接的末端都得不到处理，一个请求也可能因为该链没有被正确配置而得不到处理，所以请求就不能保证一定会被处理。
优点：
1，责任的分担。每个类只需要处理自己该处理的工作（不该处理的传递给下一个对象完成），明确各类的责任范围，符合类的最小封装原则。
2，可以根据需要自由组合工作流程。如工作流程发生变化，可以通过重新分配对象链便可适应新的工作流程。
3，类与类之间可以以松耦合的形式加以组织。
缺点：
因为处理时以链的形式在对象间传递消息，根据实现方式不同，有可能会影响处理的速度。
十、抽象工厂
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
抽象工厂类和工厂类的原理相同，只不过工厂类返回的是普通类的实例；而抽象工厂类返回的是一个工厂类的实例
比如说工厂可以生产鼠标和键盘。
那么抽象工厂的实现类（它的某个具体子类）的对象都可以生产鼠标和键盘，但可能工厂A生产的是罗技的键盘和鼠标，工厂B是微软的。
这样A和B就是工厂，对应于抽象工厂；
每个工厂生产的鼠标和键盘就是产品，对应于工厂方法；
用了工厂方法模式，你替换生成键盘的工厂方法，就可以把键盘从罗技换到微软。但是用了抽象工厂模式，你只要换家工厂，就可以同时替换鼠标和键盘一套。如果你要的产品有几十个，当然用抽象工厂模式一次替换全部最方便（这个工厂会替你用相应的工厂方法）
十一、适配器模式
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
为什么使用：我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有源代码，或者，我们不愿意为了一个应用而修改各自的接口。
一种叫类适配器模式，另一种叫对象适配器模式。其中类适配器模式是以继承的方式(多继承)来实现，而对象适配器模式是以组合的方式（建立对象的事例）实现．
但继承增加了模块间的耦合程度，而组合降低了耦合程度，所以在项目开发中往往建议多使用对象适配器模式
十二、建造模式
复杂对象的构建与他的表示分割开来，比如我们天天使用的这个显示器，他的内部实现原理可能很复杂，我们只会用他，也不知道他内部是怎么实现的。
十三、代理模式
为其他对象提供一种代理以控制对这个对象的访问。
当一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
十四、中介者模式：使用中介对象来封装一系列的对象交互。中介者使各对象不需要显示相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
通俗点说将原来两个直接引用或者依赖的对象拆开，在中间加入一个“中介”对象，使得两头的对象分别和“中介”对象引用。
它把多对多的交互变成了一对多的交互，从而简化了交互，理清了思路。
举例：
像我们买房子的时候，要办理一系列的复杂的手续，像讲价钱，到银行借贷款，这些复杂的手续我们可以交给房屋买卖中介。
使用的情况：
一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱并且难以理解。
一个对象引用其他很多对象并且直接与这些对象通信，导致难以复用该对象。
想定制一个分布在多个类中的行为，而又不想生成太多的子类。
单一职责原则（SRP）：一个类，最好只做一件事，只有一个引起它变化的原因。
在构造对象时，将对象的不同职责分离至两个或多个类中，确保引起该类变化的原因只有一个。可以有效降低耦合，减少对不必要资源的引用。
单一职责原则可以有效降低耦合，减少对不必要资源的引用。但后果是造成源文件增多，给管理带来不便，所以在实际应用中，可以对经常使用或经常需要改动的模块应用该原则。
对于违反这一原则的类应该进行重构，例如以Fa?ade模式或Proxy模式分离职责，通过基本的方法Extract Interface、Extract Class和Extract Method进行梳理。
策略模式
开放-封闭原则(OCP)：
"对于扩展是开放的"（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，可以对模块进行扩展，使其具有满足改变的新行为。也就是说，我们可以改变模 块的功能。"对于更改是封闭的"（Close for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。
带来的好处：提高灵活性、可重用性、可维护性。
职责链模式
里斯替换原则(LSP)：在实现继承时，子类型（subtype）必须能替换掉它们的基类型（base type）。 子类必须能够替换掉它们的基类。 也就是说，代码中基类出现的地方都能用子类来替换，就跟汽车能用的地方都能用轿车一样。但是，如果设计不合理，就会违反这个原则
举个例子，正方 形和矩形，矩形可以做为正方形的基类，因为正方形也是一种矩形，但对于正方形来说，setWidth()和setHeight()是冗余的，且容易引起错 误，这样的设计就违反了LSP原则。如果有两个具体类A和B之间的关系违反了LSP，可以在以下两种重构方案中选择一种：1 .创建一个新的抽象类C,作为两个具体类的超类，将A和B共同的行为移动到C中，从而解决A和B行为不完全一致的问题。 2 .从B到A的继承关系改写为委派关系。
依赖倒置原则(DIP)：A .高层模块不应该依赖于低层模块。二者都应该依赖于抽象。B .抽象不应该依赖于细节。细节应 该依赖于抽象。
模板模式
接口分离原则(ISP)：不要强迫客户依赖于它们不用的方法。
应用：一个类对另外一个类的依赖性应当是建立在最小的接口上的。如果客户端只需要某一些方法的话，那么就应当向客户端提供这些需要的方法，而不要提供不需要的方法。
结论：使用多个专门的接口比使用单一的接口要好。
命令模式，构建模式.
迪米特法则(Law of Demeter)：就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
迪米特法则在类的设计上的体现：
优先考虑将一个类设置成不变类。
尽量降低一个类的访问权限。
谨慎使用Serializable。
尽量降低成员的访问权限。
代理模式，门面模式，中介模式就是迪米特法则的应用。
1.观察者模式
2.策略模式
3.组合模式
4.模板模式
5.命令模式
6.门面模式
7.装饰器模式
8.职责链模式
9.状态模式:不同的状态的就有不同的行为
10.抽象工厂模式:创建一系列相互依赖对象的接口，而不需要指定具体的类。
11.适配器模式:使得两个互不兼容的接口的对象能够一起使用。
12.建造模式:
13.简单工厂模式:
14.单例模式:
15.代理模式:
16.中介者模式:
xwork-webwork-struts2
面向对象原则
1.单一职责原则
2.开发-封闭原则
3.替换原则
4.依赖倒置原则
5.接口分离原则
6.迪米特法则
1992610123DAN