重用属性——组合优于继承答案

【问题标题】：Reusing attributes - Composition over inheritance重用属性——组合优于继承
【发布时间】：2016-01-31 00:44:44
【问题描述】：

从头开始设计模式（关于装饰器模式）：

“完全正确。如果你有依赖于具体组件的代码类型，装饰器将破坏该代码。只要你只写代码抽象组件类型，使用装饰器将保持对您的透明代码。但是，一旦您开始编写代码针对具体的组件，你会想要重新考虑您的应用程序设计和使用装饰器。”

好吧，我遇到了这个问题，我确实想应用继承，因为我必须重用方法和属性，但我仍然需要基于类/类型工作。使用组合而不是继承对方法很有效，但是我怎样才能在属性上实现相同的效果呢？我不能用它来作曲……或者我可以吗？

PD：感谢您的宝贵时间，希望您能熟悉我的英语：P

编辑1

我的问题：

我有管理员、主管、技术人员和顾问。管理员负责一组主管、技术人员和顾问。
管理员可以使用主管来处理技术职能。
员工扮演着主要角色。
技术人员也可以是顾问。
如果技术执行顾问任务，将获得奖金。
顾问在客户办公室工作，而管理员、主管和技术人员在公司办公室工作。
为在公司外工作的员工分配了一个手机号码，而在公司工作的员工可以被呼叫到办公室的实习生。
员工编号、姓名和工资是了解员工的信息。

假设它们都是一组值得继承的方法。（有保证的方法，一些知道员工在哪里工作，另一种告诉电话号码与他联系）。

所以，起初我从一个 Employee 类继承了它们，但是这导致管理员参考 Employee 知道他负责的员工集，因此，我无法重新分配他的员工集并根据他们安排工作他们的角色类型。

我忍不住想我打破了liskov原则......但是继承似乎很方便，属性，最重要的是。

【问题讨论】：

我建议你把这个分成几个问题。
一些代码示例会有所帮助，如果没有代码并且没有关于您的具体案例的详细信息，理解问题会很复杂。一般来说，就 OOP 而言，您根本不应该“重用属性”，属性是应该封装在类中并保持私有的数据。
首先，便利是设计之死：)。真正的问题是，所有这些角色都是“真正的”员工吗？如果是，那么继承没有错。然后，您可以使用 isTaskAcceptable(Task)、accept(Task) 或类似方法扩展 Employee。那么您就不必关注类型，因为所有员工对象都可以自行决定他们能够执行哪些任务。

标签： oop inheritance design-patterns uml

【解决方案1】：

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

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

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

类对象应包含所有员工共有的所有属性和行为，并且角色/角色应确定特定角色的特定行为。

可能更难的部分是为管理员的问题及其对其他员工的参考提出一个好的解决方案。然而，它需要更多关于如何在代码/应用程序中使用它的信息。

【讨论】：