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

[Alexandr]

У нас тоже случай был...
...
С тех пор у меня на синглтоны аллергия.

У меня тоже случай был. Один if и for использовал. Код - говно. С тех пор стойкая на них аллергия

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

Очевидно, что тип сиглтона должен быть параметром шаблона

[АццкоМото]

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

Когда я спросил, каков по-вашему вред от синглтона, какой ответ я получил? Гоголь в помощь. Ну вот и вам Николай Василич поможет

[АццкоМото]

.....Я-то в курсе и не буду делать new вместо getInstance()......

лучше таки делать правильно, потому если "упрощать", то можно сказать, что даже getInstance() лишний, завел один глобальный объект и не паришься.

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

[Alexandr]

.....Я-то в курсе и не буду делать new вместо getInstance()......

лучше таки делать правильно, потому если "упрощать", то можно сказать, что даже getInstance() лишний, завел один глобальный объект и не паришься.

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

да согласен в общем-то,
просто объяснение про "лишнюю работу" тут как-то не очень, snippet сделал, который, как сейчас модно удаленным (= delete) конструктором создает и все дела.
Другое дело, что можно привести более "сложный" пример, например, можно правильно реализовать оператор =, но потребуется время, а можно ему = delete написать, так вот, если не пишешь библиотеку, а самому он не нужен, =delete ему и дело с концами. Но моя библейское убеждение, что если что-то не работает, то, по возможности, и компилироваться не должно.

[АццкоМото]

просто объяснение про "лишнюю работу" тут как-то не очень

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

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

[Alexandr]

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

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

Так что подводя итог: моя религия: если что-то доставит проблем - compile time error (либо assert), если что-то по логике можно добавить, но сейчас не нужно - нафиг.

[Roy]

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

Когда я спросил, каков по-вашему вред от синглтона, какой ответ я получил? Гоголь в помощь. Ну вот и вам Николай Василич поможет

А вы попробуйте ввести в Гугле "Unit testing with singletons". Все советы сводятся к "Don't use singletons" или "Refactor your code".

[X37WAL!^]

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

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

[X37WAL!^]

Ну как бэ... например data access layer определить через интерфейс и передавать этот интерфейс в конструктор классу, который пишет в базу. Теперь можно тестировать класс без базы.

То есть городить тучу интерфейсов для того что бы тестирование было "легче". Правда оно будет при этом мягко говоря неполным зато отчет по code coverage отлично выглядит. Взводить тестовую базу автоматически и прогонять на ней полноценную работу внутренней логики + слой доступа + логика базы конечно гораздо скучнее.

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

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

End-to-end testing и unit-testing друг друга никак не отменяют, а дополняют.

[X37WAL!^]

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

Когда я спросил, каков по-вашему вред от синглтона, какой ответ я получил? Гоголь в помощь. Ну вот и вам Николай Василич поможет

А вы попробуйте ввести в Гугле "Unit testing with singletons". Все советы сводятся к "Don't use singletons" или "Refactor your code".

Да ответ простой на самом деле. Синглтоны - это global state. Global state используется для передачи информации между объектами, которые в явном виде друг от друга не зависят. А юнит-тест обычно пытается тестировать только один объект в изоляции.

Вот эта неявная зависимость и есть вред, даже если мы вообще никаких юнит-тестов писать не собираемся.
Если я вижу класс TimeProvider c конструктором без параметров и методом GetTime(), то я вправе ожидать, что
(new TimeProvider()).GetTime() таки вернёт мне время.

Однако если внутри GetTime() сидит вызов типа
var timeServiceUrl = SettingsManager.Instance.TimeServiceUrl;

то в реальной жизни с вероятностью 75% я получаю null exception, потому что кто-то когда-то где-то далеко за пределами TimeProvider должен был сделать SettingsManager.Instance.TimeServiceUrl=ReadFromFile(...) чтобы оно работало

[Roy]

Очевидно, что тип сиглтона должен быть параметром шаблона

Чё-то я не очень понял. Можно поподробнее?

[Medium-rare]

Чё-то я не очень понял. Можно поподробнее?

Тут найдёте под Put it all together. Можно нарисовать и проще, но тогда не поймут большой разницы с глобальной переменной. А в случае с тимплейтом она есть, вы никогда явно не создаёте собственно объект. Написали вызов getinstance, и вам неявно предложен объект.

Code: Select all

#include <iostream>

template <typename T> class Singleton
{
public:
    static T& getInstance()
    {
        return instance;
    }
private:
    static T instance;
};

template <typename T>
T Singleton<T>::instance;


int main(int argc, char *argv[])
{
    Singleton<int>::getInstance() = 1;
    Singleton<char*>::getInstance() = "Wow";

    std::cout << std::endl << Singleton<int>::getInstance() << " " << Singleton<char*>::getInstance() << std::endl;
    return 0;
}

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

[Alexandr]

Medium-rare
плохая у вас Синглтона, плохая
правильные парни пишут вот так:

Code: Select all

