Is this strategy pattern?

Question

A little background:

In the system I am developing, there are various types of CSV files to be read and saved the contents in different database tables. Since this is about changing behavior based on inputs, I studies the decorator, and strategy patterns and came up with the following solution for my system.

First I created following interfaces.

• ICDRMapper reads each line from a given CSV file and maps to a object after running validations/modifications (if any). There are many concrete implementations for each CDR type.

• ICDRReader takes the input CSV file and reads each line and pass it to the mapper. Each reader implementation is decorated with MEF metadata so that the ICDREngine can locate the correct one on the fly. This interface also has many implementations for each CDR Type.

• ICDREngine implementation uses MEF metadata to locate a matching ICDRReader implementation. This usually has only one implementation.

Then, I have created a AbstractCDRReader and AbstractCDRMapper and used decorator pattern to delegate specific implementations to different concrete classes.

AbstractCDRReader selects the correct ICDRMapper implementation based on MEF metadata just like the engine does.

Following is a generated class diagram.

So my questions are,

• Is this strategy pattern or a different one?

• Is there any way I could improve this design so that next time I need to read a whole new different CSV file, I can do the implementation very quickly?

Answer 1

Choosing an architecture should not be too much about design pattern but rather about logical thinking. Do you feel that what you have come up with is easily extendible for new types of CSV files? If you do than forget about which pattern it is and be sure you can stand up for your design and you are able to explain the decision to team-mates.

That being said, it can very well be the Builder pattern. It's not obvious from the schema what the resulting product of mappers is but I think that the builder could be applied.

Basically, AbstractMapper is the Builder part, concrete mappers are ConreteBuilders and there surely is some Director in your architecture as well. It even sound like the builder. "I have an input data. I need something responsible for parsing it based on various parameters and create a product used inside the rest of my application." And when you think about it, you are basically building something, taking unfamiliar data and building known objects - it leads to creational patterns.

As for the readers, it could be the same, it could by the strategy or something else. It depends how you think about it and what it is actually doing.

Answer 2

You've described the architecture of a part of a system. It uses few design patterns:

• abstract factory (ICDREngine the process of creation concrete implementations of ICDRReader, ICDRMapper),
• 2 implementations of Strategy patern (ICDRReader, ICDRMapper hierarchies),
• you also mentioned Decorator (though I don't see it from the class diagram - it is either incomplete or you misunderstood what is called Decorator).
• The relation between Mapper and Reader hierarchies represents Bridge pattern if I'm not mistaken.

As for me your architecture looks good and flexible. I'm not sure what you expect to improve for easier adding ability to read new CSV format - currently all you need is add new implementation of ICDRReader, don't you? So it is easy enough from my point of view and nothing should be improved for this particular 'problem'.