BlogJava-myjava-文章分类-设计模式

设计模式之我见(3)

iory — Wed, 13 Aug 2008 08:56:00 GMT

继续(2)
主要模式：iterator, adater, chain of responsibility, builder, proxy, decorator, (template)strategy, bridge, state, visitor,observer, command, mediator
7.template(继承与多态)
template算是继承概念里的一个模式，这里提前说了，因为，我认为，他跟strategy有类似之处，所以提前。这结构很简单，主要利用了面向对象的多态特性，抽象类定义的具体实现绑定到派生类，而父类提供了一个模板，来组织全部或部分的结构，从而提供了具有某种普遍一样的行为。具体代码如下：
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(单向简单委托)：但是，如果你在设计中发现，这种高度耦合的结构解决不了你的问题，那么我会推荐采用另一种方案---strategy。该方案同样使用委托，它把通用模板放到了一个独立的类中，给该类注入一个被委托对象实例，然后模板的每一个执行步骤，交给被委托者一一执行。看例子：
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();
}
也许，你看到这样的结构，在哪里？builder模式，对了，看起来，真象孪生兄弟。但是，区别在哪里呢？该模式侧重于算法，某一天，你想到新的改进算法，你完全可以替换该strategy，我想你记得，本文到头到尾都再依赖具体类，Context里的Strategy本该是接口或抽象类的。真正设计时，我们会考虑这点。而对于，builder侧重于建造步骤，当然，如果，哪天你如果突然觉得有一种方式能够更好的建造房屋，那你就去改进房屋的建造细节吧。
9.bridge(单向简单委托)
10.state(单向简单委托)
11.visitor(无任何委托)
我说没任何委托，因为，我没发现，委托者手里揣这被委托者，同时被委托者手里也毫无东西。然而，我还是说它是一种委托，而且是双向简单委托。或许我该把类似这样的无任何委托的东西定义为临时委托。以下我将展示一个从双向简单委托到临时委托的演变过程。当然，我会以雇主和保姆的例子来说明它。因为构造
class Element{
    Visitor v;
    setVisitor(Visitor v){
        this.v = v;
    }
    accept(){
        v.visit();
    }
}
class Visitor{
    Element e;
    setElement(Element e){
        this.e = e;
    }
    visit(){
        访问e的过程。
    }
}
void main(){
    Element e = new Element();
    Visitor v = new Visitor();
    e.setVisitor(v);    //建立双向委托关系
    v.setElement(e);
    e.accept();
}
对于这段代码，我想说明几点：
Element: 表示雇主。
Visitor：表示保姆。
accept：表示雇主让保姆扫地的要求。//至少，扫地是我沿用一开始的感觉，其实，这个形象的描述是我一个好朋友想的，在此表示感谢。当时，我问他有没好例子来描述我给他讲的想法。
visit: 表示保姆扫地过程，当然他需要雇主的扫把和其他一些东西
OK，到现在为止，这代码能正常工作了，他解决了雇主雇用保姆扫地的问题。
让我们理清下逻辑，先是来了一个雇主和一个保姆，然后，雇主要了保姆的资料，同时保姆也要了雇主的资料，这种劳动关系就这么建立了，当雇主要求扫地时即e.accept()，他委托他持有的保姆来干活，而保姆visit()，他无任何参数，因为他也持有雇主了。然而，保姆很懒--你见过保姆很勤快的吗？他告诉雇主，我不想记那么多，你叫扫地时，把你的信息一起携带给我。为什么呢？因为保姆他也想多赚钱，这样方式，他可以为多个雇主服务，得到可观的收入。
于是，出现了下面的改写。
class Element{
    Visitor v;
    Element(Visitor v){
        this.v = v;
    }
    accept(){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问e的过程。
    }
}
void main(){
    Visitor v = new Visitor();
    Element e = new Element(v);
    e.accept();
}
这些新代码，意味着保姆有了新的工作方式，他可以为多个雇主工作，而雇主呢？看到委托了，哦，他只能雇佣一个保姆。你觉得这样如何，我想说的是，如果你想长期雇佣这个保姆，OK，它可以很好的为你工作。
这种方式，一直工作的好好的，保姆很勤劳，雇主也很友善。但是，你可曾想过，哪一天，只要关系中的任何一方翻脸，这将是一大灾烂，双方纠缠不清。所以，雇主有了经验，他不想在第二关卡结束游戏，所以，他决定找一个临时工。更具体的说，他想需要扫地时才去请保姆(但是，他有可能一时半会找不到，这个不管他)，于是，他把保姆的委托也丢掉了，他不再只让固定保姆做事了。OK，他把委托提到参数的位置去了。
class Element{
    accept(Visitor v){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问e的过程。
    }
}
void main(){
    Visitor v = new Visitor();
    Element e = new Element();
    e.accept(v);
}
这样的结果，雇主可以请临时保姆干活，保姆也可以为多个雇主服务，很满意，我们稍微修改成下面。
class Element1{
    accept(Visitor v){
        v.visit(this);
    }
}
class Visitor{
    visit(Element e){
        访问雇主e的过程。
    }
    visit(Element1 e1){        访问雇主e的过程。
    }
}
OK，这样的结果，不会变了吗？当然，我们会尽量保持住，代码写了可不能乱动。但是，有一天，城市里又来了新雇主Element2，保姆为了能为他服务，怎么办，添加visit(Element2 e2)？我建议别这么做，为什么？你违反了游戏规则(OCP)，但是，他对于固定数据结构的具体访问非常有用，如果，他很好的帮助你解决问题，那就用它吧。这个例子，引出了临时委托的概念，那什么时候，会使用它呢？我想说的是，如果委托者要做的事很多，且都是交给被委托者，也就是，委托者与被委托者的交付是频繁的，那么我建议，你保持住这个长期工(对象变量)，除此之外，你会很喜欢找临时工的。这个临时是参数的形式出现在的。所以，所有委托方式的模式，都可以使用临时委托来实现。那为什么那么模式都保持了被委托者呢？我说了。这也提示了一点，所谓设计模式，不是一成不变的，是随着具体需要而发展的。也许，你哪天使用的就是某种设计模式的变形。理解本质，核心的东西，那就让它72变吧。它逃不了的。
也许休息的时间到了，我会尽量再接下来的几天内，把这东西写完成的.....
待续......

