Помощь в рефакторинге java-кода

десктом приложение переделать в веб? это что оно у тебя там такое делает то

И в вэб, и возможно в ГУЙ на FX, и на Андроид. Чтобы менялся только интерфейс общения с юзером и технологии передачи данных (по http через вэб-сервер или напрямую), а сам бэкенд с минимальной доработкой (а в идеале вообще без нее) подходил для всех вариантов, чтобы его шлифовать один для всех - внести новую фичу а потом просто заменить пару классов на новые во всех вариантах приложения. Это же и называется модульность и инкапсуляция/полиморфизм, правильно я понимаю? Ну и для опыта архитектурирования тоже хочется. Вот ссылка на гитхаб https://github.com/Ivana-/Liscript-GUI-Java-Swing

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

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

почитай например эту книжку http://www.ozon.ru/context/detail/id/2457392/ (в инете есть в электронном виде) в частности там есть на примерах про проектирования ui приложений, сильно протухшее но тем не менее все еще актуальное

потом, когда начитаешься, возьми бумажку и нарисуй там свой «движок» приложения и все операции и их результат, которые можно с ним делать, напр:

идентификатор_скрипта передать_скрипт_на_компиляцию(текст)

идентификатор_задачи запустить(идентификатор_скрипта)

текст взять_статус_задачи(идентификатор_задачи)

текст взять_результат_задачи(идентификатор_задачи)

Это будет API, под него ваяешь разные интерфейсы UI, WEB. Учти что web - не позволяет особо гонять сложные данные, т.е. там где в UI ты мог передать ссылку на объект, придется колдовать с идентификаторами, также нужна будет авторизация, список юзеров - и соотв. каждый юзер имеет лимит на кол-во одновременных задач и т.п. т.е. это потребует еще кучи всяких вещей

но как начитаешься начни с проектирования хотябы примитивного api

ps. и код, да адовый

а клиент-сервер однонаправленный (от клиента к серверу),

во первых ты немного отстал от жизни, во вторых, если полагать что вызов любого метода - это посылка сообщения (в некоторых ЯП это из коробки), то это различие - превращается в фигню. Сложнее для переносимости задержки, необходимость сериализации\десериализации и т.п.

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

а клиент-сервер однонаправленный (от клиента к серверу)

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

Сейчас это решено вебсокетами

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

Сейчас это решено вебсокетами

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

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

а как сервер может держать вэбсокеты для миллиона пассивных пользователей (например, подписчики новостной ленты), в двух словах можно? или это невозможно?

а как сервер может держать вэбсокеты для миллиона пассивных пользователей (например, подписчики новостной ленты), в двух словах можно? или это невозможно?

А что мешает держать миллион открытых соединений?

А что мешает держать миллион открытых соединений?

Диапазон открываемых портов на один IP.

Для расширяемой архитектуры, если программа имеет дело с сохраняемыми данными, наверно, имеет смысл смотреть в сторону JPA и «богатых» (rich) пользовательских интерфейсов на основе JavaServer Faces (JSF).

А что мешает держать миллион открытых соединений?

Диапазон открываемых портов на один IP.

портов --- это например 80-ый что ли?

а как тогда мы тут все лор читаем, по очереди?

«богатых» (rich) пользовательских интерфейсов на основе JavaServer Faces (JSF).

ты сам-то пробовал этим пользоваться? :)

Пробовал. Из IDE с мастерами (см. NetBeans 8.2 - там это очень хорошо поддерживается) это выглядит легко и просто - буквально несколько кликов мышкой по формочкам построения клиент-серверного приложения CDI, JPA, JSF и можно начинать отладку. https://netbeans.org/kb/trails/java-ee.html

MVC уже предлагали? Всю логику в бэкенд. На десктопном observer-observable. В вебе такое не очень прокатит. Там свои заморочки с мвс и в основном все делается на фреймворках.

И в вэб, и возможно в ГУЙ на FX, и на Андроид.

посмотри на vaadin

а как сервер может держать вэбсокеты для миллиона пассивных пользователей (например, подписчики новостной ленты), в двух словах можно? или это невозможно?

если на обычных сокетах - то не ахти как, если на select - то ограничением будет кол-ко открытых дескрипторов

похоже изя в сетях шарит как студент-первокурсник филфака

А что мешает держать миллион открытых соединений?

Диапазон открываемых портов на один IP.

портов --- это например 80-ый что ли?

Это входящий порт для запроса соединений. Сервер держит его открытым, чтобы в ответ на клиентский запрос соединения открывать сокет с одним IP и выбранным значением порта из 1024...65535. Открытое соединение описывается четырьмя параметрами: IP сервера, номером порта сервера, IP клиента, номером порта клиента.

а как тогда мы тут все лор читаем, по очереди?

Соединения обрубаются же по таймауту. HTTP - протокол без установления долговременных соединений.