Donald McLean's Suggested Refactorings

Issue: SynPhot object

Question: Why does each instrument have its own SynPhot?

The answer appears to be that someone was thinking that there might be seperate SynPhot servers for each instrument. This appears to be an unnecessary generalization that we can refactor out, simplifying several things.

Even if each instrument DID need its own SynPhot settings, the best way to do it would be to change fMasterSynPhot back to a non-static object, put the SynPhot parameters back in the instrument model dat files, but have SynPhot's initFromResources handle them.

Files affected:

SynPhot.dat
- New file
ACSInstrumentModel.dat
- Remove SynPhot parameters
STISInstrumentModel.dat
- Remove SynPhot parameters
Wfpc2InstrumentModel.dat
- Remove SynPhot parameters
HstInstrumentModel.java
- Removed code to read SynPhot parameters
- Made fMasterSynPhot a static variable
SynPhot.java
- Added initFromResources
- Removed hard coded parameters in constructor

Issue: Spectroscopic Mode

In InstrumentModel there is a function "isSpectroscopySupported" which returns true by default. In Wfpc2InstrumentModel, this is overridden to return false.

This should really be a .dat file parameter.

Does ACS even have an instrument mode? If not, then the ACSInstrumentMode object is incorrect and should also have overridden this function.

Files affected:

Wfpc2InstrumentModel.dat
- Added line for SpectroscopySupported equal false
ACSInstrumentModel.dat
- Added line for SpectroscopySupported equal false
STISInstrumentModel.dat
- Added line for SpectroscopySupported equal true
InstrumentModel.java
- Added fSpectroscopySupported
- isSpectroscopySupported now returns fSpectroscopySupported
- initFromResources now looks for a "SpectroscopySupported" resource
WFPC2InstrumentModel.java
- Removed isSpectroscopySupported since its now handled in parent

Issue: Instrument SynPhot parameters

Considering that the general SEA approach is to put things in the XML files rather than hard code them, I can't imagine why they didn't do this with the three SynPhot parameters (mag form, instrument name, spec elem).

Files affected:

HSTInstrumentModel.java
- Added three string variables for these attributes
- Changed the accessors for these to return the string variable (instead of being abstract functions)
- Changed initFromResources to get the values of the strings from the resource file.
ACSInstrumentModel.java
- Removed the three accessor functions.
Wfpc2InstrumentModel.java
- Removed the three accessor functions.
STISInstrumentModel.java
- Removed the three accessor functions.
ACSInstrumentModel.dat
- Added values for the three parameters
WFPC2InstrumentModel.dat
- Added values for the three parameters
STISInstrumentModel.java
- Added values for the three parameters

Issue: Create Instrument Behavior

In the HSTInstrumentModel classes, the create instrument call creates an instance of HSTInstrument and then performs two calls to set the detector and filter to hard coded values. Putting these values into the .dat files would allow the create instrument call to be moved up to the HSTInstrumentModel base class.

Files affected:

HSTInstrumentModel.java
- New createInstrument call
- Strings to store default values
- initFromResources reads values
ACSInstrumentModel.java
- Remove createInstrument
STISInstrumentModel.java
- Remove createInstrument
WFPC2InstrumentModel.java
- Remove createInstrument
ACSInstrumentModel.dat
- Add default value strings
STISInstrumentModel.dat
- Add default value strings
WFPC2InstrumentModel.dat
- Add default value strings

Issue: Nearly obsolete classes

As a result of the previous refactorings, the WFPC2InstrumentModel class and the ACSInstrumentModel class now have only one member function remaining - the constructor with a call to super with a hard coded object name and XML file path. By making a couple of minor changes to the "Resource" class's buildResourceable method to look for and use a "ResourceFile" property, I was able to completely remove these two classes. Note that the STISInstrumentModel class has two non-trivial functions so it can't be removed just yet.

Files affected:

Resources.java
- Expanded buildResourceable
HstObservatory.dat
- Added resource file names for the instruments
ACSInstrumentModel.java
- This file is now obsolete and can be removed.
Wfpc2InstrumentModel.java
- This file is now obsolete and can be removed.