※ 引述《tyc5116 (累人啊....)》之铭言：
: 如题,这是我看书想到的一个问题
: 我拿书上的题目来说,有四个class,分别是采购(Purchase),库存(Stock),销售(Sale)
: 以及一个中介者(Mediator)(不把虚拟的算进去的话)
: 彼此是有关联性的,哪一天突然发现有bug,或想重构,或要修改功能,该怎么下手呢?
: 我的问题点在于,以debug来说,假设我觉得Sale部份可能有问题
: 有办法在过程中,先将Sale和其它class的关联性切开,再除错吗?
各别的物件不管有几个，只会与 Mediator 有关联。
Mediator 就是为了避免让个别的 instance 互相产生关联而想出来的做法。
个别的 instance 都只会与 Mediator 建立关系(实际持有 reference)
不同的 instance 要互动，都是透过 Mediator 间接产生关系。
所以，逻辑上，不会出现：
‘有办法在过程中,先将Sale和其它class的关联性切开,再除错吗?’
因为 Sale 在这个 Pattern 扮演的角色就只能与 Mediator 有实质的关系。
而 Mediator 的精要就是：
你已经有许多定义良好(责任明确且实作完整)的可独立运作类别。
为了组装他们成一个新的功能，土法炼钢的方法之一就是：
继承原先的类别，让他们互相持有 instance。
(我相信正常人不太会这么写，这仅是一种 worst case 的例子)
这样你去产生物件关联图就看到一堆线指来指去。
你也能用一些量测软件测出一些指标，简而言之，‘乱写’
当 Mediator 由过去的经验中，被指名为一个 pattern 后，
你依这著这概念实作，对于这个 Pattern 有 sense 的会知道，
若是想理解这组东西的关系，可以直接看 Mediator 本身就好。
在‘实作者良心’的驱使下，
我想它会尽力保持个别物件与 Mediator 有关系，
与其他物件保持一个 Mediator 的距离。
: 又或者哪天我觉得Mediator很乱了,要进行重构,可是有关联性的class很多
: 有办法将Stock和Purchase切开,对Mediator与Sale相关的程式码重构
: 再依此类推,连接Sale,切开Stock,Purchase,重构
: 连接Purchase,切开Sale,Stock,重构.....
: 若这个观念是不对的,麻烦请指正,若这观念可行,麻烦请说明一下实作的方向
: 谢谢
如果你听懂我的解说，我又没有误会您想表答的意思。
那就是你想错了。
我将描述改变一下：
‘如果我发现 Mediator 运作起来的连动效果，
不是合乎我的预期。我该如何做呢？’
‘如果我发现 Mediator 运作起来的连动效果，
合乎我的预期，但它的实作真的很乱。我该如何做呢？’
情况一。
先检查个别物件的逻辑是否正确，若有 TestCase 最好。
当个别物件都正确后，再来检查 Mediator 的逻辑本身。
这时你需要能模仿个别物件状态的工具，
不是你土炮 mock object，就是使用 library。
因为这步是测试 control flow 了，所以顺序就变得重要了。
但通常会因执行次序而有不同结果的，有些常见的情况是：
*. static 造成状态‘遗迹’、‘残渣’，让下一次结果不对
*. 多执行序产生的 race condition 等问题
*. 物件具有需要额外处理的状态，
例如：交易管理，或其它需要 alloc/destroy 生命周期管理的物件
如果你无法 reproduce，我想可以请教一下有经验的 QA，
他们对次序操作很在行的。
情况二。
所有东西都动得跟你想得一样，但你就是不满意现状。
首先，你得完成为了测试情况一的所有 TestCase，与 bug 排除。
重构的事，我想这值得另外深入地学习，但有个小技巧。
你可以利用一下 sequence diagram，
先看一下整个图的执行顺序是不是易懂，
试着以 sequence diagram 调整到易懂为主。
除了排程式码的顺序，
那就是 rename/extract method 能应用的地方了。