实现一个接口，其中泛型基于该接口
我目前正在重构我的代码，以便所有重要的类都实现一个接口（用于单元可测试性）。我遇到了一个实现 IComparable （非模板化）的类；类似于：
public MyClass : IComparable
{
public int CompareTo(object obj)
{
MyClass cObj = obj as MyClass;
if (cObj == null) { throw new ArgumentException(); }
// etc.
}
}
我想将其接口出来，并在使用时使用泛型； 但是，理想情况
public IMyClass : IComparable<IMyClass>
{
// Other methods here
}
public MyClass : IMyClass
{
public CompareTo<IMyClass>(IMyClass other)
{
...
}
// Other methods here
}
下， MyClass 应该实现 IComparable （然后 MyClass 的子类应该实现 IComparable<） MySubClass>）。
所有这一切都是为了问几个问题：
您对我描述的方法有何看法？有没有更好的方法来进行这种重构？让 MyClass 也实现 IComparable 是否有意义，或者因为我们已经实现了 IComparable，所以没有意义？我可以了解任何专业提示或“最佳”实践吗？
I am currently refactoring my code so that all important classes implement an interface (for unit testability). I came across a class that implements IComparable (non-templated); something like:
public MyClass : IComparable
{
public int CompareTo(object obj)
{
MyClass cObj = obj as MyClass;
if (cObj == null) { throw new ArgumentException(); }
// etc.
}
}
I'm wanting to interface it out, and use generics while I'm at it; something like this:
public IMyClass : IComparable<IMyClass>
{
// Other methods here
}
public MyClass : IMyClass
{
public CompareTo<IMyClass>(IMyClass other)
{
...
}
// Other methods here
}
But then, ideally, MyClass should implement IComparable<MyClass> (and then subclasses of MyClass should implement IComparable<MySubClass>).
All of this to ask several questions:
What do you think of the approach I described? Is there a better way of doing this refactoring? Is there a point in making MyClass also implement IComparable<MyClass>, or is that pointless since we already implement IComparable<IMyClass>? Any pro-tips or "best"-practices I could be made aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
拥有多个不同类型且彼此具有可比性的对象真的有意义吗？该语言允许这样做，但我可以数得过 0 次我必须使用它的次数。
我建议使用
IClass而不是IComparable，并且只让派生类实现IComparable。PS 我也反对添加“用于单元可测试性”的接口。如果您的程序设计需要具有仅接口耦合的工厂模式，那么无论如何都要提高该级别的复杂性。但不要滥用设计让你的测试更容易；使用摩尔代替。
Does it really make sense to have several objects of different types that are all comparable to each other? The language allows this, but I can count on 0 hands the number of times I've had to use it.
I'd recommend using
IClasswithout beingIComparable, and just have the derived classes implementIComparable.P.S. I'm also against adding interfaces "for unit testability". If your program design calls for a factory pattern with interface-only coupling, then by all means code up that level of complexity. But don't abuse the design just to make your tests easier; use Moles instead.
简短的回答：这取决于。
在您的具体示例中，我想说创建不必要的接口（在本例中为
IMyClass）几乎总是错误的，因为它只会为您创造工作。经验法则：仅当多个类实现接口时才使用接口。正如您所指出的，这个特定的接口甚至没有实现使您的类直接具有可比性的目标。至于哪些类应该实现 IComparable（通用或其他），这完全取决于您的比较需求。如果始终在对基类的引用之间进行比较，则派生类不需要实现该接口，因为它永远不会被调用。
Short answer: it depends.
In your specific example, I would say it is almost always the wrong thing to do to create an unnecessary interface (
IMyClassin this case) because it just creates work for you. Rule of thumb: use interfaces only when more than one class implements them. And as you point out this particular interface doesn't even accomplish the goal of making your class directly comparable.As far as which classes should implement
IComparable, generic or otherwise, it depends entirely on what your comparison needs are. If comparison is always done between references to the base class, the derived class doesn't need to implement the interface as it will never be called.