template<typename T> 
class singleton_t
{
private:
  singleton_t() { }
public:
   static T& getInstance()
   {
     static T obj;
     return obj;
   }
};

[Alexandr]

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

Имхо, вопрос был совсем в другом, насколько я его понял

[Medium-rare]

Точно, конструктор-то надо было в private засунуть. Зато от души. :-p
Ну и юнит-тест слегка адресовал в ответе.

[Medium-rare]

Имхо, вопрос был совсем в другом, насколько я его понял

Дык, если про предшествующий вопрос Роя, то вы-то ответили, параметризовать типом правильной функциональности. То есть, вместо взаимно-вызывающих синглтонов составлять некие синглтоны с новой имплементацией, совмещающей несколько функциональностей. Один чорт, ещё то решение. Замучаешься на все комбинации правильные имплементации - встраиваемые типы создавать.

[Alexandr]

Точно, конструктор-то надо было в private засунуть. Зато от души. :-p
Ну и юнит-тест слегка адресовал в ответе.

мой поинт был не в конструкторе, а в том, что нужно возвращать локальный к функции статический объект, а не статический мембер класса делать

[Boriskin]

Точно, конструктор-то надо было в private засунуть. Зато от души. :-p
Ну и юнит-тест слегка адресовал в ответе.

мой поинт был не в конструкторе, а в том, что нужно возвращать локальный к функции статический объект, а не статический мембер класса делать

А смысл? Ну будет у вас вместо глобальной переменной (ака статический мембер класса), локальная статическая переменная в поле видимости функции. Смысл ради этого мудохаться?

ЗЫ К темплейтам - надо еще фактори прихерачить и будет зоопарк, маленький, но свой.

[АццкоМото]

Расскажите, как вы пишете unit test для кода, который вызывает синглтон?

Когда я спросил, каков по-вашему вред от синглтона, какой ответ я получил? Гоголь в помощь. Ну вот и вам Николай Василич поможет

А вы попробуйте ввести в Гугле "Unit testing with singletons". Все советы сводятся к "Don't use singletons" или "Refactor your code".

Любой кто говорит "используйте" или "не используйте" что-либо вне контекста - идиот. А Гугл - мощнейшая тузла для поиска идиотов

[АццкоМото]

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

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

Капитан Очевидность говорит, что если тесты используются не для тестирования, они должны называться как-то по-другому. Рене Декарт ему вторит: "разъясните человечеству значения слов и вы избавите его от половины заблуждений". И все это задолго до первого контупера.
Тем не менее, "наблюдаемый уголок вселенной" населен идиотами, с пеной у рта пропагандирующими UT без малейшего намека на понимание, что они делают и для чего. Они не способны, например, увидеть, что они улучшают интерфейсы, которые были введены только для того, чтобы "протестировать" свою залепу на искусственных данных. Т.е. работают, как топливо для биореактора.

[X37WAL!^]

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

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

Капитан Очевидность говорит, что если тесты используются не для тестирования, они должны называться как-то по-другому. Рене Декарт ему вторит: "разъясните человечеству значения слов и вы избавите его от половины заблуждений". И все это задолго до первого контупера.
Тем не менее, "наблюдаемый уголок вселенной" населен идиотами, с пеной у рта пропагандирующими UT без малейшего намека на понимание, что они делают и для чего. Они не способны, например, увидеть, что они улучшают интерфейсы, которые были введены только для того, чтобы "протестировать" свою залепу на искусственных данных. Т.е. работают, как топливо для биореактора.

морская свинка тоже ни к морю ни к свиньям отношения не имеет. наверное ее нужно называть по-другому?

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

[АццкоМото]

морская свинка тоже ни к морю ни к свиньям отношения не имеет. наверное ее нужно называть по-другому?

Так и есть. Специалисты называют ее Cavia porcellus. Вы же косите под специалиста, или под ребеночка, которому купили типа хомячка?

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

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

[Alexandr]

Точно, конструктор-то надо было в private засунуть. Зато от души. :-p
Ну и юнит-тест слегка адресовал в ответе.

мой поинт был не в конструкторе, а в том, что нужно возвращать локальный к функции статический объект, а не статический мембер класса делать

А смысл? Ну будет у вас вместо глобальной переменной (ака статический мембер класса), локальная статическая переменная в поле видимости функции. Смысл ради этого мудохаться?

ЗЫ К темплейтам - надо еще фактори прихерачить и будет зоопарк, маленький, но свой.

[Мальчик-Одуванчик]

Очевидно, что тип сиглтона должен быть параметром шаблона

Чё-то я не очень понял. Можно поподробнее?

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

[Мальчик-Одуванчик]

Точно, конструктор-то надо было в private засунуть. Зато от души. :-p
Ну и юнит-тест слегка адресовал в ответе.

мой поинт был не в конструкторе, а в том, что нужно возвращать локальный к функции статический объект, а не статический мембер класса делать

А смысл? Ну будет у вас вместо глобальной переменной (ака статический мембер класса), локальная статическая переменная в поле видимости функции. Смысл ради этого мудохаться?

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