Используете ли вы глобальные переменные

@rikimaru2013 · Регистрация: 30.11.2013

Студворк — интернет-сервис помощи студентам

Добрый вечер,

используете ли вы у себя в коде глобальные переменные между единицами трансляции и/или в конкретной?

Моё мнение: нужна общая переменная делаем сингтон (+контроль, +гибкость, +ООП, +lazy inizilization).

P.S. Смотрю проекты гитхаба С++ - используют люди глобальные с extern, блэк-джеком и пушками. Смотрю в чём плюсы такого приёма - не вижу. Человеческая лень?

Знаю пример, когда на cpp заводят

C++
1
const char*const g_INCORRECT_NAME = "Default";

но других "удачный" примеров использования - не помню/не знаю.

@Nosey · 18.07.2016, 13:07

Не по теме:

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

я не верю, я знаю.
и мне не понятна ваша реакция.
что вас смущает?

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

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

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

Я правильно понял, что мы будем превращать сингелтон в бога богов? И никогда не остановимся?

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

чем нибудь другим займемся?

А зарплату за нас тоже кто-то другой получать будет?

Там между строк

у меня написано что задачи еще остались, но наращивать мы не можем, потому что в одном месте правишь - в 100 ломается, классический такой багофикс процесс )))) И что нам делать начинать?

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

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

Я не говорил что значит <someObject>

Если вы так боитесь наследования от класса содержащего ваши две функции subscribe & send, то не наследуйтесь, а агрегируйте и делегируйте.

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

посмотрите в сторону mfc, qt, boost::signals2, и многие другие.
никто из них не требует от классов бизнес-логики
наследоваться и реализовывать какие то дураццкие интерфейсы.
и для посылки очередного типа сообщения,
они не требуют того, что бы это сообщение обязательно являлось
классом унаследованным от интерфейса сообщений.

Смотрел, и да, но у них нет глобальной шины сообщений которую предлагаете ввести вы.

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

годный дизайн выглядит так:

Ненене

смотрите код :

C++
1
2
3
4
5
6
7
8
9
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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
event_system super_global_bus_event_system;//!!!!!!
using HZ_TYPE = void*;
 
// мы пишем на С++, а не на яве или шарпе, так что мы должны хранить хэндлер обработчика.
subscribeHandler subscribe(HZ_TYPE slot)
{
    return super_global_bus_event_system.subscribe(slot);
}
HZ_TYPE sendMessage(HZ_TYPE msg)
{
    return super_global_bus_event_system.sendMessage(msg);
}
 
// можно отправлять сообщения абсолютно любых типов
struct login //<--- и для этого, им не нужно
{              // ни от чего специально наследоваться
 
    std::string login, password
};
 
// подписчик
struct worker //<--- ему не нужно ни от кого наследоваться
{
  // здесь его чистая логика
  // класс решает свою конкретную задачу
  // и не содержит ничего
  // что не относится к ней
 
  // этот метод запускается для обработки поступающего сообщения
  void readMessage( const login& );
};
 
 
 
int main()
{
    // может существовать где угодно
    worker wrk;
 
    // подписываем объект на получение сообщений
    subscribe(wrk);
 
    // если нужно, то можно указать метод получения сообщения
    // subscribe(wrk, &worker::readMessage);
 
    // сообщением может быть объект любого типа
    // включая примитивы
    // при этом, не нужно ни от каких интерфейсов его наследовать
    login msg("login", "password");
 
    // отправлять сообщение можно из любой точки программы
    // в любое время
    sendMessage(msg);
 
    // можно так: отправка набора сообщений:
    sendMessage(10, true, "привет");
 
    // такое сообщение получит тот,
    // кто подписан на обработку сразу целого набора сообщений
    // у кого есть метод наподобие
    // readMessage(int, bool, const std::string&)
}
 
//вместо
 
struct Sender
{
    // инкапсуляция конечно неповредит)
    event_system event;
};
 
 
int main()
{
    Sender send;
    worker wrk;
 
    send.event.subscribe(wrk);
 
    login msg("login", "password");
 
    send.event.sendMessage(msg);
    send.event.sendMessage(10, true, "привет");
}

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

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

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

