После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Практически всегда, когда я писал синглтон, наступал момент, когда мне нужно было два таких объекта.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Аноним, Вы писали:

А>Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках).

Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.

J>Практически всегда, когда я писал синглтон, наступал момент, когда мне нужно было два таких объекта.

для С++ больше подходит monostate
http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Аноним, Вы писали:

А>>Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках).

Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.

хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?

Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Синглтон это такая вещь, которая почти всегда используюется неправильно

Когда лень думать про инициализацию — берут синглтон
Лень думать про передачу ссылки — берут синглтон
Нужн только один инстанц — берут синглтон

Здравствуйте, sidorov18, Вы писали:

Кё>>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.

S>хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?

А по подробнее можно унать, что за класс объекта и почему только один инстанс ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, sidorov18, Вы писали:

Кё>>>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.

S>>хм. нужен только один инстанс объекта на всю программу. какая альтернатива синглтону?

I>А по подробнее можно унать, что за класс объекта и почему только один инстанс ?

Я не топикстартер.
Я вообще

У меня, например, синглтоном класс лог.
А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

Здравствуйте, Кодёнок, Вы писали:

Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен. И кстати application во многих фреймворках просто глобальная переменная, а не «умный» синглтон.

Ну так глобальная переменная — это и есть простейший вариант синглтона, нет?

А всякие обертки нужны чтобы разрулить порядок инициализации и время жизни...

Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Вообще, синглтон повышает связанность(coupling) вашего кода. Это не значит что это плохо, но иногда может мешать(например написанию юнит тестов)
Вносится дополнительное глобальное состояние всей программы. Однако удобства его использования чаще всего склоняют в сторону его использования (мы использовали в проекте где 1М строк кода) Здесь не рассматривается вариант "мы используем синглтон потому что лень следить/управлять временем жизни объекта". Как правило это именно централизованый доступ, а не управление временем жизни объекта(CreateInstance(), DestroyInstance() присутствуют всегда явно, или объект вообще создается на стеке) В случае с многопоточностью, как правило, это один объект на поток(что также неплохо ложится на TLS)

Здравствуйте, rm822, Вы писали:

R>для С++ больше подходит monostate
R>http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf

Почитал, не понял в чем преимущество monostate.

class TMonostate
{
  static std::string s;

public:

  const std::string& getS() { return s; }
  
};

В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?

Здравствуйте, Кодёнок, Вы писали:

Кё>Синглтон не вреден или неправилен, он просто нахрен не нужен.
не соглашусь... и поддержу sidorov18'а

Автор: sidorov18
Дата: 26.07.10

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

E>В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?
Преимущество будет когда выясниться что объектов нифига не один, и что закладываться на это везде в коде было большой ошибкой

Здравствуйте, sidorov18, Вы писали:

S>У меня, например, синглтоном класс лог.
S>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

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

Здравствуйте, <Аноним>, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять . Кажется очень удобным иметь под рукой объект, в любом месте программы. То есть, и код структурируется по классам, и не нужно с передачей ссылок на объекты возиться. Но вот в "настоящих" ООП приложениях практически не встречаю его (обычно синглтоны — только объекты Application в различных фреймворках). До этого писал на С. Насколько "неправильной" для дизайна больших приложений может быть такая практика?

Вреден ровно настолько насколько глобальные данные.

Здравствуйте, sidorov18, Вы писали:

S>Я не топикстартер.
S>Я вообще

S>У меня, например, синглтоном класс лог.

Лог это как раз пример того, что не должно быть синглтоном

S>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.

И это тоже

Я знаю только три случая когда класс можно делать синглтоном:

1. Состояние объекта не меняется на протяжении времени его жизни и это состояние можно полностью описать в программном коде/ресурсах — состояние не зависит от текущего времени, содержимого конфигурационных файлов, переменных окружения и т.п. Но синглтон вполне может грузить какие-либо ресурсы, которые считаются "вшитыми" в приложение. Т.е. синглтон является не глобальной переменной, а глобальной константой.

2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)

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

Во всех других случаях считаю использование синглтонов считаю неприемлемым.

Здравствуйте, rm822, Вы писали:

E>>В таком виде использовать не получится, так как до входа в main() TMonostate::s может быть неинициализирована. Т.е. внутри надо городить синглетон, оберткой для которого будет этот TMonostate. Тогда в чем преимущество?
R>Преимущество будет когда выясниться что объектов нифига не один, и что закладываться на это везде в коде было большой ошибкой

Ну т.е. monostate — это исключительно обертка над синглетоном. С тем же успехом можно возвращать из функции TSingleton::get() умный указатель. А если выяснится, что синглтон на самом деле не синглтон, то эта функция будет создавать объекты (возможно получая какие-то опциональные параметры), а не возвращать указатель на статический...

Здравствуйте, kjam, Вы писали:

K>2. Синглтон является расширением рантайма, частью машины которая исполняет нашу программу. (Например — отладочное (!) логирование)

Это сегодня программа однопоточная, и отладочное логирование можно сделать синглтоном. А завтра появится новый поток, и привет. Пользоваться из двух потоков одним отладочным логом без синхронизации — портить лог. Городить синхронизацию — а нафиг тогда потоки? Остаётся только делать по отдельному логу на каждый поток.

Здравствуйте, Аноним, Вы писали:

А>После того, как узнал про этот паттерн, постоянно хочется его применять

использовать синглетоны совсем не вредно, поэтому используйте на здоровье.