есть класс
в нем


это лучше, чем городить if или switch, т.к. вызываемых методов прилично.
количество вызываемых методов растёт, есть желание разделить их на логические группы, а эти группы поместить в разные файлы
но как это можно реализовать?

Blazkowiczвадяэто лучше, чем городить if или switch, т.к. вызываемых методов прилично.

Зато типобезопасность идёт лесом. Лучше было использовать полиморфизм. На худой конец - HashMap. Тем более с лямбдами сейчас это очень просто.

соглашусь, но сейчас вопрос не об этом.
а как разнести методы по разным файлам (классам?)

Blazkowicz,
шутник,
как вызывать из одного класса - методы из разных классов?

делаю


на последней строке выдаёт
java.lang.IllegalArgumentException: object is not an instance of declaring class

HoBTID, это вызывает WebSocketServer.

сделал так


работает.
но смущает вот это
Object objCl = cl.newInstance();
насколько затратная операция?
зачем её делать многократно, можно ли (будет ли быстрее) как-то вставить её в Singleton?

Petro123вадячем городить if или switch
если "городить" - это всё, что не нравится. То напиши через if или switch
если цепочка из 100 if - номально, то....
да и добавлять нужно будет и в if и метод, так я добавляю только метод.

авторЕсли проект взлетит, то потомки вас будут проклинать за рефлексию.
чем рефлексия тормознута?
и чем её можно заменить?
методов для выполнения ожидается много.
if и switch при >100 методов будет тоже не быстро.

if и switch работают последовательным проходом и сравнением
как работает рефлексия?

авторНапрашивается паттерн "команда" + хеш-таблица.
более подробно можно?
если про web - то я могу занести все разрешенные методы в array (к примеру) и вызывать только их.

из просмотренного и прочитанного можно сделать вывод -
рефлексия не очень медленный процесс, и в большинстве случаев, потерю быстродействия не поймать.
рефлексия не безопасна, если использовать в лоб, можно нарваться, но если кто-то захочет что-то взломать - вопрос в цене на защиту от взлома и цене данных...(в моём случае достаточно все методы загнать в массив + вся проверка в пару строк)
следующий вопрос - цена разработки и сопровождения
в применении к своему случаю - у меня есть метод onMessage, я его написал, отладил, и забыл про него.
дальше только добавляю методы для обработки собщений, обработка простая максимум 40 строк(подготовка и обращение к базе , try/catch + немного логики).
при этом повторяющиеся куски кода можно вынести в отдельный метод. расположив его неподалёку от места где вызывается.
получается наглядно и просто.

но когда число методов вырастает - рыскать по такому количествунесколько мутноватно.
автор Паттерн "команда" предлагает безкомпромиссную декомпозицию - на каждую команду создается отдельный класс.
т.е. получеатся 100+ файлов?
компиляция многих файлов - больше времени, чем одного большого (на время разработки существенно)
да и искаить что-то в файлах затрвтнее, чем в одном файле.

if/switch - тоже не есть хорошо - (т.е. хорошо когда получаешь за строки ) -нужно написать метод, да не зfбыть добавить его в листинг if/switch
и сколько времени потребуется для прохождения и сравнения всех 100+ строковых данных....

авторМожно таки внятно объяснить, зачем все методы в одном классе?
для начала из простоты, пока их 15 проблем нет, удобно , наглядно.
вот и встал вопрос сгруппировать в разные файлы(я не говорю классы, хотя придется группировать в классы).

Petro123вадяHoBTID, это вызывает WebSocketServer.
вот тут у тебя проблема.
Если система растёт, то это не буквально растёт onMessage() на 200 методов.
Ты очень любил websockets?. Вот и получаешь его результат.
IMHO
да, я очень люблю websockets, и рост onMessage ни сколько не мешает этому.
это можно сделать и на ajax, и получить теже 200 методов. только головняков будет больше. проверено.
а многие вещи с ajax просто не реализуемы.
это 100-200 методов не недостаток websockets, а лишь результат того, что послать запрос на сервер очень дешево и получить ответ также.
если надо на сервере обработать данные с клиента - я должен отправить на него (либо через ajax либо через websockets) команду и данные. пусть тем же xml, на сервере распарсить и выполнить требуемой командой действия над данными.
тоже и на клиенте - команда + данные, только на javascript все решается проще window [comanda] (data)
так что websockets здесь только облегчает жизнь.

Petro123вадя,
вот и приведи свои 200 методов.
Тебя просили.
есть поля с возможностью поиска+редактирования найденного, + в зависимостиот найденного - отображаются еще несколько полей, также с возможностию редактирования.
к примеру (очень грубо) выбираешь клиента-список товаара,выбираешь товар-куча его свойств.
не обновлять же при каждом выборе страницу.
для клиента - как минимум 3 запроса - для поиска, для отправки редактированного, для удаления(как вариант пометка как не действующий).
а если делать удобный интерфейс - фильтры, сотрировки ...
1 страница -10-15 запросов, страниц 10-15, вот и посчитай
это не для сайта, это для корпоративного портала.
авторhttp//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= ....
ну и что я отправляю: имяметода|параметр%параметр...
мне проще распарсить мою сторку - всего два сплита

авторну, дак не все они идут через одно игольное ушко onMessage?
Нафига тогда ЯП _высокого_ уровня?

почему ты считаешь игольным ушком?
http//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= ....
также можно считать игольным ушком.