А где-то есть такие реализации которые падают в рантайме при обработке сообщений? )
Скорость vs гибкость, в данном вопросе я выберу гибкость.
Но спрошу на всякий случай, там точно std::functon внутри не стрятан? а-то это такой себе компайлтайм))

@mporro · 18.07.2016, 13:08

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

эта необходимость может быть обусловлена требованиями к механизму

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

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

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

Глобальные имена есть, но моей программе они не нужны!
Я в main создам объект моего приложения и передам в конструктор std::cout. Если потом понадобится, то передам другой объект. Я не связан глобальным состоянием. И нет никакой необходимости использовать строго один какой-то std::cout в моей системе. Да пусть их хоть 10! Моя программа от этого не испортится, потому что в конструкторе захватит один конкретный.

@hoggy · 18.07.2016, 15:31

Не по теме:

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

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

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

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

Я правильно понял, что мы будем превращать сингелтон в бога богов? И никогда не остановимся?

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

допустим изначально был функционал:

C++
1
2
3
// вернет список всех баз данных на сервере
template<class Container>
void getListOfDatabase(Container& dst);

и тут клиенты захотели, и соответственно,
нам дали задачу: сделать функцию, которая вернет список скрытых баз данных
(сигнатуры скрытых баз данных описаны в клиентском конфиге)

и вот мы добавляем функцию:

C++
1
2
3
// вернет список всех баз данных на сервере
template<class Container>
void getListOfHiddenDatabase(Container& dst);

при чем здесь вообще божества?

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

А зарплату за нас тоже кто-то другой получать будет?

а это здесь вообще причем?
нам дали задачу - мы делаем.
дали другую - делаем другую.

я помимо этого админа, ещё много чем занимаюсь.

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

ам между строк у меня написано что задачи еще остались, но наращивать мы не можем, потому что в одном месте правишь - в 100 ломается, классический такой багофикс процесс )))) И что нам делать начинать?

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

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

и кстати, я подсадил на TDD все те конторы,
в которых доводилось работать.

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

Если вы так боитесь наследования от класса содержащего ваши две функции subscribe & send, то не наследуйтесь, а агрегируйте и делегируйте.

нафига????
это теже яйца, только сбоку.

нафига мне чего то там агрегировать,
когда я могу получить тот же результат ничего не агрегируя.

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

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

event_system super_global_bus_event_system;//!!!!!!

это - говнокод, потому что нарушает фундаментальное требование к приличной эвент-систем:
"всегда быть готовой к использованию по первому требованию клиентов".

ваша глобальная переменная не отвечает этому требованию,
поскольку не имеет иммунитета простив static-order-fiasco

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

using HZ_TYPE = void*;

а за такое убивать нужно.
ну или выгонять на сишку под зад метлой.

на языке с++ элементарно реализуются безопасные решения
c проверкой всех типов времени компиляции.

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

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

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

сингелтоны тут вообще не причем.
это - бич паттерна эвент-систем.
неаккуратное использование может запросто привести к спаггети времени выполнения.
это - в тысячу раз хуже goto.

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

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

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

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

А где-то есть такие реализации которые падают в рантайме при обработке сообщений? )

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

хотите создать новое сообщение - создайте класс и наследуетесь от интерфейса.

в итоге, что там за сообщение - это информация времени рантайм.

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

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

Скорость vs гибкость, в данном вопросе я выберу гибкость.

гибкость не страдает.

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

Но спрошу на всякий случай, там точно std::functon внутри не стрятан? а-то это такой себе компайлтайм))

моя модель была создана в рамках с++03.
в те времена std::function ещё не было.

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

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

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

бред какой то.
std::shared_ptr - это конечо же следствие проблем в дизайне.
extern - это конечно же следствие проблем в дизайне.
локальный статик - это конечно же следствие проблем в дизайне.
std::cout - это конечно же следствие проблем в дизайне.

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

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

ну и что?
что в этом плохого, если это облегчает жизнь,
как при разработке,
так и при сопровождении?

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

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

Если я буду вести лог с помощью std::cout, то я буду к нему привязан. И если завтра мне понадобится писать лог в файл, а сообщения продолжать писать в std::cout -- будут проблемы. Или я захочу переиспользовать часть своей системы в другом проекте, а там другое логгирование, что делать? Искать везде std::cout и заменять на другое глобальное имя?

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

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

