Oop 大类重构规则

这是与我几分钟前提出的一个问题有关的另一个问题。如果我有一个我认为只有一个职责但有很多业务规则的类，而且该类很大，大约4000行或更多，那么不将该类重新划分为多个类就可以了。

一个4000行的类不太容易维护。孤立地测试逻辑片段可能很困难。将其拆分的一个更实际的原因是，如果将其拆分为多个类，则多个程序员可以并行处理它。如果是一门课，这就很难做到

如果将其作为一个整体怪物，您将失去许多良好的软件质量属性。有更好的模式可以降低其内在复杂性，即使它确实是内聚的。

我会说“不”。4000行太大了

我会检查业务规则，看看它们是否暗示该类是真正的复合类。特别是，如果可以将业务规则集划分为合理的子集，那么每个子集都可能表明您的类需要划分为组件，每个组件都有自己的业务规则集，并且这些规则应该在组件之间进行划分

---

我还将考虑将业务规则重构为更紧凑的表示形式。

4000行太多了。要么你有500种方法，要么你有很长的方法。我看不到一条可以管理的路。看起来很明显，但我建议您首先将类似的方法/变量分组在一起。e、 g.所有成本数据改为进入productCost类等。使用查询方法，而不是许多方法正在使用的计算字段

4000行似乎不止一项责任。用一句话描述它的功能。此类根据用户设置转换产品数据。有许多设置供用户选择，我必须考虑所有设置。生成器模式是否适用？“抽象对象的构造步骤，以便这些步骤的不同实现可以构造对象的不同表示。”我同意Mike关于构建器模式的建议。如果这些设置在类实例化之后没有改变，那么类在实例化之后就不会真正“引用”它们。分解这些设置的最大问题是，我所有的方法都使用相同的变量。那么它们不应该留在同一个类中吗？@user:它们都使用相同的变量？你有问题。这些变量中有多少引用了其他对象？需要引用同一组外部对象并不表示这些方法属于一起。它们不引用外部对象如果这真的需要是一个4000行的类，那么这将是我第一次听到这样的事情有一个合理的理由。我想我错过了为什么我应该打破它的原因，除了它更容易阅读，但我真的不认为OOP在这样的应用程序中有什么意义。