BlogJava-liuqiang5151-文章分类-设计模式http://www.blogjava.net/liuqiang5151/category/31794.htmlzh-cnFri, 30 May 2008 19:35:36 GMTFri, 30 May 2008 19:35:36 GMT60原 设计模式一些原则http://www.blogjava.net/liuqiang5151/articles/203907.html刘强刘强Thu, 29 May 2008 10:16:00 GMThttp://www.blogjava.net/liuqiang5151/articles/203907.htmlhttp://www.blogjava.net/liuqiang5151/comments/203907.htmlhttp://www.blogjava.net/liuqiang5151/articles/203907.html#Feedback0http://www.blogjava.net/liuqiang5151/comments/commentRss/203907.htmlhttp://www.blogjava.net/liuqiang5151/services/trackbacks/203907.html      看过HeadFirst设计模式这本书，感觉对OO的直觉更深了一步。真心推荐朋友们研究一下这本书，它不像四人帮写的那本经典版本，看了就想睡觉。而是犹如讲故事一样带领你在设计模式的国度里畅游。
        今天来说一些设计模式的原则，虽然有的时候在工作中用不上，但是理解了这些原则对培养你的面向对象的思想会有很大帮助的。当你带着这些经验去读一些源码的时候，会情不自禁的联想起这些原则，那种感觉就好像麦当劳。
      还是举个例子来说吧，让我们来设计一个门的类Door，我们先抽象出两个最直接的方法，open, close。
public abstract class Door {
    public abstract void open();
    public abstract void close();
    public final void info() {
        System.out.println("I'm a door");
    }
}
首先我们想到了继承，因为我们是OO程序员嘛，然后分别产生两个子类ChinaDoor ,AmericaDoor
public class ChinaDoor extends Door {
    public void open() {
        System.out.println("China open");
    }
    public void close() {
        System.out.println("China close");
    }
}

public class AmericaDoor {
    public void open() {
        System.out.println("America open");
    }
    public void close() {
        System.out.println("America close");
    }
}

分别提供不同的开关方式。看样一切都还算顺利......
可怕的事情发生了，现在要加入报警功能，于是在基类写个alarm方法，子类纷纷重写这个方法。但是并不是所有的门都有报警功能，于是我们想到了空实现。
但是这样设计并不是很好，继承的坏处体现出来了，于是我们想到了接口。把alarm行为从基类中分离出去，定义为接口，这样让有报警功能的门实现Alarm接口，没有报警功能的类就不实现接口。但是这似乎不是万全之策。
public interface Alarm {
    void doAlarm();
}
虽然这样可以避免上面的尴尬，但是这样却不能得到代码的复用，假如我有1000个类报警的行为都相同，那我还要让这1000个类都去实现这个接口吗。
我们可以设计出一些报警行为的类
public class SoftAlarm implements Alarm {
    @Override
    public void doAlarm() {
        // TODO Auto-generated method stub
        System.out.println("soft alarm");
    }
}

public class SongAlarm implements Alarm {
    @Override
    public void doAlarm() {
        // TODO Auto-generated method stub
        System.out.println("song alarm");
    }
}

现在我们的基类可以这样设计
public abstract class Door {
    private Alarm alarm;
    
    public void setAlarm(Alarm alarm) {
        this.alarm = alarm;
    }
    public abstract void open();
    public abstract void close();
    public final void performAlarm() {
        alarm.doAlarm();
    }
    public final void info() {
        System.out.println("I'm a door");
    }
}

这里保存着一个报警类型的引用，于是这里又引出了一个原则，针对接口编程，不要针对实现编程。这样我们可以很方便的利用多态来调用相应的方法。
好了，我们的门可以正式上线了
public class TestDoor {
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Door door = new ChinaDoor();
        Alarm alarm = new SoftAlarm();
        door.setAlarm(alarm);
        door.open();
        door.performAlarm();
    }
}

运行结果
China open
soft alarm
大家可以看到，在运行的时候动态的传入报警的行为，可以利用多态调用相应的方法，这就是组合的威力。
好了，我们重头看一下，因为有了alarm行为，我们不能用继承来实现了，所以我们把alarm行为抽象了出来。这就是把变化的部分抽象出来，然后利用组合（可以有各种各样的接口）在运行时动态的赋予其行为，因为我们传进去的参数是接口类型，所以我们根本不用管里面是如何运作的。多酷啊。现在你可以在加一个行为自动开关行为autoOpen，利用组合在运行时赋予其职能。gogogo