iory 2008-08-13 16:56 发表评论

设计模式之我见(2)

iory — Wed, 13 Aug 2008 08:55:00 GMT

其实，最早在思考该主题时，只考虑到上一部分，没想过把具体的设计模式请出来的，然而这样的东西很难说说服力，所以才决定把这些模式解释一遍。喜欢
5.主要模式：iterator, adater, chain of responsibility, builder, proxy, decorator, (template)strategy, bridge, state, visitor,observer, command, mediator
1.iterator模式(反向委托)：这是反向委托的应用之一，通过被委托者来获得委托实例，也就是被委托者先于委托者创建，客户最终还是面向委托者进行操作，这里迭代器就是委托者，集合就是被委托者，这只是一个形意义上的解释，例如，当客户C要求跟负责人R进行会话，而又一时无法找到负责人R时，刚好C知道R的下属员工E，当然，R会先找到E(只因为E知道R而已，E只完成一件事，找到R)，让E去把R带到他的面前来，OK，这样的话，C就可以和R会话了，但是那个懒散的家伙R，他还是把事交给了员工E，那为什么，客户不直接让那员工来处理，而是找了一个负责人来交付呢？有一点，我们会想，员工级别不够高，没人会鸟你的，太牵强了，这样的解释。因为我们想让客户看到这个负责人是以一致的行为在处理事件，其内部处理委托到具体的员工身上。这样就无需暴露员工的内部实现细节，又将不同员工不同处理以一致的方式提供给客户。当然，对客户隐藏实现细节是委托的效果之一，看你怎么使用它了，你也可以不用在迭代器上，只要任何想隐藏实现细节的，你都可以拿去用。
class Aggregate{
    private Object[] array;
    public Aggregate(int size){
        array = new Object[size];
    }
    public void put(){
        for(int i=0;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     }
    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(简单单向委托):适配器有两种实现实现方式，其一就是委托，另一种则为继承。委托方式很简单，用简单委托即可实现,代码如下：
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(单向简单委托的传递)：委托传递过程，构成了该模式，看例子。
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模式(单向简单委托)，首先，委托者(也就是建造者)，知道constuct时需要的步骤，他只是把每一步骤委托给被委托者处理，然后返回最终结果，好比，包工头，他知道建造房屋的步骤，但他不会自己动手，然后在建造过程中，他每进行一个阶段都会把该阶段的建造过程委托给某个工人，估计这工人还没疯之前，他也想当Director了，因为他没法自己构造房屋，尽管他确实有能力，房屋的从头到脚他都懂。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();
}
代理类似于委托，属于委托的一种，但是又有区别，为什么呢？因为代理人和本人要有一致的事件处理方式，我们就是为了让客户分不清是代理人在帮你处理，还是本人帮你处理，所以必须这样做，同时，我们会把本人和代理人改成同样的处理方式(method方法)。出现了这么特殊的委托，那么你是不是觉得有点别扭，好象有种阴影在心里做怪，凭什么要遵守这样的约定，那么我们就把这魔鬼驱除吧。我们把这些特殊委托的双方的公共行为提取出来，干什么？安置在接口中，或抽象类中，让委托双方都实现或继承它。OK了，问题解决了。必须遵循的规则被我们分离出来了。之前说过，面向对象思想提倡面向接口或抽象编程，本来，委托双方都该是基于借口或抽象类的，而且是独立于不同接口或抽象类的，但是为了简单起见，我们简化了。它与这里提取的共同接口或抽象类是有区别的，这里是为了驱除那该死的魔鬼，同时它也无意识的遵循了面向接口或抽象编程的思想，一举两得，很好。
演化结果：
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();
}
需要记得的一点是，委托从不强迫你的执行顺序，你可以选择任何委托时机，通用的模型是：
(1)委托前的初始化工作
(2)委托过程
(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();
}
装饰模式，是动态扩展功能是常用的。先想想，扩展某一类功能，有几种方式？继承，委托。那为什么不用继承呢？因为耦合度太高，每扩展一个功能就得派生一个新的类，这样的结果，会使类层次不断膨胀，这种膨胀不只是在一个方向上。它横纵通吃，有一天你会被多叉树似的类蜘蛛网捆住的，然后蜘蛛慢慢享受它的美餐。为了逃命我们选择了委托，让装饰者委托被装饰者，同时为了让两者有一致的行为方式，同样抽象出接口或抽象类。你会发现，这跟proxy模式结构一样的，没错，基本一样。关键是，目的不同，装饰模式是为了扩展功能，主要对于层次级别的扩展很有用，假如，你为了扩展功能而仅仅派生了一个类，我会建议你使用，继承扩展。那么层次级别的扩展什么意思呢？就是依据扩展树的深度来考虑，可能是这样的，你扩展了原先的某个类A的methodA功能，你给它加了文件的持久化功能，然后，你可能还要在文件持久化上继续扩展缓冲功能。同时，该树很可能是多叉的，所以，你可以按照这种方式进行横向扩展。演化结果：
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的简化形式，上面提到，为了扩展功能而仅仅派生了一个类的方式是不合理的，同样通过委托来扩展功能而仅仅得到一个装饰者同样也是不可取的，但是，我们不会抛弃这样的结构，如果这种情况产生了，我们改变其名称--代理，同时改变其目的，OK，得到的就是Proxy模式。然后，我想说的是，委托，是一种形，而真正的意是要结合具体模式的，就象在这里，它可以被解释为扩展，也可以被解释为代理。这才是它的意义所在。