чем жестче конструкция, тем легче в ней ориентироваться.

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

Я в main создам объект моего приложения и передам в конструктор std::cout. Если потом понадобится, то передам другой объект. Я не связан глобальным состоянием. И нет никакой необходимости использовать строго один какой-то std::cout в моей системе. Да пусть их хоть 10! Моя программа от этого не испортится, потому что в конструкторе захватит один конкретный.

и все ваши статические объекты лососнут тунца.

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

@mporro · 18.07.2016, 15:55

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

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

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

@Nosey · 18.07.2016, 16:51

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

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

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

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

допустим изначально был функционал:
// вернет список всех баз данных на сервере
template<class Container>
void getListOfDatabase(Container& dst);
и тут клиенты захотели, и соответственно,
нам дали задачу:

В 10% использований сей функции сделать А.
В других 10% использований функции сделать Б.
........
В последних 10% использований сделать <10 буква алфавита

>.
А у нас была только одна функция?

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

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

а это здесь вообще причем?
нам дали задачу - мы делаем.
дали другую - делаем другую.
я помимо этого админа, ещё много чем занимаюсь.

Не по теме:

Пошутили и хватит.

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

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

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

И где мы тут упадём? reinterpret_cast чур не предлагать

Не по теме:

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

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

Юнит-тесты нифига нам не помогут разобрать наш говнокод.
Они лишь помогут, да и скорее всего завтра.
Т.е. вместо того чтобы поправить пару ООП абстракций, мы будем достаточно долго разгребать гору процедурного кода.

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

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

Гы

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

static-order-fiasco

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Это тип вместо всего остального, я не предлагал использовать void ), у него же название говорящее:)
using HZ_TYPE = void*;
 
// Ну хорошо, кривовато конечно, но пожалуйста.
event_system& super_global_bus_event_system()/////
{
  static event_system ret;
  return ret;
}
 
// не говоря о том что мы пишем на С++, а не на яве или шарпе, так что мы должны хранить хэндлер обработчика.
slotHandler subscribe(HZ_TYPE slot)
{
    return super_global_bus_event_system().subscribe(slot);
}
HZ_TYPE sendMessage(HZ_TYPE msg)
{
    return super_global_bus_event_system().sendMessage(msg);
}

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

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

Вот, тут я не согласен. Конечно, хорошо бы сказать численные пределы своего несолгасия, но пока я устал)
Скажу лишь что сопровождать хорошую абстракцию очень легко. И написать её - проверяйте свою скорость http://klavogonki.ru/ и потом осознайте, что лишнее в абстракции пишется за 5 минут времени, а-то, что вы пишите это не за 5 минут, а за 35, так это потому, что вы не привыкли так писать, т.е. вы не знаете что писать. (hoggy, это не лично вам, я не хочу это обсуждать

, это ИМХО для интересующихся)

@hoggy · 18.07.2016, 17:17

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

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

вы что-то путаете.
мои ученики предусмотрели возможность предкомпилированных запросов.
и пул соединений.

так они решили проблему экранирования текста запроса,
и проблему балансировки серверов дата-центра.

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

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

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

и это касается не только сингелтонов,
а вообще любых наших механизмов.

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

В 10% использований сей функции сделать А.
В других 10% использований функции сделать Б.
........
В последних 10% использований сделать <10 буква алфавита >.
А у нас была только одна функция?
Мы практически никогда не можем верно оценить будущее расширение. Я не готов рисковать, точнее я устал рисковать и больше не хочу.

не распарсил этот поток сознания.

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

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

мне не понятно откуда вы все это взяли.
в общем, не распарсил.

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

И где мы тут упадём?

это же классика!

посмотрите например, как устроенна эвент систем в бибилотеке CEGUI

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

static_cast - может вернуть неконсистентную кашу, если вы ошибетесь с наследником.
dynamic_cast - тормозной, к тому же ну допустим он вернул ноль,
и что вы будите делать?

самое хреновое, это то, что любые подобные сбои будут
известны лишь времени выполнения.

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

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

