Great circle, PCA, MDF etc. have consistent behaviour for export (get headers, get blank fields, get field strings) but without a formal interface. Partly as a result, the "export sample calculations" code is a bit of a mess. Especially now that Java 8 allows default and static methods in interfaces, this can and should be fixed. Interface could contain something like:
java static List<String> getHeaders();
List<String> getFields();
static List<String> getEmptyFields() { /* default implementation calling getHeaders(), rather than the current duplicated implementation in every instance method. */ }
I'm not 100% sure that a static default getEmptyFields() will be able to access the getHeaders() of the implementing classes, but in the worst case I could just make it an instance method… albeit that leads back to the problem that we need getEmptyFields() precisely when we don't have an instance.
Perhaps it's time to implement the Null Object Pattern here (in which case getEmptyFields() becomes redundant). Java 8's Optional is another possibility, but I'm not sure that it would solve the problem.
I could pair this with a general interface for retrieving calculations in Sample. Something like
Not sure if that's quite the right syntax, but the idea is to pass e.g. GreatCircle.class as a parameter and get the stored object of the appropriate type, if any. If it's absent, maybe this is the right place to return a Null object (concocted on the fly, probably) for which getFields() returns the appropriate number of empty strings.
The more I think of this, the more I reckon Null Object is the way to go. A Null Object doesn't have very appropriate semantics for the case of a calculation in general (e.g. what direction should a Null PCA return?) but if the interface is restricted to the string-export bit, that shouldn't be a problem. In fact, the interface shouldn't be called Calculation, it should be called something like RepresentableAsListOfStrings.
Great circle, PCA, MDF etc. have consistent behaviour for export (get headers, get blank fields, get field strings) but without a formal interface. Partly as a result, the "export sample calculations" code is a bit of a mess. Especially now that Java 8 allows default and static methods in interfaces, this can and should be fixed. Interface could contain something like:
I'm not 100% sure that a static default getEmptyFields() will be able to access the getHeaders() of the implementing classes, but in the worst case I could just make it an instance method… albeit that leads back to the problem that we need getEmptyFields() precisely when we don't have an instance.
Perhaps it's time to implement the Null Object Pattern here (in which case getEmptyFields() becomes redundant). Java 8's Optional is another possibility, but I'm not sure that it would solve the problem.
I could pair this with a general interface for retrieving calculations in Sample. Something like
Not sure if that's quite the right syntax, but the idea is to pass e.g. GreatCircle.class as a parameter and get the stored object of the appropriate type, if any. If it's absent, maybe this is the right place to return a Null object (concocted on the fly, probably) for which getFields() returns the appropriate number of empty strings.
The more I think of this, the more I reckon Null Object is the way to go. A Null Object doesn't have very appropriate semantics for the case of a calculation in general (e.g. what direction should a Null PCA return?) but if the interface is restricted to the string-export bit, that shouldn't be a problem. In fact, the interface shouldn't be called Calculation, it should be called something like RepresentableAsListOfStrings.