Философия разработки на примере синглтона

[Berlaga]

один хрен, я круче, чем неумехи из ФБ, поэтому - не по пути

Ну конечно же, кто бы сомневался.

Засуньте свой сарказм туда, где ему и полагается быть

Вы настаиваете? ... Ну что ж, подставляйте.

Я сравнивал количество крашей у одного юзера с количеством крашей у тысяч.

Какое интересное сравнение. И у кого же получилось больше?

[Willy Wonka]

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

Вот давайте представим, что мы разрабатываем какой-то софт, и у нас есть нечто, что логично бы сделать синглтоном. Ну и мы привычными движениями пальцефф фигачим класс, а в нем - метод getInstance(), который смотрит, есть ли уже существующий инстанс и возвращает его, если есть, или создает и возвращает. Делов на три копейки.

Но ничего ли мы не забыли? Ах, да! Всенепременно нужно сделать конструктор приватным, чтобы никто не создал объект напрямую. Ну, тут от языка зависит, но во многих - именно так.

И вот тут возникает интересная идиосинкразия. Я уверен, что если проект двигаю только я - это совершенно лишнее. Я-то в курсе и не буду делать new вместо getInstance(). А даже несколько символов типа private Singleton() { /* Cant touch this */ } - это уже лишняя работа и даже тут можно умудриться сделать баг. Но если не дай Г-ди показать потом свой "ленивый" код нии..цца спецу, смешает ведь с дерьмом. И, действительно, для публичного кода приватный конструктор необходим

Если мыслить шире, то подобные решения - делать "как положено" или забить - мы делаем по 100500 раз в день. И я настаиваю, что для проектов, делающихся в одно рыло (или в 2-3 рыла, если все хорошо с взаимопониманием), то забить - правильное решение. Но, подозреваю, 146% народа со мной несогласны.

Ваше мнение, товарищь Маузер?

Две строчки добавить:

#include <boost/noncopyabe.hpp>
: private boost::noncopyable


и делов.

Больше времение потратил на писанину.

[Berlaga]

Вот давайте представим, что мы разрабатываем какой-то софт, и у нас есть нечто, что логично бы сделать синглтоном. Ну и мы привычными движениями пальцефф фигачим класс, а в нем - метод getInstance(), который смотрит, есть ли уже существующий инстанс и возвращает его, если есть, или создает и возвращает. Делов на три копейки.

Но ничего ли мы не забыли? Ах, да! Всенепременно нужно сделать конструктор приватным, чтобы никто не создал объект напрямую. Ну, тут от языка зависит, но во многих - именно так.

Две строчки добавить:

#include <boost/noncopyabe.hpp>
: private boost::noncopyable


и делов.

Больше времение потратил на писанину.

Нонкопибл для синглтона - условие необходимое, но не достаточное.

Вроде как в Бусте было и что-то специально для синглтонов тоже, типа boost::singleton. Давно не заглядывал.

[_newcomer_]

Две строчки добавить:
#include <boost/noncopyabe.hpp>
: private boost::noncopyable
и делов.
Больше времение потратил на писанину.

Нонкопибл для синглтона - условие необходимое, но не достаточное.
Вроде как в Бусте было и что-то специально для синглтонов тоже, типа boost::singleton. Давно не заглядывал.

Понаделают непонятных языков со всякими сложностями, понимаииишь ...
Как надо (если ленивая инициализация не уперлась... она вообще зло... хехе) - я уже писал:

Code: Select all

public enum Singleton {
  INSTANCE;
}

Все!!!
(...ухожу ухожу )

[Roy]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос. Мы тут задолбались их выковыривать из старого кода. Теперь за каждый новый синглтон можно получить люлей от бдительных товарищей .

[_newcomer_]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос.

На шо меняет продвинутая Сиэтлская общественность допотопные синглтоны?
Зависимости инжектите в интерфейсные поля и молитесь чтобы никто реализацию не узнал?

[8K]

за каждый новый синглтон можно получить люлей

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

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

[Сабина]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос.

На шо меняет продвинутая Сиэтлская общественность допотопные синглтоны?
Зависимости инжектите в интерфейсные поля и молитесь чтобы никто реализацию не узнал?

Наверняка вот так
http://programmers.stackexchange.com/qu ... to-clojure

Here's a step-by-step guide to getting from your Java example to some decent Clojure:

