我听过很多关于什么时候应该分解一个类的经验法则（例如，你的类变得难以管理），但我不知道这个问题的具体答案。
我不是在寻找“最佳实践”或“代码味道”。例如，如果我看到重复的代码，我知道有一个特定的解决方案：通过创建一个基类或其他创建一个两者都可以使用的单一方法来消除重复代码。这是我正在寻找的具体，具体答案的示例。
但是我不清楚什么时候应该将一个类分解为两个或更多类。我可以告诉你我的经验法则是，当我看到不止一项广泛的职责时，我会重构出其中一项职责。但这更像是一种“最佳实践”，我想更准确地确定这一点。
我发现最接近的是单一职责原则。“单一职责原则指出每个对象都应该有单一职责。” 但什么是责任？如何准确定义？
Bob Martin 说这是“改变的理由”。举一个具体的例子，假设你有一个应用程序，它接受输入，处理它并创建一个输出。这将使三个方面发生变化 - 输入（可能来自字符串或 XML）。处理器可以改变它的规则。并且输出可能会改变：它可能是字符串、XML 或数据库。所以它会给你三个顶级课程。
同样，不是寻找辩论或最佳实践，而是寻找可靠的分解原则。或者，一个坚实的构图原则可能是一种更好的表述方式。
分解背后的动机是组合——我发现高度组合的应用程序更加灵活且易于使用。
分解的另一个原因是，作为开发人员，我可以通过查看类来更好地理解整个应用程序。我想要清楚地了解一门课程，该课程需要有一个明确的目的。虽然这与类命名有关，但我认为如果一个类有这样的目的，那将是最容易理解的，因此是分解的良好基础。
要将其应用到上面的示例中，很明显如果我需要对输入、处理或输出进行维护，应该在哪里查看，我从显而易见的类开始，因为每个类都有一个明显的目的。（但我只是在这里大声思考，试图为自己澄清。）
所以问题是：分解有什么好处，什么表明一个类应该被分解？