ASP.NET中紧密集成的私有帮助器类

Question

半不重要的背景： 我在一个有两套可折叠面板的页面上工作。 （使用nHibernate）我得到带有项目列表的类别对象，并为每个类别生成左侧面板和右侧面板。在两个面板中，都有一个ListBox。项目已预先填充到左侧列表框中，用户可以选择项目并将其移动到右侧列表框中（在相应的类别下）。

当我构建并使用它时，我最终得到了许多泛型方法，比如buildPanel（side，categoryID），然后最终在其中有很多重复的if语句来区分双方

if type=PanelType.Left then 
    set these 5 id strings to access components
else
    ...

代码变得混乱，因此我将组件ID的许多逻辑和静态构建器字符串移动到私有辅助类中，以便使主类的其他部分更易于阅读和遵循。我看到的问题是私有类非常依赖于父类中的特定结构。即使代码中的各个组件更易于阅读，我也可能更难以遵循逻辑封装。

我的问题是：当你使用这样的私有类时，将它与父类紧密集成是可以接受的（因为它是私有的并且在同一个文件中实现），我最好再次重构并查找一种简化我的原始代码的方法，如果没有帮助程序类，可以尽可能地缩短（在一个地方粘贴所有类别/面板功能，当我不使用它们时将它们隐藏在自己的区域中），或者我应该转向放置更多辅助类中的逻辑，只是简单地将我的事件映射到子类。

输入所有这些后，我倾向于最后一个选项，但我仍然对整个事情感到困惑/困惑......

Answer 1

如果您从未在其他页面上使用此面板机制，则无需重构。

此外，在您需要在另一个页面上使用它之前，您不知道如何重构私有类以使其可重用。

Answer 2

页面是类，任何类都可以变得笨重。当你来到代码严重耦合的阶段时，它取决于这种耦合如何显示你是否应该重构。如果代码清晰，简洁且易于理解，则可以保持原样。但如果难以理解，如果你无法在几分钟内向同事解释，或者你认为自己半年内不会理解，那么它就有资格进行重构。

德米特定律（光耦合）不仅应用于类间关系，还应用于方法间关系。这经常被忽视或低估。但有时过多的重构导致另一个极端：太少的耦合也变得不可读（就像有太多的小方法或太多的大方法）。

我经常问自己一个问题：代码读起来是不是一本书有清晰的章节和故事情节，或者我是否必须阅读每个段落两次，或者更糟糕的是，转回页面来理解它？