iory 2008-08-13 16:55 发表评论

设计模式之我见(1)

iory — Wed, 13 Aug 2008 08:53:00 GMT

经过了一个周末足不出户的草稿与总结，终于能记点东西了。这是第一次，一个人写，经过认真思索的东西，因为之前，我发现，我一看这家伙--主题，我会几天就把自己看的东西忘了个精光，实话说，我很认真的，因为有牛人说，依赖程序员的记性，这是非常糟糕的设计。然后，我相信了。
    任何人学某个东西，经历了一个模糊，甚至头破血流的撞墙后，都会留下自己的一点痕迹。这痕迹来自你自己对这家伙的一点认识，或深或浅的，纵使有一天，会产生新的，更有深度的，更本质的理解，至少，它是你现在的理解，能够帮你解释，甚至解决当前面临的问题。
    主角呢？问的好奇怪，不就在题目中吗？只是想自己对设计的一点理解记下而已。这或许是我本人对设计模式，当前的，比较深刻的理解。
    OK，什么是设计模式？人们在解决一个问题时，都总有这样那样的解决方案，其中不乏一种比较好的方案，那么我们对该种方案的抽象，变成了一种设计模式，可以说，设计模式是一种抽象的，而非具体的思想性的东西。GOF里有23种设计模式，其实没人说，设计模式就只有这几种，本文主要对其中部分模式进行研究。
    在开始之前，我会说明两点，第一，为了简单起见，我暂不遵循面向对象设计思想里的某些原则，比如说面向接口编程，面向抽象编程，OCP原则等等。但是，你会疑问，这些原则都没有，你的设计在哪里，也许那是种很糟糕的设计，但是需要注意到的是，真正项目中，没有一个优秀的设计者，会不大致遵循这些原则，我说了--简单起见，把你带到核心的，本质性的东西，而非带你去凌乱的丛林中...（很可能，你会象兔子一样，见到萝卜，把白菜丢了，我知道，你也不想那样，可惜没办法，程序员的记性就是这样子），有一天，你会发现设计模式就这么简单，应用的话，不包含于此。
    内容简介：1.委托的使用..1.1 简单委托(反向委托) 1.2 双向委托 1.3 多重委托 1.4 双向多重委托
             2.回调
             3.继承与委托
             4 多态
             5.主要模式：iterator, adater, chain of responsibility, builder, proxy, decorator, (template)strategy,bridge, state, visitor,observer, command, mediator.
    这些模式的编排依照文中出现的顺序，并且遵从简单到复杂。其他模式，我会暂时放过他们。
