嵌套类 - 好的设计？答案

【问题标题】：Nested Class - Good Design?嵌套类 - 好的设计？
【发布时间】：2013-08-31 21:50:37
【问题描述】：

我有一个问题，我有一个解决数字问题的主类。为简单起见，假设它解决了Ax=b。现在，我希望用户能够选择解决它的方法。有数千个选项，每个选项都包含数千个选项。

我的想法是这样设计它：创建一个主类，然后为每个方法创建子类，并为每个方法的细节创建子子类（可能通过继承进行交互）。

例如，我设想用户执行以下操作 - Model.method='CG' Model.preconditioning=off 然后是 Model.Solve 在 Model 类中，有一个 CG 子类在运行。在CG 中，有CG_Precond 和CG_NoPrecond 方法，它们根据预处理的打开或关闭运行。（假设方法大不相同）。所以，本质上，用户正在运行Model.CG.CG_NoPrecond。

这是好的设计吗？应该避免嵌套类吗？

一个重要的注意事项是，除了Model 类之外，所有子类都只包含方法，不包含它们自己的数据（返回的除外）。

我花了一些时间阅读一些关于 SO 的非常漂亮的答案，我的问题（我相信）符合Why/when should you use nested classes in .net? Or shouldn't you? 接受答案的要求。

【问题讨论】：

看来您需要 Strategy (sourcemaking.com/design_patterns/strategy) 设计模式。
只为类提供一个包含所需信息的“ModelSettings”结构会更容易吗？
这样你就有了解决问题的方法树。树上千枝，深三？您可能必须以某种方式生成树。似乎嵌套类比你提到的其他方式更容易阅读......
我没有听从你关于树的论点。我有很多方法，每个方法都有几个旋钮可以转动。
听起来您可以通过将问题划分为子问题来解决您的问题。如果您尝试避免重复代码、上帝对象、循环依赖、过长的方法和其他不良约定，您应该做得很好。专注于保持代码的可读性和可维护性。

标签： oop nested-class

【解决方案1】：

首先，您应该创建一个类Solver 并使用策略模式创建代表解决问题的不同方法的子类。

选项和子选项是一件更难做的事。如果我猜对了，那么CG_Precond 和CG_NoPrecond 应该是CG 的子类（这也是Solver 的子类），因为它们似乎共享一些内部逻辑。

如果选项类似于不同方法的预定义值，其中每种方法都需要其他值和值类型，则变得更加困难。在那里，我希望您提供更多关于选项、子选项等的示例。

【讨论】：