I spent about 8 months in 2008 using Smart Client Software Factory to build a smart client application for traders at a Hedge Fund. This experience drilled into me the importance of separation of concerns when building windows forms applications. I like the way CAB and SCSF force you to rethink dependencies and cleanly organize complex forms based applications. I really wish I had this experience before building Snip-It Pro. That is why the first part of the refactor will be to apply some of the lessons learned to fundamentally change the architecture of Snip-It Pro for the better.

So the first step in refactoring is to rethink the Snip-It Pro UI as a composite application. By doing this, we will be able to expose extensibility points that our new plug in architecture will be able to take advantage of. Below you can see a screenshot of the UI of Snip-It Pro.

Snip-It Pro docks to the side of your screen so you can drag and drop snippets to and from and application. The UI is generally simple and there are really only a few areas that we would need to make extensible.

The Snippets themselves are organized in a tree Structure. The shell needs to be able to expose this structure to plugins so that they can add their own custom nodes or modify properties of existing nodes. This will be the first extensibility point of the shell. Because the current code base is using the concrete node types used by the UI components I am using, I will need to abstract out the concept of a snippet node and build in support for converting from the new snippet node abstraction to the concrete UI Element.

The second obvious place is the main menu. Plug ins need to be able to add their own menu items to the main menu. There are also similar context menus when you right click on snippets or snippet folders. All three areas need to be extensible. They also share a similar behavior that looks like it will work nicely with a Command Pattern. In SCSF, they had a string based Eventing system that would allow publishers and subscribers to respond to events without knowing anything about each other. This may be overkill as the plug ins should both set up the publishers and subscribers.

The last piece of extensibility is the search. Right now, the search just traverses properties of each snippet node in the tree. Additional behavior might be desired depending on the plug in. The shell should be able to expose a mechanism for a plug in to modify this behavior through a well defined interface.

If we begin to think of the UI of Snip-It Pro as a shell and the different areas of the UI as extensibility points, we can start to think of refactoring out some of the core Snip-It Pro functionality into plug ins. For example, the Clipboard History functionality could be removed from the core and implemented as a plug in. The module would add its own node for displaying what is copy/pasted. The import/export capability could be extracted as well. Heck, the core file based snippet functionality could be extracted. This would enable us to have to ability to create modules that may build snippet nodes from other sources: databases, web services, etc.

This leaves me with a lot of work to get started on. Once the UI is extensible, we can start thinking about what the plug in interfaces will look like.