【问题标题】:Is there any benefit to this refactoring?这种重构有什么好处吗?
【发布时间】:2011-08-02 19:38:03
【问题描述】:

有一个类通过每个表有 1 个string[] 变量来定义各种表中的主键。例如:

static string[] my_table_foo_TablePrimaryKeys = new string[] { "primary_key1", "primary_key2" }
static string[] my_table_bar_TablePrimaryKeys = new string[] { "user_id", "customer_number" }

对于我们稍后添加第三个表并且我们想回到这个类来定义新的第三个表的主键的情况,我发现这有点混乱并且不太可扩展。因此,我将其重构为如下所示:

    static Dictionary<string, string[]> tablePrimaryKeys = new Dictionary<string, string[]>()
    {
        {"my_table_foo", new string[] { "primary_key1", "primary_key2" }},
        {"my_table_bar", new string[] { "user_id", "customer_number" }}
    };

你们认为这是一个不错的重构更改吗?为什么?

此外,在我看来,引用主键的地方也更简洁一些。示例:

前一种情况:

DoStuffWithPrimaryKeys( my_table_foo_TablePrimaryKeys, "other stuff", 1000 );

在后一种情况下:

string[] keys = tablePrimaryKeys["my_table_foo"];
DoStuffWithPrimaryKeys( keys, "other stuff", 1000 );

如果有人还想提一下“可接受的重构”的原则是什么,以及如何知道什么是可接受的重构,什么是不可接受的,那就太好了,而且很有教育意义。

我正在使用 C# 和 .NET 3.5。

【问题讨论】:

  • 如果my_table_foo 只存在于数据库中,这不是数据库问题吗?如果my_table_foo 有一个匹配的 C# 类,你考虑过属性吗?

标签: c# refactoring


【解决方案1】:

我对这种变化并不太感兴趣。这两种情况对我来说都是可疑的,但在第一种情况下,至少你从编译器那里得到了一定程度的安全性。只要在变量初始化的地方键拼写正确,无论何时使用它们都会按预期工作。

重构后,您将在任何地方使用字符串,任何地方的拼写错误都会导致运行时错误。

【讨论】:

  • 好点。不幸的是,由于复杂的原因,高级架构无法改变,我不会在这里讨论,但我试图通过改进我能做的事情来解决这个问题。我认为字典会为我买一个更清洁的实现,但事实证明它并没有真正为我节省多少。
【解决方案2】:

这些对我来说都不好看。我不知道您的系统的要求是什么,但我会在这里查看更大的图景,看看是否有更好的方法来完全做到这一点。至于这里的重构,我不会打扰,并没有真正为变更风险增加任何大的好处。

【讨论】:

    【解决方案3】:

    我会说它没有更好或更坏。您只是在引入魔术字符串而不是变量名。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2023-04-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-02-06
      • 2010-09-14
      • 1970-01-01
      相关资源
      最近更新 更多