使用接口可以使用继承钻石吗？ [英] Is it okay to have an inheritance diamond using interfaces?
问题描述
作为一名长期的C ++程序员，我一直在寻找继承钻石的危险（可能在C ++中，因为它允许多重继承）。
在我目前的C＃程序中，我刚刚发现我在做同样的事情，但使用接口，我想知道如果功能正常吗？这是一个不好的做法，如果是的话，我应该如何重新考虑它呢？
这个完整的程序显示了我的意思的一个例子： br />
Hi,
As a long-time C++ programmer, I am always on the lookout for the dangers of the inheritance diamond (possible in C++ because it allows multiple inheritance).
In my current C# program, I have just discovered I am doing the same thing but using interfaces, and I am wondering if it is functionally okay? Is it a bad practise, and if it is, how should I be looking to re-factor it?
This complete program shows an example of what I mean:
using System;
namespace ConsoleApplication1
{
public interface IBaseService
{
int X { get; }
}
public interface ISpecificService : IBaseService
{
int Y { get; }
}
public abstract class ServiceBase : IBaseService
{
public int X { get { return 42; } }
}
public class ConcreteClass : ServiceBase, ISpecificService
{
public int Y { get { return 43; } }
}
class Program
{
static void Main( string[] args )
{
ConcreteClass c = new ConcreteClass();
Console.WriteLine( $"X={c.X.ToString()}, Y={c.Y.ToString()}" );
Console.ReadKey();
}
}
}
输出为：'X = 42，Y = 43' 。
非常感谢任何有用文章的建议或指示。
给点儿关于现实情况的更多细节，我有以下内容：
我有一个 IBaseService ，这是我所有服务必须实施的核心合同。这些功能没有基类实现，因此它需要是一个接口。
我有特定的服务，必须实施核心合同但也在合同中添加自己的要求。再一次，没有基类实现这些是可能的，所以这些特定的服务也需要是接口。
我也希望有一个家其他一些具有基类具体实现的功能，因此我对此代码有一个抽象的 ServiceBase 。
因此，任何具体服务都可以从 ServiceBase 中获得具体公共代码的好处，但是必须实现它也继承的接口链所规定的合同。
这一切看起来都很合乎逻辑，我很难看到我能做些不同的事情，而不会减少新程序员（或者我在一周的时间内）的可能性来吧，写一个新的服务，不履行所有的义务，并可以利用共同的代码。
编码比解释更容易。希望这是有道理的。
亲切的愿望~Patrick
我的尝试：
我已经尝试过上面的代码了，显然，它运行正常。猜猜我对设计严重错误感到困扰。
Output is: 'X=42, Y=43'.
Any advice or pointers to useful articles would be very much appreciated.
To give a bit more detail about the real-world situation, I have the following:
I have an IBaseService, which is the core contract that all my services must implement. No 'base-class' implementation is possible for these functions and hence it needs to be an interface.
I have specific services, which must implement the core contract but also add their own requirements to the contract. Once again, no 'base-class' implementation of these is possible, so these specific services also need to be interfaces.
I also would like to have a home for some other functionality that does have a 'base-class' concrete implementation, and so I have an abstract ServiceBase for this code.
Any concrete service thus gets the benefit of the concrete common code from the ServiceBase but then has to implement the contract dictated by the chain of interfaces it also inherits.
It all seems quite logical, and I struggle to see which bits I could do differently without reducing the chance that a new programmer (or me in a week's time) might come along and write a new service that doesn't fulfil all of its obligations and can take advantage of common code.
It's easier to code than explain. Hope this makes sense.
Kind wishes ~ Patrick
What I have tried:
I've tried the code above, obviously, which works fine. Guess I am more bothered about something being seriously wrong with the design.
推荐答案
X = {cXToString（）}，Y = {cYToString（）}）;
Console.ReadKey（）;
}
}
}
"X={c.X.ToString()}, Y={c.Y.ToString()}" ); Console.ReadKey(); } } }
输出为：'X = 42，Y = 43' 。
非常感谢任何有用文章的建议或指示。
给点儿关于现实情况的更多细节，我有以下内容：
我有一个 IBaseService ，这是我所有服务必须实施的核心合同。这些功能没有基类实现，因此它需要是一个接口。
我有特定的服务，必须实施核心合同但也在合同中添加自己的要求。再一次，没有基类实现这些是可能的，所以这些特定的服务也需要是接口。
我也希望有一个家其他一些具有基类具体实现的功能，因此我对此代码有一个抽象的 ServiceBase 。
因此，任何具体服务都可以从 ServiceBase 中获得具体公共代码的好处，但是必须实现它也继承的接口链所规定的合同。
这一切看起来都很合乎逻辑，我很难看到我能做些不同的事情，而不会减少新程序员（或者我在一周的时间内）的可能性来吧，写一个新的服务，不履行所有的义务，并可以利用共同的代码。
编码比解释更容易。希望这是有道理的。
亲切的愿望~Patrick
我的尝试：
我已经尝试过上面的代码了，显然，它运行正常。猜猜我对设计中出现严重错误的事情更加困扰。
Output is: 'X=42, Y=43'.
Any advice or pointers to useful articles would be very much appreciated.
To give a bit more detail about the real-world situation, I have the following:
I have an IBaseService, which is the core contract that all my services must implement. No 'base-class' implementation is possible for these functions and hence it needs to be an interface.
I have specific services, which must implement the core contract but also add their own requirements to the contract. Once again, no 'base-class' implementation of these is possible, so these specific services also need to be interfaces.
I also would like to have a home for some other functionality that does have a 'base-class' concrete implementation, and so I have an abstract ServiceBase for this code.
Any concrete service thus gets the benefit of the concrete common code from the ServiceBase but then has to implement the contract dictated by the chain of interfaces it also inherits.
It all seems quite logical, and I struggle to see which bits I could do differently without reducing the chance that a new programmer (or me in a week's time) might come along and write a new service that doesn't fulfil all of its obligations and can take advantage of common code.
It's easier to code than explain. Hope this makes sense.
Kind wishes ~ Patrick
What I have tried:
I've tried the code above, obviously, which works fine. Guess I am more bothered about something being seriously wrong with the design.
在C＃中不可能得到一些'纯'钻石继承（没有多重继承），但你可以得到像这：
It is impossible to get some 'pure' diamond inheritance in C# (no multiple inheritence), but you can get smething like this:
interface IA
{
void MethodA();
}
interface IB : IA
{
void MethodB();
}
interface IC : IA
{
void MethodC();
}
class D : IB, IC
{
public void MethodA()
{
//
}
public void MethodB()
{
//
}
public void MethodC()
{
//
}
}
至于好的或坏的部分......很难说，因为我们不知道你为什么到那里......它看起来不像在你的样本中太好了，但在现实生活中它很容易被证明......当然，你可以放松一下，C＃不会让你做一些像多重继承那样糟糕的事情： - ）......
As for the good-or-bad part...It is hard to tell as we do not know why you got there...It does not look too good in your sample, but in real life it can be justified easily...For sure, you can relax, C# will not let you do something that bad as multiply inheritence :-)...
这篇关于使用接口可以使用继承钻石吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
