野人献曝一下
可能是我习惯swing的设计方式吧
http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/
uiswing/components/border.html
缩：http://0rz.tw/QwN3l
Border机制的设计就是您说的这样
以C 实作画圈圈 D 实作画框框的例子来说
我觉得a.setB(new C("要显示的名字"));
或 a.setB(new D(new Date()));并无奇怪之处
所以XYZ应该也能以此类推
对我来说这种设计在现在或预想中都没有坏处
所以我觉得他是好设计：）
离题一下....
像上面这种写法
绘图物件中会包含一个负责绘出边框的物件
所以我们在component.paint时不用传入所需资讯
（例如边框资讯）
这可以避免出现像是以下
paint(Object arg);
paint(Object ... args);
不定参数、阵列参数、Object（最上层物件）出现的机会
我总觉得这种写法会不清楚arg这个参数的用途
（负责定义此method的人那时候也根本不知道后来的人会丢啥吧= ="）
而arg本身的用途也只有实作的人知道
且这种写法可能会导致大量的转型及if叙述
另一个原因是我讨厌看到参数很~长的method（光看就觉得很累）
所以个人是不太喜欢@@
另外我很佩服他的是在于抽象化的部份
Border这个interface别人只需实作3个method就能应付大部分
想像到的border样式（虽然说paintBorder有点近乎作弊啦...）
如果抽象化做的不好的话
以后就可能遇到此接口无法处理的情况
那只好修改接口或增加其他接口
至于没有参数会不会很奇怪
我觉得不会，毕竟没有理由要使他一定要有参数
虽然说我总觉得不可能会没有参数
（例如：要画的内容、要记录的内容、要传递的目的地...等等）
不过这应该要看您的实作...大家说不准的
嗯...另外
若A提供了（使用BXYZ）处理事情的骨架
如您说的
a.function(){
b.画画() ;
x.纪录() ;
y.传送图片() ;
}
BXYZ就应该要是可以代换的
例如Y的后代实作了多种传送的方式
Socket、FTP、EMAIL甚至是传真（咦
且必须的资讯都已经在new的时候给足了
那A就无需计较现在的"y"到底会怎么传送
（当然使用A的人有可能还是要留意传送方式）
如：
Y sender = SenderFactory.createMailSender("name","passwd",otherInfo);
a.setY(sender);
...
//a画图并记录后，以email的方式送出
a.doFunction();
最后，如果上述的b、x、y很多而且常常是一套的一起换
那应该可以用AbstractFactory组织起来
例如您的情况是"产生一张gif（画画）、
把档名写在mail内容中（记录）并寄到某个信箱（传送图片）"
以及"画出一幅ASCII ART后把'luoqr'附在下面，并以纯文字存在电脑的某个资料夹中"
只有这几种情况的话
应该能写成
void doFunction(ProcessorFactory p){
p.createPainter().画画();
p.createLogger().记录();
p.createSender().传送图片();
}
然后实作几种ProcessorFactory分别对应几种情况
这样就不用每次要换都要set set set
（可以只要setProcessorFactory就好）