Синглтон и паттерн. Что это такое и с чем его едят? (C#))

[Пепел Феникса]

Если вам нужны интерфейсы, то сингелтон вам не нужен.

синглетон никогда не исключал реализацию интерфейса.
не путайте статический класс и синглетон, да первый много где может его заменить, но когда нам нужно реализовать IStorageManager, причем у реализации должен быть лишь один объект(например это TapeStorageManager), то тут нужен именно синглетон.

Есть маленький такой плюсик. Когда у вас не хватает ресурсов, к примеру памяти, для создания ещё одного класса. Тога имеет смысл по очереди: создал - разрушил, создал - разрушил.

а вы в курсе что на практике от этого только хуже? фрагментацию памяти никто не отменял.

Хотя однозначно к антипаттернам я относить бы его не стал

Антипаттерном является злоупотребление синглетонами.

[ds.Dante]

Сообщение от Пепел Феникса

а вы в курсе что на практике от этого только хуже? фрагментацию памяти никто не отменял.

При чём здесь фрагментация? Если у вас миллион маленьких структур, то да, заведомо быстрее сразу объявить весь массив. А если несколько тяжёлых объектов, то пускай рантайм сам решает, что лучше - лишний раз собрать мусор или расширить кучу.

[Пепел Феникса]

Сообщение от ds.Dante

При чём здесь фрагментация? Если у вас миллион маленьких структур, то да, заведомо быстрее сразу объявить весь массив. А если несколько тяжёлых объектов, то пускай рантайм сам решает, что лучше - лишний раз собрать мусор или расширить кучу.

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

[ds.Dante]

Сообщение от Пепел Феникса

я о том что часто дергание кучи(у нас же не единственное место выделение, в реальном приложении) будет вызывать фрагментацию.
+ сборщик удалит мусор не сразу, и мы в итоге получим или фриз на сборку или OutOfMemory быстрее чем если бы оставили объект.

Зависит от размеров объектов. Куча будет дёргаться часто только если с каждым разом мы создаём значительно больший синглтон. Другие же места выделения памяти будут одинаково влиять на оба наших варианта.

А OutOfMemory мы, скорее всего, получим только в вашем варианте. Если ни в одном потоке впереди по ходу выполнения не встречается ссылка на объект, он подлежит сборке; не в первом поколении, так во втором. Области досягаемости определяются джиттером, на скорость это практически не влияет.

Сообщение от Пепел Феникса

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

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

[Пепел Феникса]

Вы недоцитировали Pavia, он говорил про "надуманный пример и реально такое не бывает"

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

new Converter().Convert(obj)

и резко хочется стукнуть автора кода.

напомню что там был контекст недостатка памяти.

[ds.Dante]

Сообщение от Пепел Феникса

резко хочется стукнуть автора кода.

Лучше посадить его писать свой сборщик мусора.


На ассемблере.

[crazy horse]

Если вам нужны интерфейсы, то сингелтон вам не нужен.

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

[ds.Dante]

crazy horse, типичный юзкейc, имхо, другой: интерфейс связи с сервером реализован обычным HTTP и тестовой заглушкой. В конструктор клиента в рабочем коде передаём первый, в большинстве юнит-тестов - второй.

[crazy horse]

Сообщение от ds.Dante

crazy horse, типичный юзкейc, имхо, другой: интерфейс связи с сервером реализован обычным HTTP и тестовой заглушкой. В конструктор клиента в рабочем коде передаём первый, в большинстве юнит-тестов - второй.

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

[pu4koff]

Сообщение от Пепел Феникса

Антипаттерном является злоупотребление синглетонами.

антипаттерном является отношение к паттернам, как к серебряным пулям. Паттерны - примеры и не более того.