Юнит-тесты нифига нам не помогут разобрать наш говнокод.
Они лишь помогут, да и скорее всего завтра.
Т.е. вместо того чтобы поправить пару ООП абстракций, мы будем достаточно долго разгребать гору процедурного кода.

этот бред противоречит самой идее TDD.

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

// Ну хорошо, кривовато конечно, но пожалуйста.
event_system& super_global_bus_event_system()/////
{
* static event_system ret;
* return ret;
}

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

@mporro · 18.07.2016, 17:35

Не по теме:

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

так они решили проблему экранирования текста запроса,
и проблему балансировки серверов дата-центра.

Как они могли решить эти проблемы, если их не было, а Вы научили их ничего не делать заранее?
Что-то у Вас показания не сходятся...

@hoggy · 18.07.2016, 17:39

Не по теме:

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

Как они могли решить эти проблемы, если их не было, а Вы научили их ничего не делать заранее?
Что-то у Вас показания не сходятся...

откуда вы взяли свое "если"?
типа проблемы экранирования никогда не было,
и тут она вдрг бац! и внезапно есть?

да, пожалуй, тут что-то явно не сходиццо.

для разработки сетевых движков существуют паттерны,
если вы вдруг не в курсе.

@ct0r · 18.07.2016, 18:19

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

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

То есть DI в конструктор - это плохо, а всякие левые флажки - это хорошо?

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

вот есть сишная функция: create_directory
и как вы изолируете её от крестового кода?

Где тут синглтон?

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

вы реально думаете, что оборачивая изолируя сишные либы в рамках ооп-архитектуры,
каким то образом избавляетесь от сингелтона?

Ты реально думаешь, что любая сишная либа использует глобальные состояния? И подразумевает, что ее можно использовать лишь в одном экземпляре?

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

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

Все так, но вопрос не в этом, а в том, есть ли вообще эта необходимость.

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

без многопоточки вполне можно жить.

Если можно обойтись без нее, то без нее и обходятся. В чем вопрос?

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

или "если мы обернули сингелтон в наш класс, то он уже или не совсем сингелтон, или не совсем зло".

Еще раз: сишная либа - это далеко не всегда какой-то там синглтон. И да, дополнительный уровень абстракции не дает использовать его отовсюду.

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

нет, вы не поняли.

Да, я не понял. Я не понял, почему логгер - это синглтон? Он что, только один на все-про-все может существовать? Очевидно, что нет. У каждой подсистемы может быть свой логгер, со своими настройками и тд. Это понятно изначально. Но синглтон каким-то образом умудрился искусить тебя. Магия, не иначе.
Приведу еще выдержку из книги "Game programming patterns":

The word “and” in the Gang of Four’s description of Singleton is a bit strange. Is this pattern a solution to one problem or two? What if we have only one of those? Ensuring a single instance is useful, but who says we want to let everyone poke at it? Likewise, global access is convenient, but that’s true even for a class that allows multiple instances.

The latter of those two problems, convenient access, is almost always why we turn to the Singleton pattern. Consider a logging class. Most modules in the game can benefit from being able to log diagnostic information. However, passing an instance of our Log class to every single function clutters the method signature and distracts from the intent of the code.

The obvious fix is to make our Log class a singleton. Every function can then go straight to the class itself to get an instance. But when we do that, we inadvertently acquire a strange little restriction. All of a sudden, we can no longer create more than one logger.

At first, this isn’t a problem. We’re writing only a single log file, so we only need one instance anyway. Then, deep in the development cycle, we run into trouble. Everyone on the team has been using the logger for their own diagnostics, and the log file has become a massive dumping ground. Programmers have to wade through pages of text just to find the one entry they care about.

We’d like to fix this by partitioning the logging into multiple files. To do this, we’ll have separate loggers for different game domains: online, UI, audio, gameplay. But we can’t. Not only does our Log class no longer allow us to create multiple instances, that design limitation is entrenched in every single call site that uses it:

Log::instance().write("Some event.");
In order to make our Log class support multiple instantiation (like it originally did), we’ll have to fix both the class itself and every line of code that mentions it. Our convenient access isn’t so convenient anymore.

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

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

