Помогите с умными указателями

[Igors]

что-то как-то не видно вашей темы.

Так вот же. И еще там пара моих тем - тоже хороших 

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

Никогда не слыхал о таком. Расскажите что же там такого хорошего 

[_Bers]

Так вот же. И еще там пара моих тем - тоже хороших 

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

Никогда не слыхал о таком. Расскажите что же там такого хорошего 

gmock - кроссплатформенный инструмент для нужд тестирования от коорпорации google.

включает в себя gtest: для проведения юнит-тестов.

и собственно gmock: тестирование взаимодействия компонентов,
и их поведенческих особенностей.

https://code.google.com/p/googlemock/

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

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

[Tuxford]

Вы отличаете разницу между юнит тестированием и функциональным тестирование.

да.

Cудя по на писаному вами ниже - вообще не видите разницы.

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

бред.

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

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

если программист написал:

Код:

foo(params);

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

Скажите пожалуйста, вы в курсе что такое легаси код? Если в курсе, то работали?
Вот представьте себе есть проект миллионы строк кода. Ни они программист не в курсе что он делает. Авторы которые писали либо уже давно менеджеры и давно забыли что писали, либо уволились. И тут опс, надо новую фичу добавить или баг пофиксить. Но для начала воспроизвести. Вот задача.
Да, я стыкался с такими тасками. При этом некоторые переменные названы то ли на голландском то ли на фламандском.
Реально такое у меня было.

я предложил вам продемонстрировать
простейшие тесты для класса UpdateDownloadManager.
смысл которых - проиллюстрировать дизайн использования.

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


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

вы не в состоянии ответить на простейшие вопросы.

Пишу простейший кейс.

Код:

void MyTestClass::TestDwlMgrAppy()
{

}

На входе принимается линк на локальный сервак, который грузит xml-ну, парсит ее и сохраняет в сторедж. Как я уже писал, реального стореджа у вас нет. Да и не нужно. Скажем, дорого. По сколько xmlна локальная, структура вам известна. Вопрос состоит в том, что сторедж надо мокнуть. Результат будет приемлемым если данные, которые попали в сторедж будут соответствовать тем которые в xml. Это и сеть результат функции apply. Протестировать надо исключительно бизнес-логику. Структуру данных можете придумать сами. Это не важно.
Что еще не ясно?

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

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

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

и покажите тестами дизайн использования.

Пример использования.

Код:

UpdateDownloadManager mgr; // в случае с синглтоном. 
mgr.apply("http://localhost:9821/config.xml");

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

Я привел достаточно кода. Вам нужно только apply. И оно есть. Остальное можете оставить пустым. Или на ваше усмотрение.

[_Bers]

Скажите пожалуйста, вы в курсе что такое легаси код? Если в курсе, то работали?

да. и это не имеет никакого отношения к тому,
что мы сейчас с вами обсуждаем.

а обсуждаем мы предложенный вами класс.

для которого вы оказались не в состоянии написать кейсы.

Пишу простейший кейс.

Код:

void MyTestClass::TestDwlMgrAppy()
{

}

это у вас такой кейс?
пустой ничего не делающий и ничего не иллюстрирующий тест?

На входе принимается линк на локальный сервак, который грузит xml-ну, парсит ее и сохраняет в сторедж. Как я уже писал, реального стореджа у вас нет. Да и не нужно. Скажем, дорого. По сколько xmlна локальная, структура вам известна. Вопрос состоит в том, что сторедж надо мокнуть. Результат будет приемлемым если данные, которые попали в сторедж будут соответствовать тем которые в xml. Это и сеть результат функции apply. Протестировать надо исключительно бизнес-логику. Структуру данных можете придумать сами. Это не важно.
Что еще не ясно?

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

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

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

проиллюстрируйте работу своего класса.

Пример использования.

Код:

UpdateDownloadManager mgr; // в случае с синглтоном. 
mgr.apply("http://localhost:9821/config.xml");

вот это уже чем то отдаленно начинает напоминать нужное от вас.

теперь оформите это в виде теста, который иллюстрирует кейс.

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

Я привел достаточно кода. Вам нужно только apply. И оно есть. Остальное можете оставить пустым. Или на ваше усмотрение.

нет, не достаточно.

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

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

вот вам простейший пример:

Код:

