java：如何定义可以从超类派生的子类实例的功能

为了使我的问题更具体，让我把它作为一个问题提出：

情况描述：

我们有3个抽象概念：

Boss:  which has a number of employees
Worker:  that can execute some types of tasks
Task:  contains the semantics needed for a worker to execute it

在实现/子类型中，我们有许多不同类型的工作人员和不同类型的任务。 特定类型的工作人员可以执行某些类型的任务（所有类型的子集）

要解决的问题

现在老板有一个他希望执行的已知类型的任务，他不知道他有哪些类型的工人（只有抽象类型/接口）。 员工可以实现什么样的接口/老板可以做什么来发现

我能想到的解决方法

我发现有两种方法，但可能还有其他更好的方法：

1） 我们为实现空任务接口的每个任务类型创建一个类 为工作人员提供执行（任务）功能： 在execute（task）的实现中，尝试将task类型检查/转换为该类型工作人员可以执行的所有TaskType。如果没有一个类型检查通过，我们抛出taskNotSupportedException。 老板现在可以把任务交给工人，直到没有异常被抛出为止

2） 我们现在没有任务类，但是 使用函数dotaskType（taskinfo）为每个任务类型定义一个功能接口 工作者实现现在可以根据其功能实现功能接口。 老板现在可以检查，直到找到具有适当能力的工人为止（打字检查） 然后给他任务，让他知道他可以执行

我没有测试2，我在java方面没有太多经验，但这应该是可能的（或者类似的）

我也更喜欢2而不是1，因为1似乎不合适（cast的级联），接口是定义类的实例可以做什么的自然方式，并且使用接口可以对功能进行分组/创建层次结构。（也是在我当前的实现（1）中，任务接口是空的，因此任务没有太多共同点，信息通过构造函数（方法2中的函数参数）传递，并由gets检索

我想知道你还想/可以用什么方式实现（调整1或2？），或者你更喜欢这两种方式中的哪一种，以及为什么。

---

（效率不重要，调制/抽象/可维护性才重要！）

不要为此使用异常。异常应用于异常情况，不能执行某些任务似乎是正常的

我想补充一个方法

boolean isAbleToExecute(Task task)

---

在Worker类中，让老板遍历他的工人，并在分配任务之前找到一个能够执行任务的工人。

工人接口可以包含一个方法supportedTasks，返回任务列表。然后你可以维护一个映射，将任务映射到支持该任务的工人列表。这样，你的老板就不需要迭代，但是建议：让老板成为承包商，让工人成为油漆工、木匠和园丁等专家。然后让他们做一次家庭改造，从厨房水槽到花园地精再到室内装饰。我也打算提出这个建议，但后来发现已经有了。理想情况下你会收集所有可以执行它的工作人员，然后以某种方式找出第一个执行它的工作人员。是的，添加该方法也是我想到的。在方法1中，这是一个好主意，但我真的不喜欢方法1，它似乎不合适（cast的级联…）.关于这个例外情况，我认为应该存在，因为这是一个需要以某种方式处理的案例，我认为工人除了抛出例外情况之外，没有其他方法来处理这个问题（也就是告诉他的老板）.您对方法2的看法是什么？平均工作人员数量将很小，因此迭代它们不会有太大的开销（我的意思是效率并不重要）。但是从编码的角度来看，我更喜欢isAbleToExecute（可能是因为名称以动词开头；）方法2如何？或者其他一些方法可以做到这一点如果我正确理解方法2，您需要类似If（worker instanceof taskCapability）（（taskCapability）worker.doTaskType（task）的内容；这种类型检查和强制转换感觉不太干净。工作人员应该提供知道他们可以执行哪些任务的方法。isAbleToExecute和SupportedTask都可以正常工作，但如果我是老板，我希望我的工作人员以对我有意义的方式编制索引。如果SupportedTask返回一组任务，则isAbleToExecute很容易通过h supportedTasks.contains（task）您理解正确，但在方法1中，同样的类型检查和转换由工人执行，这很奇怪，因为他从老板那里得到了一个明确的任务，仅仅因为它是通过execute（task）传递的。定义什么（！=如何）也很奇怪一个类可以在它的实现中而不是在它的接口中完成。你不认为方法1会导致更难维护代码吗，因为想要添加任务的程序员必须在两个不同的方法中完成（如果他忘记了1会怎么样？），而在方法2中实现接口会迫使程序员定义函数。