Leonid KudryavtsevМинусы примера
это был пример решения задачи в общем виде, не применительно к сокетам, сервлетам, кол-ву запросов или чему либо еще. на счет как это называется, без разницы :)

Leonid Kudryavtsevпередавать обрабатываемые данные через параметры.
Лишняя операция создания объекта лично меня обычно напрягает
они и так будут через параметры передаваться. вопрос в том куда и как. на счет создания объектов - это все детали реализации. у нас вполне могут быть thread safe синглтоны (не в смысле статический класс, а в смысле один экземпляр)

Leonid Kudryavtsevмного букв, т.к. нужно для каждой операции создавать свой класс. Но тут вполне могут помочь лямбды и клосуры в новой Java. По смыслу будет тоже самое, но буковок в итоге может оказаться меньше и код получится более компактный.

Но компактность IMHO это плюс для случаев, когда операций мало. Если операций много, то лучше через классы, т.к. компактности в любом случае не получится, но с лямбдами можно сотворить помойку, а с классами хоть и будет много букв, зато строгая и логичная системаименно так - это тоже детали реализации - о конечно задаче ведомо только ТС. если у нас куча функций со своими зависимостями (репозитарии, сервисы) - то без классов никак, если у нас 4-5 команд, можно как угодно решать.

вадяты не понял проблемы
вопрос не в количестве обработчиков, а как их вызвать
ок, какая разница 300 методов или 300 условных строчек вида
type1 --> class1
это точно такой же табличный метод записи, только у тебя вместо Map - класс, вместо ключей - названия методов, а вместо значений - их тела

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

вадямне его просто найти -есть страница с которой работаю - есть для неё файл/класс
у меня нет никаких страниц, я описал способ централизованной обработки входящих сообщений

вадяя работаю с одно страницей не мешаю никому работать с другой.
что-что?

вадядля выбора нужного ты перебираешь все до нужного, я вызываю нужный
вадя, соберись. где у меня "перебираешь"?

вадяу меня в файле/классе 20-30 методов
что-то мало, у настоящих мастеров все вообще в одном классе

вадя300 методов в одном классе? ну уж нет
это был сарказм. а 30 в самый раз да?

вадяесли я правлю одну страницу то я работаю с двумя файлами jsp странице и файлом
откуда у нас уже взялись какие-то jsp, где в топике про jsp? может у ТС messenger на сокетах? задача сформулирована довольно общим образом, особенно в разрезе применения внутреннего класса. Но отвечая на твой вопрос, у нас 16 апреля 2018, курс биткоина 8.087,46€ , merge уже изобрели.


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

Tsyklopдопер Ваш вариант
можно на "ты", мы же на каком нибудь 4pda.ru ;)

Tsyklopкак мне в каждом обработчике получать доступ к списку подключенных к сокету юзверей? Делать этот лист публичным? или package private?имхо правильней выделить список пользователей в отдельный класс (да-да, еще один класс ;) ) . как до него достучаться в разных местах - возможны варианты. Можно его сделать статическим (если очень хочется) потокобезопасным. Можно его инжектировать там где надо с помощью di. Все зависит от конкретной ситуации и сферы применения.


P. S. тут я хочу немного отскочить в сторону: что ты конкретно реализуешь? что есть в наличии? di framework типа spring, или "все своё", как вадя любит? почему например не взять готовый framework для сокетов? тот же спринг. Я не специалист по сокетам, может еще десяток отличных framework-во существует.
Просто когда я смотрю, на то, что перетерли тут на двух страницах, а потом на примеры из спринга


то у меня возникает закономерный вопрос набуя козе баян?

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

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

Leonid Kudryavtsevкогда ссылаетесь на спринг, давайте пожалуйста RTFM на книжку/доку
дружище, spring + socket и первая же ссылка на пример, вторая на доку.

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

Сообщение, отправленное по адресу "/hello" попадает в наш метод greeting - т.е. у нас уже из коробки роутинг (по сути предмет этого топика) и конвертация json -> dto. Далее мы возвращаем другой dto который в свою очередь снова превращается в json и улетает всем подписчикам

вадяэто всё красиво пока в теории.
и в малом количестведа-да, spring для hello world, твой велосипед для дела - строго в таком порядке

вадяты читай всё - 21341559
у него 10 страниц...
мне больше заняться нечем. я ответил общим образом на общий вопрос

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

тут ты меня уел

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

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

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