(note) I would appreciate help generalizing the title. I am sure that this is a class of problems in OO land, and probably has a reasonable pattern, I just don’t know a better way to describe it.
I’m considering the following — Our server script will be called by an outside program, and have a bunch of text dumped at it, (usually XML).
There are multiple possible types of data we could be getting, and multiple versions of the data representation we could be getting, e.g. “Report Type A, version 1.2” vs. “Report Type A, version 2.0”
We will generally want to do the same thing action with all the data — namely, determine what sort and version it is, then parse it with a custom parser, then call a synchronize-to-database function on it.
We will definitely be adding types and versions as time goes on.
So, what’s a good design pattern here? I can come up with two, both seem like they may have som problems.
Option 1
- Write a monolithic ID script which determines the type, and then
imports and calls the properly named class functions. -
Benefits
- Probably pretty easy to debug,
- Only one file that does the parsing.
-
Downsides
- Seems hack-ish.
- It would be nice to not have to create
knowledge of dataformats in two places, once for ID, once for actual
merging.
Option 2
- Write an “ID” function for each class; returns Yes / No / Maybe when given identifying text.
- the ID script now imports a bunch of classes, instantiates them on the text and asks if the text and class type match.
- Upsides:
- Cleaner in that everything lives in one module?
- Downsides:
- Slower? Depends on logic of running through the classes.
Put abstractly, should Python instantiate a bunch of Classes, and consume an ID function, or should Python instantiate one (or many) ID classes which have a paired item class, or some other way?
You could use the Strategy pattern which would allow you to separate the logic for the different formats which need to be parsed into concrete strategies. Your code would typically parse a portion of the file in the interface and then decide on a concrete strategy.
As far as defining the grammar for your files I would find a fast way to identify the file without implementing the full definition, perhaps a header or other unique feature at the beginning of the document. Then once you know how to handle the file you can pick the best concrete strategy for that file handling the parsing and writes to the database.