如何使这种方法更通用？

Question

我有这个名为LoadToDictionary的方法.它接受字典和文件路径.目前,它看起来像这样: void LoadToDictionary(Dictionary<string, string> dict, string filePath.然后在里面,它会有很多代码将filePath中文件的内容提取到字典中.我想让它更通用,所以它可以,比如说,用一个带有int的字典,以及改变方法中的解析代码的能力.我应该标记此方法,然后覆盖它吗？还有其他方法吗？

Answer 1

过早的普遍性使得过早的优化成为了金钱的根源.一般性是昂贵的,昂贵的代码应该通过明确的好处来证明.

因此,我会根据具体情况推动您的方法的普遍性.我可以想出很多方法来使你的方法更通用:

1. 不要把字符串字典串起来; 把字符串比作任意类型.

2. 不要拿一个Dictionary<...>; 拿一个IDictionary<...>.

3. 不要拿任何字典.采取Action<K, V>行动可能是在字典中输入项目.

4. 不要采用文件名.无论如何,您只是将文件名转换为流,因此请先开始使用Stream.让呼叫者为您打开流.

5. 不要采取流.无论如何,您只是将流转换为一系列项目,因此请IEnumerable<...>调用并让调用者为您解析流.

我们一般能做到这一点吗？假设我们有一个T序列,然后转换成从K到V的映射.我们需要什么？序列,键提取器,值提取器和地图编写器:

static void MakeMap<T, K, V>(this IEnumerable<T> sequence, Action<K, V> mapWriter, Func<T, K> keyExtractor, Func<T, V> valueExtractor)
{
    foreach(var item in sequence)
        mapWriter(keyExtractor(item), valueExtractor(item));
}

注意代码在真正通用时如何变得非常简短.这是非常奇怪的一般,因此呼叫网站现在看起来像一个邪恶的混乱.这真的是你想要的吗？你是否会有效地利用所有这些普遍性？可能不是.你实际拥有哪些场景会促使人们更加普遍？ 使用这些特定方案来激发您的重构.

那是我们可以去的吗？我们能比这更普遍吗？当然.例如,我们可以注意到在那里产生副作用似乎很糟糕.该方法不应该只返回一个新构造的字典吗？该词典的比较政策应该是什么？如果有多个项目具有相同的密钥怎么办？它应该被替换,还是应该让字典实际上是从键到值列表的映射？我们可以采取这些想法并制定一种解决所有这些问题的新方法:

public static ILookup<TKey, TElement> ToLookup<TSource, TKey, TElement>(
this IEnumerable<TSource> source,
Func<TSource, TKey> keySelector,
Func<TSource, TElement> elementSelector,
IEqualityComparer<TKey> comparer) { ... }

嘿,我们刚刚彻底改造了ToLookup()扩展方法.有时,当你使方法足够通用时,你会发现它已经存在.