Ты слишком все упрощаешь. Типа "это сейчас нам не нужно, сделаем сейчас как хотим, а там видно будет". Точка зрения, ведущая в дальнейшем к большим проблемам.
Каждое решение принимается не так просто.
1) Прикидываем, как система может расширяться
2) Оцениваем вероятность каждого расширения
3) Для каждого возможного решения: для каждого расширения считаем трудозатраты на код сейчас + код расширения, с учетом вероятности; суммируем для всех расширений, получаем грубую оценку в уме для каждого решения.
4) Сравниваем решения, выбираем лучшее.

@Nosey · 18.07.2016, 18:53

Не по теме:

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

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

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

вы что-то путаете.
мои ученики предусмотрели возможность предкомпилированных запросов.
и пул соединений.

Я тоже хочу к вам учиться, я хочу видеть будущее и предусматривать только то, что случится, и ни грамом больше и с расслабленными булками фигачить статики

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

и что вы будите делать?

Использовать static_cast адекватность и мозг, в общем работать))
Но да, компайлтайм проверка выглядит вкуснее.

Не по теме:

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

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

Если так рассуждать, то я готов сделать заявление о смысле кода и всего такого : "любая архитектура станет тыквой". И я это точно знаю, поскольку прекрасно знаю какие у любой:) архитектуры возможности и ограничения

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

не распарсил этот поток сознания.

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

в общем, не распарсил.

Вот ответьте на вопросы с чувством и расстановкой:
1) Какими инструментами вы будете расширять сингелтон? Добавление еще функций-методов - раз. Какими ещё инструментами?
2) Если новая функция-метод потребует изменение внутреннего представления состояния, вы будете его менять? Или дублировать? Или возвращать копию/"<data>_view"?
3) Сколько новых функций(или другие количественные характеристики приведите) вы готовы поддерживать? Где заканчивается сингелтон и приходит говнокод?
Третий вопрос требует какого-нить контекста, пусть это будет обсуждаемый выше конфиг "connection/user/pass" и функции учитываем достаточно серьезные, аля вернуть сгруппированное древо, и раз это модель, то можно в неё запихать например фильтры.

@hoggy · 18.07.2016, 19:33

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

Я тоже хочу к вам учиться, я хочу видеть будущее и предусматривать только то, что случится, и ни грамом больше и с расслабленными булками фигачить статики

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

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

1) Какими инструментами вы будете расширять сингелтон? Добавление еще функций-методов - раз. Какими ещё инструментами?

добавим функций-членов, если понадобится.

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

Если новая функция-метод потребует изменение внутреннего представления состояния, вы будете его менять?

разумеется.
ведь у меня не будет выбора.

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

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

Сколько новых функций(или другие количественные характеристики приведите) вы готовы поддерживать?

сколько нужно, столько и буду.
что за вопрос вообще?

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

Где заканчивается сингелтон и приходит говнокод?

там, где начинается спаггети времени выполнения.
выше я ужке писал, что это в тысячу раз хуже, чем goto.

например:

A связывается с Б
Б связывается с Ц
Ц - убивает A

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

а концы потом искать... по всей этой петле лазить
вникать во все уровни иерархии класов.
шляпа в общем.

здесь на самом деле полная аналогия с эвент-систем.
событийные модели так же жестоко страдают от подобного пинпонга.
но если систему сообщений можно исскуственно ограничить
(например, обязать всех подписчиков быть std::shared_ptr)
то с паттерном "сингелтон" все гораздо печальнее.

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

а иначе - запрещайте паттерн.

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

в реалиях нашего мира, c его 8ми ядерными процессорами,
мы зачастую имеем дело с многопоточными приложениями.

здесь классическая реализация сингелтона очень уязвима.
мы конечно можем повтыкать в него критические секции.
но адепты многопоточки лишь криво усмехнуццо.

представьте себе: мы из разных потоков пишем в std::cout
что бы данные не перемешивались, нужно ставить синхронизацию.
но если мы это сделаем - мы создадим чудовищную конкуренцию за ресурс,
и сведем на нет весь профит от многопоточки.

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

то есть, я хочу сказать, это не проблемма паттерна.
это проблема прямых рук.

Добавлено через 14 минут

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

То есть DI в конструктор - это плохо, а всякие левые флажки - это хорошо?

да.

кстати, флажков - нет.
(в реализации)

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

Где тут синглтон?