1 委托
    委托，顾名思义，很简单，有些事，或者你不会或者你懒，你交给了另一个人帮你做，这就是委托。但是，请记住一点，这里的委托有他拓展的意思，我把所有交给别人做事这一过程定义为委托，可能你会在某些书上看到它--你小子放屁，会被你误倒的，我会很虚心承认这一点的。但是，它对我有效，如果发现它起到了side effect(副作用) on you,或许你得停止这场糟糕的旅行。回到你原来的地方。
    看了很多文字，很是糟糕，很多人不喜欢，包括我也是，我是说之前的我，但是现在我会很喜欢一些理论性的东西，然后里面加点实践的味道进去。真是佩服牛人，已经到了那种境界。既能当牛，又同时是人。
   1.1 简单委托：我们定义两个类A,B,然后让B来委托A做事（不给钱的，）,但是会有代价。
       Class A{
          methodA() {}
          methodA'() {}
       }
       Class B{
          A a;
          methodB() {
            a.methodA();
          }
          methodB'() {
            a.methodA'();
          }
       }
       void main(){   //这不是我们的目标，是一个可协商的客户，难得碰上这么好的客户
          B b = new B();
          b.methodB();
       }
   代码很简单，客户期待的是b对象，让他处理，然后，对象b包含的委托对客户是透明的，也就是说main压根不知道有A这样的一个类存在。但是，目的没达到，很糟糕，出现了NULL Pointer，最糟糕的也是最好解决的错误。接下来，得实例话a对象。
方案1：分别改类B和main为
     Class B{
         A a;
         B(A a) {            //多了构造函数，给a附一实例
            this.a = a;
         }
         methodB() {
            a.methodA();
         }
         methodB'() {
            a.methodA'();
         }
     }
     void main(){    //多么和蔼的客户，他得根据我们来调整，感动....
(1)      A a = new A();  //当然，将(1)(2)写成B b = new B(new A());会显得简洁
(2)      B b = new B(a);
         b.methodB();
     }
待续......
继续...... 2008-04-15
方案(2): 我们可以在类B中设置一个方法，setA来给B传递A实例,去掉刚才的构造函数。
      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,有效果了。然后，我们怀疑这样的逻辑，客户跟某公司的经理谈判项目的协议签定问题时，即使该经理把这事交给了下属去完成，客户也得去了解那下属家伙究竟做了什么，客户知道的太多了。很不好(就象程序员完成某功能时，他得知道很多细节，这样的编程方式比较危险，为什么会这样呢？我们得认真考虑这问题，而这也是现在的想法，我们会想着尽量美好的憧憬)，我们继续走下去，下面会有更好点的方案。
方案(3): 我们把对象a的实例化安置到了类B里面，那么这样的话，依赖的一方必须了解被依赖者，而客户压根不懂委托者。
      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();
      }
如果，用setA函数替代构造函数，会得到方案（4）
方案(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();
      }
到此，简单的委托处理就先告一段落。发现没有，这四种（其实只有两种）方案我们在新框架出来之后，我们改了名字---注入对象实例。然后，后来(当然是很早以前),配置文件方式的注入，如spring框架，取了个叫什么依赖注入，反转控制来着。也就是这东西确实很简单，没啥好说的，但是，我又说了，是因为，这跟设计模式有莫大的关系，至少我这么觉得。然而，我还是得说，以上两种方案各有好处，在一些简洁的设计中，我们会习惯于构造类B时同时给被委托者创建实例，一旦，发现被委托者是动态被注入或者被委托者被多次注入时(可以是委托集合)，我们会偏向于(2)(4)注入方式。你会发现设计模式大多是这两种方式的。
方案(5): 反向委托：客户面向B，而B万一很忙或不在呢，或者干脆你没权利联系B，也就是你没法实例化一个B，然后，我们可以通过另一种方式来获取B实例。我称它为反向委托--可能不恰当，我没经过太多考虑.
代码修改如下：在类A中添加getB方法，通过实例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();
       }
