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.