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

[metaclass]

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

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

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

Comments

[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.