..that you write a parent class from which the actual storage mechanisms will inherit. IOW, you write an interface and set that in stone. Then you write a tool which implements that interface, whether that be XML, flat-file, database, what-have-you. If someone else wants to implement the same set of operations with a pickle storage mechanism, they are welcome to do so. The rest of your program only needs to know that, when it's time to save state to disk, it calls childclass.saveGame() or equivalents. Since each possible way-of-saving uses the same interface (i.e. - the same set of methods and properties, which they inherit and override from the parent class), the rest of your program doesn't need to care which storage mechanism is used. This is a common design pattern, and allows you to:

1) Write the rest of your program without forcing it to "know" how data is stored,
2) Have multiple storage mechanisms in the same application,
3) Solicit multiple mechanisms from multiple programmers, at various times in the project lifecycle (even after it's released),
4) Write temporary classes which allow you to test the functionality of other parts of the app before you've finished coding the storage mechanism,
5) I could go on and on. I'll stop now.

In the design of an application, whenever you ask yourself, "which way should I implement this?", the first answer that comes to your mind should be, "all ways". Then you can pare down from there. :)