首先，两个职责放在同一个类中，并不代表会发生耦合。
耦合的意思是当一个职责内部发生变动时，会影响到另外一个职责的正常执行。假设把两个职责的代码糅合在一起，形成一个大的代码块，这当然是耦合的，此时修改任何一个职责都要小心，牵一发而动全身。
但是我们可以把这两个职责放在两个不同的方法中，比如拆分成 Game.trackFrame(), Game.calcScore()两个方法后，在修改其中一个职责时，只要输入输出的参数不发生变化，也并不会产生耦合。也就是说，要解决耦合这一问题，并非只有“拆分成两个不同的类”这一个解决方案，在同一个类中拆分成两个方法也可以解决，因为拆分成方法是拆分成类的前提。是否需要拆分成类，还需要有其他方面的考虑，解耦这一理由还不够充分，此处就不详细展开。
其次，很多人都忽略了为何两个职责可以被拆分开。
我们需要回到现实生活来分析保龄球游戏的核心生命周期。
在现实生活中打保龄球时，确实有算分这一环节。在每一次打球结束时， 机器会自动给出分数。当然，在早期没有机器时，这个分数肯定是由打球人自己来算的。为什么后来可以拆分出来交给机器来算呢？因为算分活动必须等待打球结束才能进行，打球与算分二者在执行时间上是属于完全不会发生交叉的两个连续动作，且打球的结果作为算分的输入，所以两个动作本来就是没有耦合的，可以拆分开，成为保龄球游戏生命周期中的两个相续活动。
这两个活动哪一个才是核心生命周期活动呢？可以看到，人们去保龄球馆是为了亲身体验打球，而不是为了体验得分。而且即使没有算分规则，人们也 可以玩的很开心，但如果没有打球的体验，只有算分规则，那么这个游戏也就不成立了。所以，这个游戏的核心生命周期是打球，而非算分。算分只是在打球结束后对结果的计算，属于非核心生命周，因此分数计算规则代码可以从打球代码中拆分出来，以保龄球游戏所产生的结果作为算分的输入来推动执行，形成树状结构。
而在拆分后，Game 的原本功能并没发生任何变化，只不过将其中一个步骤的实现代码分离出去了而已，然后通过方法调用，以直接获取结果的方式整合回归，还是同一个整体，没有发生变化。这一做法，使得 Game 能够更加专注于其本身的职责，分数计算自身也能更加专注，各自被修改时也可以互不影响。
所以，二者能够拆分开，并非“Because each responsibility is an axis of change”，而是因为其中存在非核心生命周期活动。并且拆分也并不仅限于拆分成类，首先应该能拆分成方法，这是拆分为类的前提。