什么时候写代码来预测循环，什么时候专门做一些事情'；X'；时间

本文关键字：什么时候 时间 代码 循环 | 更新日期: 2023-09-27 18:21:45

如果我知道一个方法必须执行一定次数的操作，例如检索数据，我应该编写代码来具体执行所需的次数，还是我的代码能够预测以后的更改？例如，我被告知要编写一个方法，从字典中检索2个值（我在这里称之为Settings），并使用提供的已知密钥返回它们

public Dictionary<string, string> GetSettings()
{
   const string keyA = "address"; //I understand 'magic strings' are bad, bear with me
   const string keyB = "time"
   Dictionary<string, string> retrievedSettings = new Dictionary<string,string>();
    //should I add the keys to a list and then iterate through the list?
    List<string> listOfKeys = new List<string>(){keyA, keyB};
    foreach( string key in listOfKeys)
    {
      if(Settings.ContainsKey(key)
      {
          string value = Setting[key];
          retrieveSettings.Add(key, value);
      }
    }
    //or should I just get the two values directly from the dictionary like so
    if(Settings.ContainsKey(keyA)
    {
        retrievedSettings.Add(keyA , Setting[keyA]);
    }
    if(Settings.Contains(keyB)
    {
        retrievedSettings.Add(keyB , Setting[keyB]);
    }

    return retrievedSettings   
}

我之所以这么问，是因为代码重复总是一件坏事，即DRY，但与此同时，更有经验的程序员告诉我，如果只需要执行已知次数的

什么时候写代码来预测循环，什么时候专门做一些事情'；X'；时间

，就没有必要编写逻辑来预测更大的循环

我会提取一个以键为参数的方法：

private Dictionary<string, string> GetSettings(params string[] keys)
{
    var retrievedSettings = new Dictionary<string, string>();
    foreach(string key in keys)
    {
        if(Settings.ContainsKey(key)
            retrieveSettings.Add(key, Setting[key]);
    }
    return retrievedSettings;
}

你现在可以这样使用这个方法：

public Dictionary<string, string> GetSettings()
{
    return GetSettings(keyA, keyB);
}

我之所以选择这种方法，是因为它使您的主要方法难以理解："啊哈，它得到了keyA和keyB的设置"
即使我确信我永远不需要得到超过这两把钥匙，我也会使用这种方法。换言之，之所以选择这种方法，并不是因为它能预见到以后的变化，而是因为它能更好地传达意图。

然而，使用LINQ，您实际上并不需要提取的方法。你可以简单地使用这个：

public Dictionary<string, string> GetSettings()
{
    return new [] { keyA, keyB }.Where(x => Settings.ContainsKey(x))
                                .ToDictionary(x => x, Settings[x]);
}

DRY原则并不一定意味着程序中的每一行代码都应该是唯一的。这只是意味着你不应该在你的程序中分布大量的代码来做同样的事情。

当您有大量的项目要搜索时，选项1可以很好地工作，但其缺点是使代码的阅读稍微不那么琐碎。

当您有少量选项时，选项2效果良好。它更简单，实际上更高效。

既然你只有两个设置，我肯定会选择第二个选项。为了预期未来的变化而做出这样的决定是浪费精力。我发现这篇文章非常有助于说明过于关注不存在的需求的危险。

相关文章：