By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,797 Members | 1,251 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,797 IT Pros & Developers. It's quick & easy.

Design Pattern?

P: n/a
Hi,
I'm not an expect in .NET, so would anyone know an answer a design
pattern for the following?
There are many customers that require minor customizations to the
program I will be developing. I would like to reuse the majority of the

functionality of this program since each customer is only requiring
certain changes to this program.
Is there a way to design this so that the main base, skeleton of the
program is seperate from the customization and the different
customizations can be loaded like a snap on module? Sort of like a SNES

game system, and each cartridge makes the console provide a differnt
type of service? Is there a design pattern for this?
Thanks!

Jan 31 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Google for plugins and automation models.

HTH,
Kent

<pi*****@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Hi,
I'm not an expect in .NET, so would anyone know an answer a design
pattern for the following?
There are many customers that require minor customizations to the
program I will be developing. I would like to reuse the majority of the

functionality of this program since each customer is only requiring
certain changes to this program.
Is there a way to design this so that the main base, skeleton of the
program is seperate from the customization and the different
customizations can be loaded like a snap on module? Sort of like a SNES

game system, and each cartridge makes the console provide a differnt
type of service? Is there a design pattern for this?
Thanks!

Jan 31 '06 #2

P: n/a
Hi,

There are many customers that require minor customizations to the
program I will be developing. I would like to reuse the majority of the

functionality of this program since each customer is only requiring
certain changes to this program.


Are you primarely talking about a on/off situation, where a customer either
have one module or not.
Or it's more like this customer has this process and the other have another
for the same action?
If you case is the first then a plugin pattern solve it.
In the latter case a strategic pattern could be more useful.

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Jan 31 '06 #3

P: n/a
Hi Ignacio,

Basically, the STANDARD version of this program should provide X number
of functionalities.

Customer A might like the standard version and would have all of X
number of functionalties, while Customer B will only need (X - N)
number of functionalities. But what happens in the case when Customer C
don't like just 1 or 2 of these functionalties and want us to replace
it with a modified version of functionalites? How could I just update
these "pluggable" modules so that it everything else stays the same,
except those 2 functionalities? Or what if I want to add 3 NEW
functionalities in addition to this X number of standard
functionalities? Is there a design pattern for that?

Jan 31 '06 #4

P: n/a

<pi*****@gmail.com> wrote in message:
Hi,
I'm not an expect in .NET, so would anyone know an answer a design
pattern for the following?
There are many customers that require minor customizations to the
program I will be developing. I would like to reuse the majority of
the functionality of this program since each customer is only
requiring certain changes to this program.
Is there a way to design this so that the main base, skeleton of the
program is seperate from the customization and the different
customizations can be loaded like a snap on module? Sort of like a
SNES game system, and each cartridge makes the console provide a
differnt type of service? Is there a design pattern for this?


Polymorphism is the concept you'll use. Many, if not all, of the design
patterns in GoF use polymorphism.

Isolate the parts of your application that will change and represent
those parts as interfaces. Have the "main base" refer to these
interfaces instead of concreate implementations. This way, new
implementations can be plugged into your framework without changing the
existing code.

Now, the solution I've just given is necessarily general and broad. Look
through GoF and study each design pattern. Some may be applicable to
your situation. You could start with the Template design pattern. Hope
this helps.

Jan 31 '06 #5

P: n/a
Hi,

Customer A might like the standard version and would have all of X
number of functionalties, while Customer B will only need (X - N)
number of functionalities. But what happens in the case when Customer C
don't like just 1 or 2 of these functionalties and want us to replace
it with a modified version of functionalites? How could I just update
these "pluggable" modules so that it everything else stays the same,
except those 2 functionalities? Or what if I want to add 3 NEW
functionalities in addition to this X number of standard
functionalities? Is there a design pattern for that?


You just use a plug in structure, take a look at
http://www.yoda.arachsys.com/csharp/plugin.html for where to start.

You can have in a config file what plugin you need to load.

In case that you need to change functionality of the same module you have to
decide what to do depending of your situation, if you have a small number
each for a particular client then you could simply consider them as another
plugin, if you have a number of variation of one module you could use a
Strategic pattern

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Jan 31 '06 #6

P: n/a
Hi Ignacio and Leslie,

Thank you very much for your replies.

Does it make a difference if the desired final result is for these
custom modules to be (in PC Hardware terms) hot swappable? The skeleton
of the application should be running constantly without shutting off. I
would literally like to just drop the customizations into a specific
folder and the app should be able to run that specific customer's
customization. All these customizations would be running from the same
application (I'm not actually repackaging for different clients).
Basically, just one application would be processing different
customizations simultaneously.

Jan 31 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.