Java: как определить возможности экземпляра подкласса, который может быть получен из суперкласса - PullRequest
2 голосов
/ 28 апреля 2011

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

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

У нас есть 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 (задача): в реализации execute (задача)попытайтесь выполнить проверку типов / типов для всех типов задач, которые может выполнять тип работника.Если ни одна из проверок типов не пройдена, мы генерируем исключение taskNotSupportedException.теперь босс может давать задания работникам до тех пор, пока не будет выдано исключение.

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

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

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

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

Ответы [ 2 ]

2 голосов
/ 28 апреля 2011

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

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

boolean isAbleToExecute(Task task)

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

0 голосов
/ 28 апреля 2011

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

...