Selecting the right design pattern

Question

I've a consolidated product xml that I receive by making an API call.Xml contains data for various products like P1,P2,P3,etc. I need to write a windows service in which I'll make this API call, parse the xml and then break it into three separate xmls..i.e.one for each product P1,P2,P3....etc. The business rule for parsing the xml for each of the products could be different.

In the future,I may need to break the same input xml into new additional products P4,P5 etc.

I can think of Strategy design pattern to address this problem so that the code is maintainable, easier to test and extensible in the future. Would this be the correct pattern to apply here please?

Thanks.

Answer 1

@hasen sure, it makes sense to start with simple straight forward design, but starting with (probable) good design will save efforts.

I feel Chain of Responsibility (COR) might be a good pattern for this kind of requirement. I suppose data is coming from (probably sequential) xml parser. We pass the data (tags) stream to the chain of tag handlers where each handler in a chain is capable of handling one type of object (or part of it). each tag either handles it or passes it further to provide opportunity to others.

This chain being formed at run time, it is flexible to reorganize itself depending upon new tags and products with additional handlers and there by providing extension point.

This may need some additional capability of keeping memory to be handled (possibly through delegation) by few (meta) tag handlers.

Though i haven't imagined full design, COR looks to be a better candidate for it.

Answer 2

Don't apply any design patterns prematurely.

Write the most straight forward code that works and is easy to read.

When future requirements arise, you can come back and revisit the code. As long as it's written in a clear and straight forward fashion, it will be easy to see what's the common pattern that can be applied to cleanup the code and make it easier to read.