- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
/// generic Singleton<T> (потокобезопасный с использованием generic-класса и с отложенной инициализацией)
/// <typeparam name="T">Singleton class</typeparam>
public class Singleton<T> where T : class
{
/// Защищённый конструктор необходим для того, чтобы предотвратить создание экземпляра класса Singleton.
/// Он будет вызван из закрытого конструктора наследственного класса.
protected Singleton() { }
/// Фабрика используется для отложенной инициализации экземпляра класса
private sealed class SingletonCreator<S> where S : class
{
//Используется Reflection для создания экземпляра класса без публичного конструктора
private static readonly S instance = (S) typeof(S).GetConstructor(
BindingFlags.Instance | BindingFlags.NonPublic,
null,
new Type[0],
new ParameterModifier[0]).Invoke(null);
public static S CreatorInstance
{
get { return instance; }
}
}
public static T Instance
{
get { return SingletonCreator<T>.CreatorInstance; }
}
}
/// Использование Singleton
public class TestClass : Singleton<TestClass>
{
/// Вызовет защищенный конструктор класса Singleton
private TestClass() { }
public string TestProc()
{
return "Hello World";
}
}
Код из Википедии. Создание синглтона на шарпике с излишествами и извращениями
В самом деле, кому нужна инкапсуляция, нам же нужен синглтон
P.S может я чего не понимаю.
Follow us!
Так например
a ?? b = a !=null ? a : b (аля coalesce в sql) или я туплю?
P.S. Этот код не потокобезопасен.
именно
>> Этот код не потокобезопасен
Большенству синглтонов не нужна потокобезопасность, так как, как правило, состояние его не изменяется. В примитивном случае можно залочить типом
Удобный сахарок.
> Большенству синглтонов не нужна потокобезопасность
Большенство синглтонов вообще нинужно.
> состояние его не изменяется
А при чем тут его состояние? Я о потокобезопасности получения инстанса синглтона, а не о его собственной потокобезопасности.
В это смысле я сам больше предпочитаю статичный класс)
> А причем тут его состояние? Я о потокобезопасности получения инстанса синглтона, а не о его собственной потокобезопасности.
Да я уже понял свою ошибку. Но время на редактирование дают чертовски мало
Пример ниже
Или можно так
> В это смысле я сам больше предпочитаю статичный класс)
Не-не-не Девид Блейн. Класс с паблик статик методами на порядок хуже синглтона...
Когда ты, внезапно, понимаешь, что тебе нужно 2 инстанса синглтона, тебе надо переделывать только точки, где получают инстанс синглтона. Работа с его методами и свойствами не меняется.
Когда ты, внезапно, понимаешь, что тебе нужно 2 инстанса класса со статиками - ты в жопе.
P.S. Естественно я не предлагаю переделывать сборники статических методов (не юзающих никакого состояния) и констант в синглтон ;) Я все-таки о объектах с достаточно сложной логикой, где эти статические методы работают со статическим же состоянием.
Некоторые все стараются синглтоном заделать - например класс констант в каком нибудь модуле. Я просто статичный класс пишу
Я вот про какие случаи: чел думает, что его прога будет юзать только один инстанс скриптового движка. Из лени он загоняет этот инстанс в синглтон "шоб и с DI не трахаться и руками ссылку не таскать". Внезапно задание меняется, и ему нужно два-три параллельно работающих инстанса движка...
Я вот писал тестовое задание (все по техам) а потом вдруг оказалось, что у работодателя "особое видение" интерфейса, которое он, почему то, не мог описать. А если учесть, что задание - граф. редактор и View-Controller занимает больше 2/3...)
Заказчик никогда не может описать интерфейс. Да и не должен, если он все время этим не занимается... Ты должен показать ему сляпанный за пару дней набросок, и спросить, устраивает ли это его...
Ну так для того и нужен набросок, чтобы синхронизировать мысли заказчика и мысли разработчика прежде чем начинать писать все по-серьезному ;) Что тебе не понравилось то? :)
Ну да. Просто, когда прототип показываешь, что-то менять - вполне нормально и адекватно. А когда уже все запилено - да, жопа.
private static readonly Lazy<SomeSingleton> _instance = new Lazy<SomeSingleton>(()=> new SomeSingleton(), true);
public static SomeSingleton Instance
{
get {return _instance.Value;}
}
И все заморочки. Не нужна потокобехопасность - просто заменить true на false.
int a = <something>;
bool b = !!a;
Во-вервых, не все знают, что делает a??b (если не ошибаюсь, a!=null?a:b), во-вторых некоторые (вроде меня :) ) только что узнали, что ?? может быть lvalue, а в-третьих, болезнь всех lvalue, отличных от переменных - хрен поймёшь, куда же оно таки присвоилось.
Я поюзал = в его математическом смысле, просто спросив, что a ?? b это тож самое, что и a != null ? a : b...
P.S. Не знаю как в шарпе, но в сишке можно и так: x = (b ? sin : cos)(x)
Проверил сейчас на всякий случай - ведёт себя как rvalue
если хочется аргументы один раз в конце - можно вот так извратится