SLF4J とは何か。これ、わりと分かりづらい人もいるかと思います。SLF4J の FAQ にそのものズバリな回答があるんですけど、
What is SLF4J?
SLF4J is a simple facade for logging systems allowing the end-user to plug-in the desired logging system at deployment time.
SLF4J って何?
SLF4J っていうのは、デプロイするタイミングで、使いたいロギングシステムをプラグインできるようにする簡易なロギングシステム用 Facade だよ
SLF4J FAQ
(意訳)
SLF4J っていうのは、デプロイする時点ではじめて、使いたいロギングのライブラリをバインドできるようにする Facade ライブラリだよ
ウワッ、何をいっているのかさっぱりわからない、という父兄もいらっしゃることでしょう。これ、知識があればなんとなく理解できるという意味では「バルスのファルシのルシがパージでコクーン」と同じ匂いがします。
Facade とは
プログラミングのコンテキストで出てくる「Facade」というのは、だいたい GoF の Facade パターンを指していると思って間違いないと思います。なんか、wikipedia がわりとまとまっていましたので、そっちを参照してください。
Facade パターンの肝は、ユーザに対してインタフェースを提供しつつサブシステムの実装の詳細を隠して、ユーザを実装から開放することで、SLF4J もその名 (Simple Logging Facade For Java) が示すとおり、Facade として作用します。
SLF4J
はてさて、SLF4J はユーザに対して何の実装を隠すのか、ですが隠す対象は「ロギングシステム」です。
Java には、有名所のロギングシステムとして、log4j
というのも、ライブラリ内部のログ、フレームワーク内部のログと、それらを利用して動作するアプリケーションのロギングシステムは、基本的に同じにしたいというのがユーザの要望だからです。ライブラリ開発者やフレームワーク開発者が勝手にロギングシステムを決めてしまうと、そのロギングシステムの使用をアプリケーション開発者に半ば強制してしまうことになる。
強制してしまうならまだ良い。ライブラリA がロギングシステムA を使用し、ライブラリBがロギングシステムBを使用するようなケースで、ライブラリAとBを利用するアプリケーションCのロギングシステムに何を使ったら良いでしょう、という難題も発生します。これはこまった。そういう中で生まれたのが SLF4J とでも考えれば良い。
SLF4J は、ライブラリ開発者やフレームワーク開発者に対し、「具体的なロギングシステム」を選択させるかわりにその窓口となるロギング用インタフェースを提供することで、「ロギングシステムの選択」という結論の出ないタスクから開放しています。そして、その「ロギングシステムの選択」をアプリケーション開発者の責務にできるような仕組みを持たせています。
このあたりは、公式サイトにある以下の図が分かりやすい。
SLF4J Manual via kwout
SLF4J は、その下層にあるロギングシステムのレイヤを、アプリケーションから隠していることが図から見て取れると思います。アプリケーション(ここでは、ライブラリやフレームワークも含みます)は、SLF4J API を叩いておけば良く、その下層のロギングシステムへのブリッジは SLF4J が実施してくれるので、もはやアプリケーションは下層のロギングシステムに何が使われるかを意識することなく、開発を行うことができます。
そして、SLF4J の優れているところは、クラスパスに配置されたロギングシステムの jar に応じて、使うべきロギングシステムを判断してくれることにあります。さきほどの例だと、ライブラリA、ライブラリBの双方が SLF4J を使っていてさえくれれば、アプリケーションCがSLF4Jを通してロギングシステムCを使うことで、ライブラリA、B、アプリケーションCのすべてが、いつのまにかロギングシステムCを使えるようになると。便利ですね。
なお、似たような話に [http://commons.apache.org/proper/commons-logging/:title] があります。
