{"id":2690,"date":"2017-01-23T11:06:34","date_gmt":"2017-01-23T00:06:34","guid":{"rendered":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/?p=2690"},"modified":"2019-12-13T17:27:45","modified_gmt":"2019-12-13T06:27:45","slug":"the-package-level-logger-anti-pattern","status":"publish","type":"post","link":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/2017\/01\/23\/the-package-level-logger-anti-pattern","title":{"rendered":"The package level logger anti pattern"},"content":{"rendered":"\n

This post is a spin-off from various<\/a> conversations<\/a> around improving (I’m trying not to say standardising, otherwise I’ll have to link to XKCD) the way logging is performed in Go projects.<\/p>\n\n\n\n

Consider this familiar pattern for establishing a package level log<\/code> variable.<\/p>\n\n\n\n

package foo\n\nimport \u201cmylogger\u201d\n\nvar log = mylogger.GetLogger(\u201cgithub.com\/project\/foo\u201d)<\/pre>\n\n\n\n
What’s wrong with this pattern?<\/p>\n\n\n\n
The first problem with declaring a package level log<\/code> variable is the tight coupling between package foo<\/code> and package mylogger<\/code>. Package foo<\/code> now depends directly on package mylogger<\/code> at compile time.<\/em><\/p>\n\n\n\n
The second problem is the\u00a0tight coupling between package foo<\/code> and package mylogger<\/code> is transitive. Any package that consumes package foo<\/code> is itself dependant on mylogger<\/code> at compile time.<\/p>\n\n\n\n
This leads to a third problem, Go projects composed of packages using multiple logging libraries, or<\/em> fiefdoms of projects who can only consume packages that use their particular logging library.<\/p>\n\n\n\n
Avoid source level coupling<\/h1>\n\n\n\n
The solution to this anti pattern is to delay the binding between the type that does the logging, and the type that needs to log, until it is needed. That is, until the variable is declared.<\/p>\n\n\n\n
package foo\n\nimport \"github.com\/pkg\/log\"\n\ntype T struct {\n        logger log.Logger\n        \/\/ other fields\n}<\/pre>\n\n\n\n
Now, the consumer of  type T<\/code> supplies a value of type log.Logger<\/code> when constructing new T<\/code>‘s, and the methods on T<\/code> use the logger<\/code> they were provided when they want to log.<\/p>\n\n\n\n
Interfaces to the rescue<\/h1>\n\n\n\n
The eagle eyed reader will note that the previous selection removed the package level log<\/code> variable, but the coupling between package foo<\/code> and package log<\/code> remains.<\/p>\n\n\n\n
However, this can be remedied by the consumer<\/em> of the logger<\/code> type declaring its own interface for the behaviour it expects.<\/p>\n\n\n\n
package foo\n\ntype logger interface {\n        Printf(string, ...interface{})\n}\n\ntype T struct {\n        logger\n        \/\/ other fields\n}<\/pre>\n\n\n\n
As long as the type assigned to foo.T.logger<\/code> implements foo.logger <\/code>the decision for which specific type to use can be deferred until run time in the same way that io.Copy<\/code> escapes any knowledge of the io.Reader<\/code> and io.Writer<\/code> implementations in use until it is invoked.<\/p>\n\n\n\n
It’s not just logging<\/h1>\n\n\n\n
Logging is a cross cutting concern, but the anti patterns associated with it also apply to other common areas like metrics, telemetry, and auditing.<\/p>\n\n\n\n
Get involved<\/h1>\n\n\n\n
The Go 1.9 development window is opening next month. If this topic is important to you, get involved<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
This post is a spin-off from various conversations around improving (I’m trying not to say standardising, otherwise I’ll have to link to XKCD) the way logging is performed in Go projects. Consider this familiar pattern for establishing a package level log variable. package foo import \u201cmylogger\u201d var log = mylogger.GetLogger(\u201cgithub.com\/project\/foo\u201d) What’s wrong with this pattern? The first problem […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":3,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[29,36],"tags":[202,192],"class_list":["post-2690","post","type-post","status-publish","format-standard","hentry","category-golang","category-programming-2","tag-design","tag-logging"],"_links":{"self":[{"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/posts\/2690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/comments?post=2690"}],"version-history":[{"count":11,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/posts\/2690\/revisions"}],"predecessor-version":[{"id":3925,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/posts\/2690\/revisions\/3925"}],"wp:attachment":[{"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/media?parent=2690"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/categories?post=2690"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/dave.cheney.net\/wp-json\/wp\/v2\/tags?post=2690"}],"curies":[{"name":"wp","href":"https:\/\/proxy.goincop1.workers.dev:443\/https\/api.w.org\/{rel}","templated":true}]}}