Статьи

Пересматривая цель классов менеджера

Я натолкнулся на дискуссию о том, является ли целесообразным называть имя [Something] Manager класса. В основном я наткнулся на эту статью , но также нашел другие ссылки здесь и здесь . У меня уже были свои мысли на эту тему, и я решил поделиться ими с вами.

Я начал думать об этом некоторое время назад, работая в настольном приложении на базе Swing. Мы решили, что будем использовать модель Listeners, которую Swing устанавливает для своих компонентов. Чтобы зарегистрировать слушателя в компоненте Swing, вы говорите:

// Some-Type = {Action, Key, Mouse, Focus, ...}
component.add[Some-Type]Listener(listener); 

Это не проблема, пока вам не нужно динамически удалить этих слушателей или переопределить их (удалить и добавить нового слушателя, который прослушивает то же событие, но запускает другое действие), или делать с ними какие-либо другие «неестественные» действия. Это оказывается немного сложным, если вы используете интерфейс, который Swing предоставляет «из коробки». Например, чтобы удалить слушателя, вам нужно передать весь экземпляр, который вы хотите удалить; вам придется держать ссылку на слушателя, если вы собираетесь удалить ее через некоторое время.

Поэтому я решил сделать еще один шаг и попытаться абстрагироваться от беспорядка, создав класс Manager. То, что вы могли сделать с этим классом, было примерно таким:

EventsListenersManager.registerListener(
        "some unique name", component, listener);
EventsListenersManager.overrideListener("some unique name", newListener);
EventsListenerManager.disableListener("some unique name");
EventsListenerManager.enableListener("some unique name");
EventsListenerManager.unregisterListener("some unique name");

Что мы здесь приобрели ??? Мы избавились от явной спецификации [Some-Type] и имеем одну функцию для каждого типа слушателя; и мы определили уникальное имя для привязки, которое будет использоваться как идентификатор для удаления, включения / отключения и переопределения слушателей; иначе нет необходимости держать ссылки.

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

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

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

  • Слушатели дороги, потому что с ними может быть трудно играть, и они могут быть узким местом в производительности (мы должны держать их короткими и быстрыми).
  • Соединения дороги в строительстве.
  • Медиа ресурсы дорого загружать.
  • Аппаратные ресурсы дороги, потому что их мало.

Поэтому мы создаем для них разных менеджеров:

  • Мы создаем менеджер для слушателей, чтобы облегчить и контролировать их использование.
  • Мы создаем пул соединений, чтобы ограничить и контролировать количество соединений с базой данных.
  • Разработчики игр создают диспетчер ресурсов, чтобы иметь единую точку для доступа к ресурсам и уменьшить возможность их загрузки несколько раз.
  • Мы все знаем, что для каждого устройства есть драйвер. Это их менеджер.

Здесь мы видим множество вариантов реализации классов менеджера, но все они пытаются решить одну вещь: снизить затраты, которые мы можем понести при непосредственном использовании дорогих ресурсов.

Я думаю, что у людей должна быть такая мысль: создать класс менеджера для каждого дорогого ресурса, который вы обнаружите в своем приложении . Вы будете более чем благодарны, когда захотите добавить дополнительную логику, и вам нужно всего лишь пойти в одно место. Кроме того, принудительно используйте объекты менеджера вместо прямого доступа к ресурсам.

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