关于桥BRIDGE设计模式

我们做了一个系统关于制作相片作品的,包括相册,海报,T恤,台历等,统称为作品,以后有可能增加新的作品,作品,从分类上可以将其抽象出来作品类,这些作品的制作方式都是不同的,但是都是去制作(行为)作品,我可以将这个制作的行为封装,这样就存在了抽象和行为两个维度的变化,这样我是不是可以应用桥模式了,将来增加一个新的作品类型和对应的制作行为就很方便容易扩展了,不知道我这样的设计是否合理!



public interface Makeable {
public void make();
}

public abstract class Product implements Makeable {

}

public class TShirt extends Product {

@Override
public void make() {
// TODO Auto-generated method stub

}

}

public class Album extends Product {

@Override
public void make() {
// TODO Auto-generated method stub

}

}

-----------------------

不过我想来想去......既然是"制作",也就是"生成",也就是new
直接extends 父类然后Override一下构造函数就得了

像上述的结构的话,除非接口是Flyable之类的......
没必要去特意去实现一个makeable接口,因为本身new就是make

[该贴被laoliang于2008-09-04 16:29修改过]
[该贴被laoliang于2008-09-04 16:33修改过]

目前来看是不错的。

如果对于一类产品比方说相册,它有两套或以上的制作方法,用桥是合适的,如果只有一种制作方法就不必要了。
只有一种制作方法的情况的实现:


abstract class Category{
abstract void display(Product product);
}
class Photo extends Category{
public void display(Product product){
//根据产品参数进行一类产品的制作
//do make
//直接添加边框和背景
}
}
class Product{
//先虚拟一下产品的材料,照实际情况定义这个(些)值。
private Stuff stuff;
private Category category;
void display(){
category.display(this);
}
}
class Client{
void test(){
product.display();
}
}

如果有两套或以上的制作方法:

abstract class Displayer{
//添加边框的方法
void addBorder(Stuff stuff);
//添加背景图片的方法
void addBackImg(Stuff stuff);
}
//比如说这个零件制作器需要先把所有的图片转成jpg格式
class OneDisplay extends Displayer{
void addBorder(Stuff stuff){}
void addBackImg(Stuff stuff){}
}
//比如说这个零件制作器需要把图转成png格式
class TwoDisplay extends Displayer{
void addBorder(Stuff stuff){}
void addBackImg(Stuff stuff){}
}
abstract class Category{
protected Displayer displayer;
void setDisplayer(Displayer displayer){
this.displayer=displayer;
}
abstract void display(Product product);
}
class Photo extends Category{
public void display(Product product){
//根据产品参数用具体的零件制作器进行一类产品的制作
displayer.addBorder(product.getStuff());
displayer.addBackImg(product.getStuff());
}
}
class Client{
void test(){
Displayer d;
//get d
Product p;
p.getCategory().setDisplayer(d);
p.display();
}
}