recognize that your singleton is just global, mutable state. The singleton may work fine but it's not necessary. So we've moved from Java: singleton -> Java: global, mutable state
refactor your Java example to use local mutable state instead of global mutable state, by passing the map to the methods that modify it. So let's move from Java: global, mutable state -> Java: local, mutable state
*now, instead of destructively updating the map every time, find/write a Java library (such as the one the Clojure implementation uses) that does not mutate when adding/removing key/value pairs to/from maps. Remember to return values that have been "updated", otherwise, the changes won't be visible to other code. So we've just moved from Java: local, mutable state -> Java: local, immutable state
at this point, you have an FP solution, but it's coded in Java. Your initial Clojure solution could end up as a nearly 1:1 translation, but as you learn more Clojure you'll figure out how to take advantage of its strengths and improve and shorten the code. Plus, you might learn some cool patterns for dealing with "mutable" state in a purely functional way. So it's up to you to make the leap from Java: local, immutable state -> Clojure: local, immutable state

[Песня]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос.

На шо меняет продвинутая Сиэтлская общественность допотопные синглтоны?
Зависимости инжектите в интерфейсные поля и молитесь чтобы никто реализацию не узнал?

Именно так. Только Depedency Injection, только хардкор

[АццкоМото]

Больше времение потратил на писанину.

Действительно немного обидно. Всю клавиатуру истоптал, а до нечитателей так и не дошло, что синглтон - просто пример. Первое, что в голову пришло. Речь про общий подход: каждый раз, когда мы делаем мелкие приседания "чтобы правильно" и чтобы потом чего страшного не случилось - мы фактически тратим время на то, что не имеет отношения к поставленной задаче. Мы считаем, что это "окупится потом". Будто с нашим кодом будут работать поколения. Вот апчом речь. А вовсе не об #include <boost/ещеоднаневедомахрень.хрр>

[АццкоМото]

Как надо (если ленивая инициализация не уперлась... она вообще зло... хехе) - я уже писал:

Code: Select all

public enum Singleton {
  INSTANCE;
}

Все!!!
(...ухожу ухожу )

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

[АццкоМото]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос.

На шо меняет продвинутая Сиэтлская общественность допотопные синглтоны?
Зависимости инжектите в интерфейсные поля и молитесь чтобы никто реализацию не узнал?

Именно так. Только Depedency Injection, только хардкор

Вот кстати DI - отличный пример. Его сейчас лепят к месту и не к месту. Просто типа модно. Сейчас все так делают. Блдж... Оно реально нужно благо если в 1% из всех тех мест, куда его прилепили

[8K]

Мы считаем, что это "окупится потом".

В том-то и дело, что окупается. По крайней мере, в моем конкретном случае. Если на одном месте не сидеть больше года-полутора, то да, смысла нет, кроме морального удовлетворения от того, что не срешь в карман соседу.

[АццкоМото]

Мы считаем, что это "окупится потом".

В том-то и дело, что окупается. По крайней мере, в моем конкретном случае. Если на одном месте не сидеть больше года-полутора, то да, смысла нет, кроме морального удовлетворения от того, что не срешь в карман соседу.

Да нет же
Может окупаться, а может и нет. Нужно тщательно взвешивать все аргменты
А то вон сидят какие-нибудь "гении", клепают WebOS, рассуждают об окупаемости хорошего кода. А потом - пинок под зад, коробку в зубы и дверь вон там. Окупилось, блин

[olis]

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

Вот давайте представим, что мы разрабатываем какой-то софт, и у нас есть нечто, что логично бы сделать синглтоном. Ну и мы привычными движениями пальцефф фигачим класс, а в нем - метод getInstance(), который смотрит, есть ли уже существующий инстанс и возвращает его, если есть, или создает и возвращает. Делов на три копейки.

Но ничего ли мы не забыли? Ах, да! Всенепременно нужно сделать конструктор приватным, чтобы никто не создал объект напрямую. Ну, тут от языка зависит, но во многих - именно так.

И вот тут возникает интересная идиосинкразия. Я уверен, что если проект двигаю только я - это совершенно лишнее. Я-то в курсе и не буду делать new вместо getInstance(). А даже несколько символов типа private Singleton() { /* Cant touch this */ } - это уже лишняя работа и даже тут можно умудриться сделать баг. Но если не дай Г-ди показать потом свой "ленивый" код нии..цца спецу, смешает ведь с дерьмом. И, действительно, для публичного кода приватный конструктор необходим

Если мыслить шире, то подобные решения - делать "как положено" или забить - мы делаем по 100500 раз в день. И я настаиваю, что для проектов, делающихся в одно рыло (или в 2-3 рыла, если все хорошо с взаимопониманием), то забить - правильное решение. Но, подозреваю, 146% народа со мной несогласны.

