紧密集成的私人助手类

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

由于我已经构建并处理了它，因此我得到了很多的通用方法，如buildPanel（边，的categoryID），然后结束了大量的重复，如果在他们里面的语句双方

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

的代码有杂乱的区分，让我感动了很多的逻辑和为了使主类的其他部分更易于阅读和遵循，将组件ID的静态构建器字符串转换为私有助手类。我看到的问题是私有类非常依赖父类中的特定结构。有很少量的封装正在进行，即使代码中的单个组件更易于阅读，我也可能会使逻辑更难以遵循。

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

打字出这一切之后，我倾向于最后一个选项，但我仍然蹂躏/困惑的整个事情...

来源

2010-06-30 Kendrick

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

Demeter的（光耦合）的法不仅应该在类间的关系应用，而且在-方法间的关系。这往往被忽视或低估。但是有时候太多的重构会导致另一个极端：太少的耦合也会变得无法读取（就像有太多的小方法或太多的大方法）。

我经常问自己这样一个问题：不读代码像一本书有明确的章节和故事情节，还是我要读每一段的两倍，或者更糟糕，回头页面明白了吗？

来源

2010-06-30 20:14:34 Abel

我喜欢这本书的比喻。现在，它不符合这个标准，我可能会将其余的实施移到助手类中。当你试图向别人解释你的问题时，你可以更好地理解你的问题。 – Kendrick 2010-06-30 20:26:25

请注意，我不一定表示当你不能“像读一本书一样阅读它或向同事解释”时，你应该将它移动到一个辅助类。重构也意味着您只需重新访问代码并重命名或移动某些方法，合并或扩展它们，检查每个方法的一个函数，创建某些本地字段的属性，或仅添加区域和注释。目标应该是清晰的，并且将事物移出情境（助手类）并不总是意味着它变得更清晰。 – Abel 2010-07-01 06:58:57

如果你从来不使用这个面板机制另一个页面上，然后你不需要重构。

而且，直到你需要使用它的另一个页面上，你不知道如何重构私有类，以使其可重复使用。

来源

2010-06-30 19:56:41

紧密集成的私人助手类

回答

相关问题