Decorater pattern or strategy pattern

Question

I'm constructing a c# serverside application and I'm trying to do this in a way it can easily be maintained aswell as extended if needed.

So what we have is 4 different requests that need to be done (SOAP, HTTPREQUEST and so on). These are then to be combined with a chunk of different actions like Importing/Exporting/Updating.

What I'm thinking is that every request should be a strategy, much like the switching algorithms description for the strategy pattern. Then I want to extend the strategy with a decorator, adding new functionality to the request. Is there a need to contain this in a separate class(SoapRequest_Import/HTTPRequest_Update) or how should I think? Last one about containing everything in a class seems to take away the flexibility?

So with that said, am I wrong? First question, is this done better with each of the patterns or is it okay to combine them. I was thinking strategies for the different clients, and decorators for the commands(or added functionalites). Or am I just overdoing this?

Lastly how would it look codewise if I did combine them. I do understand that I need at least one interface for the decorators. Do I need one for the strategies too?

Answer 1

Stop thinking in terms of specific patterns. At least stop looking for places to apply patterns. Start thinking in terms of separation of concerns, and if that leads you back to a pattern, so be it.

You have two different groups of concerns there. The communication interfaces (Http, Soap, etc) and the data interfaces (Import, Export, Update, etc). Your goal should be to separate those concerns as completely as possible.

That is, imagine that you need to add 100 more communication protocols and 100 more data actions. Would it be better if you could do that by writing 200 more classes or would you expect to have to write 10,000 classes? If you're answering "10,000" then you're thinking about it all wrong.

So what you need is a framework that hooks everything together. Take messages from some kind of communication protocol, without knowing which protocol, and route these messages into actions that write to a data source, without ever knowing where the message is coming from or why it has been sent to this action.

Now, stretch your mind a little bit and this is starting to sound like a problem that's already been solved.

• Data Source = Model
• Communications protocols = View
• Actions = Controller
• Routing = well ... routing

Take a look at MVC frameworks. One of them may actually suit all your needs, or at least allow you to extend the framework to suit your needs. If not then look at the patterns used by an existing framework, see what you can learn and reapply in your own framework.

In places, I'm sure, you will recognise all sorts of GoF patterns. I'm certain there will be adapters, factories, maybe strategies. But the overall problem you're trying to solve is a problem that MVC at least partly resolves (for example, you can route web page requests and Json requests to the same methods in a controller).

So that would probably be a good place to start researching. But, ultimately, the problem you're trying to solve is separation of concerns, so that the extension of one concern doesn't heavily affect existing code in the other concern.

So keep that in mind throughout.