TEST(tools, xml)
{
    // --- заполняем файл какими то данными
    // фактическое содержимое сейчас не важно
    const XML src = GenerateTestData("config.xml");

    // --- заливаем на локалхост
    // если все в порядке, вернется true
    const auto success = PostData("http://localhost:9821", src)
    ASSERT_EQ(true, success);    

    // --- теперь выкачиваем файлик обратно
    // в случае ошибки будет выброшено исключение

    try{

        const XML dst = DownLoad("http://localhost:9821/config.xml");

        // --- убедимся, что отправленные данные 
        // и полученные совпадают
        EXPECT_EQ(src, dst);    
   }
   catch(const std::exception& e)
   {
        ::testing::AssertionFailure() << e.what();
   }
}

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

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

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

[Tuxford]

Еще раз смотрим код функции apply (случай с синглтоном):

Код:

void UpdateDownloadManager::apply(const std::string& url)
{
  Items dwlItems = Download(url);
  StoragePtr pStorage = Storage::instance();
  Items localItems = pStorage->getLocal();
  Items diff = compareWithLocal(localItems , dwlItems);
  doUpdate(diff);
  pStorage->addNewItems(diff);
}

Эта функция должна загрузить, распарсить и положить в сторедж некие данные.
В результате я хотел видет что-то такое.

Код:

void MyTestClass::TestDwlMgrAppy()
{
  DownladManager mgr;
  mgr.apply(url);

 // Проверить каким то хреном что пошло в сторедж.
}

Теперь рассматриваю случай нормального проектирования.

Код:

UpdateDownloadManager::UpdateDownloadManager(IStoragePtr pStorage) : _pStorage(pStorage)
{}

void UpdateDownloadManager::apply(const std::string& url)
{
  Items dwlItems = Download(url);
  Items localItems = pStorage->getLocal();
  Items diff = compareWithLocal(localItems , dwlItems);
  doUpdate(diff);
  pStorage->addNewItems(diff);
}

И пишем тестик.

Код:

class StorageMock : public IStorage
{
public:
// Методы означенные ключевым словом virtual объявлены в интерфейсе. Остальные только в моке.
  virtual Items getLocal() override { return _someItems; } 
  virtual void addNewItems(Items items) override  { _newItems = items;   }

  Items getNewItems() { return  _newItems; }

private:
  Items _newItems;
};

void MyTestClass::TestDwlMgrAppy()
{
  StorageMock pStorage = std::make_shared<StorageMock>();
  DownladManager mgr(pStorage);
  mgr.apply(url);

  Items newItems = pStorage->getNewItems();
  ASSERT_CHECK(newItems == expectedItems);
}

Вот оно что нужно было. Чтобы не было тролинга, сразу уточню getNewItems() в продакшин-класе не представляется возможен. К тому же 10 раз было проигнорирован тот факт, что физически сторедж недоступен.

Так что учитесь писать правильно код без костылей.

[_Bers]

Так что учитесь писать правильно код без костылей.

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

смотрите какой дизайн у вас в итоге получился:

Код:

  StorageMock pStorage = std::make_shared<StorageMock>();
  DownladManager mgr(pStorage);
  mgr.apply(url);

  Items newItems = pStorage->getNewItems();
  ASSERT_CHECK(newItems == expectedItems);

и чем это отличается от простейшего:

Код:

  Items newItems =  DownladManager::apply(url);
  ASSERT_CHECK(newItems == expectedItems);

ну и нафига здесь вообще нужен какой то сингелтон, и какой то сторедж?

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

[Tuxford]

Так что учитесь писать правильно код без костылей.

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

11й раз повторяю: ФИЗИЧЕСКИ стореджа НЕТ (или занят).  Как предлагаете этот вопрос обойти с помощью синглтона?
 

и чем это отличается от простейшего:

Код:

  Items newItems =  DownladManager::apply(url);
  ASSERT_CHECK(newItems == expectedItems);

ну и нафига здесь вообще нужен какой то сингелтон, и какой то сторедж?

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

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

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

Нужен. См. что я повторил 11й раз. Второе - у стореджа свой респонсибилити. Он занимается исключительно операциями ввода-вывода. В нашем случаем только сохранением. Вопрос отдельного класса не обсуждается в принципе. Он может быть реализован или через интерфейс или через синглтон. Точно так же использовать его должен DownloadManager. Считайте что это некое ограничение. Скажем заказчик так захотел.

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

Этот вопрос не обсуждается. Это вам кажется сложно. В действительности при достаточных знаний ООД и ТДД, это тривиальная задача. которая в данном случае решена правильно. Вообще то там все намного сложнее. Там есть свой даулоадер, который иплементирован точно так же. И апдейтер. Все оттестировано и все работает. В теории все эти сущности и есть синглтоны в контексте приложения. Но сделаны как обычные классы для минимизации зависимостей. Но я вопрос сильно упростил чтобы показать суть проблемы. Другой вопрос что вы пытаетесь откатится эдтак к 2005му году, когда синглтоны шли по полной, а большинство джуниоров и от некоторый процент мидлов, еще замечали проблем мультипоточности, связанности кода и прочие прелести. В то время как сеньоры с тимлидами уже матом ругались на это дело.

