The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design Question.

I have a situation here, and I am looking for the best possible design option.

I have a properties reader class, which must behave differently when invoked by (a) The configuration Utility and (b) the application.

When invoked by configuration utility, it must permit for the props file not being there, since it may be the first run of the configuration util.

When invoked by the application, it must throw an exception if the props file is missing.

I was thinking of two constructors, the default starts it in "application mode", and a second constructor accepts a MODE - the config mode.

This approach will accomplish my job, but something about it doesn't feel right.

Thursday, September 07, 2006
The configuration utility presumably will write the properties file? Then the configuration utility should use a PropsWriter which assumes the file may not exist. The PropsReader should always assume it exists.
son of parnas
Thursday, September 07, 2006
There are several ways you can do this. You've described one.

Other options include:

* Use a virtual function for handling the error case. Then derive two subclasses: one which throws an exception, and the  other that works without the file being present. Use the appropriate concrete class in each context.

* Pass in a strategy object to your constructor that has the right code in it to handle the error case.

* Isolate the file access into another class. Create two implementations: one that can handle the file being missing, one that can't. Let the propertyreader work though this other class.

There are many options. Which one is best for you depends on a lot of other factors.
Chris Tavares Send private email
Friday, September 08, 2006
This is not exactly a "solution", but why throw an exception when you know there is alternative code to do configuration? Why not call the code that allows the user to create a configuration file and give him some feedback to the positive like, "Your properties file does not exist. <App> will create one now. [OK]" (or something on that lines).
Sarat Pediredla Send private email
Friday, September 08, 2006
I would only have one constructor and just throw the exception if the file isn't there. The result being that the configuration utility is smart enough to actually catch and handle the exception and the regular application just reports it.

This is what exception handling is supposed to do. You usually don't catch exceptions within the application unless you intend to do something about it. In your case, the configuration utility should catch it and then go down a slightly different path with the knowledge that no config file was present.

Having two different constructors or throwing an exception in one case but not the other is probably wrong because it moves the state handling into the properties object itself. The properties object should not care how errors are handled or even who is calling it. It's sole job should be to locate/load the file and throw an exception if it is not there. Period.
Friday, September 08, 2006
Since the distinction is a variation in behavior, maybe it would make sense to derive two subclasses, one for each case.  You can control the visibility of each subclass so that it is available, as appropriate, to the individual clients.
Another option
Saturday, September 09, 2006
I agree with anon.

The properties object shouldn't know anything about who is calling it or what they expect. If the file isn't there the properties object should always just throw an exception. It is the caller's responsibility to decide what to do with the exception. In the case of the configuration app, it should create a new default property file. In the case of the application, it should show an error and exit.

Google for "separation of concerns". Whether or not an application continues when a properties file is missing should not be a concern of the properties object itself. It should only be a concern of the calling application.
dood mcdoogle
Sunday, September 10, 2006
Here is my 2 cents.

Why would you want the application to choke on the file being missing?  I would use that as a chance to load up the config editor and let it handle it.  I would not want the application to have to crash because a file is missing.

What if the user accidentally deleted the file?  What if the user started the application before the config editor (even though you state again and again in all the docs to launch the config editor first, users dont read docs).

Tuesday, September 26, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz