Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager).
One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
