Re: Advice on dealing with a legacy file format
The Frog wrote:
Nice tool, thankyou for sharing this with the world. Looks like it is
up to the task of reading the file itself, but I still have no idea
how to feed some form of structural information to an app so that it
can build objects from that structural data and populate the members /
fields with the values in the data file. I have sniffed around
serialization but am not sure if this is the way to go, or perhaps
there is a 'better' approach.
As I see it, the package will evolve with the evolution of the data
files themselves. As a new format becomes available / known, some form
of descriptive document is added to the package that allows the
package to correctly interpret the data file and build appropriate
objects. I am just not sure how to approach this last part. Is there
anything you can point me to that might help me solve this?
Your questions are the logical guideposts for your next iteration. You are
showing good software design sense.
Forgive my taking a side topic here, but often it pays big benefits to
consider a problem in holistic terms and let analysis control your thinking.
Instead of considering implementations - serialization, CSV, a 'better'
approach (how can you even tell?) - without understanding the behavior these
specific implementations must support, document the behavior itself.
For your application I would draw a state diagram, among other things.
Based on that diagram, I'd write a code framework - I wouldn't pick libraries
to support an unwritten code framework for an undocumented algorithm.
To support the framework you likely will benefit most from a lower-level
library that does part or most of what you want, but not all, encapsulated in
custom code that handles the particulars of your situation, matching your
state diagram and other documentation.
Your approach to understand candidate libraries, and to iteratively refine
your solution, is a good one. But there is no one-size-fits-all 'better'
approach independent of the purpose at hand. Your situation is one for which
the 'better' approach is to analyze and document the problem in detail prior
to coding, and to consider custom code in the mix.
That's a pattern for you to solve your own problem rather than a solution to
your problem. Others in this thread have already excelled at suggesting
particulars; my aim is to describe literally what you asked for, an approach.
--
Lew