OO app design advice wanted - oop

Question

I've inherited an application that accesses several websites and parses HTML to store data locally.
The HTML parsing is a breeze, but in an effort to make it easier to add additional site "parsers" in the future, I'm working on the overall design.
The area that I'm struggling with is how to encapsulate the parsing and data "conversion" or "mapping" for each "parser" so that I can create a standard convention for adding new ones.
The overall structure is as follows:
-- A scheduled task kicks off every 15 minutes, and runs what is essentially a method in a central controller.
-- The system loops over a list of "parsers" that are to be executed
-- Each parser goes to its specific site and downloads the page and parses it for data
-- The "columns" of data from each site do not "line up" with the local database table, so a translation of sorts needs to happen
-- after translation, the data is stored locally.
My initial thought was that each parser should return ONLY a recordset representing THAT site's data, after which some other translator
should turn that into a recordset that is then stored locally. But because it would be different for each site, i quickly started leaning towards each parser actually returning the same thing -- a properly formatted (by local database schema standards) recordset ready for storage.
The prior version of the app actually had each parser writing to a csv file, which was then used to import the data. The designer was doing something close to the way I'm leaning, only I believe all of this can be done in-memory without writing to a CSV file.
So should each parser have the job of retrieving the data and creating a generic locally-relevant recordset for storage? If the local database structure changes, each parser would have to be touched, and touched pretty deep. If I had a mappng "convention" at the start of each parser that said which column numbers from the remote site map to which column numbers of the local site, then when one or the other changed, it may not be quite so difficult to update all the parsers, and creation of new parsers would be easier as a "format" for the structure of them would already be in place.
OO-wise, I envision having a ParserBase object, which each specific site would extend (ParserVendorX, ParserVendorY, etc). The base (or perhaps abstract) parser would define all the methods that must be in each specific parser, and off the top of my head I'd say the following private methods would be required:
retrieveData
parseData
translateData
and the only public method might be "getData" - which would simply return a recordset for a data object to use for storing the data in the database.
So I'm looking for either a recommendation on a pattern that might apply here, and/or real world solutions others may have implemented for projects similar to what i'm working on.
For the record, I'm purposely not mentioning which language I'm working in unless it's absolutely essential... this is a high-level question so someone's solution in any other language would still be considered relevant.
Thanks!

Answer 1

As a start have a look at the Strategy Pattern
The strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable
In your case you would have a family of parsers and many implementations that do different things.
For example:
public interface BaseParser
{
bool Parse(SomeRequest request);
}
With many implimentations:
public class Html5Parser : BaseParser
{
public bool Parse(SomeRequest request)
{
... does stuff
}
}
public class XHtmlParser : BaseParser
{
public bool Parse(SomeRequest request)
{
... does stuff
}
}
Then you could execute them like this:
foreach(var parser in ParserList)
{
parser.Parse(myRequest);
}
As for what to do within each one, apply the single responsibility principle from S.O.L.I.D
and you should be able to figure it out, just neatly encapsulate each piece of work into a seperate component to make up the whole.