OBO-Edit: Potential Refactoring

From GO Wiki
Revision as of 10:41, 8 October 2007 by Jrichter (talk | contribs) (New page: There are several areas in which OBO-Edit might benefit from a large scale refactoring. This page lays out these possibilities, and hopefully will invite discussion amongst the users of th...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are several areas in which OBO-Edit might benefit from a large scale refactoring. This page lays out these possibilities, and hopefully will invite discussion amongst the users of the OBO-Edit libraries. I feel that now is the perfect time to do these refactors, because OBO-Edit libraries are being used in more and more applications. Making these changes now will have a smaller impact on the user community than any future changes, and it will be much simpler to make these changes before OBO-Edit changes hands.

Package Naming Changes Proposal

Weak Version

Change the prefix of all packages from org.geneontology.oboedit to org.oboedit

Strong Version

Break OBO-Edit into the following packages (and corresponding jars):

  • org.obo
    • This package would include all the general-purpose code for representing and manipulating OBO ontologies. All of this code would be application agnostic and would include NO gui elements.
    • Subpackages:
      • org.obo.datamodel
      • org.obo.datamodel.impl
      • org.obo.datamodel.annotation
      • org.obo.datamodel.annotation.impl
      • org.obo.dataadapter
      • org.obo.dataadapter.impl
      • org.obo.filter
      • org.obo.filter.impl
      • org.obo.history
      • org.obo.history.impl
      • org.obo.identifier
      • org.obo.identifier.impl
      • org.obo.reasoner
      • org.obo.reasoner.impl
      • org.obo.query
      • org.obo.query.impl
      • org.obo.util
      • org.obo.util.postcomp
      • org.obo.verify
      • org.obo.verify.impl
  • org.bbop (or something - this could go into org.geneontology) (or all of org.geneontology could be dumped into this package)
    • This package would contain all the gui pieces that I'm calling the BBOP Application Framework. These packages would have NO dependencies on org.obo or org.oboedit, but would contain pieces from OBO-Edit that would be useful for rapidly developing ANY future swing application, including the general plugin system, the background task system, the component system, and the docking system.
    • Subpackages:
      • org.bbop.controller
      • org.bbop.gui
      • org.bbop.gui.dock
      • org.bbop.gui.dock.resources
  • org.oboedit
    • This package would contain all the OBO-Edit-specific gui code, including OBO-Edit startup tasks, OBO-Edit GUI components, settings, resources, etc.
    • Subpackages:
      • org.oboedit.controller
      • org.oboedit.gui
      • org.oboedit.gui.graph
      • org.oboedit.gui.factory
      • org.oboedit.gui.component
      • org.oboedit.launcher
      • org.oboedit.piccolo

Impact

These changes would have little impact on OBO-Edit, although there may be a certain amount of work in removing unexpected dependencies from components that ought to be indepent. It will have a much greater impact on Phenote & other users of the OBO-Edit libraries, because they'll break everyone's code who uses OBO-Edit libraries. On the other hand, in most cases fixing the problems will just be a matter of changing import statements, and most of those can be done with a search and replace.

Advantages

These changes should make it much clearer what each of the pieces of OBO-Edit actually does, and will enforce independence between pieces of code that should not be interdependent.