Design Question: Do I need a pluggable system?

[jmDesktop]

I'm using C#, but I don't know that it matters for this question. I
know that many experienced folks are on here, so sorry for being off
topic. I am finally at a point where I want to and I think able to
design software that is modular and pluggable. The only problem is
that I'm not sure if I need to or if this lends itself to it.

I have a project that requires building a scheduler. It's more of a
virtual take number program as in taking a number at the butcher
counter or something. It's small and not too complicated. I want to
use this small project to learn how to design in a modular, pluggable
way.

What I want to do is design it in such way that I can expand it, but
not expand it in the usual (my usual anyway) of simply creating a new
web page in C#, put in a new class for my BLL, hit the table adapter
that has my SQL. I'll still probably need much of that. But what I
want to do is make it so that when I add stuff later it adheres to a
standard way of doing things.

I am thinking the best way to do this is with Interfaces, at least
that is what I keep reading in pluggable architecture.

I think what I am most confused about is what exactly the "contract"
should be. What types of commonalities would I care about in a system
like this for expansion. None? Surely something should be common so
I can design it with this architecture in mind. I hope this make
sense. If it does, any help is appreciated. My struggle to explain
indicates my struggle to design.

 

[sloan]

You can take a look here:
http://sholliday.spaces.live.com/blog/cns!A68482B9628A842A!126.entry

and pay attention to the "Reflection" version.

...
Basically I have one interface, and several concretes. The blog talks about
different methods of setting up your factory class.

......

www.dofactory.com has some examples as well.

 

[Ignacio Machin ( .NET/ C# MVP )]

I'm using C#, but I don't know that it matters for this question.  I
know that many experienced folks are on here, so sorry for being off
topic.  I am finally at a point where I want to and I think able to
design software that is modular and pluggable.  The only problem is
that I'm not sure if I need to or if this lends itself to it.

I have a project that requires building a scheduler.  It's more of a
virtual take number program as in taking a number at the butcher
counter or something.  It's small and not too complicated.  I want to
use this small project to learn how to design in a modular, pluggable
way.

What I want to do is design it in such way that I can expand it, but
not expand it in the usual (my usual anyway) of simply creating a new
web page in C#, put in a new class for my BLL, hit the table adapter
that has my SQL.  I'll still probably need much of that. But what I
want to do is make it so that when I add stuff later it adheres to a
standard way of doing things.

I am thinking the best way to do this is with Interfaces, at least
that is what I keep reading in pluggable architecture.

I think what I am most confused about is what exactly the "contract"
should be.  What types of commonalities would I care about in a system
like this for expansion.  None?  Surely something should be common so
I can design it with this architecture in mind.  I hope this make
sense.  If it does, any help is appreciated.  My struggle to explain
indicates my struggle to design.

Jon Skeet has a very good article about writting plug-ins. Basically
you use three projects, in one project you define the interface of the
plugin. in the other you define the type that implements that
interface (this is the plug-in itselft) and finally you have the
consumer of the plugin.
Both implementator & consumer make a reference to the interface
project. The beauty is that the consumer does not need to know who is
implementing the plugin. You can load the assembly using reflection
and create an instance of it without knowing the real implementator.