Какой шаблон проектирования вы бы рассмотрели при необходимости ведения журнала?

Ответ 1

Вы можете использовать AOP для применения регистрации без какого-либо навязчивого поведения. АОП может чувствовать себя как смесь прокси и декоратора.

Ответ 2

Не объединяйте команду и журнал Memento.

Команда - это то, что делается. Это может включать некоторые общие аспекты во всех командах, включая запись записи в журнал.

Сама запись журнала может быть Memento или резюме Memento.

Регистратор - это своего рода Factory, который создает Mementos для зарегистрированных событий.

Как и в большинстве случаев, у вас есть большое количество взаимосвязанных шаблонов проектирования. Какой "один" шаблон "самый популярный/подходящий" не входит в него.

Вопрос: "Что должно произойти?"

Ответ 3

Наблюдательный шаблон хорошо подходит для ведения журнала. Вы можете иметь класс Logger, расширяемый Observable, и дочерние классы, такие как log to console, log to Database и log to File system etc, а каждый дочерний класс реализует Observer. Теперь, когда регистрируется сообщение журнала, все классы наблюдателей, зарегистрированные в классе Logger, будут уведомлены, чтобы каждый дочерний класс ex: log to console записывал сообщение в консоль. Кроме того, класс Logger может следовать шаблону Singleton, чтобы убедиться, что один экземпляр Logger доступен через приложение.

Ответ 4

Я согласен, я думаю, что шаблон команды будет максимально соответствовать, поскольку у вас есть все перечисленные действия.

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

Ответ 5

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

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