On 26 Apr 2016, at 23:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-04-26 20:16 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>: Making log events subclasses of Announcement and using an Announcer instance local to a subsystem is one easy implementation choice, but not necessarily the only one.
One concrete (but not perfect) implementation of my ideas can be found in the package 'Zinc-HTTP-Logging' in your image.
I look at it.
Thanks for giving feedback.
And I saw hierarchy of ZnClientLogEvent (9 classes) which is just data objects without any behaviour.
Right now the event objects themselves are indeed pretty simple, but not totally without behaviour I would say. Most of the functionality is in the objects they encapsulate (like the request and response, the timing information).
For each class there is method in ZnClient with #log...thisEvent pattern. And most of this methods has only sender which executes real business logic on httpClient. For example:
ZnConnectionEstablishedEvent ^ logConnectionEstablishedTo: url started: initialMilliseconds ^ newConnectionTo: url
So for each event ZnClient has two methods.
The fact that the logging is abstracted into helper methods is not a requirement per se, it is just code organisation, preferable to super long methods. I see only one #logXXX method per log event.
What I feel here is that if Zinc will be designed with some kind of command pattern all of this would be not needed. Instead of events and corresponding methods Zinc would have commands which implement real logic and can be logged directly without any special objects.
I know designing http library is complex task. And maybe my idea is not applicable here.
The idea of using command objects as log objects might work in specific situations, it is a good idea, but I doubt it would be applicable to many situations, or cover all logging needs. I'll certainly think about it.
But what I want to say: applications usually already have objects which incapsulate all needed information for logs. And logging system should not require anything else.
But that is what is happening here (where it is applicable): the log event object that signals that a request resulted in a specific response for example, contains the actual, original objects; that is why doing this is cheap, the objects already exist. Sven