注：不属于 23 种设计模式之一，是面向对象设计模式中常用的一种模式。
public interface Cook {
void cook();
}
public class 川菜厨子 implements Cook {
@Override
public void cook() {
System.out.println("我是川菜师傅，我的做菜工序有9*9 81到工序，总做及其繁杂,.....省略81行代码");
}
}
public class 湘菜厨子 implements Cook {
@Override
public void cook() {
System.out.println("我是湘菜师傅，我的做菜工序有7*7 49到工序，工作及其繁杂,.....省略49行代码");
}
}
public class 业务场景 {
public static void main(String[] args) {
//要求 做饭 但是代码不要体现那么多，而且日后菜系还要换,
// 但是在这个业务场景的代码类 里 不允许更改！！！为了维护时不修改此类中的源代码
Cook cooker = new 厨师();
cooker.cook();
}
}
不知道你看完整个代码有啥感觉，反正我第一次感觉就是什么 静态代理，或者策略模式，还有就是感觉奇奇怪怪的感觉，很不爽，感觉业务场景的代码中直接调用 川菜厨子或者湘菜厨子的函数不是挺好的吗？ 搞这么多的花里胡哨的，有问题吧。仔细想想了这都不是重点，涉及模式是一种巧妙的代码编写艺术，我们知道这种编程技巧带来的美感，运用到实际生产中减轻我们的二次开发维护等问题是目的。所以我仔细感受下，咱们暂且不说到底叫什么什么模式，就说他这个编写调用，带来的妙处。我在代码中写了一些注释，如果感受不深我们在看下面举的例子。
首先把总结再说下：
委托说白了是吧大堆的代码隐藏起来，用一个函数调用简而言之代替大堆，代替并不准确说应该是隐藏！！为啥这么搞，解耦，原来说的解耦单一职责我经常是停留在方法上，通过这个委托模式，感觉是在类的层次上进行解耦。
* 需求制作一个门：
零部件要求：
1 门框的木材金丝楠木 2 把手为琉璃把手 3 门为水晶钢化玻璃 4 80年代的左右旋转开滑的门锁！
维护要求：
1可以与时俱进，意思零件随时可以替换为市场最好的。
这里的 1 2 3 4 每个都是组成一个完成的门必要组成，但是这四个部件还必须是灵活可以随时更新的！
拿其中的门锁举例，设计的时候这样考虑：
工匠师傅预先在门上留下一个5*5cm 的一个位置空白给门锁，后来啊随着时代变化，这个门主人为了与时俱进，向我一样（哈哈）要求把这个门锁换成手触摸电子密码锁， 就把门锁替换了密码，替换的时候很简单，这样替换，（锁主人又为了向我一样低调且怀旧，想换完锁呢门从外表来看最好是没变化或者变化很小）由于锁是在门的夹心内部安置的，所以只要把盖子打开，取出80年代的左右开滑的门锁！ 放进写有123456789 的电子显示屏的密码锁，然后再盖上盖子，仅仅留下一个显示屏，尽量门的外观不做巨大改动。
，
文字不够形象，大家看图片，（领会精神！美感不重要哈！）
更换前是这个样子 左右旋转可以锁门
，更换后是这个样子 去掉旋转按钮，用9键密码锁！
总结下，这个自认为还算恰当的例子：
此门就像我们写代码一样，要分为几个类 ，1 材料 2 门把手 3 门窗 4 门锁， 但是最好是将这几个类定义成接口！
并且用一个组装类来，door.java 来组装一个门，而具体组装时就用4个接口类型来调用，这样保证日后维护时，door.java 类不用再去更改代码，仅仅去把具体的实现更改或者更换，或者增加，这都符合开闭原则。
大家看loadBeanDfinitions 被调用了时干活的实际上就是 XmlBeanDefinitionReader(beanFactory) 这个对象，！！！！
==并且后边还有很多，我想你一定明白了为什么spring经常嵌套那么深了吧，看起源码总觉的他那么绕来绕去，其实就是在解耦，方便维护，spring 的代码似乎是一个大的积木，细看是一个个模块。
但是在微观看每个模块就是许多重复的颗粒重复的利用，代码似乎做到了不做多于的冗余，之所以这么说是因为有时一定的冗余是必要的。从现在开始我准备像欣赏美女，哦不！，是艺术品来看待spring,从里到外一点一点拨开它的面纱… ==