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

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

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