[_Bers]

11й раз повторяю: ФИЗИЧЕСКИ стореджа НЕТ (или занят).  Как предлагаете этот вопрос обойти с помощью синглтона?

что значит "физически нет" ?
нахер он тогда нужен?

ваш собственный кейс:

Код:

  StorageMock pStorage = std::make_shared<StorageMock>();
  DownladManager mgr(pStorage);
  mgr.apply(url);

  Items newItems = pStorage->getNewItems();
  ASSERT_CHECK(newItems == expectedItems);

предполагает, что очень даже доступен.

можно периписать этот говнокод так:

Код:

  DownladManager mgr;
  mgr.apply(url);

  const auto& newItems = mgr.getNewItems();
  ASSERT_CHECK(newItems == expectedItems);

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

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

[_Bers]

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

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

вы вообще понимаете,что делаете?

касательно "тяжести структуры".
её в любом случае необходимо создать.

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

[_Bers]

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

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

я понял, что бы ни бум бум TDD

[KrupaKarlo]

1. Bers просил ему рассказать про smart pointers.
2. Он попытался привести пример что он имеет ввиду.

Спрашивается: нахрена ему тут толковать про TDD про легаси код? Ему оно не нужно. Откуда это желание учить других?  
Ответа Bers явно показывают что он не понимает что вы ему говорите. Че биться головой об стену?

[Tuxford]

11й раз повторяю: ФИЗИЧЕСКИ стореджа НЕТ (или занят).  Как предлагаете этот вопрос обойти с помощью синглтона?

что значит "физически нет" ?
нахер он тогда нужен?

Объясняю 12й раз. Внешнее устройство, которое втыкается в ЮСБ. На весь тим одно. Стоит несколько килобаксов. Заказчик не успел еще сделать устройство. Да и до того времени как оно будет нужно, еще пол года жать. Что будем делать?
ваш собственный кейс:

Код:

  StorageMock pStorage = std::make_shared<StorageMock>();
  DownladManager mgr(pStorage);
  mgr.apply(url);

  Items newItems = pStorage->getNewItems();
  ASSERT_CHECK(newItems == expectedItems);

предполагает, что очень даже доступен.

Не предполагает. Прочитайте что такой Mock, Fake, Stub в контексте юнит-тестирования.

можно периписать этот говнокод так:

Код:

  DownladManager mgr;
  mgr.apply(url);

  const auto& newItems = mgr.getNewItems();
  ASSERT_CHECK(newItems == expectedItems);

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

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

Не можно переписать. Тогда придется ждать когда появится физический девайс. А работать надо уже. Если вы не бывали в такой ситуации, значит или пока что ваш уровень джуниор и не выше.
Предназначение стореджа - хранение шифрованных данных. Просто говоря положил что-то и тебя не волнует что оно делает с ним. Пользователь знает что их никто не украдет. Вообще слишком много вопросов. Задача предельно просто, но у вас все не так. Если в все так, то надо уже задуматься.
Проблему в данном случае я описал и сказал, что на синглтонах ее решить невозможно в принципе. Вы пытаетесь как-то выкрутится. Но получается какая-то лажа. В прочем я подобное предполагал. Не думал что все настолько запущено. Проблема в том что синглтон Mock'ать никак не получится. Еще не дошло?

[Tuxford]

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

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

Такое требование кастомера. Еще вопросы будут?

вы вообще понимаете,что делаете?

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

касательно "тяжести структуры".
её в любом случае необходимо создать.

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

Скажем так. Передать по ссылке не получится. Если через указатель, то получаем снова никому ненужное копирование. Так как надо выделить блок и скопировать туда данные. Через одно место. Все это в архитектуре все это было учтено.

Если так подходить как предлагаете, то мы возвратимся к процедурному программированию времен Паскаля. Даже не С.

[Tuxford]

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

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

я понял, что бы ни бум бум TDD

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

[Tuxford]

1. Bers просил ему рассказать про smart pointers.
2. Он попытался привести пример что он имеет ввиду.

Спрашивается: нахрена ему тут толковать про TDD про легаси код? Ему оно не нужно. Откуда это желание учить других?  
Ответа Bers явно показывают что он не понимает что вы ему говорите. Че биться головой об стену?

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