Я натолкнулся на дискуссию о том, является ли целесообразным называть имя [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 мы добавили некоторую дополнительную логику, чтобы улучшить способ использования слушателей, предоставляя интерфейс, который упрощает их использование: теперь проще переключаться между двумя слушателями, чем это было раньше. Еще одна вещь, которую мы могли бы сделать, — ограничить число слушателей, зарегистрированных в одном компоненте, для повышения производительности (подсказка: выполнение слушателей не выполняется параллельно).
Поэтому классы менеджера кажутся полезными, но мы не можем создать менеджера для каждого объекта, которым мы хотим управлять в приложении . Это заняло бы время и заставило бы нас начать думать в классе менеджера, даже когда оно нам не нужно. Но мы можем обнаружить шаблон для определения менеджера. Я видел их использование, когда ресурсы, которыми они управляют, дороги, такие как соединения с базой данных, медиа-ресурсы, аппаратные ресурсы и т. Д .; и, как я понимаю, дороговизна может быть разных вкусов
- Слушатели дороги, потому что с ними может быть трудно играть, и они могут быть узким местом в производительности (мы должны держать их короткими и быстрыми).
- Соединения дороги в строительстве.
- Медиа ресурсы дорого загружать.
- Аппаратные ресурсы дороги, потому что их мало.
Поэтому мы создаем для них разных менеджеров:
- Мы создаем менеджер для слушателей, чтобы облегчить и контролировать их использование.
- Мы создаем пул соединений, чтобы ограничить и контролировать количество соединений с базой данных.
- Разработчики игр создают диспетчер ресурсов, чтобы иметь единую точку для доступа к ресурсам и уменьшить возможность их загрузки несколько раз.
- Мы все знаем, что для каждого устройства есть драйвер. Это их менеджер.
Здесь мы видим множество вариантов реализации классов менеджера, но все они пытаются решить одну вещь: снизить затраты, которые мы можем понести при непосредственном использовании дорогих ресурсов.
Я думаю, что у людей должна быть такая мысль: создать класс менеджера для каждого дорогого ресурса, который вы обнаружите в своем приложении . Вы будете более чем благодарны, когда захотите добавить дополнительную логику, и вам нужно всего лишь пойти в одно место. Кроме того, принудительно используйте объекты менеджера вместо прямого доступа к ресурсам.
В следующий раз, когда вы планируете сделать урок менеджера, спросите себя: «вещь», которую я хочу контролировать, дорогая в любом случае ???