> On 26 Apr 2016, at 23:17, Denis Kudriashov <[email protected]> wrote: > > > 2016-04-26 20:16 GMT+02:00 Sven Van Caekenberghe <[email protected]>: > 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
