Hi, consider the possibility where future plugins would like to use code from both of the suggested Abstract classes
- AbstractPluginExecuter - AbstractBioAssaySetExporter as you can only extend on of the abstract classes the problem remains. I suggest you try to separate the plugin code from the "code that is useful elsewhere" by putting them into separate classes. You have already done this in part by having the class FileUtil which in it's documentation states "This class collects some useful methods for file and stream handling." This would be a good, if not great :-), place to put eg. - copy(..) - deleteDir(...) - emptyDir(...) from Base1PluginExecutor. Cheers! //Gregory vegard nygaard wrote: > Hi. I also think that Nicklas' "Abstract" approach will work well for me. I > just need to refresh my java skills and test it out to be sure. I will get > back with some detailed proposals in a few days. > > Vegard. > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:basedb-devel- >> [EMAIL PROTECTED] On Behalf Of Adam Ameur >> Sent: Thursday, August 30, 2007 2:00 PM >> To: BASE dev >> Subject: Re: [basedb-devel] How to extend and >> overrideBioAssaySetExporterand Base1PluginExecuter? >> >> Hi, >> >> Thanks for the reply Nicklas. It makes a lot of sense to create >> abstract classes as you suggest. We'll investigate what things we'd >> like to have in an AbstractPluginExecuter class, but mainly I think >> is code having to do with data import/export and plugin permisssions. >> But I'm sure others will have different opinions about this. >> >> /Adam >> >> >> On Aug 29, 2007, at 6:35 PM, Nicklas Nordborg wrote: >> >>> 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 >>> (http://lev.thep.lu.se/trac/baseplugins/wiki/se.lu.thep.affymetrix), >>> 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. >>> >>> /Nicklas >>> >>> ---------------------------------------------------------------------- >>> --- >>> This SF.net 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 >> http://get.splunk.com/ >>> _______________________________________________ >>> basedb-devel mailing list >>> basedb-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/basedb-devel >> >> ------------------------------------------------------------------------- >> This SF.net 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 >> http://get.splunk.com/ >> _______________________________________________ >> basedb-devel mailing list >> basedb-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/basedb-devel > > > ------------------------------------------------------------------------- > This SF.net 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 >> http://get.splunk.com/ > _______________________________________________ > basedb-devel mailing list > basedb-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/basedb-devel -- Gregory Vincic Theoretical Physics Department, Lund University Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ------------------------------------------------------------------------- This SF.net 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 >> http://get.splunk.com/ _______________________________________________ basedb-devel mailing list basedb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basedb-devel
