синглтон / статические классы для сервисов - PullRequest
5 голосов
/ 23 августа 2011

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

Эти классы создаются только один раз при запуске приложений, и нет никакого смысла иметь более одного на тип.

Так как я прочитал много ответов о синглетонах здесь, на SO, где их использование не рекомендуется, я продолжил, передавая ссылку на сервисы thoose, когда это необходимо. По мере роста проекта я обнаружил, что у меня есть много классов, которым нужна ссылка на службу для их конструктора, а в некоторых случаях даже фасад этих служб, чтобы избежать добавления всех ссылок на службы.

Я думаю, что делаю это неправильно. Я думаю, что это должно быть полезно для статических / синглтон-классов.

Это правильный подход?

Ответы [ 4 ]

2 голосов
/ 23 августа 2011

Похоже, вам нужен контейнер для инъекций зависимостей с некоторыми возможностями автоматического подключения.Если вы используете Java, рассмотрим Spring, например.

1 голос
/ 23 августа 2011

Я вижу, один ответ предлагает ввести Spring.Под прикрытием Spring все еще передает эту ссылку там, где это необходимо.

Вместо того, чтобы вводить новый фреймворк в приложение, почему бы просто не использовать Singleton?Если это делает работу и ее легче поддерживать, чем передавать ссылку на сервис, я говорю, используйте ее.

Если вы беспокоитесь о Singletons из-за их влияния на тестируемость, используйте Dependency Injection (шаблон, а не платформа), чтобы уменьшить связь с реализацией.

0 голосов
/ 23 августа 2011

Я согласен с MikeG.Используйте синглтон.Поскольку вы говорите, что эти классы в основном ориентированы на обслуживание, я не ожидал, что это вызовет какие-либо проблемы.

0 голосов
/ 23 августа 2011

Синглтон фактически означает объекты, которые должны создаваться только один раз только в течение жизненного цикла приложения.Эти объекты на самом деле содержат некоторые из фиксированных настроек.Допустим, у вас есть класс парсера, предназначенный для разбора только html.Корнем HTML должен быть тег "".Кроме того, вы не хотите создавать множество экземпляров из этого класса синтаксического анализатора, потому что каждый экземпляр класса будет делать то же самое.Экземпляр получит строку html и вернет вам X. Если вы думаете, что ваши классы будут выполнять только одну вещь за раз, вы можете перейти на singleton.Однако, если вы скажете, что, например, ваша аудиослужба должна воспроизводить разные аудиозаписи за раз, я думаю, создание экземпляра класса лучше, чем создание его одиночным.

...