※ 引述《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做出来的结果是如何啦～