Ваше мнение, товарищь Маузер?

Я бы забил.

PS Хорошо что в С никаких конструкторов, тупо

int get_a()
{
static int a = 0;
if (a == 0) a = 1;
return a;
}

[Roy]

А шо - кто то ещё использует синглтоны? Это же ужос-ужос.

На шо меняет продвинутая Сиэтлская общественность допотопные синглтоны?
Зависимости инжектите в интерфейсные поля и молитесь чтобы никто реализацию не узнал?

Именно так. Только Depedency Injection, только хардкор

Вот кстати DI - отличный пример. Его сейчас лепят к месту и не к месту. Просто типа модно. Сейчас все так делают. Блдж... Оно реально нужно благо если в 1% из всех тех мест, куда его прилепили

Всяко лучше чем singleton. А применять надо с умом - понятное дело. Но мы используем гораздо чаще, чем 1%. Иначе тестировать не получается по-нормальному. Может у вас специфика другая или вы что-то другое подразумеваете под DI.

[Berlaga]

PS Хорошо что в С никаких конструкторов, тупо

int get_a()
{
static int a = 0;
if (a == 0) a = 1;
return a;
}

Можно проще.
int get_a()
{
return 1;
}


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

[olis]

PS Хорошо что в С никаких конструкторов, тупо

int get_a()
{
static int a = 0;
if (a == 0) a = 1;
return a;
}

Можно проще.
int get_a()
{
return 1;
}


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

Какая разница, можно указатель вернуть. Не суть.
А вместо a=1 может быть что нибудь более полезное, присваивание случайного числа, например.

[M. Ridcully]

// i_dont_need_your_stupid_singletons.h
extern int a;

// i_dont_need_your_stupid_singletons.c
int a = 42;

[АццкоМото]

Всяко лучше чем singleton. А применять надо с умом - понятное дело. Но мы используем гораздо чаще, чем 1%. Иначе тестировать не получается по-нормальному. Может у вас специфика другая или вы что-то другое подразумеваете под DI.

От синглтона вреда никакого, в отличие от DI
И именно юнит тесты - ценность которых переоценена на порядки - основной источник проблем с DI. Задумайтесь над очевидными фактами
1. Ошибки происходят от сложности
2. Чем больше ошибок делается, тем больше их "ускользает" от тестирования
3. Цель тестирования - минимизация ускользнувших ошибок
4. Юнит-тесты DI добавляют сложности

Складывая 2+2 получаем, что DI вреден для тестирования. Упс

(Еси чо, я не против дозированного использования DI in UT, но только дозированное, а не повсеместное, как того требуют программистские представления о крутизне)

[oshibka_residenta]

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

Не нужно поколений. Десяток среднего пошиба девелоперов наступят на все грабли, на которые толко можно наступить и еще немного. Ну уж не говоря о том, что код иногда живет удивительно долго.
А если пишешь один и тем более не Production, a какой-нибудь прототип, то можно не то что все сделать Public, а еще и переменные назвать
t1, t2, t3, а не thisNameShallSelfExplainWholeFckingAlgorithm

[oshibka_residenta]

Я бы забил.

PS Хорошо что в С никаких конструкторов, тупо

int get_a()
{
static int a = 0;
if (a == 0) a = 1;
return a;
}

Google: thread-safe

[olis]

Я бы забил.

PS Хорошо что в С никаких конструкторов, тупо

int get_a()
{
static int a = 0;
if (a == 0) a = 1;
return a;
}

Google: thread-safe

Зачем?

[АццкоМото]

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

Не нужно поколений. Десяток среднего пошиба девелоперов наступят на все грабли, на которые толко можно наступить и еще немного. Ну уж не говоря о том, что код иногда живет удивительно долго.
А если пишешь один и тем более не Production, a какой-нибудь прототип, то можно не то что все сделать Public, а еще и переменные назвать
t1, t2, t3, а не thisNameShallSelfExplainWholeFckingAlgorithm

Ну я же в заглавном посте написал: для проектов, делающихся в одно рыло (или в 2-3 рыла, если все хорошо с взаимопониманием), то забить - правильное решение
При десятке рыл уже нужна дисциплина

[Pantigalt]

Если мыслить шире, то подобные решения - делать "как положено" или забить - мы делаем по 100500 раз в день. И я настаиваю, что для проектов, делающихся в одно рыло (или в 2-3 рыла, если все хорошо с взаимопониманием), то забить - правильное решение. Но, подозреваю, 146% народа со мной несогласны.

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