我不太确定如何标题这个问题,但基本上我有一个这样的界面:
public interface IFoo
{
string ToCMD();
}
几个实现 IS Food 的抽象类,例如:
public abstract class Foo : IFoo
{
public abstract string ToCMD();
}
public abstract class Bar : IFoo
{
public abstract string ToCMD();
}
然后继承 Foo 和 Bar 的类:
public class FooClass1 : Foo
{
public override string ToCMD()
{return "Test";}
} ///there are about 10 foo classes.
public class BarClass : Bar
{
public override string ToCMD()
{return "BarClass";}
} ///about the same for bar classes.
我这样做是为了当我有自定义列表时,例如:
public class Store<T> : List<T> where T : IFoo {}
然后我可以限制其中的类型,但通过接口,它仍然可以采用任何类型的 IFoo。
就像是:
Store<Foo> store = new Store<Foo>(); //Only Foo types will work.
store.Add(new FooClass1()); //Will compile.
Store<IFoo> store = new Store<IFoo>(); //All IFoo types will work.
store.Add(new FooClass1()); //Will compile.
store.Add(new BarClass()); //Will compile.
我的问题是:这是解决这个问题的好方法吗?或者,还有更好的方法?
EDIT: Picture->
一般来说,是否需要继承链是值得怀疑的。
然而,将抽象基类与接口相结合的具体场景..我是这样看的:
如果你有这样的抽象基类,那么你也应该有一个相应的接口。如果您有接口,则仅在继承链合理的情况下使用抽象基类。
也就是说,如果我正在编写一个库并且这是我的 API/框架的一部分,我通常会包含一个可以用作基类的“默认实现”。它将在可能的情况下以简单、通用的方式实现接口方法,并将其余的留给继承者根据需要实现/覆盖。
但这只是该库的一个便利功能,通过提供可能涵盖他们已经需要实现的大部分内容的功能示例来帮助想要实现该接口的人。
简而言之,接口比基类更有价值,但是基类可能会节省大量时间并减少有缺陷的接口实现。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)