Правильный дизайн для глобального доступа к данным и их модификации

Question

Я уверен, что это то, что происходит регулярно, но я не знаю, как с этим справиться, и при этом я не знаю соответствующих терминов для поиска.Я создаю утилиту для поисковой системы, которая добавляет «эвристику» к входящим поисковым заданиям с использованием Java.(Так, например, если пользователь ищет слово «диван», утилита добавит такие термины, как «диван» и «мебель для спальни», чтобы получить более релевантные результаты.)

У меня возникли некоторые проблемыобработка глобальной информации.В этом конкретном случае эвристические термины - это глобальная информация, которая может быть изменена кем-то, работающим на бэкэнде, или может быть доступна клиенту с помощью поиска.Итак, я хотел знать, что будет лучшим в этом случае: я могу создать класс с почти чисто статическими методами, который называется что-то вроде HeuristicSearchEngine, который можно запустить в начале запуска сервера, загрузить эвристику в память иесть методы, которые можно использовать для доступа к эвристике для поиска или изменения условий.Это просто кажется неаккуратным, поскольку не использует никаких преимуществ ООП.Итак, другой подход заключается в использовании синглтона для создания экземпляра текущей эвристики.Таким образом, каждый раз, когда запускается поисковое задание, оно может загрузить экземпляр текущего состояния, добавить эвристику к поиску и продолжить работу.Однако синглтон здесь не показался мне подходящим, и я хотел бы знать, как другие будут обращаться с этим делом.

Дайте мне знать, если вы хотите получить дополнительные разъяснения по поводу любой другой информации.

Answer 1

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

Вместо одноэлементного / факторного подхода рассмотрим внедрение зависимостей. Это более громоздко для реализации, но расширяется более изящно.

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

В качестве более конкретного примера, вместо того, чтобы ваши сервлеты вызывали com.me.Herusitic#getInstance(), они вместо этого имели бы экземпляр Heuristic, передаваемый их конструкторам. Эта ссылка Heuristic сохраняется внутри объекта и вызывается по мере необходимости. Позже, когда вы расширили Heuristic до FancyHeuristic и FakeHeuristicForTesting и хотите, чтобы ваши сервлеты использовали их вместо этого, вам не нужно изменять код сервлета: просто введите новый тип эвристики. При заводском подходе вам придется переписать свою заводскую логику.

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