Java: Как определить возможности экземпляра подкласса, который можно получить из суперкласса

Question

Чтобы сделать мой вопрос более конкретным, позвольте мне представить его как проблему:

Описание ситуации:

У нас есть 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) Мы производим класс для каждого типа задачи, реализуя пустую задачу, дайте работнику функцию Exepute (Task): в реализации выполнения (задача) Попробуйте TypeCheck/Cast Task для всех задач, которые может выполнять тип работника. Если ни одна из типовых чеков не пройдет, мы бросаем TaskNotsUpportedException. Босс теперь может дать задачи работникам, пока не будет брошено никаких исключений.

2) Теперь у нас нет классов задач, но определяем интерфейс возможностей для каждого типа задачи с помощью функции dotasktype (taskInfo). Реализация работника теперь может реализовать интерфейсы возможностей, зависимые от того, каковы его возможности. Теперь босс может проверить, пока работник с надлежащей способностью не найден (Typechecking), а затем даст ему задачу, зная, что он может выполнить его.

Я не тестировал 2, и у меня нет такого большого опыта в Java, но это должно быть возможно (или что -то очень похожее).

Я также предпочитаю 2 более 1, потому что 1 кажется ненадлежащим (каскад слепков), а интерфейсы - это естественный способ определить, что может сделать экземпляр класса, а также с интерфейсами вы можете группировать возможности/создать иерархии. (Также в моей текущей реализации (1) Интерфейс задачи пуст, поэтому задачи не имеют большого общего, и информация передается через конструктор (который будет параметрами функций в методе 2) и получена с помощью GET.

Мне было интересно, каким образом вы бы/могли бы реализовать (корректировку 1 или 2?) Это или какой из двух вы предпочитаете и почему. (Эффективность не важна, модуляция/абстракция/обслуживание!)

Answer 1

Не используйте исключения для этого. Исключения должны использоваться для исключительных ситуаций, и неспособность выполнять какую -либо задачу кажется нормальной.

Я бы добавил метод

boolean isAbleToExecute(Task task)

в классе работников, и проведу босс провести через своих работников и найти работника, способного выполнить задачу, прежде чем назначить ее.

Answer 2

Рабочий интерфейс может включать в себя метод поддержки, возвращающий список задач. Затем вы можете поддерживать карту, сопоставить задачу с списком работников, поддерживающих эту задачу. Тогда вашему боссу не нужно итерации, но может просто искать всех работников, которые поддерживают данную задачу.