Emmanuel Bourg wrote:
Indeed, as I explained, once you write
new MyConcreteLocator("basepath", "file")
The locator is no longer a strategy to locate the file, it becomes an object defining the location of the file (i.e it could replace the URL). The same strategy should also be reusable for several configurations, and this is not possible once the file name is bound to the locator, the locator must remain "stateless".
Emmanuel Bourg
I am not convinced that a Locator must be stateless. In fact my view was that a Locator serves as a replacement of the URL.
With this stateless strategy approach you will always have problems to define the correct interface. ATM your locate() method expects a file name. What if a custom Locator implementation needs more information? Then the Locator must be initialized separately and cannot be shared between Configuration objects. Or you use some cryptic encoding in your string parameter.
So why not keeping all information to locate a configuration source together in one object? If the name Locator does not fit any more, how about ConfigurationSource or something?
I still think that a Locator could be useful for saving, too, because sometimes creating the output stream is part of the locator strategy, e.g. if a DirectoryLocator needs to create the desired directory structure if it does not exist yet.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
