Затраты на поиск и вызов метода с отражением

Question

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

Существует более 30 типов сообщений.

Один из способов отправить сообщение - просто использовать переключатель, но он действительно уродлив и подвержен ошибкам (я уже изучал этот случай? Я два раза обрабатывал этот случай?).

Еще один способ - определить интерфейс с одним методом (данными) и создать один класс для каждого типа сообщений, который реализует этот интерфейс, зарегистрировать эти классы с помощью карты и в коде, который должен обработать сообщение, просто вызовите map.get (messageType) .process (data); но действительно раздражает создание 30+ классов.

Другим способом является использование отражения: определите одну функцию для каждого типа сообщения с точной сигнатурой и именем шаблона, как processMessagetype; затем создайте карту из messagetype в Method (заполненную простым поиском по getDeckaredMethods ()), а затем сделайте что-то вроде: map.get (MessageType) .invoke (это данные).

Какой метод вы должны использовать? Каковы издержки использования отражения Java?

Answer 1

Отражение имеет большие издержки, если вы ищете хорошую производительность. Если ваша рутина (отправка сообщений) будет использоваться снова и снова, лучше использовать альтернативу полиморфизма. Кроме того, ИМО лучше, если смотреть в ОО-перспективе, поскольку, как сказал Брайан в своем ответе, проще и дешевле в обслуживании.

Ваш класс обработки более 30 сообщений может легко вырасти до 100+ сообщений, тогда у вас будет класс с более чем 100 методами, добавьте также частные методы, и повторное использование кода будет затруднено, а ваш класс только что стал беспорядком. *

Затраты на размышления над полиморфизмом и переключателем выглядят примерно так:

time spent on a switch case call: 1
time spent on a polymorphism call: 1.1
time spent on a reflection call: 1.9-2.0

Некоторое время назад я тестировал этих парней, и это были мои результаты, у меня сейчас нет кода, потому что эти тесты были сделаны для моей предыдущей компании, и у меня больше нет доступа к этому коду.

Answer 2

Вы можете добавить метод процесса к перечислению.

Что именно не так с большим переключателем (в каждом случае просто вызывая метод)?

Основная плата за размышления заключается в том, что она приводит к тому, что код становится отстойным. ;)

Answer 3

Я собираюсь угадать, поскольку вы говорите о "сообщениях" и "конвертах", что вы передаете эти сообщения по проводам. Время, необходимое для этого, будет абсолютно доминировать дополнительное время, необходимое для размышлений. Я использовал отражение, как это, и это не плохая модель.

Answer 4

Вы не говорите, что будет делать ваш метод process (), но я был бы удивлен, если какие-либо накладные расходы при отправке вызова метода будут вообще значительными.

Я бы заставил язык и систему OO работать на вас и создал бы интерфейс / абстрактный базовый класс с соответствующей реализацией (ями) метода.

Помните, что преждевременная оптимизация - корень всего зла ( Кнут )

Answer 5

Я думаю, что первый метод / алгоритм, который вы описали (Карта типа сообщения для класса), со временем будет легче управлять с помощью обновлений, обслуживания и т. Д.

Второй шаблон, который вы описываете, будет включать в себя класс с более чем 30 методами, верно? Это было бы довольно трудно со временем.

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