The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Building extendable applications - please help get me started

I've got a few ideas for a Windows GUI applications.  I want to get V1.0 out the door ASAP and see what the interest is like.

If things go well, I want to be able to extend functionality at a later date.  At the moment, I don't know exactly what this will be.  I plan on getting user feedback, checking industry trends, etc.

The plan in my head says to build something modular and then I can add new modules of functionality at a later date.  This, of course, also opens the door for 3rd parties to develop "add-ons" - I'm ok with this.

So, I'm looking for guidelines/pointers as to how to start designing and then writing an extendable modular application.

As an example (this is not what I plan on doing...), consider an accounting application.  Say I want to then develop an add-on module that calculates some new level of tax the government wants.  That's the sort of thing I want to do.

So I'm thinking that these new modules will basically be new (win)forms that are opened by new menu options.  So when you install a new module, new menus/menu options appear and then new forms are available.

Of course, all data (new modules and "core") may need to be accessible across all parts of the app.

I'm confused.  Please help.

I have no issue with GUI programming in general.  I'm just confused on where to start with the design and initial prototype of an extendable-by-modules application.


Billy B. James
Thursday, November 13, 2008
You didn't say what framework you are using. If you are using .NET you can start with the System.Addin namespace.
Thursday, November 13, 2008
Also try looking into Patterns&Practices's Composite UI/CAB application block. It has a learning curve to it but it's a framework designed to address modularity in WinForms application by using inversion of control, object builder strategies, placeholder design approach to UI composition and event dispaching. I hear they even suport WPF lately but i havent tried that.
Thursday, November 13, 2008
Thursday, November 13, 2008
If you're new to extensible apps, CAB will be ... well lets just say it's a lot more than you need, and you'll get totally confused by it.

I'd suggest you look at the recently released Composite Guidance for WPF (formerly known as Prism) from . We've learned a lot from CAB in the years since it's release, both what it did right and what it did wrong. The CompositeWPF team took a very different approach that emphasized simplicity, understandability, and ease of consumption. They addressed the majority of the CAB scenarios in a much, much better way (both to understand and to implement).

One of our advisors, Brian Noyes, has done some work to adapt the code back to WinForms at .
Chris Tavares Send private email
Friday, November 14, 2008
Plugins come in various sizes and shapes, being a very generic term.

The most basic plugin is an executable; if it's found in a subdirectory, display it's icon in the menu and a short description. Give an (encrypted) connectionstring in the startup-arguments and your done :)

Very flexible in debugging, and each 'plugin' will feel like a separate proces. (Kinda like the tabs in Google Chrome do) Even Visual Studio has a menu-point that you can extend with your own applications.

This gives you some extra isolation, which can be a blessing in itself, or a curse (depending on your level of communication between the various modules)

Have fun,
Eddy Vluggen Send private email
Saturday, November 15, 2008
Having add ins as executable files is a great idea, just bear in mind that this has some limitations... If you need to pass around big amounts of data from the application to the addins then using inter applications communication means is a requirement.
What I suggest is, first decide on what do you want to expose to your customers who will write their add-ins. Second, define the contract between your application and the add ins i.e put in place some interfaces that the add-ins should implement. Loading these add-ins at runtime is a fairly easy operation using reflexion if you are in the Java/.NET world.
An example: the application exposes the menu bar to the add-ins so that they can add their menus...
Please don't forget your application has to consider multithreading as well. Should the add ins run in the main or separate threads/processes?

Best regards,

Tahar Send private email
Saturday, November 29, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz