singleton пащиму?

Ты серьёзно читаешь всякое, содержащее фразы вроде «wrong usage of the pattern»? Это бессмысленный набор слов. Если бы он имел смысл, то по ссылке было бы 5 строк кода, которые просто показывают почему при некоторых обстоятельствах использование синглтона может привести к беде.

Глобально, со всеми вытекающими минусами, если я правильно понял автора

Ну в частности я сейчас столкнулся с Unit test'ами. У меня есть враппер к библиотеке на основе синглтона. Почему синглтон - потому что не вижу смысла, зачем может понадобится второй экземпляр этого враппера.
Набрёл ещё на интересную статью, как решить проблемы с тестами http://www.drdobbs.com/once-is-not-enough/184401625

А как его правильно использовать?

Никак (почти, по аналогии с goto). Синглетон — это антипаттерн.

http://molecularmusings.wordpress.com/2011/11/11/singleton-is-an-anti-pattern/

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

А зачем понадобился первый экземпляр?

Если честно, то почти все примеры притянуты за уши, и синглтон там действительно не нужен.

А зачем понадобился первый экземпляр?

Инициализировать библиотеку и продолжать общаться с ней on session basis

Инициализировать библиотеку и продолжать общаться с ней on session basis

Библиотека допускает несколько одновременных сессий? Какие-либо содержательные действия с этой библиотекой можно делать не через сессии?

Какие-либо содержательные действия с этой библиотекой можно делать не через сессии?

Только data conversion. Общение по сети только с сессией.

Библиотека допускает несколько одновременных сессий?

Библиотека допускает несколько одновременных сессий?

Define одновременно. Несколько использовать можно, но она не thread-safe.

Define одновременно.

Поочередно из одного потока.

Да, можно. При этом сессия передаётся параметром.

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

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

Сессия - это сишная структура, так что я с другой стороны как бы )

Вот и получается, что твой синглтон притянут за уши.

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

Тогда это хозяйство можно вообразить, будто параметр сессии — это экземпляр класса «либа». Просто класс написан хреново, так что портит данные, если вызывать его члены из нескольких потоков. Соответственно, от враппера этой либы нужна дополнительная функциональность в виде обеспечения упорядоченного доступа к либе из разных экземпляров. А исходя из этого непонятно, как сингл он решил проблему.

Сессия - это сишная структура, так что я с другой стороны как бы )

Нарисуй сюда свой си-шный апи: функции создания/уничтожения сессии и какую-нибудь одну функцию, которая через эту сессию что-нибудь полезное делает.

http://www.net-snmp.org/wiki/index.php/TUT:Simple_Application

Интересно... Но я пошёл по принципу:

class Host:
   struct snmp_session *m_ss;
...

Допустим. Ну и где тут место для синглетона?

Запихать используемые snmp_* туда. =)

Желание «запихать ... туда» имеет какие-нибудь рациональные причины, или его истоки лежат целиком в области подсознательного? :D

Lol.
Ну, хотелось свести все сетевые вызовы в одни класс, чтобы облегчить тестирование.
Да, с синглтоном тестирование усложняется )

хотелось свести все сетевые вызовы в одни класс

В теории, каждый класс в твоей программе должен соответствовать какому-то имени-существительному из предметной области. Если твой класс предназначен для того, чтобы свалить в него все какие попались под руку сетевые вызовы, то соответствующую сущность логично назвать «помойкой». Или «кладбищем вызовов». У тебя в предметной области помойки и кладбища предусмотрены?

Ok, ты придрался к словам. Не все сетевые вызовы, а все snmp вызовы. Так логичней? )

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

Синглетон — это антипаттерн.

Юзкейсы у него есть: классы вроде Log и Settings.

Log

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

Settings

Ты упоролся что ли?

Синглетон — это антипаттерн.

вы таки ещё скажите, что enum - это антипаттерн.

Про enum я такого не скажу. А что до синглтона... ну, кому и кобыла — невеста.

Ok, ну так чё советуешь в итоге? Убрать синглтон и параметром во все объекты передавать?
P.S.: unit тесты всё равно отменяются, поскольку не вижу в них смысла для этих объектов...

