ООП-пуристский вопрос
Может ли класс, являющийся моделью для данных предметной области, содержать в себе ссылку на логгер(log4net,log4j) и выводить данные в лог? :)
Вот представьте себе, есть у вас описание какой-нибудь хреновины, например карточка клиента. И эта карточка при попытках сделать с ней что-нибудь нехорошее, записывает это дело и отсылает "куда нужно" :)
Если бы это был Haskell, такого вопроса не возникло бы вообще, т.к. данные они и есть данные, а в лог без таскания за собой IO или unsafePerformIO и не запишешь ничего.
Вот представьте себе, есть у вас описание какой-нибудь хреновины, например карточка клиента. И эта карточка при попытках сделать с ней что-нибудь нехорошее, записывает это дело и отсылает "куда нужно" :)
Если бы это был Haskell, такого вопроса не возникло бы вообще, т.к. данные они и есть данные, а в лог без таскания за собой IO или unsafePerformIO и не запишешь ничего.
no subject
no subject
no subject
Если это библиотека, то было бы неплохо использовать шаблон функциональности, параметризованный трассировочным классом (функцией?), соответствующей какому-то условному стандарту, и описать этот стандарт концептом (если бы он был зааппрувлен). Если это не C++ (по виду — Java), то тогда не очень знаю, как там такое замутить. Наверное при инстанциации класса передавать логгер, с известным интерфейсом, в параметре.
no subject
Но у меня конкретно, в дотнете, это вообще статик поле, как принято их инициализировать:
static log4net.ILog mLog = log4net.LogManager.GetLogger(System.Reflection.MethodInfo.GetCurrentMethod().DeclaringType);
no subject
no subject
no subject
Можно, конечно, сделать логирование заюзав AOP, но как-то не прижилась эта идея в продакшене.
no subject
Для целей тестирования, как минимум, важно иметь возможность извлечь функциональность и потыкать её с разных сторон. Логгинг этому будет мешать в какой-то степени, но остальные взаимодействия с внешним миром как пить дать мешать этому будут гораздо больше. Например, чтение конфига, отдача ответов по SNMP, etc — это всё пристёгиваемые сверху (методом взятия на себя ответственности за ведение обсуждаемой функциональности) или сбоку (методом [опциональной] параметризации функциональности объектами со стандартным интерфейсом) активности.
Тогда можно добыть голый функционал и даже отдать его кому-то без исходников.
no subject