※ 引述《hsnucsc (hsnugo)》之铭言： : 我也有找到另一个方法, 是增加interface : http://www.codingefficiency.com/2009/07/18/ : solid-s-single-responsibility-principle/ : http://0rz.tw/QP6hs (缩过的网址) : 不过仍然让人很难分辨responsibility : 说严格一点, 好像每个method, 都有理由改变 : 但是又不可能把每个method都新增一个物件去处理这项功能 : 希望有人可以帮忙解答 : 谢谢 我发现我没有回答到你问的问题 Orz (结果我打那麽长的废话 -.-) 你说的没错 「好像每个method, 都有理由改变」 但是是否有需要将所有的属性或方法全部分开封装？ 这个问题就要看你是做什麽样的专案了！ 有些专案 某些类别几乎是不会变化 那麽你将它封装的很细就只是白花功夫 但是有些类别很容易被要求改变 那你去使用design pattern就会有效果... 这完全视你的专案目的而定 所以才会在专案一开始 就先做OOA&D 你才会知道这个专案 哪些部分很容易发生改变 而需要使用pattern 这个responsibility完全是看专案需求而定 不过 即使在一个专案下 有一些物件是完全不需要使用pattern来重新封装(因为很少改变) 但是如果你有「先见之明」 觉得这些物件很可能会在将来其他专案被reuse 那麽先套上pattern可以有利於将来的再使用 甚至是专案和专案之间的整合 另外「针对介面写程式」 这句话 就是告诉你SRP的思维 事实上 「真正要履行SRP的就是介面」 专案一开始 真正要规划的 并不是要规划产生多少个类别 而是要规划需要多少个介面(或是抽象类别，以下所说的介面都包含抽象类别) 每个介面都是被规划来处理某些事情 而这些介面必须遵守SRP原则 当一个介面在这个专案下会因为两个截然不同的理由而需要修改时 就必须考虑将介面拆开 并藉由reference来couple到抽离出来的介面 (介面的coupling等於实体类别的松耦合 因为是绑介面而不是绑特定的类别) 最後才去实作你的实体类别 若是一个介面之下 只会有一个类别去实践这个介面(也就是变更需求不大) 通常我们就不会花功夫去做介面 直接在该实体类别去实践这个介面就好 而其实刚刚说的一整个过程 就是依赖倒转原则 Dependency Inversion Principle(DIP) 什麽「细节应该依赖抽象，抽象不应该依赖细节」 这句话听听就好 因为用这种文言文讲给初学者听 根本一点效果都没有 讲白一点 先将「专案的需求」转成「介面或抽象类别」 而每个「介面或抽象类别」都必须只为一种「专案需求的变化」才会改变 这个「介面或抽象类别」所承担的就是单一个变化的responsibility (SRP) 把这些「介面或抽象类别」依循固定规则方式来耦合起来 就是使用design pattern 最後才去实践这些「介面或抽象类别」变成实体类别 就是依赖倒转原则 而要怎麽知道一个「专案」会有多少「专案的需求」 就是靠OO analysis (靠经验可以) 回到一开始你问的「好像每个method, 都有理由改变」 就端看你的OOA做出来的结果是如何啦～ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 203.77.52.127 ※ 编辑: leondemon 来自: 203.77.52.127 (02/26 00:50)