Before I hit the ground coding, let's go over some of the features that were in LinFu v1.0 that will also be in 2.0:
- Dynamic Proxies
- Late Binding / Multiple Dispatch
- Duck Typing
- Mixins
- Universal Event Handling
- Closures with Lambda Arguments
- Design By Contract
- AOP (static and dynamic weaving)
- Inversion of Control / Dependency Injection
- Adaptive Object Models
- A MyXaml Engine Clone
Aside from the fact that v1.0 has a fairly hefty feature list, one thing that I've noticed with the source is that despite those features, LinFu itself doesn't really use its own IoC or DbC facilities to improve the quality of its own code, and that's a wasted opportunity.
With that in mind, I've decided to implement the following features first:
- Inversion of Control / Dependency Injection
- Dynamic Proxies
- Design by Contract
- Static AOP Weaving
Building an IoC/DI container will help enforce a separation of concerns, and using Design by Contract in tandem with TDD will eliminate over 90% of the bugs in the code. The reason why I'm also implementing the static AOP weaving and dynamic proxy generator first is that there has to be a way to transparently inject those contracts into a service instance using a dynamic proxy without having to clutter the original source code. In addition, using the static AOP weaving in a debug build will allow me to dynamically inject diagnostic code without affecting the actual release build.
As for LinFu's Design by Contract v3.0, my goal is to make it injection-agnostic. That means that the library itself should be completely unaware of how it's actually being injected into a service instance. It will allow you to inject contracts using a 3rd-party dynamic proxy generator (such as Castle), and most importantly, it should make no distinction between LinFu's static AOP injection and its own proxy generator.
Probably the most striking difference that you'll see between v1 and v2 is that
LinFu will no longer be split into multiple projects (aside from PostWeaver.exe, and the MSBuild task for LinFu.AOP). There might be some who might say that clumping all of LinFu into one DLL violates the principle of Separation of Concerns, but in practice, it will save you an untold amount of headaches when managing your project dependencies.
I realize that rebuilding LinFu is a very tall order, and I'm putting my heart and soul into this one to make sure that it's the best code that I'll ever write. This is going to take some time to redo, and I'll keep posting more and more updates on my blog as time progresses.
