Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну тогда содержимое файла — не меньшее зло. Оно ж тоже, считай, статически распределяется.
Не путай теплое с мягким.
Одно дело IO в специально отведенных местах другое дело IO везде.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote:
> Более того лично я чем больше думаю тем сильнее склоняюсь к мысли что "функции" типа DateTime.Now, File.Open,... вобще должны быть запрещены на уровне системы типов. Просто запрещаем статические переменные, и так как данные "функции" невозможно реализовать без статических переменных... > Это сразу позволяет делать много интересных вещей типа доказанного отсутствия гонок, непробиваемой системы безопасности без костылей типа CAS и много еще чего. > Без IoC не попишешь но оно того стоит.
Полностью поддерживаю — я бы еще вдобавок сформулировал это правило еще
и с другой стороны: весь код, получающий ресурсы или наоборот отдающий
ресурсы за пределы разрабатываемой программной системы должен быть
выделен в отдельный слой, и чем тоньше этот слой — то есть чем меньше
кода там будет, тем легче будет тестировать все остальное.
Под ресурсами я понимаю: чтения запись файловых потоков, сокеты,
дерганье разных системных функций, получение списков оборудования и все
прочее. Текущее время — такой же ресурс.
То есть цель всего этого — возможность легкого формирования некой
"Матрицы" вокруг нашей программы-"Нео" — когда мы моками конфигурируем
для нашего основного кода полную иллюзию его полноценного существования
и функционирования под нашим полным тотальным контролем в виде тестов.
Здравствуйте, samius, Вы писали:
S>Код, использующий DateTime.Now можно не тестировать?
Как бы это попроще объяснить. Код, использующий DateTime.Now должен иметь такой дизайн, чтобы не было потребности в тестировании таким манером, чтобы понадобилось подменять реальные значения суррогатом.
S>Речь вообще идет о конкретном примере с жизнью объектов, или вообще о коде, который использует методы с неконтроллируемым поведением?
Речь о конкретном примере, когда сервисами начинают подменять все подряд.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mazurkin, Вы писали:
M>Полностью поддерживаю — я бы еще вдобавок сформулировал это правило еще и с другой стороны: весь код, получающий ресурсы или наоборот отдающий ресурсы за пределы разрабатываемой программной системы должен быть выделен в отдельный слой, и чем тоньше этот слой — то есть чем меньше кода там будет, тем легче будет тестировать все остальное.
Ты не понял. Я вобще не про тесты. Тестам эти правила помогут просто как побочный эффект.
Вобще говоря запрет статических переменных это достаточное условие чтобы ты не мог пуступить иначе.
Ибо без статических переменных теоритически невозможно получить ресурс не передав ссылку на него или фабрику этих ресурсов.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote:
> Ты не понял. Я вобще не про тесты. Тестам эти правила помогут просто как побочный эффект.
Нифигасе побочный эффект
> Вобще говоря запрет статических переменных это достаточное условие чтобы ты не мог пуступить иначе. > Ибо без статических переменных теоритически невозможно получить ресурс не передав ссылку на него или фабрику этих ресурсов.
В джаве нет никаких статических переменных — совсем! Только статические
методы классов — их тоже запретить?
Здравствуйте, mazurkin, Вы писали:
>> Ты не понял. Я вобще не про тесты. Тестам эти правила помогут просто как побочный эффект. M>Нифигасе побочный эффект
Именно побочный.
M>В джаве нет никаких статических переменных — совсем! Только статические методы классов — их тоже запретить? Re[7]: То ли лыжи не едут ...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Код, использующий DateTime.Now можно не тестировать?
AVK>Как бы это попроще объяснить. Код, использующий DateTime.Now должен иметь такой дизайн, чтобы не было потребности в тестировании таким манером, чтобы понадобилось подменять реальные значения суррогатом.
Допустим, есть метод, вычисляющий возраст клиента. Фигня конечно, но предположим, что сервис продает видеодиски с возрастным ограничением, и если произойдет ошибка с возрастом на пару минут то заказчик рискует огрести иск. Это все к тому, что метод, вычисляющий возраст должен работать гарантированно точно.
Требуется проверить, как этот метод будет работать в разных нестандартных ситуациях. Сколько лет он навычисляет для человека, родившегося 29 фефраля хххх года 28 февраля уууу года, 1 марта zzzz года....
Какой дизайн должен быть у метода, вычисляющего текущий возраст клиента,
чтобы не было потребности в тестировании таким манером, чтобы понадобилось подменять реальные значения суррогатом.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот именно! Но, судя по всему, мы с тобой в меньшинстве. И вот эта легкость, с которой идут на навороты дизайна для решения небольшой тактической задачи, вместо того, чтобы задуматься, почему и для чего, меня и удивляет. Создается ощущение, что лыжи у меня таки не едут.
Ну не всегда на тестовых примерах можно реальную обстановку смоделировать. Так что же, отменять тесты вообще?
Здравствуйте, samius, Вы писали:
S>Допустим, есть метод, вычисляющий возраст клиента.
И если этот метод использует хоть DateTime.Now, хоть TimeService — проектировщика расстрэлять.
S>Какой дизайн должен быть у метода, вычисляющего текущий возраст клиента
В параметрах должна передаваться дата, на которую надо рассчитать возраст. Объяснять, почему?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Константин Л., Вы писали:
AVK>>Наткнулся тут на запись в блоге. Было бы интересно услышать, кто что думает об этом коде.
КЛ>а это типичный пример всей ущербности tdd
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Константин Л., Вы писали:
AVK>>>Наткнулся тут на запись в блоге. Было бы интересно услышать, кто что думает об этом коде.
КЛ>>а это типичный пример всей ущербности tdd
L>хотелось бы уточнить, tdd или тестов как таковых?
Здравствуйте, Sshur, Вы писали:
ГВ>>Прежде всего, контроль времени существования — это функция не управляемого объекта, а управляющего агрегата. Соответственно, для ручной отладки короткоживущих объектов, скорее всего, достаточно перенастроить агрегат так, чтобы он удалял объекты не через 5 секунд, а спустя большее время. А для тестов я вообще не понимаю, зачем городить такую конструкцию. Получается, что тестирование проводится в условиях, заведомо не похожих на реальные. Спрашивается, а на фига? Планирование процессов таким образом не меняется, гонки так не выкусишь, чего тогда огород городить?
S>Ну во-первых, управляющий агрегат тоже может потребоваться тестировать. И ему может потребоваться подменить функции, возвращающие текущее время.
Честно сказать, это чертовки странно. На мой неквалифицрованный взгляд, такие задачи прекрасно решаются масштабными коэффициентами времени. Ну, если, конечно, взаимодействие со временем не доведено до идиотизма, типа привязки к какому-нибудь ".NoonTime()" — сиречь до употребления трививальных имён моментов врени вместо масштабируемых интервалов.
S>Тестируется логика работы — скажем, сначала надо создать объект А, потом по прошествии N секунд создать B, потом убить их обоих. Для систем, управляющих какими-нибудь объектами в зависимости от времени, это актуально. Логика может быть достаточно сложная, и если в неё вносятся изменения, то её надо как-то тестировать. Это не для того, чтобы тестировать устойчивость многопоточных приложений, а для тестирования бизнес-логики, зависящей от времени.
Всё равно не понятно. Кто мешает заменить N секунд на N*C секунд? Подменяя отсчёт времени сервисом мы добиваемся того же, но атомной бомбой по тараканам.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот именно! Но, судя по всему, мы с тобой в меньшинстве. И вот эта легкость, с которой идут на навороты дизайна для решения небольшой тактической задачи, вместо того, чтобы задуматься, почему и для чего, меня и удивляет. Создается ощущение, что лыжи у меня таки не едут.
Да ладно! Всё те же анекдоты о бессмысленных абстрактных слоях, но в других ипостасях. Хорошо, что хоть компонентную модель с вебсервисом и базой данных вместо TimeService не придумали.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Допустим, есть метод, вычисляющий возраст клиента.
AVK>И если этот метод использует хоть DateTime.Now, хоть TimeService — проектировщика расстрэлять.
Здравствуйте, Геннадий Васильев, Вы писали:
S>>Тестируется логика работы — скажем, сначала надо создать объект А, потом по прошествии N секунд создать B, потом убить их обоих. Для систем, управляющих какими-нибудь объектами в зависимости от времени, это актуально. Логика может быть достаточно сложная, и если в неё вносятся изменения, то её надо как-то тестировать. Это не для того, чтобы тестировать устойчивость многопоточных приложений, а для тестирования бизнес-логики, зависящей от времени.
ГВ>Всё равно не понятно. Кто мешает заменить N секунд на N*C секунд? Подменяя отсчёт времени сервисом мы добиваемся того же, но атомной бомбой по тараканам.
гм, если вы например пишете программу для приготовления яичницы в перспективном кухонном комбайне, где сначала надо кинуть яйца, потом взбивать их 30 секунд, потом выложить на сковороду и жарить 5 минут, то как будет выглядеть и сама программа и тесты? От этого много чего зависит. И потом, что вы понимаете под словом "сервис"? Это просто интерфейс в терминах C#, который будет реализован классом, возвращающим реальное время в "боевых" условиях, и заглушкой в тестовых. Где тут атомная бомба?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, AndrewVK, Вы писали:
S>>Какой дизайн должен быть у метода, вычисляющего текущий возраст клиента
AVK>В параметрах должна передаваться дата, на которую надо рассчитать возраст. Объяснять, почему?
А это то же самое. Я, на самом деле, отвечая, что не вижу тут ничего плохого, никогда у себя не делал спец. прослойку для расчета даты, а передавал нужную дату как параметр. Более того, так как я больше занимаюсь БД и в частности логикой в БД, то часто использую для создания логики UDF. Тамв ызовы GetDate() (аналог DateTime.Now на TSQL) и прочих недетерминированных функций просто запрещены. Сначала передаешь текущее время как параметр в такую процедуру и материшь разработчиков языка, но потом понимаешь, что так лучше.
Если передается текущая дата — то это можно сказать тривиальный случай того самого сервиса. Если больше ничего не надо, то и ладно, а если нужно будет получать несколько таких глобальных величин, то почему бы не объединить несколько этих величин в один интерфейс?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, samius, Вы писали:
S>>>Допустим, есть метод, вычисляющий возраст клиента.
AVK>>И если этот метод использует хоть DateTime.Now, хоть TimeService — проектировщика расстрэлять.
I>почему?
за DateTime.Now — понятно почему. За TimeService — пока не очень.
В том, что параметризация метода временем, на которое нужно вычислить возраст, избавляет от необходимости иметь TimeService — я согласен с AndrewVK. Но это может некоторым образом напрячь потребителя метода GetAge(DateTime) и заставит его в свою очередь обратиться к DateTime.Now. Благо, что потребитель никаких вычислений с полученным значением не делает и проверить то что он передает нужное значение в метод GetAge(DateTime) довольно легко.
Как вариант можно создать перегруженный метод
??? GetAge() { return GetAge(DateTime.Now); }
А если требуется метод GetMagicNumber, требующий текущее время, число процессоров, список MAC адресов и анализы любимого хомяка пользователя, то создание сервиса не будет уже атомной бомбой?
Есть ли какие-то формальные критерии, когда приемлемо создавать сервис, а когда нет? (К здравому смыслу просьба не аппелировать)
Здравствуйте, Sshur, Вы писали:
ГВ>>Всё равно не понятно. Кто мешает заменить N секунд на N*C секунд? Подменяя отсчёт времени сервисом мы добиваемся того же, но атомной бомбой по тараканам.
S>гм, если вы например пишете программу для приготовления яичницы в перспективном кухонном комбайне, где сначала надо кинуть яйца, потом взбивать их 30 секунд, потом выложить на сковороду и жарить 5 минут, то как будет выглядеть и сама программа и тесты? От этого много чего зависит.
Тесты точно будут пригоревшими. Давай не будем писать программу для сферического комбайна в вакууме. На RSDN их и так полно. Если ты хочешь привести пример, где предложенное решение с подменой Time-сервиса удобно и оправдано — приводи.
S>И потом, что вы понимаете под словом "сервис"? Это просто интерфейс в терминах C#, который будет реализован классом, возвращающим реальное время в "боевых" условиях, и заглушкой в тестовых. Где тут атомная бомба?
Я представляю в данном случае под словом "сервис" ровно то, что представляется под ним по ссылке в топикстарте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
