Hi Ian,
I am not answering for Jeroen - hopefully he will come back and give his own answers. But my take on Jeroen's comments is:
Having the Data class as a Proxy, or having it as a Facade, allows us to keep the idea of having each class having a distinct set of responsibilities.
So the MetaData class is responsible for handling anything to do with metadata. The DataFile class is responsible for handling anything to do with the data file itself. There may also be seperate classes that just handle locking. Finally the Data class is responsible for providing access to all the other classes.
I suspect that the MetaData class and the DataFile class will only allow package level access, forcing users to go through the public methods of Data class to get access to the data.
Since we have division of responsibility, I know that if I need to look at something to do with the meta-data, I will go to the MetaData class. I will not need to look at several hundred lines of code that are specific to data-file access, since they are off in their own class.
In eXtreme Programming, one of the recommend practices is to try and avoid the use of the
word "AND" when describing a class or method. As soon as you have to use the word AND, there is the
potential that your class or method may be doing too much, and should be refactored. As mentioned a paragraph ago, this might only have the benefit of removing extraneous code (which makes your code easier to read / maintain), but it might also result in fewer cases where unrelated sections of code affect each other in unexpected ways just because they are within the same class and have access to everything else within the class.
The Data class provided by Sun is a classic case where you might want to look at having either a Proxy or a Facade (and what the differences are, and which to use is a seperate discussion). If Data class does everything itself, then you have one large class that contains all the locking code, AND all the data access methods, AND all the meta-data handling, AND all the schema handling. Just refactoring into an additional two classes - one for lock handling and one for anything related to the file - will result in much cleaner, simpler to understand code.
Hope this gives you some idea of why you might want to split classes.
Jeroen - time for you to shoot holes in anything I got wrong in general or in my interpretation of your specific comments
Regards, Andrew