Looking for a good way to handle string parsing

Hi!

I am currently looking at an old .NET 1.1 system, which is a "broker" of sorts, that recieves from a remoting endpoint string values that come from bar code scanners. The code is a horrible mess with so much diferent parsing methods, nestled if statements etc etc that it is impossible to understand what is going on. And there are no nit tests of course, everything is pretty much in a single static "helper class", plus there is some bits of parsing going on in the scanner clients as well. Now, the system handles 4 different bar codes, and now there is a request for 8 more. And the system as it is now is impossible to build upon. Now here are the requrements.

1) The system should accept "ANY" scanned string from the barcode scanner (could be from a milk package label).

2) First the ssystem should validate the string so it is indeed a valid barcode (possibly by checking the first 2 characters, as it is today)

3) Next the system should indentfy the TYPE of barcode (each type of barcode is identified by the first 2 characters (AB, AA, CC, DK, XX etc)

4) Each barcode contains data based on position, and each barcode has a specification (from an old mainframe system that prints the barcodes).

5) The system should "process" each barcode, attempting to parse the string according to specifications, and create an object/entity/model based on this string. The object should then be stored in the db, and the barcode client polls the db and should get a "pop" when the scan is validated.


Now, my question here is, obviously this can be extremly messy with lots of substrings, pads, indexofs etc etc so what is the best way to handle scenarios like this? When dreaming about different classes, I can see:

BarCodeFactory
BarCodeBase
AABarCode
XXBarCode
BarCodeValidator

the raw string is passed to the factory where some basic validation occurs to see if it is even a valid bar code by using the Validator class, and if that is the case, the factory determines what kind of barcode it is, and sends the string to a constructor of say XXBarCode and then it is up to this class + base class to try and figure out how to extract the values from the string and populate itself.

Is this a good approach in terms of OO and design?

/S

Would it be possible to have a single entry point function that receives the scanned string and does the basic validation and then have a dictionary of string and function delegate where the string key is the first two characters of a valid barcode and the functions beeing implementations of the different type specifications that get the scanned string as input parameter and return a "object/entity/model based on this string" (your words) of some generic interface definition?

What is different about each code (I'm going to refrain from calling it a bar code, since that's basically a specialized font, by the time your app is processing it, it's just a string, no different if it was entered from the keyboard) that you think you need a different class for each one? why not just have an enumeration value that describes the type, and then have a class with a property of that enum type? I haven't seen anything described so far that would warrant a different class for each type.

-tg

I believe each bar code class would implement it's own parsing logic.