※ 引述《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 能应用的地方了。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.231.49.183 ※ 编辑: qrtt1 来自: 61.231.49.183 (02/20 22:57)