刘强 2008-05-29 18:16 发表评论
]]>原：装饰器模式http://www.blogjava.net/liuqiang5151/articles/203610.html刘强刘强Wed, 28 May 2008 10:35:00 GMThttp://www.blogjava.net/liuqiang5151/articles/203610.htmlhttp://www.blogjava.net/liuqiang5151/comments/203610.htmlhttp://www.blogjava.net/liuqiang5151/articles/203610.html#Feedback0http://www.blogjava.net/liuqiang5151/comments/commentRss/203610.htmlhttp://www.blogjava.net/liuqiang5151/services/trackbacks/203610.html在OO中，继承可以达到代码复用的目的。但是滥用继承却会使代码具有一定的耦合性。究竟继承应该怎样用，什么时候用，装饰器模式给出了一个很好的例子。
     废话少说，举个例子先。就举个上帝造人的例子吧，首先创建一个Human的基类。
public abstract class Human {
    final void create() {
        System.out.println("create a person");
    }
    protected abstract void doSkill(); 
}
这里有一个抽象方法,并且定义了一个final方法，这就意味着子类不能继承这个方法，而必须重写doSkill方法，doSkill方法到底做什么用一会再探讨。现在我们只知道当实例化一个Human之后，一个person就成型了。下面让我们分别写两个子类。
public class Man extends Human {
    @Override
    protected void doSkill() {
        // TODO Auto-generated method stub
        System.out.println("Im a man");
    }
}

public class Woman extends Human {
    @Override
    protected void doSkill() {
        // TODO Auto-generated method stub
        System.out.println("Im a woman");
    }
}

最基本的，男人和女人。人是造好了，要让他们学东西了。下面就引出了最关键的一个类，装饰器类。
public abstract class DecratorSkill extends Human {   
    protected void pri() {
        System.out.println("im skill");
    }
}
是一个描述技能的类，要装饰到人的身上，给他们赋予技能。
public class Eye extends DecratorSkill {
    Human skill;
    public EagleSkill(Human skill) {
        this.skill = skill;
    }
    
    @Override
    protected void doSkill() {
        // TODO Auto-generated method stub
        skill.doSkill();
        System.out.println("eye");
    }
}

眼睛的类，能看东西。
public class Ear extends DecratorSkill {
    Human skill;
    public WolfSkill(Human skill) {
        this.skill = skill;
    }
    
    @Override
    protected void doSkill() {
        // TODO Auto-generated method stub
        skill.doSkill();
        System.out.println("ear");
    }
}

听东西。
好了，主要类都写完了，下面连上测一下
public class Test {
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Human role = new Man();
        role = new Ear(new Eye(role));
        role.create();
        role.doSkill();
    }

}

打印出
create a person
Im a man
eye
ear
让我们来看一下DecratorSkill这个类，构造函数里面传进来一个Human类的子类的引用，保存起来，当调用doSkill方法的时候，根据多态性调用相应的doSkill方法
再累加上当前类的技能，也就是println出来的那句话，依次类推一直返到最外层，这样最外层的引用当调用doSkill方法的时候就会逐个打印出相应的技能。
这样在程序运行的时候动态的赋予了对象的职责，试想一下如果不这样做，我们要写多少个这样的类，现在只有Eye Ear这两个类，可以组合成一个能看到并且能听到的类，当我们再加入hand, leg,head这些类的时候可以组合成不同的技能，那简直是类爆炸。
其实在我们日常开发中，装饰器模式随处可见，java.io包就是装饰器模式的最好代表。有一个基类InputStream 下面有几个不同的子类FileInputStream ByteArrayInputStream还有一个FilterInputStream，这个类就是装饰类，像BufferedInputStream就是继承FilterInputStream这个类的，在使用的时候我们需要InputStream is = new FileInpuStream("1.txt")，这样生成了一个基本的读文件的类，现在我们需要加入带缓冲区的功能，那我们就用BufferedInputStream这个类来包装，is = new BufferedInputStream(is)，就可以实现带缓冲区的功能了。
好了 今天先写这么多。

刘强 2008-05-28 18:35 发表评论
]]>