ООП-пуристский вопрос

[metaclass]

Может ли класс, являющийся моделью для данных предметной области, содержать в себе ссылку на логгер(log4net,log4j) и выводить данные в лог? :)

Вот представьте себе, есть у вас описание какой-нибудь хреновины, например карточка клиента. И эта карточка при попытках сделать с ней что-нибудь нехорошее, записывает это дело и отсылает "куда нужно" :)

Если бы это был Haskell, такого вопроса не возникло бы вообще, т.к. данные они и есть данные, а в лог без таскания за собой IO или unsafePerformIO и не запишешь ничего.

Comments

[lionet.livejournal.com]

Нет, нельзя. Необходимо сделать из этого класса монаду и параметризовать её моноидом трассировки.

[metaclass.livejournal.com]

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

[lionet.livejournal.com]

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

Если это библиотека, то было бы неплохо использовать шаблон функциональности, параметризованный трассировочным классом (функцией?), соответствующей какому-то условному стандарту, и описать этот стандарт концептом (если бы он был зааппрувлен). Если это не C++ (по виду — Java), то тогда не очень знаю, как там такое замутить. Наверное при инстанциации класса передавать логгер, с известным интерфейсом, в параметре.

[metaclass.livejournal.com]

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

Но у меня конкретно, в дотнете, это вообще статик поле, как принято их инициализировать:
static log4net.ILog mLog = log4net.LogManager.GetLogger(System.Reflection.MethodInfo.GetCurrentMethod().DeclaringType);

[lionet.livejournal.com]

А этому интерфейсу ещё какая-то независимая имплементация логгера соответствует, или это log4net специфичный интерфейс?

[metaclass.livejournal.com]

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

[feorex.livejournal.com]

Юзаю log4net. Добавляю его в классы, ничего страшного в это не вижу.
Можно, конечно, сделать логирование заюзав AOP, но как-то не прижилась эта идея в продакшене.

[lionet.livejournal.com]

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

Для целей тестирования, как минимум, важно иметь возможность извлечь функциональность и потыкать её с разных сторон. Логгинг этому будет мешать в какой-то степени, но остальные взаимодействия с внешним миром как пить дать мешать этому будут гораздо больше. Например, чтение конфига, отдача ответов по SNMP, etc — это всё пристёгиваемые сверху (методом взятия на себя ответственности за ведение обсуждаемой функциональности) или сбоку (методом [опциональной] параметризации функциональности объектами со стандартным интерфейсом) активности.

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

[x-a-e-p.livejournal.com]

Ну какбэ да, Writer monad

[zamotivator.livejournal.com]

Странный какой-то вопрос. Решений как обычно два:
1) Синглтон
2) Ссылка на логгер
Дальше начинаются вопросы "как это всё оформить красиво". Т.е. дизайн.

Есть подозрение, что ты не описал задачу, которую решаешь.
Что тебя смущает?

[metaclass.livejournal.com]

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

А вопрос заключается в том, что:
1) Меня напрягает "активное" поведение объекта данных. Это все равно, как бумага на столе после рисования на ней уползала со стола в копир и там себя копировала.
2) Ссылка из этого объекта во внешний мир. Не хаскелеобразно и бесит.
3) Я представляю себе, сколько всяких контекстов пришлось бы передавать моим объектам, будь они функционально чистыми, и мне становится страшно за будущее функциональной парадигмы.

[zamotivator.livejournal.com]

А я не вижу проблемы - ты просто это всё неправильно готовишь.

1) Разделение обязанностей.
Пусть у нас есть логирование карточки, запись в БД, etc.
Что декларирует ООПшный подход? Агрегирование ссылок на логгер иди БД-шный аксесор, вызов к ним.
Попробуем сделать по ФП-шному построим родственные классу функции "запись в лог", "запись в БД".
Таким образом, эти обязанности реализуются в функциях.

2) Комбинирование поведение.
Гамма завещал нам декоратор. Именно декоратором и являются построенные нами родственные функции.

Что остаётся? Ну, построить сущность (подозрительно напоминающую моноид) являющуюся по сути "классом" твоей карточки.

Дальше ты таскаешь карточки (суть данные) + сборную солянку (классы) и получаешь profit.

[metaclass.livejournal.com]

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

[zamotivator.livejournal.com]

Ну там оно и получается.
Функциональная парадигма всё-таки разделяет данные и поведение.
Потому нужно сосредоточиться на описании "классов" - т.е. поведения, а данные просто plain - болтаются сбоку.
Инкапсуляция достигается суть замыканием состояния в обработчике....
Всё верно ведь?

[metaclass.livejournal.com]

Да, вроде все так и получается.

[zamotivator.livejournal.com]

Кстати, этот подход к дизайну отлично описан в SICP.

[pete-by.livejournal.com]

AOP специально для таких случаев придумали.

[blackyblack.livejournal.com]

lionet всё здорово и правильно описал.
Единственное что можно поправить - это сильно сложное описание статического поля для экземпляра логгера. Если представить, что кому-то в руки попал твой класс, а логгер он ещё не скачал, то придётся не только создавать заглушку на ILog, но и приделывать таинственный неймпспейс log4net.
К тому же неясно, зачем тут рефлекшн. Точнее ясно, но неясно как логгер оторвать от класса с наличием этого рефлекшена.