A road named NoNameUno

Do I really like to do the same thing time and again ? That's the question I ask to myself. The answers are different for different situations. Some tasks I can't left to others - like taking a shower etc. And it is repetitive that I can not avoid :-). Others I really don't want to repeat.

One such example is tracing your program thru debug messages, so you know when was the last time, the program behaved as expected, or at least hope for.

So how could I write a debugging module that would take care most of my tracing work, when in need to trace them. Yeah, you will say - as if none of us seen this before. And you are right. We have seen a lot of them. Sometime they are old cruft, and codes are defacto standard copy/paste from even older code. No one really likes to trace/debug, or at least not much of it. Hence the result.

Recently, due to way many things coming into software complexity, people are trying to have different debug tracing, and even systems support logging and tracing. Some of them are system supplied, and you can not change the behaviour and sometime very hard to share with experts on the other side of the globe or galaxy.

Questions aboud -

1) How can I use some design, that does not restrict me in most ways, like use of common languages like: Java, C++, object-C, Swif etc.

2) How can I use in a location independent way ?

3) How can I turn on/off tracing at will and control different types of tracing messages I'm interested in ?

4) How can I make the fairly secure and private ?

5) How can I have them thead safe, so that it does not get in the way of debugging / tracing itself?

etc., etc...

All of these boil down to one thing, in some sense, decouple every little feature(s) as it is always the fact that we don't have complete requirements aprioi. All most always, we will see some thing is either not present or never thought about while at the design table.

All of these, leads to open ended design, so we can plug and play as we go along without compromising structure integrity by large magnitude. And translate to Design Patterns. Mapping requirements to existing design patterns ( or to even come up with new ones ) is the process that I'm talking about by taking an example implementation of a sofware component.

In summary, it will have the formatting meta data to know where is log is coming from, it will have the privacy/encription etc., it will allow dynamic control of what we trace and where the traces go, it should be able to allow multiple related software programming languages... 

Basic design pattern for this I chose is called Observer pattern. This is part of a class of patterns named Behavioural pattern. The choice of implementation language is C++, since the C interface is common among the languages I mentioned above along with many more.

Note that not all patterns are simple, and some of them are even fairly complex to get it right. Here we choose Observer to decouple producer from consumer of the trace to dynamically control both trace message types and destinations of the messages. A message can land in any other remote machine, along with quick console debugging, and system file logging. Messages could also be for different reasons ( event types ) too.

Adapter pattern is used to capture multiplatform supports.