Одиночка: частота применения

[Bgg]

Сообщение от TanaTiX

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

Почитай тему про MVC. Как только контроллер звука изменил громкость он шлет событие об этом, и те объекты кого это интересует должны это событие услышать.

[terbooter]

Вообщем, синглтон в неумелых руках это зло.
Тк бесконтрольное его применение позволяет разводить макаронный код, при этом автор утверждает, что ничего страшного, он же использует шаблоны =)

[TanaTiX]

terbooter

У синглтона плюсы небольшие, но минусы огромные.

можно про минусы подробней? Согласен что они есть, но вот в чем "огромногсть"?

Лично я стараюсь не использовать.

Каким образом удается обходиться без одиночки?

при этом автор утверждает, что ничего страшного, он же использует шаблоны =)

Я ничего не утверждаю, я чувствую недостатки в своей манере программирования и хочу исправить ситуацию.

[Gaen]

Каким образом удается обходиться без одиночки?

А каким образом устроен ваш код, что необходимо наличие одиночки? Что в нем сломается, если одиночку превратить в обычный класс?

[mikhailk]

можно про минусы подробней? Согласен что они есть, но вот в чем "огромногсть"?

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

Понятно, что это целиком в зоне ответственности разработчика, но тем не менее.

А каким образом устроен ваш код, что необходимо наличие одиночки? Что в нем сломается, если одиночку превратить в обычный класс?

Синглетон он на то и синглетон, что содержит ссылку на свой единственный экземпляр. MyClass.instance.

Мне лично больше нравятся целиком статические функции/классы.

[TanaTiX]

mikhailk

возникает большой соблазн не заморачиваться с пересылкой событий

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

Мне лично больше нравятся целиком статические функции/классы.

Сколько помню, в вопросе между статикой и одиночкой в 99% описывается "победа" за одиночкой (исключение - классы, по функционалу схожие с Math)
GAIKER

А каким образом устроен ваш код, что необходимо наличие одиночки?

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

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

[expl]

Мне лично больше нравятся целиком статические функции/классы.

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

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

(Правда, один товарищ благоразумно удержался от лепки if-ов и сделал обёртку для своего приложение над статикой. Но это не сильно щас помогает, потому как функционал нужен многим, а не только его приложению)

Теперь твердо уверен, что статический класс имеет право на жизнь только тогда, когда не имеет состояния (не содержит внутренних/внешних полей) и то не всегда - как его в духе "стратегии" подпихнуть то?

[mikhailk]

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

Как ни странно, такого соблазна не возникает - создаются события и все идет своим чередом.

Так а зачем тогда синглтон?
В смысле, чем он отличается от обычного класса?

Я встречал реализацию синглтонов в различных проектах и всегда это затевалось именно в целях глобального доступа к единственному объекту через публичную переменную instance (или что-нибудь типа того). Если не использовать эту особенность синглтона (которая, собственно, и отличает объект синглтона от объекта обычного класса), то зачем вообще использовать синглтон? Для контроля рождаемости?

[expl]

Никто не предлагает лепить все статикой. Но иногда это удобно.

Я тоже так говорил на вопрос "нафига ты этот сервис статикой сделал?"

Не, я сам юзаю статику для фабрик контролов, фабрик стилей текстовых полей, для общих, ни от чего не зависящих алгоритмов - пока полёт нормальный (не огреб ещё с ними )

Так а зачем тогда синглтон?
В смысле, чем он отличается от обычного класса?

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

А контроль рождаемости - это защита от почесывания правого уха левой пяткой - только лишнее ограничение в коде. Бывало просто: "А теперь нам нужен второй сервис - чисто для ..., т.к. чтобы ... работало надо на другой сервер ходить" - и понеслось:
- перед использованием синглтона лепим флаг "использовать особый сервис"
- лепим внутрь ветку if-а, которая меняет url-ки к которым класс должен обращаться;
- поиспользовали - надо вернуть флаг обратно - чтобы приложение работало
Веселье еще то.
(и при этом всём надеемся, что пока синглтон работает с этими настройками к нему не обратятся другие части приложения, считая, что он настроен по-дефолту)

[TanaTiX]

Для контроля рождаемости?

Собственно да. Фраза кстати порадовала
Так вот, мне нужно знать что SharedObject у меня может записываться только в одном экземпляре класса, что никто не перепишет записанное значение. Или тоже самое относительно настроек звука и пр. Т.е. глобальный доступ - да, это удобно, но основное, что мной движет - то, что необходим единственный экземпляр. Почему тогда у меня возникли сомнения? Потому что, к примеру, класс Main (базовый класс приложения) и другие глобальные контейнеры создаются тоже в единственном экземпляре, при этом никому и в голову не приходит реализовывать их через сингл. Вот проведя такую параллель после того как количество одиночек в текущем проекте перевалило за 5, и появились сомнения.