Tag: 代码 气味

使用generics类型参数代替System.Type类型的参数。 这是一种气味吗？

我经常看到（例如在许多模拟库中）方法，其中使用generics类型参数代替System.Type类型的参数。 我特别谈到generics类型仅用于typeof(T)操作的情况（即，在方法中的任何地方都没有使用类型T的实例，并且T不用于返回类型或其他参数）。 例如，考虑以下方法： public string GetTypeName(System.Type type) { return type.FullName; } 这种方法通常伴随着通用版本： public string GetTypeName() { return GetTypeName(typeof(T)); } 问题是一种不好的做法还是一种好的做法？ 这是一种语法糖还是更多呢？ 我认为这是滥用语言function来缩写对接受System.Type类型的参数的方法的调用 你觉得这有气味吗？ 这应该避免吗？ 或者这实际上是一种很好的做法（提供一种通用方法作为避免输入typeof()的快捷方式）。 以下是使用我能想到的这种模式的一些实际问题： 如果添加了非System.Type类型的参数 – 可能需要将方法重写（如果参数的顺序在语义上很重要）到非generics版本（否则一些参数将是generics类型参数，而一些参数将是常规参数）。 它需要两个方法（对于在编译时未知类型的情况，通用和非通用）。 因此增加了几乎毫无意义的unit testing。 另一方面，这是一种常见的做法（大多数总是正确的，对吗？）但更重要的是，当我对需要在编译时知道System.Type类型的单个参数的代码进行Extract Method重构时，ReSharper更喜欢该签名（和我学会了接受他们的建议，虽然不是出于信仰，但认真）。

IOC / DI：注册混凝土类型代码气味？

在我目前的项目中，我一直在努力解决这个问题。 我遇到过一些我没有（并且不需要）实现任何特定接口的具体类型的情况。 有时我希望通过容器进行解析，因为类型是在singleon生命周期中注册的; 有时，类型具有构造函数参数，这些参数是较大对象图的一部分，或者自身在单例生命周期中注册。 当我输入如下代码时，我总觉得有点奇怪： Container.RegisterType(); 有关这是代码气味还是违反使用IOC容器的最佳做法的任何想法？