C# 结合类继承的接口继承

我对分配给我的任务有问题，我想征求意见

我被告知要实施： IPerson接口 基于IPerson的Person类 i员工和员工扩展i个人和人员

最后一句话让我感到困惑，我不知道如何应对这种要求。我有一个想法，我希望您能够验证，因为人员和员工将使用列表存储，然后：

IEmployee是否会扩展IPerson，而员工是否会实施IEmployee？或者除此之外，员工还应该扩展人员

---

谢谢你回答这个问题

所有员工都是人，因此所有员工都实现了

IEmployee

和

IPerson

。

Employee

类扩展了

Person

类

public interface IPerson
{
}

public class Person : IPerson
{
}

public interface IEmployee : IPerson
{
}

public class Employee : Person, IEmployee
{
}

这就是你想要的：

public interface IPerson { }
public interface IEmployee : IPerson { }
public class Person : IPerson { }
public class Employee : Person, IEmployee { }

---

问题是，在实现接口层次结构之前，您应该三思而后行

您不希望强制接口实现类实现将不使用的方法，因此请考虑使用IEmployee作为参数的方法是否也需要allIPerson属性。如果没有，最好定义一个只包含所需属性的新接口

---

这符合坚实的原则

作为补充：记住C#不支持多重继承。一个类只能扩展一个类，但它可以实现n个接口。只需给

IPerson

一个

string Name

属性和

ieemployee

一个

string EmployeeCode

属性，看看你能得到多少？@COdeCaster你是对的，我应该这么做的。我只是想在实现它之前问一下，最重要的是要确认我的想法，我相信这两种方法（扩展Person和非扩展Person）都会有效，只要它们实现相同的接口，但是员工需要亲自重复所做的事情。最后一点正是我希望您自己了解的。“给一个人一条鱼，你就喂他一天；教一个人钓鱼，你就可以养活他一辈子”。为什么这是OP想要的？@CodeCaster-我认为这直接回答了OP。当然是这样，但没有解释为什么会这样。我不认为“使用这个代码，它会解决你的问题。”“这是一个很有帮助的答案。我认为

员工

应该扩展

人

，这就是我第一次理解这个答案的原因，所以我将把它标记为正确的答案。感谢您确认我的想法。当您试图用过于抽象或模糊的需求来教授OO时，OO开始变得模糊。当然，在日常语言中，“雇员”总是“人”，但这是一个原因，这个

IEmployee

interface需求首先被创建。如果这个例子是针对支付系统，

IEEmployee

显然是错误的。例如，你可能需要支付清洁工的工资（你通过一家公司雇佣），或者雇佣个体经营者

IPayableEntity

会更有意义，因为您无论如何都不会将这些实体作为人来处理，因此，

（I）Person

在继承树中没有位置。我不认为我的解释太抽象，但我用一个详细的示例更新了链接到“不太抽象”的链接。（顺便说一句，你的例子很好…）我不是指你的例子，而是指一般谈论OO设计的问题。所以我们不能谈论OO设计？我不是在批评你的文章，我是在补充我的观点。一般来说，OO示例过于简单化。是的，一个员工就是一个人，所以他可以从中继承，每个人都点头表示理解。一辆汽车和它的轮子有很多联系，所以这应该是一辆汽车的属性，每个人都再次点头表示同意。但是，这些几乎没有触及到您在OO设计中遇到的实际问题，我试图对此进行演示。OP的问题陈述本身只有一个正确答案，为了更多地批评设计，我们需要知道

IPerson

和

ieemployee

应该是什么意思。