设计模式单一职责原则的理解？

Question

我们知道单一指责原则的目的是只存在一个原因引起类的变化。
那么是否可以这么理解，就是理想情况下，一个类只能有一个方法，但是这样做在实际开发过程中，会引起很多额外的麻烦，所以很多时候，it's hard to say。

可以这么理解吗？

Answer 1

不是吧，目前的时间进行合理的抽象（单一职责=>高内聚），正确的时间进行更加细化的抽象（重构），产品迭代的过程中重构是不可避免的，不可能一步登天。

Answer 2

单一职责， 也就是一个类应该只负责一件事。
关键是取决于你认为这件事请的粒度有多大？
字符串小写转大写是一件事(1)。
字符串处理也是一件事(2)。
如果你认为(1)就是一个职责的话， 那么小写转大写就要写一个类， 判断非空要写一个类， 字符统计就要写一个类。
如果你认为(2)就是一个职责的话， 那么所有字符串处理的东西都在一个类似StringUtils类里面。
所以其实这是比较抽象的东西， 并没有绝对的标准，和具体业务有一定的关系。

Answer 3

不是说只有一个方法，是只能由一个维度引起的变化，这样的好处就是职责分明，结构简单，耦合性地，这样的组织有利于大型程序的组织，试想一下，像QQ这样复杂的App，假如不执行单一职责原则，谁知道一个程序里面包含多少东西，改变一处会有多大影响。