My project contains a lot of classes, a bunch of which can be described by XML files. Don't worry, it's not the logic or implementation in XML. It's a game, and an example would be that a game tile can be defined in XML, the image file, animation frames, etc.
I'm going to end up having a bunch of functions that look like this:
public static Foo FromXml(ref XmlTextReader reader) { ... }
The question is this: should these functions be contained in their own matching class, for example the one above would be Foo.FromXml. Or, should I make a separate class for reading things from files? There seem to be two general guidelines competing here:
- A class should to know everything about one thing - itself.
- A class should only have one reason to change.
First of all, I don't really understand the second one, because "reason" is quite vague. The first guideline suggests put each reader in the related class. The second says to make one class dedicated to reading xml files. But the pros and cons are debatable. On the one hand, each class could contain its own reader, so there aren't a dozen classes referenced. On the other hand, every class would have to include System.Xml, and if I change my xml format, things could change in multiple files (but I don't think that's too bad).
I know the most important rule is "use your brain" and there is no such thing as a "correct" solution, only a good and working one. So what do you think would be more readable, or better yet, maintainable?
edit: to clarify, the classes can be totally unrelated. Since it's a game, one may be the sprite animation class, one may define enemy behavior, one might define the map layout or properties. So inheritance has nothing to do with this.