is there a “Data Conversion Object” principle/patt

Question

I recently had a question regarding String Object with fixed length C# . (Please read this question first)

Some of the answers, which were given, pointed out that my design might be flawed.

Since the last question was about Strings with a fixed length this one is about the underlying principle. This question might be a little bit long so pleas bear with me.

Requirements:

I have a plain textfile with values in it with a specified fixed length. The standard for this textfiles is from the 90's. I have to create such a file.

1. A File may contain 1-60 Rows.
2. There are 10 different types of Rows.
3. A Row has between 10-40 values.

A Row is specified like this:

Back in the 90's there was an application which created those files placed it on a Server and the server then read the File and did something with it like writing it to the database or informing somebody that something went wrong etc.

This application isn't usable anymore due to recent legal changes.

Suggested design

The new Application that is in its place doesn't provide any data in the form of an export but it has a database with the values inside. I have the responsibility to write a converter. So I have to get the data and write an exported text file. The Data is only send and never received !

Question

Since a A DTO's only purpose is to transfer state, and should have no behavior(POCO vs DTO) Is there something like a "Data Conversion Object" which has the purpose of converting data which is transfered ? Is there a design pattern which is applicable ?

Answer 1

I recently designed a solution for a similar problem, though my solution was in SAS language, which is not Object-Oriented. But, to me it seems that the problem is pretty much the same. Now, lets dissect the problem:

The problem:

1. There are some plain text files.
2. These files have specification, about the layout, fields, types etc.
3. These files need to be converted to some other format.

Solution (Objected-Oriented): I would define three classes, PlainTextFile, Specification, Output, and a Reader Class.

Specification: Contractor takes an specification (probably it is stored in a file or so), and parses that into an Specification object.

PlainTextFile: This can be handle to a text file, or a wrapper around the handle if some other feature is added to it. I prefer the second option.

Output: This is the output you would like to produce.

Reader: It takes two inputs, PlainTextFile and Specification. Uses Specification to read and parse the PlainTextFile and write the output in the Output object/format.

Now, the output can be the final step or not. I suggest, that the Reader do only this much. It you want to write the output to a database, or send it somewhere, create another class to do this.

Remember, I don't know what the name of this pattern. Actually, I don't think that matter much. For me, this method solved a problem that existed in the company for a decade and it integrated two of the most used systems there.