Здравствуйте, WolfHound, Вы писали:

К>>Затем, чтобы не тащить это окошко сквозь все функции (членом класса, а тем паче — ещё одним аргументом).
WH>А зачем вобще таскать окошко?
WH>Что будешь делать если этот код понадобится запустить в пакетном режиме на линуховом сервере у которого даже видюхи нет?
А это как раз к коду отношения не имеет. Т.е. если метод calculateEmployeeSalary() на сервере бросит исключение, то будет корректно откачена тразнакция, а исключение записано в лог. На клиенте сработает ловец исключений в цикле событий GUI-потока, который вызовет уже мой код отсылка stacktrace'а.

Ещё стандартный пример:

public class SomeClass
{
     private static final Logger logger=Logger.getLog(SomeClass.class);
  
     void someMethod()
     {
           log.debug("Some message");
     }
}

//В файле log4j.properties:
# Turn on debug messages for SomeClass
log4j.com.somepackage.SomeClass=DEBUG

Естественно, доводить до синглтонов с бизнес логикой такое нельзя. Но и совсем без статиков — тоже плохо.

Здравствуйте, WolfHound, Вы писали:

C>>Например, у меня статик используется в коде обработки ошибок. Чтоб узнать какое окно делать parent'ом для диалога отправки stacktrace'а и имя пользователя, который программу опять сломал. Мелочь, а неудобно без неё.
WH>И зачем тут статики?
А как ты ещё передашь эти данные?

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, WolfHound, Вы писали:

C>>>Например, у меня статик используется в коде обработки ошибок. Чтоб узнать какое окно делать parent'ом для диалога отправки stacktrace'а и имя пользователя, который программу опять сломал. Мелочь, а неудобно без неё.
WH>>И зачем тут статики?
C>А как ты ещё передашь эти данные?

InteractionPoint ip = (context/provider/etc)->GetInteractionPoint();
ip->ShowError(e);

InteractionPoint в context/provider/etc кладет тот, у кого есть хендл окошка/кому нужна модальность и т.п.

Здравствуйте, WolfHound, Вы писали:

К>>Слава богу, под симбиан пишет только мой коллега! И именно от него я наслушался вотзефаков.
WH>На сколько я понимаю в симбиане много других вотзефаков.
WH>А отсутствие статиков момент сугубо положительный.
Есть там статики, самые разные
Раньше их использование было затруднено, поэтому исторически сложилось мнение, что их нет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Код, использующий DateTime.Now должен иметь такой дизайн, чтобы не было потребности в тестировании таким манером, чтобы понадобилось подменять реальные значения суррогатом.

+1: криво написанный код приводит к ещё более кривым костылям при тестировании. В порыве пректирования забыли о более простых вещах.

Здравствуйте, _FRED_, Вы писали:

_FR> В порыве пректирования забыли о более простых вещах.

Хуже, в порыве тестирования, если я правильно понял.

Здравствуйте, Аноним, Вы писали:

А>InteractionPoint в context/provider/etc кладет тот, у кого есть хендл окошка/кому нужна модальность и т.п.
Это требует:
1) Передавать её параметром в большинство функций.
2) Заранее подумать о ней.

Да и DI в GUI-приложениях не так удобен.

Здравствуйте, AndrewVK, Вы писали:

_FR>> В порыве пректирования забыли о более простых вещах.

AVK>Хуже, в порыве тестирования, если я правильно понял.

Выдумывание сервисов — это уже проектирование: и не суть, для тестов оно надо или нет

Главное вот не понимают: либо в алгоритме\модуле дата должна приходить снаружи, либо _ничего_ кроме DateTime.Now там быть не должно.

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

Здравствуйте, Cyberax, Вы писали:

C>Да и DI в GUI-приложениях не так удобен.

Чем же?

Здравствуйте, _FRED_, Вы писали:

C>>Да и DI в GUI-приложениях не так удобен.
_FR> Чем же?
Почти всегда созданием иерархии контролов занимается GUI-фреймворк, он же устанавливает и их свойства и позволяет их графически редактировать.

Здравствуйте, Cyberax, Вы писали:

C>>>Да и DI в GUI-приложениях не так удобен.
_FR>> Чем же?
C>Почти всегда созданием иерархии контролов занимается GUI-фреймворк, он же устанавливает и их свойства и позволяет их графически редактировать.

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

Здравствуйте, WolfHound, Вы писали:

AVK>>Т.е. ты считаешь нормальным заменять DateTime.Now на сервис?
WH>Да.
WH>Более того лично я чем больше думаю тем сильнее склоняюсь к мысли что "функции" типа DateTime.Now, File.Open,... вобще должны быть запрещены на уровне системы типов. Просто запрещаем статические переменные, и так как данные "функции" невозможно реализовать без статических переменных...

А как быть, например, с DependencyProperty?

Во-вторых, это ведёт к тому, что DI дожен уже быть в самой стандартной библиотеке, так как будет нужен и стандартным классам, например, TransactionScope или SqlCollection.

