IT-redneck

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

From:

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

From:

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

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

From:

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

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

From:

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

From:

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

From:

feorex.livejournal.com

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

From:

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

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

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

From:

x-a-e-p.livejournal.com

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

From:

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

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

From:

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

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

From:

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

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

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

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

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

From:

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

From:

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

From:

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

From: