Reflexive Reflection
I've been prepping a lot lately at work (ie. not teaching). So I've been using that time to work on a .NET based plugin architecture, which I call NPlugin. The idea is that a developer can write a program that acts as a PluginHost. Another developer can write an assembly that contains a class that implements the IPlugin interface. With a few XML config files, the program can load the assembly and the plugin and leverage whatever functionality it contains.
This requires a very flexible design. There's a high demand for extensibility. So I've been using a lot of pattern based design. This has lead to some pretty interesting scenarios.
For example, I want the host to be capable of loading plugins from anywhere- the local filesystem, the web, a database, someplace I haven't yet thought of- which means I need to make the PluginLoader extensible. It would be great, for example, if I had some sort of... plugin architecture.
And that's the design I'm using- the plugin architecture uses itself to manage itself. The PluginLoader is a PluginHost. This is why programmers often refer to parts of software and operating systems as "bootstrappers"- your operating system, and my plugin architecture "lift themselves up by their own bootstraps". I've never worked with a bootstrapped design before, so this has been an incredibly educational experience for me.
I'm nowhere near done- I've got the core of the framework built, but I need to actually implement other PluginHost classes, as well as test the damn thing- oh, and a few GUI widgets would be smart for managing it all too. When I've got a working alpha, I'll throw it up on SourceForge and try and rope a few other .NET devs into it with me.
Oh, and (heresy of heresies), I'm writing it all in VB.NET. VB.NET is more flexible than C# when it comes to OOP and patterns- C# is more flexible for low level interactions which this library doesn't need.
This requires a very flexible design. There's a high demand for extensibility. So I've been using a lot of pattern based design. This has lead to some pretty interesting scenarios.
For example, I want the host to be capable of loading plugins from anywhere- the local filesystem, the web, a database, someplace I haven't yet thought of- which means I need to make the PluginLoader extensible. It would be great, for example, if I had some sort of... plugin architecture.
And that's the design I'm using- the plugin architecture uses itself to manage itself. The PluginLoader is a PluginHost. This is why programmers often refer to parts of software and operating systems as "bootstrappers"- your operating system, and my plugin architecture "lift themselves up by their own bootstraps". I've never worked with a bootstrapped design before, so this has been an incredibly educational experience for me.
I'm nowhere near done- I've got the core of the framework built, but I need to actually implement other PluginHost classes, as well as test the damn thing- oh, and a few GUI widgets would be smart for managing it all too. When I've got a working alpha, I'll throw it up on SourceForge and try and rope a few other .NET devs into it with me.
Oh, and (heresy of heresies), I'm writing it all in VB.NET. VB.NET is more flexible than C# when it comes to OOP and patterns- C# is more flexible for low level interactions which this library doesn't need.