Adam Ameur wrote:
 > Hi,
 > I would like to extend some methods in the Base1PluginExecuter for
 > another purpose.

I think we need to be careful about this. The Base1PluginExecuter and 
BioAssaySetExporter was designed and implemented to solve ONE specific 
problem: Being able to run plug-ins developed for BASE 1 under BASE 2.

I can understand why people want to use the two classes for other but 
similar purposes since they contain a lot of useful code. Considering 
the historical changes (which has been large) in those two classes I 
don't think they are stable enough to make subclassing an appropriate 
solution in this case. Making methods 'public' or 'protected' instead of 
'private' also means a future commitment to not change the contract of 
those methods (ie. method name, method parameters, return values, what 
they are supposed to do, etc...).

The developers of the Affymetrix-related plug-ins, RMAExpress and Plier 
faced almost the same problem. In this case, the RMAExpress plug-in was 
developed first. When development on the Plier plug-in started the 
developers realized that a lot of code was very similar and moved much 
code to an abstract base class: AbstractExternalBinaryPlugin

I think a similar approach is a better solution also in the case of the 
Base1PluginExecuter and BioAssaySetExporter. That is, we should 
introduce the abstract classes AbstractPluginExecuter and 
AbstractBioAssaySetExporter. The hard part will be to decide what should 
go into the new abstract classes. The existing code will not take us all 
the way. I think we also need Vegard's and Adam's use cases to find a 
common pattern that can be used when designing the abstract classes.

Other opinions on this matter and offers to help with the implementation 
are welcome.


This email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
basedb-devel mailing list

Reply via email to