Oop 重用属性-组合优于继承

从头先设计模式（关于装饰模式）：

“完全正确，如果你有 依赖于混凝土构件的 类型，装饰程序将破坏该代码。 只要您只针对 抽象组件类型，使用 装饰程序将对您的用户保持透明 但是，一旦你开始写代码 针对混凝土构件，您需要 重新思考您的应用程序设计和使用 装饰师的名字。”

嗯，我遇到了这个问题，我确实想应用继承，因为我必须重用metods和属性，但我仍然需要基于类/类型进行工作。使用组合而不是继承对方法很有效，但是如何在属性上实现同样的效果呢？我不能用它来作曲。。。还是我

谢谢你的时间，希望你能了解我的英语

编辑1 我的问题是：

• 我有行政人员、主管、技术人员和顾问。管理员负责一组主管、技术人员和顾问。
• 管理员可以使用主管来涵盖技术功能
• 员工是主要角色
• 技术人员也可以是顾问
• 如果执行技术顾问任务，将获得奖金
• 顾问在客户办公室工作，而行政、主管和技术人员在公司办公室工作
• 在公司外工作的员工会有一个手机号码，而在公司工作的员工可以打电话给办公室的实习生
• 员工编号、姓名和工资是了解员工的信息

让他们都有一套值得继承的方法。（有两种方法，一种是知道员工在哪里工作，另一种是告诉电话号码与他联系）。

所以，一开始我从一个类雇员那里继承了他们，但这会导致管理员通过引用雇员来了解他负责的雇员的集合，因此，我不能成为他的雇员集合，并根据他们的角色类型安排他们的工作。

---

我忍不住想我打破了利斯科夫的原则。。。但是继承似乎很方便，尤其是属性。

如果不了解整个上下文，就没有简单的答案。然而，根据我的经验，在这种情况下继承（用户+角色）迟早会导致问题

IMHO的管理员、主管、技术人员和顾问都是雇员，但这并不意味着我们应该以扩展雇员的Admin、Supervisor等类结束。我认为他们都是员工，但他们的角色不同。如果员工和角色之间的关系组织良好，我们可以让员工担任多个角色：

class Employee {}
interface Role {}
class Admin implements Role {}
class Superviosr implements Role {}

类对象应包含所有员工通用的所有属性和行为，角色/角色应确定特定角色的特定行为

---

也许更难的部分将是想出一个好的解决方案，与管理和它的参考其他员工的问题。但是，它需要更多关于如何在代码/应用程序中使用它的信息。

我建议您将其分解为几个问题。一些代码示例会有所帮助，没有代码，没有具体案例的细节，理解问题很复杂。一般来说，在OOP中，您根本不应该“重用属性”，属性是应该封装在类中并保持私有的数据。真正的问题是，所有这些角色都是“真正的”员工吗？如果是的话，那么继承没有什么错。然后，您可以使用isTaskAcceptable（任务）、accept（任务）或类似工具扩展Employee。然后，您不必关注类型，因为所有employee对象都可以自行决定能够执行哪些任务。