твою ж заногу! ну сколько можно уже?

найдите 10 принципиальных отличий:

C++
1
2
3
namespace fs {
    void create_directory(const char*);
}

и

C++
1
2
3
4
5
6
7
struct fs
{
    static create_directory(const char* name){ get(),cd(name); }  
private:
    static fs& get() { fs f; return f; } 
    void cd(const char*);
};

в обоих случаях использование:

C++
1
fs::create_directory("trololo");

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

Ты реально думаешь, что любая сишная либа использует глобальные состояния? И подразумевает, что ее можно использовать лишь в одном экземпляре?

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

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

а в том, есть ли вообще эта необходимость.

выше я описал примеры.

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

Еще раз: сишная либа - это далеко не всегда какой-то там синглтон.

всегда.

см природу чингелтона и сишного модуля.

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

Да, я не понял. Я не понял, почему логгер - это синглтон?

это просто и удобно.

выдержку не читал.

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

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

я не предлагал передергивать.
я лишь утверждаю, что гибкость ради гибкости не нужна.

алгоритм оценок рисков у меня схож с вашим по описанию.

@mporro · 18.07.2016, 20:10

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

найдите 10 принципиальных отличий:

А при чём тут синглетон-то? В GoF прямым текстом написано, что синглетон -- это не набор статических функций, а обычный класс, реализующий нужный интерфейс. Только экземпляры его могут существовать в единственном числе. Своего рода фабричный метод, который настроен так, чтобы всегда возвращать одно и тоже.
Вы нам предъявляете какое-то статической чудо и обзываете его синглетоном.

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

да - сишный модуль всегда в ед. экземпляре

Что это вообще значит?
Каждый модуль имеет свою функцию инициализации, которая возвращает указатель на выделенный энвайронмент/неймспейс/окружение, с которым и работает программа-клиент. То есть, по сути, любой сишный модуль -- это набор "методов", а каждое окружение -- отдельный объект, который, па скудности средств Си, приходится передавать в каждый вызов руками. Но никаких синглетонов.
Взять хотя бы работу с файловыми дескрипторами. Я могу их создать столько, сколько мне нужно, как наплодить объектов-потоков...

@ct0r · 18.07.2016, 20:33

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

да.

А по-моему нет. Флажков может быть куча.

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

кстати, флажков - нет.
(в реализации)

А что есть? Как мне вырубать в рантайме в нужных местах ненужную функциональность синглтона?

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

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

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

найдите 10 принципиальных отличий:

То есть дошли до того, что любая свободная функция - синглтон?

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

это просто и удобно.

А еще просто и удобно мешать логику с интерфейсом, все писать в одном файле, не думать об именах и тд и тп. Правда, до поры до времени.

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

выдержку не читал.

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

выше я описал примеры.

Я тоже не вчитывался.

@hoggy · 18.07.2016, 21:06

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

А что есть? Как мне вырубать в рантайме в нужных местах ненужную функциональность синглтона?

см паттерн "policy"

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

То есть дошли до того, что любая свободная функция - синглтон?

не функция, а модуль.

пачка сишных функций (модуль/библиотека)
ничем по своей природе не отличается от сингелтона.

надеюсь вам не нужно рисовать сишное апи,
и аналог в виде сингелтона?

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

А еще просто и удобно мешать логику с интерфейсом, все писать в одном файле, не думать об именах и тд и тп. Правда, до поры до времени.

бред.

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

Я тоже не вчитывался.

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

Добавлено через 9 минут

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

А при чём тут синглетон-то?

вы нашли 10ть отличий?

пока вы их не найдете
(а вы их не найдете, потому что их нет)

вы не поймете.

@ct0r · 19.07.2016, 22:38

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

см паттерн "policy"

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

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

пачка сишных функций (модуль/библиотека)
ничем по своей природе не отличается от сингелтона.

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

hoggy, а есть причина, по которой лучше выбрать синглтон, а не например service locator?

@hoggy · 19.07.2016, 23:26

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

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

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

то есть, этот момент ортогонален паттерну "сингелтон".

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

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

нет. любая сишная функция не является сингелтоном,
и не имеет к паттерну никакого отношения.

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

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

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

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

есть причина, по которой лучше выбрать синглтон, а не например service locator?

