现在有两个类
class A
{
B bb;
int getSomething()
{
return B.getInt(this);
}

void setB(B pb)
{
this.bb = pb;
}
}

class B
{
int getInt(A aa)
{
...code...
return 1 或 0;
}
}

调用时
B b = new B();
A a = new A();
a.setB(b);
print a.getSomething();

z请问 A和B之间的关系应该是什么关系,用uml来怎么画?

我估计大部分的情况下，你是可以用多个方法的参数实现的，建议把
int getInt(A aa)
改成
int getInt(int n1, int n2, ...)


这样大体上就可以归并flyweight pattern 里去了

谢谢,我当时这样写主要是想,将对象传过去可能扩展性好些.
我当时自己觉得这样写比较怪,不知道这样写是不是有什么不好?

 可能刚才是我弄错了...
　

---

我有一个问题没弄清楚：B中有没有业务数据
我楼上的说法仅限于“B中也存储了业务数据”的情况，没细看题目，就想当然了 :(



如果没有业务数据的话就是我弄错了
这样的话你的做法是典型的strategy pattern(虽然我个人极不喜欢把代码放在独立的对象里，并称之为类的做法，觉得这只有学术意义)

我个人的习惯是：
如果有setB 这样的操作的话，我用state pattern
否则我会用template method pattern

我还有点想法要说：
“面对对象”理论中的类图，就是在考虑：什么是术语概念
包括类图上我们可以看见许多的关联，其实关联也都是用来辅助说明“什么是术语”的
类图无法体现“如何通过业务逻辑得到最佳的类图”，甚至不能保证“业务逻辑是正确的”，类图只是说明根据业务逻辑设计的软件




至于这个strategy pattern，明显地带有代码和数据相分离的企图
代码和数据肯定都是软件中必然接触到的术语，但是这种企图似乎并不值得面对对象的系统分析员们提倡，我个人认为这种样式下的类图肯定不会是“最佳的类图”

其它明显带这种企图的pattern 还包括：
Memento
Iterator
Visitor