566 lines
33 KiB
Markdown
566 lines
33 KiB
Markdown
# Архитектура gui-client
|
||
|
||
## 1. Обзор проекта
|
||
|
||
Проект состоит из четырёх Gradle-модулей:
|
||
|
||
```
|
||
common/ — общие модели (HumanBeing, Coordinates, Car, WeaponType)
|
||
и сетевые типы (Request, Response, AuthRequest)
|
||
client/ — низкоуровневый UDP-клиент (NetworkManager)
|
||
server/ — сервер (ForkJoinPool, Exposed ORM, PostgreSQL)
|
||
gui-client/ — JavaFX-клиент (наш модуль)
|
||
gateway/ — UDP/TCP-шлюз
|
||
```
|
||
|
||
Модуль `gui-client` — это толстый JavaFX-клиент, который:
|
||
- аутентифицируется (login / register) через UDP
|
||
- отображает коллекцию HumanBeing в таблице и на Canvas
|
||
- позволяет добавлять, редактировать, удалять объекты
|
||
- автоматически обновляет данные каждые 3 секунды (polling)
|
||
- поддерживает 4 языка (ru, nl, hu, en_AU) без перезапуска
|
||
- собирается в fat JAR (`shadowJar`)
|
||
|
||
---
|
||
|
||
## 2. Почему JavaFX + Kotlin, а не что-то ещё
|
||
|
||
**JavaFX** выбран, потому что:
|
||
- Это требование лабораторной работы — использовать JavaFX.
|
||
- Даёт полноценный desktop-GUI: TableView, Canvas, модальные окна, CSS-styling.
|
||
- Работает вне браузера, что важно для UDP-сокетов (браузеры не поддерживают произвольные UDP).
|
||
|
||
**Kotlin** выбран вместо Java, потому что:
|
||
- Значительно короче (data class, scope functions, лямбды, trailing lambda).
|
||
- Полная совместимость c JavaFX (прозрачная interop через Kotlin → JVM байткод).
|
||
- Coroutines для асинхронной работы с UDP (без callback-hell).
|
||
- Kotlin 2.2.0 с новым компилятором K2.
|
||
|
||
---
|
||
|
||
## 3. Структура gui-client
|
||
|
||
```
|
||
gui-client/src/main/kotlin/
|
||
├── Main.kt — точка входа
|
||
├── localization/
|
||
│ └── AppLocale.kt — i18n (4 локали, динамическое переключение)
|
||
├── model/
|
||
│ ├── Session.kt — глобальное состояние (singleton)
|
||
│ └── HumanBeingProperty.kt — observable-обёртка над HumanBeing
|
||
├── network/
|
||
│ └── ClientProvider.kt — coroutine-обёртка над NetworkManager
|
||
├── controller/
|
||
│ ├── AuthController.kt — логика аутентификации
|
||
│ └── MainController.kt — логика главного экрана (polling, фильтры, команды)
|
||
├── view/
|
||
│ ├── AuthView.kt — окно входа / регистрации
|
||
│ ├── MainView.kt — главное окно (таблица + Canvas + тулбар)
|
||
│ ├── EditDialog.kt — модальное окно добавления / редактирования
|
||
│ └── CollectionCanvas.kt — Canvas-визуализация
|
||
└── util/
|
||
└── StreamUtils.kt — Streams API filter + sort
|
||
```
|
||
|
||
---
|
||
|
||
## 4. Почему такая архитектура?
|
||
|
||
### 4.1. Разделение на View / Controller
|
||
|
||
Выбран **MVC-подобный паттерн** (не MVVM, не MVP):
|
||
|
||
- **View** (пакет `view/`) — только построение UI-дерева и обработка пользовательских событий. Никакой бизнес-логики, никаких прямых вызовов сети.
|
||
- **Controller** (пакет `controller/`) — бизнес-логика, асинхронные операции, работа с Session и ClientProvider.
|
||
- **Model** (пакет `model/`) — состояние и observable-свойства.
|
||
|
||
Почему не MVVM:
|
||
- JavaFX TableView из коробки требует `ObservableList` + cell value factories, что естественно ложится на простые property-обёртки.
|
||
- Добавление ViewModel-слоя (ещё один уровень абстракции) неоправданно усложнило бы код для desktop-приложения такого размера.
|
||
- Контроллер в нашем случае — не JavaFX Controller (не `@FXML`), а обычный класс, который вызывается из View. Это разделение достаточно для тестируемости и переиспользования.
|
||
|
||
Почему `c` (controller) строчной, а `v` (view) строчной — Kotlin style (package names lowercase).
|
||
|
||
### 4.2. Session — singleton, а не dependency injection
|
||
|
||
```kotlin
|
||
object Session {
|
||
var client: ClientProvider? = null
|
||
var token: String = ""
|
||
var userId: UUID? = null
|
||
var username: String = ""
|
||
val collection: ObservableList<HumanBeingProperty> = FXCollections.observableArrayList()
|
||
...
|
||
}
|
||
```
|
||
|
||
- Kotlin `object` — это потокобезопасный singleton на уровне JVM.
|
||
- Все компоненты (View, Controller, Canvas, EditDialog) читают и пишут состояние через `Session.*`.
|
||
- Альтернатива (DI: Guice, Koin, Dagger) неоправданна для такого масштаба — DI имеет смысл, когда есть десятки классов с глубокими графами зависимостей. У нас 4 view, 2 controller, несколько утилит.
|
||
- `ObservableList<HumanBeingProperty>` — единственный источник истины (single source of truth). Парсинг ответа сервера (`show`) обновляет именно её, Canvas и TableView подписаны на её изменения.
|
||
|
||
### 4.3. HumanBeingProperty — observable-обёртка
|
||
|
||
```kotlin
|
||
class HumanBeingProperty(humanBeing: HumanBeing) {
|
||
val name = SimpleStringProperty(humanBeing.name)
|
||
val coordinateX = SimpleObjectProperty<Long>(humanBeing.coordinates.x)
|
||
val weaponType = SimpleObjectProperty<WeaponType?>(humanBeing.weaponType)
|
||
...
|
||
}
|
||
```
|
||
|
||
Почему не использовать `HumanBeing` напрямую?
|
||
- `TableColumn<HumanBeingProperty, String>` требует cellValueFactory, который возвращает `ObservableValue<String>`. Поле `SimpleStringProperty` это даёт.
|
||
- Если бы мы использовали `HumanBeing` напрямую, пришлось бы оборачивать каждое чтение в `SimpleObjectProperty` внутри cellValueFactory, что создаёт временные объекты при каждом обновлении.
|
||
- `HumanBeingProperty` — это value object, который живёт столько же, сколько и элемент в таблице. Его поля — это binding targets.
|
||
- `toHumanBeing()` позволяет преобразовать обратно в модель для отправки на сервер.
|
||
|
||
### 4.4. ClientProvider — coroutine-обёртка над blocking NetworkManager
|
||
|
||
```kotlin
|
||
class ClientProvider(host: String, port: Int) {
|
||
private val net = ClientNetworkManager(host, port)
|
||
|
||
suspend fun auth(login: String, password: String, type: AuthType): AuthResponse? =
|
||
withContext(Dispatchers.IO) {
|
||
net.sendRequest(AuthRequest(login, md5Hash(password), type))
|
||
}
|
||
|
||
suspend fun execute(commandName: String, ...): Response? =
|
||
withContext(Dispatchers.IO) {
|
||
net.sendRequest(Request(...))
|
||
}
|
||
}
|
||
```
|
||
|
||
- `NetworkManager` (из модуля `client`) — blocking API. Он использует `DatagramChannel` с блокирующими вызовами `send`/`receive`.
|
||
- `ClientProvider` оборачивает блокирующие вызовы в `withContext(Dispatchers.IO)` — стандартный Kotlin-паттерн для bridge между blocking и coroutine мирами.
|
||
- Все контроллеры работают с `Session.client?.execute()`, который возвращает `suspend` и запускается в `scope.launch { ... }` контроллера.
|
||
|
||
Почему не сделать `NetworkManager` сам async:
|
||
- `client` — отдельный модуль, его API жёстко задан (требование лабораторной — "модуль client"). Менять его нельзя без согласования.
|
||
- Coroutine-обёртка изолирует изменения: если API `NetworkManager` изменится, правим только `ClientProvider`, а не все контроллеры.
|
||
|
||
### 4.5. Two-stage аутентификация
|
||
|
||
`AuthController` отделён от `AuthView`:
|
||
- View собирает данные (host, port, username, password, login/register).
|
||
- View вызывает `controller.authenticate(...)`.
|
||
- Controller в `scope.launch` создаёт `ClientProvider`, отправляет `AuthRequest`, и результат передаёт через callback `(Boolean, String) -> Unit`.
|
||
|
||
Callback, а не возврат значения:
|
||
- `authenticate` не может вернуть результат синхронно (сеть блокирует).
|
||
- Она не может вернуть `suspend` — тогда View пришлось бы работать с coroutines (Parental ответственность View — показывать UI, не управлять потоками).
|
||
- Callback безопасно вызывается через `Platform.runLater`, чтобы UI обновлялся из JavaFX Application Thread.
|
||
|
||
Почему `Session.userId = provider.getUUID()` устанавливается именно в AuthController:
|
||
- `NetworkManager.setUUID(id)` хранит UUID внутри net-слоя.
|
||
- `Session.userId` — это глобальное состояние, нужное для:
|
||
- `EditDialog.onOk()` — установка `ownerId` для новых объектов.
|
||
- `Session.isOwnObject()` — проверка владения для edit/delete.
|
||
- Устанавливать его позже (в View) было бы поздно — к моменту открытия EditDialog userId уже должен быть известен.
|
||
- `kotlin.runCatching { UUID.fromString(it) }.getOrNull()` — безопасный парсинг: если сервер вернёт кривой UUID, клиент не упадёт.
|
||
|
||
### 4.6. MainController — polling + команды
|
||
|
||
```kotlin
|
||
class MainController {
|
||
private val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())
|
||
private var pollingJob: Job? = null
|
||
|
||
fun start() {
|
||
Session.collection.addListener(collectionListener)
|
||
startPolling()
|
||
}
|
||
|
||
private fun startPolling() {
|
||
pollingJob = scope.launch {
|
||
while (isActive) {
|
||
delay(3000)
|
||
refreshCollection()
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему polling (pull), а не server-sent events (push):
|
||
- Сервер работает поверх UDP. Server-sent events требуют TCP или WebSocket.
|
||
- UDP не гарантирует порядок доставки. Если мы полагаемся на пуш-уведомления, можем пропустить обновление.
|
||
- Polling каждые 3 секунды — разумный компромисс: UI обновляется достаточно быстро для desktop-приложения, нагрузка на сервер минимальна.
|
||
- `delay(3000)` в корутине — не блокирует поток (в отличие от `Thread.sleep`).
|
||
|
||
Почему `SupervisorJob`:
|
||
- Если `refreshCollection()` упадёт с исключением, это не отменит весь scope и не остановит polling.
|
||
- `SupervisorJob` изолирует ошибку внутри одной корутины.
|
||
|
||
Как работает `refreshCollection()`:
|
||
1. Выполняет `Session.client?.execute("show")` — блокирующий вызов, обёрнутый в `Dispatchers.IO`.
|
||
2. Парсит текстовый ответ (строка → список HumanBeingProperty).
|
||
3. Сравнивает ID текущей коллекции с ID из ответа:
|
||
- `toRemove` — элементы, которых нет в ответе.
|
||
- `toAdd` — новые элементы.
|
||
- `toUpdate` — элементы, чьё name изменилось.
|
||
4. Все изменения через `Platform.runLater`.
|
||
|
||
Парсинг ответа — почему не JSON:
|
||
- Ответ от сервера — это строковое представление `toString()` объекта HumanBeing.
|
||
- Формат: `HumanBeing(id=..., name=..., ...)`.
|
||
- Парсинг через regex (extractValue) — да, это хрупко. Но:
|
||
- Изменять формат на стороне сервера (переписывать show) — нельзя (требование лабораторной).
|
||
- JSON-парсинг на клиенте потребовал бы координации схемой с сервером.
|
||
- Regex-парсинг достаточно надёжен для стабильного формата вывода.
|
||
|
||
### 4.7. StreamUtils — функциональный filter/sort
|
||
|
||
```kotlin
|
||
object StreamUtils {
|
||
fun applyFiltersAndSort(
|
||
items: List<HumanBeingProperty>,
|
||
filters: Map<String, String>,
|
||
comparators: List<Comparator<HumanBeingProperty>>,
|
||
): ObservableList<HumanBeingProperty> {
|
||
var stream = items.stream()
|
||
for ((key, query) in filters) {
|
||
if (query.isNotBlank()) {
|
||
stream = stream.filter { prop ->
|
||
val fieldValue = when (key) { ... }
|
||
fieldValue.lowercase().contains(lower)
|
||
}
|
||
}
|
||
}
|
||
if (comparators.isNotEmpty()) {
|
||
val combined = comparators.reduce { a, b -> a.thenComparing(b) }
|
||
stream = stream.sorted(combined)
|
||
}
|
||
return stream.collect(Collectors.collectingAndThen(
|
||
Collectors.toList(),
|
||
{ FXCollections.observableArrayList(it) }
|
||
))
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему `java.util.stream.Stream`, а не Kotlin Sequences:
|
||
- Это прямое требование лабораторной — использовать Streams API.
|
||
- `Stream.filter` / `sorted` — ленивые операции. Композиция нескольких .filter + sorted не создаёт промежуточных коллекций.
|
||
- `collect(Collectors.collectingAndThen(toList(), FXCollections::observableArrayList))` — создаёт копию списка, которую можно безопасно вставить в TableView.
|
||
|
||
Почему перебираем `Map<String, String>`, а не строим Predicate для каждого поля:
|
||
- Фильтры динамические: пользователь вводит текст в 11 полях, каждое применяется как `.contains(lowercase)`.
|
||
- Использование рефлексии или property references могло бы быть элегантнее, но:
|
||
- Рефлексия в JavaFX Property — избыточна (O(n) вызовов через MethodHandle).
|
||
- `when (key)` — читаемый и однозначный диспатчинг. Да, это switch на 11 кейсов, но он стабилен: если добавится поле, компилятор не даст забыть кейс (в Kotlin нет exhaustiveness для when со String, но визуально заметно).
|
||
|
||
### 4.8. AppLocale — i18n без ResourceBundle
|
||
|
||
```kotlin
|
||
object AppLocale {
|
||
val currentLocale: ObjectProperty<Locale> = SimpleObjectProperty(Locale("ru"))
|
||
|
||
private val strings: Map<Locale, Map<String, String>> = mapOf(
|
||
Locale("ru") to mapOf(...),
|
||
Locale("nl") to mapOf(...),
|
||
...
|
||
)
|
||
|
||
fun bind(property: Property<String>, key: String) {
|
||
property.value = get(key)
|
||
currentLocale.addListener { _, _, _ ->
|
||
property.value = get(key)
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему `.properties` файлы не используются:
|
||
- Требование лабораторной — "i18n должен храниться прямо в коде" (в классе).
|
||
- Это упрощает сборку: не нужно копировать ресурсы в JAR (нет `processResources`).
|
||
- Изменение строк не требует сборки проекта — просто правка Kotlin-файла.
|
||
|
||
Почему `ObjectProperty<Locale>`:
|
||
- При смене языка нужно перерисовать ВСЕ UI-элементы, которые уже привязаны к строкам.
|
||
- `bind(property, key)` регистрирует listener, который обновляет свойство при смене `currentLocale`.
|
||
- Можно было бы пересоздавать все сцены при смене языка. Но `bind` — это точечное обновление: меняется только текст, без потери состояния полей ввода, выделения в таблице, позиции скролла.
|
||
|
||
Locale `en_AU`:
|
||
- Выбран для юмора (Ryan Gosling + Australian English).
|
||
- "Carn't" для car.cool, "Server's cactus", "Check ya credentials" и т.д.
|
||
- Это демонстрирует кастомную локаль, не ограничиваясь стандартными en_US / en_GB.
|
||
|
||
### 4.9. EditDialog — модальное окно
|
||
|
||
```kotlin
|
||
class EditDialog(private val owner: Window, private val existing: HumanBeing? = null) {
|
||
fun showAndWait(): HumanBeing? {
|
||
dialog.initModality(Modality.WINDOW_MODAL)
|
||
dialog.initOwner(owner)
|
||
...
|
||
dialog.showAndWait()
|
||
return result
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему return-значение через `result`, а не callback:
|
||
- Диалог модальный — он блокирует ввод в родительском окне, пока открыт.
|
||
- `showAndWait()` «замораживает» выполнение до закрытия диалога.
|
||
- `result` записывается в `onOk()` при нажатии OK, диалог закрывается, и `showAndWait()` возвращает управление.
|
||
- Код в `MainView.onAdd()` выглядит последовательно: `val humanBeing = dialog.showAndWait() ?: return; controller.executeCommand(...)` — нет вложенных колбэков.
|
||
|
||
Валидация:
|
||
- Каждое поле проверяется при OK (а не по мере ввода).
|
||
- Это проще: не нужно показывать/скрывать ошибки на каждое нажатие клавиши.
|
||
- Если какое-то поле невалидно, показывается `Alert` (ошибка), диалог остаётся открытым.
|
||
|
||
Почему `Session.userId ?: return`:
|
||
- При добавлении нового объекта `ownerId` должен быть установлен.
|
||
- Если `Session.userId` == null (пользователь не залогинен или произошла ошибка), создавать объект бессмысленно.
|
||
- `run { showError(...); return }` — явная диагностика вместо молчаливого игнора.
|
||
|
||
### 4.10. CollectionCanvas — анимация через AnimationTimer
|
||
|
||
```kotlin
|
||
private val renderTimer: AnimationTimer = object : AnimationTimer() {
|
||
override fun handle(now: Long) {
|
||
animationTime = now / 1_000_000_000.0
|
||
render()
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему `Canvas` + `AnimationTimer`, а не JavaFX Shapes (Circle, Rectangle):
|
||
- 50+ объектов на Canvas — один draw call на объект. Shapes создают отдельный Node для каждого — overhead для Scene Graph.
|
||
- `AnimationTimer` вызывает `handle()` при каждом кадре рендера (60 FPS), что нужно для плавного свечения.
|
||
- Glow-эффект — это полупрозрачный овал позади основного, чья alpha пульсирует по `sin(time * 3.0)`. Никаких JavaFX effects (DropShadow, Glow) — они бы грузили GPU без необходимости.
|
||
|
||
Почему ручное преобразование координат (world → screen):
|
||
- `worldToScreenX(x) = x * scaleX + offsetX` — линейное преобразование из мировых координат в пиксели Canvas.
|
||
- Автомасштаб: дельта между min и max по X/Y определяет `scaleX`/`scaleY`.
|
||
- При одном элементе (min == max) используется `defaultRange = 200.0`, чтобы точка не уезжала в бесконечность.
|
||
- Цвет владельца: `ownerColor(ownerId) = Color.hsb(hashCode % 360, 0.7, 0.9)`. Хэш UUID детерминирован — один и тот же владелец всегда одного цвета.
|
||
|
||
Почему `isResizable() = true` и `prefWidth/Height`:
|
||
- Canvas в JavaFX по умолчанию не участвует в Layout (всегда сам задаёт размер).
|
||
- Переопределение `isResizable`, `prefWidth`, `prefHeight` заставляет Canvas вести себя как Node, который можно растягивать через `widthProperty().bind(...)`.
|
||
- Без этого Canvas бы не подстраивался под SplitPane при изменении размеров окна.
|
||
|
||
### 4.11. Парсинг `parseShowResponse`
|
||
|
||
```kotlin
|
||
private fun parseShowResponse(message: String): List<HumanBeingProperty>? {
|
||
val lines = message.lines().filter { it.isNotBlank() }
|
||
var currentLines = mutableListOf<String>()
|
||
var braceCount = 0
|
||
for (line in lines) {
|
||
currentLines.add(line)
|
||
braceCount += line.count { it == '{' }
|
||
braceCount -= line.count { it == '}' }
|
||
if (braceCount == 0 && currentLines.isNotEmpty()) {
|
||
val parsed = parseHumanBeingBlock(currentLines)
|
||
if (parsed != null) items.add(parsed)
|
||
currentLines.clear()
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему brace-счётчик, а не разбивка по строкам:
|
||
- HumanBeing содержит вложенные объекты Coordinates и Car. Их `toString()` тоже содержит фигурные скобки.
|
||
- Простое разделение по `\n\n` не сработает, если у Coordinates будет многострочный вывод.
|
||
- Brace-счётчик отслеживает вложенность: открывающая `{` увеличивает счётчик, закрывающая `}` уменьшает. Когда `braceCount == 0` — блок завершён.
|
||
|
||
### 4.12. MainView — сборка UI
|
||
|
||
```kotlin
|
||
private fun buildTablePane(): Node {
|
||
val columns = listOf(
|
||
"name" to { p: HumanBeingProperty -> p.name.value },
|
||
"coordinates.x" to { p: HumanBeingProperty -> p.coordinateX.value.toString() },
|
||
...
|
||
)
|
||
for ((i, col) in columns.withIndex()) {
|
||
val headerLabel = Label()
|
||
AppLocale.bindLabel(headerLabel, "table.$key")
|
||
headerLabel.setOnMouseClicked { toggleSort(key) }
|
||
...
|
||
val tableCol = TableColumn<HumanBeingProperty, String>()
|
||
tableCol.cellValueFactory = Callback { SimpleObjectProperty(extractor(it.value)) }
|
||
...
|
||
}
|
||
}
|
||
```
|
||
|
||
Почему программное построение UI, а не FXML:
|
||
- FXML удобен для крупных форм со сложной вложенностью. У нас — один BorderPane с ToolBar, SplitPane и HBox.
|
||
- FXML требует `@FXML` аннотаций, отдельного контроллера, FXMLLoader с ClassLoader.
|
||
- Для 300 строк UI проще писать на Kotlin: типизировано, нет магических строк `#onLogin`, компилятор проверяет вызовы.
|
||
|
||
Почему 11 отдельных TextField для фильтров, а не один поиск:
|
||
- Требование: фильтр по каждому полю отдельно.
|
||
- Пользователь может искать по имени И координате X одновременно.
|
||
- `Map<String, String>`, где key = имя поля, value = строка поиска, передаётся в `StreamUtils.applyFiltersAndSort`.
|
||
|
||
Сортировка по клику на заголовок:
|
||
- Клик по headerLabel переключает сортировку для колонки.
|
||
- `toggleSort(key)` меняет `sortAscending` и создаёт `Comparator<HumanBeingProperty>`.
|
||
- Компаратор сравнивает строковые представления значений — это универсально, работает для всех типов (String, Int, Double, Boolean).
|
||
- `padStart` для чисел: `1.toString().padStart(20, '0')` = `"00000000000000000001"`. Это нужно, чтобы лексикографическая сортировка строк дала правильный числовой порядок.
|
||
|
||
### 4.13. MainView — команды add / edit / delete
|
||
|
||
```kotlin
|
||
private fun onAdd() {
|
||
val dialog = EditDialog(stage.scene.window)
|
||
val humanBeing = dialog.showAndWait() ?: return
|
||
controller.executeCommand(name = "add", humanBeing = humanBeing) { success, message ->
|
||
if (success) controller.requestRefresh() else showError(message)
|
||
}
|
||
}
|
||
```
|
||
|
||
`controller.requestRefresh()`:
|
||
- При вызове `requestRefresh()` контроллер сразу запускает `refreshCollection()`.
|
||
- После успешной операции (add/update/delete) новый объект появляется в таблице немедленно, без ожидания 3-секундного poll.
|
||
- `Platform.runLater` внутри `refreshCollection` гарантирует, что обновление коллекции происходит в JavaFX Application Thread.
|
||
|
||
### 4.14. Сборка shadowJar
|
||
|
||
```kotlin
|
||
// build.gradle.kts
|
||
plugins {
|
||
kotlin("jvm")
|
||
id("org.jetbrains.compose")
|
||
id("com.gradleup.shadow")
|
||
}
|
||
|
||
tasks.shadowJar {
|
||
archiveBaseName.set("Lab8-gui-client")
|
||
archiveVersion.set("1.0")
|
||
archiveClassifier.set("all")
|
||
mergeServiceFiles()
|
||
}
|
||
```
|
||
|
||
- `com.gradleup.shadow` — создаёт fat JAR со всеми зависимостями (Kotlin stdlib, JavaFX, Exposed, Jackson, Log4j).
|
||
- `mergeServiceFiles()` — объединяет META-INF/services из всех JAR-ов, иначе не работают JavaFX ServiceLoader и JDBC Driver.
|
||
- JavaFX modules (javafx.controls, javafx.graphics) — добавляются в runtime через Gradle Compose plugin.
|
||
|
||
---
|
||
|
||
## 5. Data Flow
|
||
|
||
### 5.1. Аутентификация
|
||
|
||
```
|
||
AuthView.onLogin()
|
||
→ читает host, port, username, password, isLogin
|
||
→ controller.authenticate(host, port, username, password, isLogin) { success, msg -> ... }
|
||
→ scope.launch(Dispatchers.Default)
|
||
→ Session.client?.close()
|
||
→ ClientProvider(host, port) // создаётся новый провайдер
|
||
→ provider.auth(login, password, type)
|
||
→ withContext(Dispatchers.IO)
|
||
→ NetworkManager.sendRequest(AuthRequest(...))
|
||
→ DatagramChannel.send() / receive() (blocking)
|
||
→ response.success?
|
||
→ Session.client = provider
|
||
→ Session.username = username
|
||
→ Session.userId = provider.getUUID()
|
||
→ Platform.runLater { onResult(true, "") }
|
||
→ AuthView: stage.close(), onSuccess?.invoke()
|
||
→ Main.Stage → MainView.show()
|
||
```
|
||
|
||
### 5.2. Получение коллекции (polling)
|
||
|
||
```
|
||
MainController.start()
|
||
→ startPolling()
|
||
→ scope.launch { while(isActive) { delay(3000); refreshCollection() } }
|
||
|
||
refreshCollection()
|
||
→ Session.client?.execute("show")
|
||
→ withContext(Dispatchers.IO)
|
||
→ NetworkManager.sendRequest(Request("show", ...))
|
||
→ parseShowResponse(response.message)
|
||
→ lines → brace-счётчик → parseHumanBeingBlock → HumanBeingProperty
|
||
→ Platform.runLater {
|
||
Session.collection.removeAll(toRemove)
|
||
Session.collection.addAll(toAdd)
|
||
Session.collection[idx] = updated
|
||
}
|
||
→ TableView обновляется (items привязан к filteredList ← Session.collection + фильтры)
|
||
→ Canvas перерисовывается (collectionListener → scheduleRender())
|
||
```
|
||
|
||
### 5.3. Добавление объекта
|
||
|
||
```
|
||
MainView.onAdd()
|
||
→ EditDialog(stage.scene.window).showAndWait()
|
||
→ модальный диалог → пользователь заполняет поля → OK
|
||
→ onOk(): валидация → result = HumanBeing(...) → dialog.close()
|
||
→ возвращает HumanBeing
|
||
→ controller.executeCommand("add", humanBeing = humanBeing)
|
||
→ scope.launch {
|
||
Session.client?.execute("add", [], humanBeing)
|
||
→ withContext(Dispatchers.IO)
|
||
→ NetworkManager.sendRequest(Request("add", ..., humanBeing))
|
||
}
|
||
→ callback { success, message ->
|
||
if (success) controller.requestRefresh()
|
||
else showError(message)
|
||
}
|
||
```
|
||
|
||
### 5.4. Фильтрация и сортировка
|
||
|
||
```
|
||
Пользователь вводит текст в filterField
|
||
→ filterField.textProperty().addListener { _, _, _ → applyFilters() }
|
||
→ controller.updateFilters(filters)
|
||
→ currentFilters = filters
|
||
→ reapplyFiltersAndSort()
|
||
→ StreamUtils.applyFiltersAndSort(Session.collection, currentFilters, currentComparators)
|
||
→ stream.filter(...).sorted(...).collect(collectingAndThen(...))
|
||
→ Platform.runLater { filteredList.setAll(result) }
|
||
```
|
||
|
||
---
|
||
|
||
## 6. Почему именно такие решения: сводная таблица
|
||
|
||
| Решение | Альтернатива | Почему выбрано это |
|
||
|---------|-------------|-------------------|
|
||
| MVC (View → Controller) | MVVM, MVP | Простота, JavaFX TableView из коробки работает с ObservableList |
|
||
| Session singleton | DI (Koin, Dagger) | 2 controller + 4 view — DI избыточен |
|
||
| HumanBeingProperty | Прямое использование HumanBeing | Observable для TableView |
|
||
| ClientProvider (coroutine wrapper) | Сделать NetworkManager suspend | Нельзя менять модуль client; wrapping = изоляция |
|
||
| Polling 3s | Push / WebSocket | UDP, сервер не поддерживает push |
|
||
| StreamUtils (Streams API) | Kotlin Sequences | Требование лабораторной |
|
||
| i18n в коде (Map) | .properties файлы | Требование лабораторной |
|
||
| ObjectProperty<Locale> + bind | Пересоздание Scene | Сохраняет состояние UI при смене языка |
|
||
| Canvas + AnimationTimer | Shapes + Timeline | Производительность при 50+ объектах |
|
||
| Regex-парсинг ответа show | JSON | Формат ответа сервера фиксирован и не-JSON |
|
||
| Программный UI | FXML | Малый размер UI, типизация, без FXMLLoader |
|
||
| shadowJar | jlink / jpackage | Простота, одношаговая сборка, без модульных рисков |
|
||
|
||
---
|
||
|
||
## 7. Известные дефекты и ограничения
|
||
|
||
1. **Regex-парсинг ответа `show` хрупок** — если сервер изменит формат вывода, парсинг сломается. Решение: согласование формата с сервером или JSON API.
|
||
|
||
2. **Polling каждые 3 секунды** — избыточная нагрузка при сотнях клиентов. Решение: увеличить интервал или перейти на push.
|
||
|
||
3. **Фильтры на стороне клиента** — если коллекция большая (100K+ объектов), фильтрация через Streams API занимает время. Решение: server-side filtering.
|
||
|
||
4. **Canvas не использует GPU-ускорение** — JavaFX Canvas рендерится на CPU. Для 500+ объектов могут быть просадки FPS. Решение: перейти на `Group` с `Circle` или OpenGL через `Node`.
|
||
|
||
5. **Нет обработки reconnect** — если сервер перезагрузился, client.close() не пересоздаёт подключение. Решение: таймаут + retry logic в ClientProvider.
|
||
|
||
6. **Session.client — var с nullable** — возможно race condition: два вызова `execute()` в разных корутинах пока client уже закрыт. Решение: `synchronized` или `Mutex`.
|
||
|
||
7. **Нет кэширования locale-строк** — при переключении языка каждый bind вызывает `get(key)` на каждый listener. Для 50+ bind-ов это O(n * m). Решение: кэш `MutableMap<String, String>` при смене локали.
|