очевидно, когда нужен именно сингелтон,
а не сервис-локатор, который вообще сингелтонам ортогонален.

ничего не мешает реализовать сервис-локатор,
как сингелтон, например

@ct0r · 20.07.2016, 00:27

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

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

Зачем мне править вообще какой-то код в случае того же DI? Или service locator? Я могу все спокойно сделать в своем, что хорошо - open/closed принцип в действии.

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

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

Так, стопэ. Ну вот есть у нас функции, мы ее засовываем в класс, из класса делаем синглтон. Но смысл? Это не use-case синглтона все равно. Поэтому сравнение мне не кажется уместным.

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

очевидно, когда нужен именно сингелтон,
а не сервис-локатор, который вообще сингелтонам ортогонален.

Так если ортогонален, то тогда ведь легко привести пример, когда я не смогу использовать локатор вместо синглтона? Можно коротенький, или просто ссылкой на пост, если уже в этой теме писал.

@hoggy · 20.07.2016, 00:45

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

Зачем мне править вообще какой-то код в случае того же DI?

я не телепат.

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

Или service locator? Я могу все спокойно сделать в своем, что хорошо - open/closed принцип в действии.

да. можете.
для этого вам придется это сделать.
код сам себя не напишет.

если вам это понадобилось - вам придется написать интерфейсы,
реализации, и тп.

при этом не важно, чем является ваш сервис-локатор:
сингелтоном, или обычным классом.

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

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

Ну вот есть у нас функции, мы ее засовываем в класс, из класса делаем синглтон. Но смысл?

вы так ничерта и не поняли.

в этой теме я уже приводил этот пример:

C++
1
2
3
4
5
6
7
// сишный модуль
namespace sample
{
    work(); 
}//namespace sample
 
//использование: sample::work();

C++
1
2
3
4
5
6
7
8
9
10
// сингелтон
struct sample
{
    static void work(){ get().work_(); }
private:
    static sample& get() { static sample obj; return obj; }
    void work_();
}//namespace sample
 
//использование: sample::work();

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

Но смысл? Это не use-case синглтона все равно. Поэтому сравнение мне не кажется уместным.

смысл в том, что бы до ваших мазгов наконец дошло:
между сингелтоном и сишным модулем
вообще нет никакой разницы в техническом смысле.

с технической точки зрения у них одна и та же природа,
одни и те же недостатки,
и даже один и тот же дизайн использования.

ругать синглетон - все равно что ругать сишный модуль.

но почему то никому не приходит в голову ругать сишные модули.
а само сравнение полагают неуместным.

наверное, потому что не доходит до мозгов,
что разницы между ними на самом деле нет.

@_Ivana · 20.07.2016, 01:34

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

@mporro · 20.07.2016, 01:42

Да, делать яичницу из огурцов -- это не моё.

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

однако, любой сингелтон всегда можно представить в виде пачки сишных функций

Нет, совсем повторить синглетон только на "сишных функциях", то есть везде использовать одни и те же глобальные имена, не получится. Синглетон может реализовывать интерфейс и с глобальным именем связана только фабрика. Я вполне могу написать:

Code
1
2
SomeClass some_obj(
    SomeSingleton::get_instance());

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

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

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

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

Новые блоги и статьи Все статьи Все блоги /
Знаете, от чего появляется стресс? kumehtar 15.07.2026 Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот. Ларри Уингет	Нас бьют, а мы крепчаем? Какая чушь! kumehtar 15.07.2026 Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .	сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .
Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .	сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	20.07.2016, 01:34
	Эмм... В тему топика. Когда ~~мне нужно было~~ я по-другому не придумал как реализовать пачку функций под одной крышей в джаве, я слепил класс с пачкой статических методов (и статических полей туда же, но об этом пока не будем) и вообще не создавал его экземпляра - ну не понял я зачем нужен его экземпляр. И никакого синглтона, лези инициализации, и т.п. На С++, полагаю, можно сделать то же самое. И я понимаю, что это по сути ничем не отличается от сишного модуля. Остался вопрос - зачем нужен экземпляр (ака синглтон)? Для сериализации и передачи вдаль? Или для чего-либо еще? Не бейте - ООП не знаю, банду паттернов не читал. 0