Qual padrão de design é mais adequado para o log?

10

Devo registrar alguns eventos em um programa, mas, tanto quanto sei, seria melhor manter o código de log fora do programa, porque não se trata da funcionalidade real do programa. Então, você pode me dizer se devo mantê-lo completamente fora de código e usar apenas Observadores e Ouvintes para registrar os eventos? Ou posso adicionar uma linha de código como a seguinte sempre que precisar registrar algo:

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

Cometo um erro ao usar o padrão de design do Observer? Preciso de outro padrão de design? Ou devo parar de pensar em padrões de design?

PS1. Se eu quiser registrar usando apenas ouvintes e observadores, certamente precisarei adicionar e melhorar os observadores e ouvintes do programa.

PS2. Eu certamente sei que existem bibliotecas diferentes para efetuar login em Java e estou usando java.utils.logging, mas preciso ter um wrapper para registrar meus objetos especiais.

java design-patterns logging observer-pattern user1892555
fonte
2
Java já possui 17 estruturas de log e estruturas de meta-log (slf4j) e provavelmente alguma estrutura de meta-meta-log e nenhuma delas funciona para você?
kevin Cline

Respostas:

15

Logginggeralmente é implementado com o padrão da Cadeia de responsabilidade . Claro que você pode (e eu combinaria) isso com uma fachada . Eu realmente não usaria ouvintes ou observadores.

Cadeia de responsabilidade - Logger

Elliott Frisch
fonte
Isso está basicamente dizendo "escreva no seu logger abstrato no seu código"? Acho que minha pergunta é: devo acionar eventos de onde quero registrar e fornecer um ouvinte que faça logon em resposta a eventos ou devo ligar diretamente para o meu serviço Logger (que usa cadeia de responsabilidade internamente) e é isso?
Fire-Dragon-DoL
8

Use a Programação Orientada a Aspectos, que usa conselhos Após, Antes e Ao redor sobre os métodos. Lá, conforme sua necessidade, você pode adicionar logs antes do início da API, após ou em algumas condições e também separar seu código principal do código de log.

Yogesh Patil
fonte
0

Bem, o Observer parece impróprio para mim. Além disso, lançar chamadas de logger "onde você precisar" quebrará seu código e violará o SRP.

Você pode, por exemplo, estar interessado em AOP para isso, para poder anexar chamadas do criador de logs por meio de anotações de método.

Powerslave
fonte
0

A cadeia de responsabilidade parece ser um bom padrão quando sua saída pode chegar a vários locais. Na UML, você tem um agente de log diferente, que direciona para o console, outro para errorFile e o terceiro simplesmente para registrar informações.

Normalmente, vi que os níveis de log são diferentes, mas o arquivo de log é o mesmo.

Não vejo um padrão de observador tão ruim para o registro, pois desacopla seu código de registro do código do aplicativo. Qual é uma boa prática, migrar para diferentes mecanismos de registro é fácil dessa maneira. Toda vez que você desejar registrar, inicie um evento e o ouvinte apropriado receberá e registrará o evento. Deve haver um objeto singleton intermediário que contém a lista de todos os registros.

Dessa forma, vejo que podemos separar nosso código de log do código do aplicativo.

user2922188
fonte