如果看过设计模式，细心的你也许会发现了一个这东西很类似于Iterator模式，a是个集合对象，b是个迭代器，可以通过一个迭代器访问集合类，把数据的操作和数据分开了。当然此处a,b都是普通类，a不是集合，b也不是迭代器。具体的演化过程，接下来的章节将继续讨论。
1.2 双向委托
    看过简单委托，估计聪明的你猜到了，双向委托就是互相包含依赖对方。没错，确是这样的。看例子：
       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();
       }
这是种高度耦合的结构，在他们的世界里，谁都离不开谁，类似于，邻居关系，咱家没的东西去找邻居借，邻居没的东西会来找咱家借一样。当然，这似乎不是很好的设计，但是确实经常碰到，也很有用。可以看看敏捷软件开发里的线程控制的模拟实现---active object模式，虽然，它不是经典模式之一。
继续我们的旅程--2008-04-16
1.3 多重委托
    一个类中包含多个被委托者，而这委托是单向的，当然这些被委托者可以是同类型--称之为委托集合，我们把这种结构定义为多重委托。例子：
       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){       //此处我们也可以分别定义三个类似setA这样的方法实例化他们
            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();
       }
   就是这种结构，类B委托了3个其他类A,A1,A2。这里我们也可以分别定义三个类似setA这样的方法实例化他们，同时我们也喜欢这样做，因为世界是变化的，你也得遵循这样的约定。这只个表示多重委托的例子，它是个原型，他还未能用于我们的设计中，你会发现这种结构有它的缺点，最简单之一，他违反了OCP原则，这个类B将无法扩展，扩展的意义在于不应该通过修改原始代码来完成而应该是通过继承或委托来完成，想象一下，如果你有一段代码，每次增加新功能或修改bug时，你都得把类B修改一遍，这样的结果，很简单，有一天你会被自己写的东西淹没了，你会感觉到一种恐慌，很无助，无奈于客户的抱怨声中，同时，也很难保证项目的维护成本。然而这样的结构确实对我们的设计具有启发性的意义。我们积极去改写这样的结构，使它慢慢处于我们的掌控中，然后，你会有惊奇的发现。
    想要扩展性，我们可以让这些被委托者以集合形式保持住。于是，我们想到观察者模式，没错，就是这样的一个例子。你还想到什么模式呢？
1.4 双向多重委托
    双向多重委托是比较复杂的结构，它其实应该是个网状模型，每一个委托者同时又是被委托者，学过数学的你，自己算算其复杂度。然而，问题在于解决问题时应该尽量简单化，没有任何一个司机喜欢，在乘客多时，让乘客划拳决胜负后再上车。OK，这样的结构我们会尽量少用，转为利用上面多重委托的变形，在类B中保持多个被委托者的同时，让各个被委托者持有一个委托者，即类B。
2.回调
    回调这个词，你肯定早听说过了，没啥好说的，不清楚的百度一下，这里说这个，也啥其他意思。这只是我思考该主题的一个byproduct(副产品)，我把对象与对象之间的穿梭行走定义为了回调。
       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();
       }
   这样就能实现类B的回调，也许你会认为为什么B不直接调用它自己呢？反而绕了一圈呢，相信聪明的你，以后会慢慢理解的，在这里，回调不是主角，同时，如果你想让这个回调永远持续下去，那你就去做吧。
3.继承与委托
     讲了一堆的委托概念--其实不是这些都不经典理论，只是个人的一点想法而已，该看看继承了，它已经呆不住了。其实，学过面向对象编程的人都知道，这里只是理理其关系罢了。有一个纂书人，说了一句经典之言，继承是生离死别，委托是潇洒分离，我很喜欢这样的描述，这句话提到了，对象与对象之间的耦合性在这两者之间的体现，每个人都知道其耦合性应该降到最低层次。然而继承给我们带来的麻烦，他纠缠于父类与子类之间，例子还在整理中....所以，牛人又说了，尽量用委托代替继承。然后，我又相信了。但是，得确认的一点是，继承也是面向对象的组成之一，我们该权衡之使用。我也自己经常用它。
4 多态 --暂略过
     在以后的部分，即将开始真正的内容，它将引领你一起去...,你想去哪里？

iory 2008-08-13 16:53 发表评论