Один из аспектов разделения интересов.
Я пару раз сталкивался с этим на работе, и это раздражает. Он иллюстрирует случай, когда детали реализации «просачиваются» в клиентский код.
В одном из сценариев у клиента запрашиваются определенные данные, например размер и форма. Однако реализация (на сервере) не распознает эти входные данные, но распознает «шаблоны», которые представляют собой комбинации размера и формы. Итак, где-то по пути размер X и форма Y должны быть преобразованы в шаблон Z.
Есть несколько способов решить эту проблему. Самый очевидный и правильный способ — заставить сервер выполнять перевод, принимать размер и форму и определять путем поиска в базе данных соответствующий шаблон. Устаревший код является унаследованным кодом, и вы часто боитесь его трогать из-за его непостижимости и хрупкости. И, вероятно, вы все равно собираетесь заменить его, поэтому не хотите тратить много времени на его улучшение.
Итак, вы можете сделать перевод на сервере, но с использованием шаблона адаптера. Метод адаптера принимает размер и форму и «адаптирует» его к устаревшему API, выполняя преобразование в форму шаблона (опять же, через поиск в базе данных). Если соответствие размера/формы и шаблона устарело и относительно стабильно, то использование таблицы в коде для сопоставления приемлемо, на мой взгляд.
Однако самое худшее, что можно сделать, — это сделать этот перевод в JavaScript, работающем в браузере. Браузерный код предназначен для ввода и представления… во всех остальных вопросах он должен быть глупым. Задачей кода в браузере является передача желаний пользователя, пассивное сохранение инициированного сервером состояния и отображение результатов операций.
В следующем посте мы немного подробнее поговорим о бухгалтерском учете, связанном с передачей состояния.