чем отличается http//имяПриложения/ИмяМетода?ПарамМетода1=фф, ПарамМетода2= .... от websockets?

websockets удобней, проще, быстрее, универсальней, двунаправленно

авторRest Full (url семантика) хотя бы по семантике тот же самый как код методов программиста.
Он как минимум сохраняет состояние программы у пользователя на рабочем столе.
Было бы оригинально, если бы мне предлагали писать новый протокол общения сервера и клиента на TCP по порту 1521
Ты пишешь обвязку над сокетами? Фреймворк для прикладника-программиста?
Тогда так в теме и пиши.
мы видимо о разном говорим...
есть протокол websockets(ws) альтернатива ajax, comet и пр. поддерживается даже ie10+
опуская весь путь от браузера до сервера, имеем слушателя на понравившемся порту, сообщение после прочей обработки, расшифровки попадает в onMessage. по спецификации websockets пересылает строку (либо массив байт), как использовать эту строку - отдано прикладной программе.
я разделителями делю на части - команда и данные
команда = имя метода для обработки(для простоты).
причем здесь
авторТы пишешь обвязку над сокетами? Фреймворк для прикладника-программиста?
очень грубо говоря - я пишу вебморду для работы с данными - формы ввода, просмотра, и пр., как продолжение грубой фссоциации - интернет магазин с раширенными фунциями. можно сделать и десктоп , но придется устанавливать, а так открыл браузер и работай.(ws хорошо встроится и в десктоп, и в андроид)

авторты не БАД'ы продаешь? ))...с такой формулировкой?
Откуда тогда полиморфизм и твоя тема на сокетах?
чтоб это написать
websockets удобней, проще, быстрее, универсальней, двунаправленно
надо бадов накушаться?
против каких пунктов из выше перечисленных ты против?
одно то, что инициатором сообщения может быть сервер многого стоит. тут даже comet курит в стороне, не говоря об ajax.

авторЧто тут технологически красиво - сложно сказать.
У него сейчас 15 методов. А будет ли 500 - неизвестно.

вот я и ищу более "красивого вида"
даже при 20 методах всё красиво и для сопровождения и для отладки.
if мне не нравится, уже писал.
"паттерн команд" тоже не очень, по скорости я думах, что проиграет рефлексии

авторВ сервлет 3.0 у меня есть

@WebServlet("/ИмяПроцедуры")
public class ИмяПроцедуры extends HttpServlet {
и есть
request.getParameter("ПараметрПроцедуры");


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

но для 100+ именПроцедур у тебя тоже возникнут аналогичные проблемы.
все методы в одном файле?

Petro123вадя,
off
- а зачем мне сервер будет спамить в браузер?
- сервлет в отдельном файле
а вот тут и есть преимущества - всё дело в трактовке .
если трактовать как спам - то да, это безобразие.
1)
а если тебе (опять очень грубый пример) нужно отображать изменения кучи параметров в браузере изменения случайны каждое изменение рекое, но таких изменений 20 в минуту .
ты своим способом будешь бомбить сервер на вопрос - покажи ка мне, а не изменилось ли что?
а если таких клиентов 50+
у тебя сервер будет работать в пустоту,
а если использовать "спам" - изменение пришло - сервер разослал "подписчикам" только изменённые данные и курит
2)
я выбрал клиента - уменя обновилось в окне несколько полей - сервер отправил несколько последовательно ответов для обновления этих полей и метод для обновления конкретного поля я использую многократно. в любоим месте. просто вызываю метод с нужным параметром - и он отправляет данные для обновления , нужно отобразить изменения 10 полей - сервер отправит 10 сообщений - ООП.

авторвадя,
1) у тебя ведь не такой проект? Мало ли каких проектов есть на свете.
Опиши свой проект...в отдельной теме.
100% что он уже есть в сети и учебниках.
Просто флейм неинтересен.
у меня именно такие проекты.
в сети такого нет, использование websocets в сети пока просто демонстрация чата на ws.
я нашел хорошую библиотеку для ws её несколько модифицировал (эти тонкости ws пока в инете не рассматривают)
и использую вариант wss (с шифрованием).
если есть желание можно в скапе обсудить
с удовольствием послушаю дельные замечания.

Basil A. Sidorovвадяа если тебе (опять очень грубый пример) нужно отображать изменения кучи параметров в браузере изменения случайны каждое изменение рекое, но таких изменений 20 в минуту .
ты своим способом будешь бомбить сервер на вопрос - покажи ка мне, а не изменилось ли что?Никто ничего бомбить не будет - сервер не обязан мгновенно отвечать "ничего не изменилось". Может подожать секунд пятнадцать и, если что-то изменилось - прислать данные. Не изменилось - вот тогда так и скажет.
Этакая авторегулировка частоты опроса.
опять очень грубый пример
можно найти решение, но если есть более простое - почему его не использовать?
нужно на клиенте делать таймер, чтоб раз в 15 секунд опрашивать. на сервере запрос чтоб "спал".
а если в эти 15 секунд потребуется сделать ещё какой запрос? более короткий? что его обработает на клиенте?
как ответ от первого? или ?

ещё раз
нужно на клиенте делать таймер, чтоб раз в 15 секунд опрашивать. на сервере запрос чтоб "спал".
а если в эти 15 секунд потребуется сделать ещё какой запрос? более короткий? что его обработает на клиенте?
как ответ от первого? или ?