7.template(l承与多?
template是l承概念里的一个模式，q里提前说了Q因为，我认为，他跟strategy有类g处，所以提前。这l构很简单，主要利用了面向对象的多态特性，抽象cd义的具体实现l定到派生类Q而父cL供了一个模板，来组l全部或部分的结构，从而提供了h某种普遍一L行ؓ。具体代码如下：
abstract class AbstractClass{
public void templateMethod(){
method1();
method2();
}
abstract public void method1();
abstract public void method2();
}
class ConcreteClass extends AbstractClass{
public void method1(){
}
public void method2(){
}
}
void main(){
AbstractClass abstractClass = new ConcreteClass();
abstractClass.templateMethod();
}
8.strategy(单向单委?Q但是，如果你在设计中发玎ͼq种高度耦合的结构解决不了你的问题，那么我会推荐采用另一U方?--strategy。该Ҏ同样使用委托Q它把通用模板攑ֈ了一个独立的cMQ给该类注入一个被委托对象实例Q然后模板的每一个执行步骤，交给被委托者一一执行。看例子Q?
class Strategy{
public void method1(){
}
public void method2(){
}
}
class Context{
private Strategy strategy;
public Context(Strategy strategy){
this.strategy = strategy;
}
public void algorithmMethod(){
strategy.method1();
strategy.method2();
}
}
void main(){
Context context = new Context(new Strategy());
context.algorithmMethod();
}
也许Q你看到q样的结构，在哪里？builder模式Q对了，看v来，真象孪生兄弟。但是，区别在哪里呢Q该模式侧重于算法，某一天，你想到新的改q算法，你完全可以替换该strategyQ我想你记得Q本文到头到N再依赖具体类QContext里的Strategy本该是接口或抽象cȝ。真正设计时Q我们会考虑q点。而对于，builder侧重于徏造步骤，当然Q如果，哪天你如果突然觉得有一U方式能够更好的建造房屋，那你去改进房屋的徏造细节吧?
9.bridge(单向单委?
10.state(单向单委?
11.visitor(无Q何委?
我说没Q何委托，因ؓQ我没发玎ͼ委托者手里揣q被委托者，同时被委托者手里也毫无东西。然而，我还是说它是一U委托，而且是双向简单委托。或许我该把cMq样的无M委托的东西定义ؓ临时委托。以下我展CZ个从双向单委托到临时委托的演变过E。当Ӟ我会以雇d保姆的例子来说明它。因为构?
class Element{
Visitor v;
setVisitor(Visitor v){
this.v = v;
}
accept(){
v.visit();
}
}
class Visitor{
Element e;
setElement(Element e){
this.e = e;
}
visit(){
讉Ke的过E?nbsp;
}
}
void main(){
Element e = new Element();
Visitor v = new Visitor();
e.setVisitor(v); //建立双向委托关系
v.setElement(e);
e.accept();
}
对于q段代码Q我惌明几点：
Element: 表示雇主?
VisitorQ表CZ姆?
acceptQ表C雇主让保姆扫地的要求?/臛_Q扫地是我沿用一开始的感觉Q其实，q个形象的描q是我一个好朋友想的Q在此表C感谢。当Ӟ我问他有没好例子来描q我l他讲的x?
visit: 表示保姆扫地q程Q当然他需要雇ȝ扫把和其他一些东?
OKQ到现在为止Q这代码能正常工作了Q他解决了雇主雇用保姆扫地的问题?
让我们理清下逻辑Q先是来了一个雇d一个保姆，然后Q雇主要了保姆的资料Q同时保姆也要了雇主的资料，q种力_关系p么徏立了Q当雇主要求扫地时即e.accept()Q他委托他持有的保姆来干z，而保姆visit()Q他无Q何参敎ͼ因ؓ他也持有雇主了。然而，保姆很懒--你见q保姆很勤快的吗Q他告诉雇主Q我不想记那么多Q你叫扫地时Q把你的信息一h带给我。ؓ什么呢Q因Z姆他也想多赚钱，q样方式Q他可以为多个雇L务，得到可观的收入?
于是Q出C下面的改写?
class Element{
Visitor v;
Element(Visitor v){
this.v = v;
}
accept(){
v.visit(this);
}
}
class Visitor{
visit(Element e){
讉Ke的过E?nbsp;
}
}
void main(){
Visitor v = new Visitor();
Element e = new Element(v);
e.accept();
}
q些C码，意味着保姆有了新的工作方式Q他可以为多个雇d作，而雇dQ看到委托了Q哦Q他只能雇䄦一个保姆。你觉得q样如何Q我惌的是Q如果你想长期雇佣这个保姆，OKQ它可以很好的ؓ你工作?
q种方式Q一直工作的好好的，保姆很勤劻I雇主也很友善。但是，你可曾想q，哪一天，只要关系中的M一方翻脸，q将是一大灾烂，双方U缠不清。所以，雇主有了l验Q他不想在第二关卡结束游戏，所以，他决定找一个时工。更具体的说Q他想需要扫地时才去请保?但是Q他有可能一时半会找不到Q这个不他)Q于是，他把保姆的委托也丢掉了，他不再只让固定保姆做事了。OKQ他把委托提到参数的位置M?
class Element{
accept(Visitor v){
v.visit(this);
}
}
class Visitor{
visit(Element e){
讉Ke的过E?nbsp;
}
}
void main(){
Visitor v = new Visitor();
Element e = new Element();
e.accept(v);
}
q样的结果，雇主可以请时保姆干z，保姆也可以ؓ多个雇主服务Q很满意Q我们稍微修Ҏ下面?
class Element1{
accept(Visitor v){
v.visit(this);
}
}
class Visitor{
visit(Element e){
讉K雇主e的过E?nbsp;
}
visit(Element1 e1){ 讉K雇主e的过E?nbsp;
}
}
OKQ这Ll果Q不会变了吗Q当Ӟ我们会尽量保持住Q代码写了可不能乱动。但是，有一天，城市里又来了新雇主Element2Q保姆ؓ了能Z服务Q怎么办，dvisit(Element2 e2)Q我别这么做Qؓ什么？你违反了游戏规则(OCP)Q但是，他对于固定数据结构的具体讉K非常有用Q如果，他很好的帮助你解决问题，那就用它吧。这个例子，引出了时委托的概念Q那什么时候，会用它呢？我想说的是，如果委托者要做的事很多，且都是交l被委托者，也就是，委托者与被委托者的交付是频J的Q那么我Q你保持住这个长期工(对象变量)Q除此之外，你会很喜Ƣ找临时工的。这个时是参数的Ş式出现在的。所以，所有委托方式的模式Q都可以使用临时委托来实现。那Z么那么模式都保持了被委托者呢Q我说了。这也提CZ一点，所谓设计模式，不是一成不变的Q是随着具体需要而发展的。也许，你哪天用的是某种设计模式的变形。理解本质，核心的东西，那就让它72变吧。它逃不了的?br /> 也许休息的时间到了，我会量再接下来的几天内Q把q东西写完成?....
待箋......
]]>
1.iterator模式(反向委托)Q这是反向委托的应用之一Q通过被委托者来获得委托实例Q也是被委托者先于委托者创建，客户最l还是面向委托者进行操作，q里q代器就是委托者，集合是被委托者，q只是一个Ş意义上的解释Q例如，当客户C要求跟负责hRq行会话Q而又一时无法找到负责hRӞ 刚好C知道R的下属员工EQ当ӞR会先扑ֈE(只因为E知道R而已QE只完成一件事Q找到R)Q让ELR带到他的面前来，OKQ这L话，C可以和R会话了，但是那个懒散的家伙RQ他q是把事交给了员工EQ那Z么，客户不直接让那员工来处理Q而是找了一个负责h来交付呢Q有一点， 我们会想Q员工别不够高Q没Z鸟你的，太牵ZQ这L解释。因为我们想让客L到这个负责h是以一致的行ؓ在处理事Ӟ其内部处理委托到具体的员工n上。这样就无需暴露员工的内部实现细节，又将不同员工不同处理以一致的方式提供l客戗当Ӟ对客户隐藏实现细节是委托的效果之一Q看你怎么使用它了Q你也可以不用在q代器上Q只要Q何想隐藏实现l节的，你都可以拿去用?
class Aggregate{
private Object[] array;
public Aggregate(int size){
array = new Object[size];
}
public void put(){
for(int i=0;i<array.length;i++){
array[i] = i;
}
}
public Object getAt(int index){
return array[index];
}
public int length(){
return array.length;
}
public Iterator iterator(){
return new Iterator(this);
}
}
class Iterator{
Aggregate aggregate;
int curIndex = 0;
public Iterator(Aggregate aggregate){
this.aggregate = aggregate;
}
public boolean hasNext(){
return curIndex<aggregate.length();
}
public Object next(){
return aggregate.getAt(curIndex++);
}
}
void main(){
Aggregate aggregate new Aggregate();
aggregate.put(); //初始化数?
for(Iterator iterator = aggregate.iterator();iterator.hasNext();){
String value = (String)iterator.next();
System.out.println(value);
}
}
2.adapter(单单向委?:适配器有两种实现实现方式Q其一是委托Q另一U则为ѝ委托方式很单，用简单委托即可实?代码如下Q?
class Adaptee {
public void methodAdaptee(){
....
}
}
class Adapter{
private Adaptee adaptee;
public Adapter(Adaptee adaptee){
this.adaptee = adaptee;
}
public void methodAdapter(){
adaptee.methodAdaptee();
}
}
void main(){
Adapter adapter = new Adapter(new Adaptee());
adapter.methodAdapter();
}
Adapter委托者委托被委托者Adaptee处理。这东西生活中到处都是，比如处理电压不一致问题时所使用的变压器{等。承方式暂略?
3.chain of responsibility(单向单委托的传?Q委托传递过E，构成了该模式Q看例子?
class A{
public void methodA(){}
}
class B{
A a;
public B(A a){
this.a = a;
}
public void methodB(){
if(未处? a.methodA();
}
}
class C{
B b;
public C(B b){
this.b = b;
}
public void methodC(){
if(未处? b.methodB();
}
}
void main(){
C c = new C(new B(new A()));
c.methodC();
}
4.Builder模式(单向单委?Q首先，委托?也就是徏造?Q知道constuct旉要的步骤Q他只是把每一步骤委托l被委托者处理，然后q回最l结果，好比Q包工头Q他知道建造房屋的步骤Q但他不会自己动手，然后在徏造过E中Q他每进行一个阶D都会把该阶D늚建造过E委托给某个工hQ估计这工hq没疯之前，他也惛_Director了，因ؓ他没法自己构造房屋，管他确实有能力Q房屋的从头到脚他都懂。god让他只是个工人?
class Builder{
public void buildpart1(){
}
public void buildpart2(){
}
public void buildpart3(){
}
public Object getResult(){
}
}
class Director {
Builder builder;
public Director(Builder builder){
this.builder = builder;
}
public void constuct(){
builder.buildpart1();
builder.buildpart2();
builder.buildpart3();
builder.getResult();
}
}
void main(){
Director director = new Director(new Builder());
director.constuct();
}
5.proxy(单向单委?,下面是最原始的委托?
class Subject{
public void methodSubject(){
}
}
class Proxy{
private Subject subject;
public Proxy(){
this.subject = new Subject();
}
public void methodProxy(){
subject.methodSubject();
}
}
void main(){
Proxy proxy = new Proxy();
proxy.methodProxy();
}
代理cM于委托，属于委托的一U，但是又有区别Qؓ什么呢Q因Z理h和本有一致的事g处理方式Q我们就是ؓ了让客户分不清是代理人在帮你处理Q还是本人帮你处理，所以必这样做Q同Ӟ我们会把本h和代理hҎ同样的处理方?methodҎ)。出Cq么Ҏ的委托，那么你是不是觉得有点别扭Q好象有U阴影在心里做怪，凭什么要遵守q样的约定，那么我们把q魔鬼驱除吧。我们把q些Ҏ委托的双方的公共行ؓ提取出来Q干什么？安置在接口中Q或抽象cMQ让委托双方都实现或l承它。OK了，问题解决了。必遵循的规则被我们分d来了。之前说q，面向对象思想提倡面向接口或抽象~程Q本来，委托双方都该是基于借口或抽象类的，而且是独立于不同接口或抽象类的，但是Z单v见，我们化了。它与这里提取的共同接口或抽象类是有区别的，q里是ؓ了驱除那该死的魔|同时它也无意识的遵@了面向接口或抽象~程的思想Q一举两得，很好?
演化l果Q?
abstract class Subject{
abstract public void method();
}
class RealSubject extends Subject{
public void method(){
}
}
class Proxy extends Subject{
private Subject subject;
public Proxy(){
this.subject = new RealSubject();
}
public void method(){
subject.method();
}
}
void main(){
Proxy proxy = new Proxy();
proxy.methodProxy();
}
需要记得的一ҎQ委托从不强q你的执行顺序，你可以选择M委托时机Q通用的模型是Q?
(1)委托前的初始化工?
(2)委托q程
(3)委托后的善后处理
以上三步骤可以多层嵌套，需具体而定?
所以，比如在proxy模式里，你可以在交给代理处理前后做你惛_的事?
6.decorator(单向单委?
下面是最原始的委托?
class Component{
public void methodComponent(){
}
}
class Decorator {
private Component component;
public Decorator(Component component){
this.component = component;
}
public void methodDecorator(){
component.methodComponent();
}
}
void main(){
Decorator decorator = new Decorator(new Component());
decorator.methodDecorator();
}
装饰模式Q是动态扩展功能是常用的。先xQ扩展某一cd能，有几U方式？l承Q委托。那Z么不用承呢Q因合度太高，每扩展一个功能就得派生一个新的类Q这Ll果Q会使类层次不断膨胀Q这U膨胀不只是在一个方向上。它横纵通吃Q有一天你会被多叉树似的类蜘蛛|捆住的Q然后蜘蛛慢慢n受它的美。ؓ了逃命我们选择了委托，让装饰者委托被装饰者，同时Z让两者有一致的行ؓ方式Q同h象出接口或抽象类。你会发玎ͼq跟proxy模式l构一LQ没错，基本一栗关键是Q目的不同，装饰模式是ؓ了扩展功能，主要对于层次U别的扩展很有用Q假如，你ؓ了扩展功能而仅仅派生了一个类Q我会徏议你使用Q承扩展。那么层ơ别的扩展什么意思呢Q就是依据扩展树的深度来考虑Q可能是q样的，你扩展了原先的某个类A的methodA功能Q你l它加了文g的持久化功能Q然后，你可能还要在文g持久化上l箋扩展~冲功能。同Ӟ该树很可能是多叉的，所以，你可以按照这U方式进行横向扩展。演化结果：
abstract class Component{
abstract public void method();
}
class ConcreteCompnent extends Component{
public void method(){
}
}
abstract class Decorator extends Component{
protected Component component;
public Decorator(Component component){
this.component = component;
}
public void method(){
component.method();
}
}
class ConcreteDecorator extends Decorator{
public void method(){
base.method();
增加新功?
}
}
proxy可以认ؓ是decorator的简化Ş式，上面提到Qؓ了扩展功能而仅仅派生了一个类的方式是不合理的Q同样通过委托来扩展功能而仅仅得C个装饰者同样也是不可取的，但是Q我们不会抛弃这Ll构Q如果这U情况生了Q我们改变其名称--代理Q同时改变其目的QOKQ得到的是Proxy模式。然后，我想说的是，委托Q是一UŞQ而真正的意是要结合具体模式的Q就象在q里Q它可以被解释ؓ扩展Q也可以被解释ؓ代理。这才是它的意义所在?
]]>
主角呢？问的好奇怪，不就在题目中吗？只是惌己对设计的一点理解记下而已。这或许是我本h对设计模式，当前的，比较深刻的理解?
OKQ什么是设计模式Qh们在解决一个问题时Q都Lq样那样的解x案，其中不乏一U比较好的方案，那么我们对该U方案的抽象Q变成了一U设计模式，可以_设计模式是一U抽象的Q而非具体的思想性的东西。GOF里有23U设计模式，其实没h_设计模式只有这几种Q本文主要对其中部分模式q行研究?
在开始之前，我会说明两点Q第一Qؓ了简单v见，我暂不遵循面向对象设计思想里的某些原则Q比如说面向接口~程Q面向抽象编E，OCP原则{等。但是，你会疑问Q这些原则都没有Q你的设计在哪里Q也讔R是种很糟p的设计Q但是需要注意到的是Q真正项目中Q没有一个优U的设计者，会不大致遵@q些原则Q我说了--单v见，把你带到核心的，本质性的东西Q而非带你dq丛林?..Q很可能Q你会象兔子一P见到萝卜Q把白菜丢了Q我知道Q你也不想那P可惜没办法，E序员的记性就是这样子Q，有一天，你会发现设计模式p么简单，应用的话Q不包含于此?
内容介：1.委托的?.1.1 单委?反向委托) 1.2 双向委托 1.3 多重委托 1.4 双向多重委托
2.回调
3.l承与委?
4 多?
5.主要模式Qiterator, adater, chain of responsibility, builder, proxy, decorator, (template)strategy,bridge, state, visitor,observer, command, mediator.
q些模式的编排依照文中出现的序Qƈ且遵从简单到复杂。其他模式，我会暂时放过他们?
1 委托
委托Q顾名思义Q很单，有些事，或者你不会或者你懒，你交l了另一个h帮你做，q就是委托。但是，误住一点，q里的委托有他拓展的意思，我把所有交l别人做事这一q程定义为委托，可能你会在某些书上看到它--你小子放屁，会被你误倒的Q我会很虚心承认q一点的。但是，它对我有效，如果发现它vCside effect(副作? on you,或许你得停止q场p糕的旅行。回C原来的地斏V?
看了很多文字Q很是糟p，很多Z喜欢Q包括我也是Q我是说之前的我Q但是现在我会很喜欢一些理论性的东西Q然后里面加点实늚味道q去。真是佩服牛人，已经C那种境界。既能当牛，又同时是人?
1.1 单委托：我们定义两个cA,B,然后让B来委托A做事Q不l钱的，
Class A{
methodA() {}
methodA'() {}
}
Class B{
A a;
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){ //q不是我们的目标Q是一个可协商的客P隑־Cq么好的客户
B b = new B();
b.methodB();
}
代码很简单，客户期待的是b对象Q让他处理，然后Q对象b包含的委托对客户是透明的，也就是说main压根不知道有Aq样的一个类存在。但是，目的没达刎ͼ很糟p，出现了NULL PointerQ最p糕的也是最好解决的错误。接下来Q得实例话a对象?
Ҏ1Q分别改cB和main?
Class B{
A a;
B(A a) { //多了构造函敎ͼla附一实例
this.a = a;
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){ //多么和蔼的客P他得Ҏ我们来调_感动....
(1) A a = new A(); //当然Q将(1)(2)写成B b = new B(new A());会显得简z?
(2) B b = new B(a);
b.methodB();
}
待箋......
l箋...... 2008-04-15
Ҏ(2): 我们可以在类B中设|一个方法，setA来给B传递A实例,L刚才的构造函数?
Class B{
A a;
void setA(A a){
this.a = a;
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){
B b = new B();
b.setA(new A());
b.methodB();
}
OK,有效果了。然后，我们怀疑这L逻辑Q客戯某公司的l理谈判目的协议签定问题时Q即使该l理把这事交l了下属d成，客户也得M解那下属家伙I竟做了什么，客户知道的太多了。很不好(pE序员完成某功能Ӟ他得知道很多l节Q这L~程方式比较危险Qؓ什么会q样呢？我们得认真考虑q问题，而这也是现在的想法，我们会想着量好的憧?Q我们l走下去Q下面会有更好点的方案?
Ҏ(3): 我们把对象a的实例化安置CcB里面Q那么这L话，依赖的一方必M解被依赖者，而客户压根不懂委托者?
Class B{
A a;
B(A a){
this.a = new A();
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){
B b = new B();
b.methodB();
}
如果Q用setA函数替代构造函敎ͼ会得到方案（4Q?
Ҏ(4):
Class B{
A a;
void setA(){
this.a = new A();
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){
B b = new B();
b.setA();
b.methodB();
}
到此Q简单的委托处理先告一D落。发现没有，q四U（其实只有两种Q方案我们在新框架出来之后，我们改了名字---注入对象实例。然后，后来(当然是很早以?,配置文g方式的注入，如spring框架Q取了个叫什么依赖注入，反{控制来着。也是q东西确实很单，没啥好说的，但是Q我又说了，是因为，q跟设计模式有莫大的关系Q至我q么觉得?然而，我还是得_以上两种Ҏ各有好处Q在一些简z的设计中，我们会习惯于构造类B时同时给被委托者创建实例，一旦，发现被委托者是动态被注入或者被委托者被多次注入?可以是委托集?Q我们会偏向?2)(4)注入方式。你会发现设计模式大多是q两U方式的?
Ҏ(5): 反向委托Q客户面向BQ而B万一很忙或不在呢Q或者干脆你没权利联pBQ也是你没法实例化一个BQ然后，我们可以通过另一U方式来获取B实例。我U它为反向委?-可能不恰当，我没l过太多考虑.
代码修改如下Q在cA中添加getBҎQ通过实例A来获取B实例?
Class A{
B getB() {
return new B(this);
}
methodA() {}
methodA'() {}
}
Class B{
A a;
B(A a){
this.a = a;
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){
A a = new A();
B b = a.getB();
b.methodB();
}
如果看过设计模式Q细心的你也怼发现了一个这东西很类gIterator模式Qa是个集合对象Qb是个q代器，可以通过一个P代器讉K集合c，把数据的操作和数据分开了。当然此处a,b都是普通类Qa不是集合Qb也不是P代器。具体的演化q程Q接下来的章节将l箋讨论?
1.2 双向委托
看过单委托，估计聪明的你猜到了，双向委托是互相包含依赖Ҏ。没错，是q样的。看例子Q?
Class A{
B b;
A(B b) {
this.b = b;
}
methodA() {}
methodA'() {}
}
Class B{
A a;
B(){
this.a = new A(this);
}
methodB() {
a.methodA();
}
methodB'() {
a.methodA'();
}
}
void main(){
B b = new B();
b.methodB();
}
q是U高度耦合的结构，在他们的世界里，谁都M开谁，cM于，d关系Q咱家没的东西去N居借，d没的东西会来扑֒家借一栗当Ӟq似乎不是很好的设计Q但是确实经常碰刎ͼ也很有用。可以看看敏捯Y件开发里的线E控制的模拟实现---active object模式Q虽Ӟ它不是经典模式之一?
l箋我们的旅E?-2008-04-16
1.3 多重委托
一个类中包含多个被委托者，而这委托是单向的Q当然这些被委托者可以是同类?-UC为委托集合，我们把这U结构定义ؓ多重委托。例子：
Class A{ methodA() {}
methodA'() {}
}
Class A1{ methodA1() {}
methodA1'() {}
}
Class A2{ methodA2() {}
methodA2'() {}
}
Class B{
A a;
A1 a1;
A2 a2;
B(A a, A1 a1, A2 a2){ //此处我们也可以分别定义三个类似setAq样的方法实例化他们
this.a = a;
this.a1 = a1;
this.a2 = a2;
}
methodB() {
a.methodA();
}
methodB1() {
a1.methodA1();
}
}
void main(){
A a = new A();
A1 a1 = new A1();
A2 a2 = new A2();
B b = new B(a, a1, a2);
b.methodB();
}
是q种l构Q类B委托?个其他类A,A1,A2。这里我们也可以分别定义三个cMsetAq样的方法实例化他们Q同时我们也喜欢q样做，因ؓ世界是变化的Q你也得遵@q样的约定。这只个表示多重委托的例子，它是个原型，他还未能用于我们的设计中Q你会发现这U结构有它的~点Q最单之一Q他q反了OCP原则Q这个类B无法扩展，扩展的意义在于不应该通过修改原始代码来完成而应该是通过l承或委托来完成Q想象一下，如果你有一D代码，每次增加新功能或修改bugӞ你都得把cB修改一遍，q样的结果，很简单，有一天你会被自己写的东西Ҏ了，你会感觉CU恐慌，很无助，无奈于客L抱怨声中，同时Q也很难保证目的维护成本。然而这Ll构实Ҏ们的设计h启发性的意义。我们积极去改写q样的结构，使它慢慢处于我们的掌控中Q然后，你会有惊奇的发现?
惌扩展性，我们可以让这些被委托者以集合形式保持住。于是，我们惛_观察者模式，没错Q就是这L一个例子。你q想C么模式呢Q?
1.4 双向多重委托
双向多重委托是比较复杂的l构Q它其实应该是个|状模型Q每一个委托者同时又是被委托者，学过数学的你Q自q其复杂度。然而，问题在于解决问题时应该尽量简单化Q没有Q何一个司机喜Ƣ，在乘客多Ӟ让乘客划招_胜负后再上R。OKQ这Ll构我们会尽量少用，转ؓ利用上面多重委托的变形，在类B中保持多个被委托者的同时Q让各个被委托者持有一个委托者，即类B?
2.回调
回调q个词，你肯定早听说q了Q没啥好说的Q不清楚的百度一下，q里说这个，也啥其他意思。这只是我思考该主题的一个byproduct(副?Q我把对象与对象之间的穿梭行走定义ؓ了回调?
Class A{ methodA(B b) {
b.methodB'();
}
methodA'() {}
}
Class B{
A a;
methodB() {
a.methodA(this);
}
methodB'() {
System.out.println("methodB'");
}
}
void main(){
B b = new B();
b.methodB();
}
q样p实现cB的回调，也许你会认ؓZ么B不直接调用它自己呢？反而绕了一圈呢Q相信聪明的你，以后会慢慢理解的Q在q里Q回调不是主角，同时Q如果你惌q个回调永远持箋下去Q那你就d吧?
3.l承与委?nbsp;
讲了一堆的委托概念--其实不是q些都不l典理论Q只是个人的一Ҏ法而已Q该看看l承了，它已l呆不住了。其实，学过面向对象~程的h都知道，q里只是理理其关pȝŞ了。有一个纂书hQ说了一句经怹aQ承是生离dQ委托是潇洒分离Q我很喜Ƣ这L描述Q这句话提到了，对象与对象之间的耦合性在q两者之间的体现Q每个h都知道其耦合性应该降到最低层ơ。然而承给我们带来的麻烦，他纠~于父类与子cM_例子q在整理?...所以，牛h又说了，量用委托代替ѝ然后，我又怿了。但是，得确认的一ҎQ承也是面向对象的l成之一Q我们该权衡之用。我也自q常用它?
4 多?--暂略q?
在以后的部分Q即开始真正的内容Q它引领你一起去...,你想d里？
]]>