Generic way to load resources

Hi,

I am currently developping a program that uses files to store data. There
are different sorts of data: preferences about the program, high scores
(it 's a game) and document data (the main data of the program - a
game-map in this case).

My problem is the following: how do I create an object-structure to load
data from files in a flexible way? With flexible I mean:
- When I change the file-format, I need to hack in as less classes as possible.
- When I migrate from files to a database in the future, it must be easy in my
design.
- When I add extra data in a later version of the program, or support different
file formats for the data, it must also be possible.

I tought that the 'abstract factory pattern' could be a solution for my
problem. I make an 'abstractdatafactory' object and for each data-format a
'concretefactory'. Each 'concrete factory' will implement the abstract
method 'loadData(file : String) : Data' of the 'abstract factory'. Is this
a good way to load data? And is it also permitted to put the 'save part'
in the factory classes?

Has sombody proposals to solve this problem? Any kind of tips or tricks
are appreciated.

Greetz,

Jan Meskens
Student Computer Science

"Knolselder" <knolselder2003@hotmail.com> wrote in message
newsan.2005.11.14.19.38.22.364759@hotmail.com...
> Hi,
>
> I am currently developping a program that uses files to store data. There
> are different sorts of data: preferences about the program, high scores
> (it 's a game) and document data (the main data of the program - a
> game-map in this case).
>
> My problem is the following: how do I create an object-structure to load
> data from files in a flexible way? With flexible I mean:
> - When I change the file-format, I need to hack in as less classes as
> possible.
> - When I migrate from files to a database in the future, it must be easy
> in my
> design.
> - When I add extra data in a later version of the program, or support
> different
> file formats for the data, it must also be possible.
>
> I tought that the 'abstract factory pattern' could be a solution for my
> problem. I make an 'abstractdatafactory' object and for each data-format a
> 'concretefactory'. Each 'concrete factory' will implement the abstract
> method 'loadData(file : String) : Data' of the 'abstract factory'. Is this
> a good way to load data? And is it also permitted to put the 'save part'
> in the factory classes?
>
> Has sombody proposals to solve this problem? Any kind of tips or tricks
> are appreciated.

No particular (set of) design patterns immediately jump to mind. I think
you just need to have a good division of responsibilities.

Have one class (or set of classes) that takes care of getting a stream
of bytes. For example, this class might simply be given a string that
uniquely identifies the resource, and then gets the stream of bytes that
make up the resource. Then, when you switch from files to DB, only this
class needs to change.

Have another class (or set of classes) that takes care of building
instances of objects based on byte streams that they are provided. That way,
when the file format changes (or new data is added), this is the only class
that changes.

For saving, reverse the process: Use the latter classes to convert a
live object into a byte stream, then use the former classes to store that
bytestream either to the disk or the DB as appropriate.

- Oliver

The use of the factory here, is a good decision. I can see that your
current problem is to make the file evolve with time. What you'll need
for this is a better file format. Take examples from XML. XML is very
good for a file that can change with time and still be supported. In
other words, it's not hard to create a XML version of a file that work
with both older and newer version of a software.

By seeing this, you'll probably say: yeah, but I don't want to use XML
to save things up. People could modify it or .....

Yes I agree. Don't take XML! But take the concept. Just try to
understand what is so special with XML...

iscy

"iscy" <iscy@claurendeau.no-ip.com> wrote in message
news:1134322742.703378.68030@g14g2000cwa.googlegroups.com...
> The use of the factory here, is a good decision. I can see that your
> current problem is to make the file evolve with time. What you'll need
> for this is a better file format. Take examples from XML. XML is very
> good for a file that can change with time and still be supported. In
> other words, it's not hard to create a XML version of a file that work
> with both older and newer version of a software.
>
> By seeing this, you'll probably say: yeah, but I don't want to use XML
> to save things up. People could modify it or .....
>
> Yes I agree. Don't take XML! But take the concept. Just try to
> understand what is so special with XML...

The secret behind XML's extensibility is the behaviour of "Ignore tags
you don't understand".

- Oliver

This is not really what I tried to mean...

iscy