Паттерн Singleton против функционального подхода

[FiloXSee]

Написал статью про сравнение функционального подхода с паттерном "Синглетон". Две ее части можно прочитать тут:

http://itw66.ru/blog/c_plus_plus/65.html
http://itw66.ru/blog/c_plus_plus/71.html

А вы как считаете, какой подход лучше?

[p51x]

СПАМ о своих статьях в http://programmersforum.ru/forumdisplay.php?f=24

[Utkin]

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

[FiloXSee]

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

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

Сложный вопрос - нафига? Это к вопросу о том, пользуешься ты паттернами при написание кода или всегда изобретаешь велосипед. Лично я довольно интенсивно пользовался синглетонами, когда мне нужно было создать какую-то систему. Синглетон кажется хорошим средством для создания функций, к которым можно отовсюду получить доступ... Однако есть и важные недостатки. Когда я их осознал и переосмыслил этот паттерн, то отказался от его использования в С++. Эти статьи - это объяснение лучшего подхода для достижения целей. И там не сильно синтетический код.. просто имена вымышленные и выкинуто все, что не относится к теме.

[pu4koff]

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

Кроме того, внешнему миру дается только то, что ему нужно, а все детали реализации, внутренние константы (такие как ARRAY_SIZE), внутренние переменные, внутренние структуры будут определяться только в одном файле (*.cpp) и при их изменение будет перекомпилирован только один файл.

Тут появляется сомнение по поводу знания автором ООП и любой синглтон всё то же самое легко предоставит.
4. Не раскрыта тема управления памятью в аналоге. Кто-то где-то ручками должен вызвать метод Create, а потом Destroy?

В общем, однобокая статья, которая обгаживает синглтон и совершенно не раскрывает темы аналога.

[Utkin]

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

Сложный вопрос - нафига? Это к вопросу о том, пользуешься ты паттернами при написание кода или всегда изобретаешь велосипед. Лично я довольно интенсивно пользовался синглетонами, когда мне нужно было создать какую-то систему. Синглетон кажется хорошим средством для создания функций, к которым можно отовсюду получить доступ... Однако есть и важные недостатки. Когда я их осознал и переосмыслил этот паттерн, то отказался от его использования в С++. Эти статьи - это объяснение лучшего подхода для достижения целей. И там не сильно синтетический код.. просто имена вымышленные и выкинуто все, что не относится к теме.

То есть реального примера применения не имеется?

[still_alive]

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

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

Нет там проблем. Читай статью Саттера+Александреску, а дальше смотри на DCLP + run_once.

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

Современная программа и без многопоточности?

Да. И? Многопоточность без явной необходимости - зло.

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

[alex_x_x]

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

То есть реального примера применения не имеется?

так или иначе они существуют, да

[Utkin]

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

так или иначе они существуют, да

Логично . Но только речь идет применительно к статье.

[pu4koff]

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

Нет там проблем.

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

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

а дальше смотри на DCLP + run_once.

А теперь пожалуйста расшифровку что сие такое есть

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

Да. И? Многопоточность без явной необходимости - зло.

Современные программы обычно идут с GUI. Вешать GUI из-за проведения каких-то расчетов - есть еще большее зло. Учитывая особенности синглтона и его типичное использование, не получится его использовать как, например, подключения к БД. Частенько же для облегчения жизни просто в каждом потоке используется своё подключение к БД, но с синглтоном такое уже не прокатит.

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

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

Это касается всех паттернов, а еще ранее это касается и ООП в целом.
Я бы вообще паттерны перевёл не как "шаблоны проектирования", а как "образцы/примеры проектирования". Паттерны - это вовсе не рекомендация к действию, а просто примеры решения типовых задач.