0

Update: I edited my question to make my intentions more clear.

So I think this question about logging will be different to the often asked questions.

First things first: I have an application that is doing some stuff. While the stuff is beeing done, some situations can occur where the application has to give notice to e.g. some people. To be more concrete, imagine a function that copies a file from A to B. If it succeeds, the function should give notice to the user that started the application by writing something to stdout. If it however fails, it should give notice to this user on stderr but also write to the error to a file and send a mail to e.g. the administrator.

Edit: Please note that this is not "classical" logging in that I want to have some logs for debugging and searching for errors. It is more about a notify system that has the job for deciding how and whom to notify depending on the situation depending on the business-logics.

In my opinion the function should not know about who is notified or exactly how to notify. Instead a service should be given to the function that has a method beeing called on success and one for failure. The service then decides what to do next. The methods could be called like providingImportantFileWasSuccessfull and providingImportantFileFailed. (please feel free to give better names here!)

So, here comes my question: how to design this service? Or better: how to desing the service architecture. I don't want to make one service class that contains all the business-logic functions as there may be hundreds or even more. Should I create subservices for specific business-logic cases? How could my class-structure look like? Are there other concepts for handling the logging?

valenterry
  • 2,429
  • 16
  • 21
  • 2
    It would help us to answer this question if you can explain what parts of your question are not answered by http://programmers.stackexchange.com/questions/112402/what-are-some-patterns-and-anti-patterns-of-application-logging?rq=1 – James Snell Oct 22 '14 at 11:10
  • I read this question. However my question is not regarding which log-levels to use or best practice but rather about the software architecture (what logging classes, how they work together, what design patterns to use) and so on. Does this make it more clear? Then I will update my question. – valenterry Oct 22 '14 at 11:59
  • 1
    You'll get more help if you make an attempt and provide the classes yourself. – JeffO Oct 22 '14 at 12:08
  • http://meta.stackexchange.com/a/194495/165773 – gnat Oct 22 '14 at 12:47
  • @JeffO But that is my question: what classes would be appropriate (in a general context of course, not for my given example)? At Gnat: Why this link? As I said I read the given question and this is not even close a duplicate and does not answer my own question. – valenterry Oct 22 '14 at 12:58
  • 1
    consider [edit]ing your explanation into the question, because many readers ignore comments – gnat Oct 22 '14 at 13:45
  • related (possibly a duplicate): [Which design pattern is more suitable for logging?](http://programmers.stackexchange.com/q/221490/31260) – gnat Oct 22 '14 at 18:27
  • A couple of ways that immediately come to mind. 1 - have your "logger" always signal a "LogEvent" containing log entry information. Each module that might need do something with a log entry registers for the LogEvent and the observing modules decide what to do if anything based on the log entry information. From your example you'd probably have User, ErrorLogger and MailNotification modules. 2 - Each class signals its specific kinds events and each module registers for events of interest from each specific class and the modules take action accordingly, e.g. write to file, send email. – Dunk Oct 24 '14 at 13:27
  • Unfortunately I can't "answer" the question due to it being restricted. **The answer is** that you have to use **the proxy pattern**. You have the right idea when you explained that the function (or class) should not know about who is notified. Just apply the proxy pattern. – z0mbi3 Nov 28 '14 at 23:30

0 Answers0