Implementing Decorator pattern with Windsor Container

The Decorator design pattern makes it possible to extend an abstraction's behavior without touching the implementing class at all. I didn't use to use it as often as I should in the past, but as I'm reading (for the second time, btw) the fresh edition of the excellent Dependency Injection in .NET book by Mark Seemann, I'm getting to really understand how useful it could be.
But the most amazing thing is that how elegantly Windsor Container wires up Decorators. Everything you have to do is register the Decorators in outside-in order and resolve the abstraction. For example, if we have Abstraction interface and two implementations - Impl1 and Impl2:


and we would like Impl1 be injected into Impl2 via its constructor, then all we have to do is register Impl2 as the implementation of Abstraction, then register Impl1 in the same way (no explicit names are required for both). As a result, when we resolve Abstraction from the container, we get instance of Impl2 with its _inner field initialized with an instance of Impl1. Excellent! What's more, the same trick works for collection dependencies (i.e. IEnumerable'1): a Decorator with such a constructor gets all below registered classes as a collection, which is perfectly fits into resolving composite decorators.


In the other hand, having such an automation, we can't compose Decorators in more than one way at the same time. Though, I've not met this restriction in the reality yet.

Comments

Post a Comment

Popular posts from this blog

Haskell: performance

It turned out that it's not Haskell who was slow in my previous Fibonacci test. It was my lack of Haskell knowledge. Haskell has two integral types - Int, which has bounds -2147483648..2147483647 and Integer, which is unbounded. Both types implement Integral type class, so out fib function can be defined in terms of this type class: OK, now we can test performance of the function parametrizing it with the two concrete types. Integer first: We get our previous result ~15 seconds which is rather slow. Now test it with Int type: Whoa! The Int type is ~6 times faster than Integer! And with result of 2.8 seconds Haskell's took the third position in our small rating :) Current list (in seconds): C# - 1.26 F# - 1.38 Nemerle - 1.45 Haskell - 2.8 Clojure - 9 Erlang - 17 Ruby - 60 Python - 120
Read more

Regular expressions: Rust vs F# vs Scala

Image
Let's implement the following task: read first 10M lines from a text file of the following format: then find all lines containing Microsoft namespace in them, and format the type names the usual way, like "Microsoft.Win32.IAssemblyEnum". First, F#: Now Rust: After several launches the file was cached by the OS and both implementations became non IO-bound. F# one took 29 seconds and 31MB of RAM at peak; Rust - 11 seconds and 18MB. The Rust code is as twice as long as F# one, but it's handling all possible errors explicitly - no surprises at runtime at all. The F# code may throw some exceptions (who knows what kind of them? Nobody). It's possible to wrap all calls to .NET framework with `Choice.attempt (fun _ -> ...)`, then define custom Error types for regex related code, for IO one and a top-level one, and the code'd be even longer then Rust's, hard to read and it would still give no guarantee that we catch all possible exceptions. Up
Read more

STM: F# vs Haskell

STM is a very nice parallel programming model used intensively in Haskell and Clojure. There's a F# implementation which can be found in FSharpx library. Today I'm going to test performance of both the Haskell and the F# STMs. The test is very simple - read a couple TVars, check their equality, then write them back incremented by 1, repeat a million times. First, the Haskell code: So, it took about 170 ms. OK, now F#: It took about 1,6 seconds which is an order of magnitude slower than the Haskell result. It's rather frustrating.
Read more