Синглетон — это антипаттерн.

вы таки ещё скажите, что enum - это антипаттерн.

Как из одного вдруг вытекло другое?

ну а где различие между мультитоном (enum) и синглтоном, почему синглтон - антипаттерн, а мультитон - нет?

см выше

http://en.wikipedia.org/wiki/Multiton_pattern
Погуглил по слову enum - не нашёл... задумался.

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

Не преумножайте сущности без надобности ©

Построй свою программу вокруг логгера-синглтона, и этой возможности ты лишишься.

Это даже к лучшему.

Все эти вопли вокруг Singleton — ерунда. Есть случаи, когда объект один и все тут. У нас одно Солнце, так нет же, обязательно найдется умник и скажет: «представь, что у нас два Солнца!». Да пофиг! Потому что, когда будет два Солнца, Земля не будет больше вращаться по эллиптической орбите и много-много чего еще будет по-другому. Но есть умники, которые думают, что заменив Singleton на что-то другое, мы автоматом получим нужную траекторию...

думать - это вообще полезно, делайте это почаще.

мультитоном (enum)

Под словом «enum» вообще-то обычно подразумевают «enumerated type». А ты говоришь о... мульти-что?

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

иди, как твой товарищ выше - подумай, это полезно.

Законы-то останутся прежними

Для системы сириуса?

Законы те же, а решения может уже и не быть, man «Задача трёх тел».

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

именно по-этому синглтоны и плохи. сейчас приведу примеры синглтонов и им подобных конструкций

1. gtk_main()/gtk_main_quit() - работают на основе единого счётчика синглтона, «благодаря» чему, гибкой модальности в многооконном приложении можно добиться только за счёт костылестроения

2. zodb - по умолчанию, предлагает синглтонное подключение к дб, «благодаря» чему, коммиты в дб производятся глобально и усложняется создание более одного подключения в одном приложении

3. SQLAlchemy - тоже самое - строим костыли

и так далее.

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

синглтоны, глобальные, детские проблемы с многозадачностью.. всё это атавизмы пришедшие из неразвитости и неудобности языка C. да, на C можно написать драйвер или линукс, но будьте добры, использовать C++, D или другой язык с нормальной объектностью и неймспейсингом.

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

Не преумножайте сущности без надобности

Я лишь продемонстрировал, что природа логгера вовсе не подразумевает его единственности.

Потому что, когда будет два Солнца, Земля не будет больше вращаться по эллиптической орбите и много-много чего еще будет по-другому.

Двум разным солнечным системам вовсе не обязательно взаимодействовать. Чего ради лишать себя возможности хотя бы в каких-то технических целях держать в программе одновременно несколько не зависящих друг от друга экземпляров солнечных систем?

У нас одно Солнце, так нет же, обязательно найдется умник и скажет: «представь, что у нас два Солнца!». Да пофиг!

Чем меньше разные части программы знают друг о друге, тем программа проще. Многим юниорам это не очевидно, но по факту действует принцип «разделяй и властвуй». Это распространяется и на познания класса о единственности (или множественности, или вообще об устройстве) тех или иных объектов из окружения этого класса. (Кстати, здесь уместно вспомнить еще и про interface segregation; солнце — скорее всего слишком богатый и конкретный объект, и лучше бы классу не знать о том, что он имеет дело именно с солнцем, а не, например, с луной). Твоему классу передали инстанс солнца, ну работай с ним; одно в программе солнце или их много — это не в компетенции твоего класса. Такой класс будет гораздо проще будет переиспользовать, потому что его можно «как есть» разместить в абсолютно непохожем окружении, и он попросту не заметит никаких изменений. Такой код легче юнит-тестировать, потому что в него можно просто передать тестовую версию солнца, не хакая глобальное окружение.

А разве не лучше применить Dependency Injection?

иди, как твой товарищ выше - подумай, это полезно.

Классный совет, не забудь напомнить о нём своей маме. Ну а по делу можешь сказать что-нибудь?