Гхм, может оно и не плохо. А есть уже среды, которые так реализованы (c DI как базовым механизмом)?

Здравствуйте, _FRED_, Вы писали:

C>>Почти всегда созданием иерархии контролов занимается GUI-фреймворк, он же устанавливает и их свойства и позволяет их графически редактировать.
_FR>Понятно. Но ведь можно инжектить уже и сконструированные объекты, причём по-разному в дизайн-тайм и в ран-тайм. Да, будет лишний шаг, но не кривой и не сложный.
А смысл? GUI-фреймворки неплохо справляются с этим. А делать DI ради DI я просто смысла не вижу.

Здравствуйте, _FRED_, Вы писали:

_FR>А как быть, например, с DependencyProperty?

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

Все что нужно это задизайнить DependencyProperty неизменяемым.

_FR>Во-вторых, это ведёт к тому, что DI дожен уже быть в самой стандартной библиотеке, так как будет нужен и стандартным классам, например, TransactionScope или SqlCollection.
Ну напишут разработчики стандартной библиотеки IoC контейнер и все.

_FR>Гхм, может оно и не плохо. А есть уже среды, которые так реализованы (c DI как базовым механизмом)?
ХЗ.
Но если пытатся делать безопасность на всю катушку то по другому не получится никак.

Здравствуйте, WolfHound, Вы писали:

_FR>>А как быть, например, с DependencyProperty?
WH>

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

WH>Все что нужно это задизайнить DependencyProperty неизменяемым.

Ага, если отказаться от изменяемых статических данных, то +100.

_FR>>Во-вторых, это ведёт к тому, что DI дожен уже быть в самой стандартной библиотеке, так как будет нужен и стандартным классам, например, TransactionScope или SqlCollection.
WH>Ну напишут разработчики стандартной библиотеки IoC контейнер и все.

Если сейчас уже несколько контейнеров на слуху, то "один стандартный" многим не понравится, придётся "скрещивать" и т.п. Или несколько контейнеров разной природы могут органично существовать в рамках одного проекта? Есть у кого опыт?

Здравствуйте, _FRED_, Вы писали:

AVK>>Хуже, в порыве тестирования, если я правильно понял.

_FR>Выдумывание сервисов — это уже проектирование: и не суть, для тестов оно надо или нет

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

_FR>Кстати, я бы кстати, спросил шире: а где (в каких участках кода или архитектуры) вообще допустимо использовать DateTime.Now? В подлежащей тестированию логике Да ни в жизнь.

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

Здравствуйте, Cyberax, Вы писали:

C>>>Почти всегда созданием иерархии контролов занимается GUI-фреймворк, он же устанавливает и их свойства и позволяет их графически редактировать.
_FR>>Понятно. Но ведь можно инжектить уже и сконструированные объекты, причём по-разному в дизайн-тайм и в ран-тайм. Да, будет лишний шаг, но не кривой и не сложный.
C>А смысл? GUI-фреймворки неплохо справляются с этим.

Что ты имеешь в виду под "этим"? Мы говорим о инжекции зависимостей. Какой GUI-фреймворк "неплохо справляются с этим"?

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Хуже, в порыве тестирования, если я правильно понял.
_FR>>Выдумывание сервисов — это уже проектирование: и не суть, для тестов оно надо или нет
AVK>Тут главное обоснование — не делаем нормальную архитектуру, потому что код трогать сильно нельзя, но, поскольку затестить не получается, ломаем по месту не оглядываясь на архитектуру в целом.

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

AVK>Там рядом еще такой пост есть, все на ту же тему.

Да, то же самое: переписать нормально не может, но кастылей понафтыкаем

Здравствуйте, AndrewVK, Вы писали:

AVK>Наткнулся тут на запись в блоге. Было бы интересно услышать, кто что думает об этом коде.

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

По ссылке кому-то вот хотелось DI, хотя ответ содержится в постановке задачи. Если возникло требование подавать "текущее время" извне, дык его надо и подавать извне. И сразу же станет очевидным следующее решение (уже указанное Геной), кто и что должен контроллировать относительно времени жизни.

Мне лично топик показался интересным именно из-за DateTime.Now, ибо он — популярный источник странных ошибок. У нас в проекте DateTime.Now дай бог в одном-двух местах максимум вызывается, в другие места передаётся как параметр/контекст (и подобных проблем с тестированием не возникает, разумеется).

Здравствуйте, Cyberax, Вы писали:

AVK>>Т.е. ты считаешь нормальным заменять DateTime.Now на сервис?
C>Да. Например, мне нужно тестировать логику, зависящую от текущего времени. Как ты предлагаешь иначе это делать?

+1, но я не понял, почему в там все методы static? Разве не удобнее сделать интерфейс ICurrentTime и получать реализацию (CurrentTime vs CurrentTimeStub) от какого-нибудь провайдера?