[Joelib-devel] Re: [Cdk-devel] QSAR

[Christoph S. <c.s...@un...>]

Rich,

it was interersting to learn about your projects, and of course you=20
point about interfaces is a valid one.
We had this discussion for CDK again and again and we are likely to move=20
to core class (Atom, Bond, Molecule, etc.) interfaces in the future.
With now three Chemoinformatics Java frameworks on Sourceforge and this=20
interesting discussion about the QSAR project, we have a decent chance=20
to agree on a well-defined interface for those core classes.

Cheers,

Chris

--=20
Dr. rer. nat. habil. Christoph Steinbeck (c.s...@un...)
Groupleader Junior Research Group for Applied Bioinformatics
Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de)
Z=FClpicher Str. 47, 50674 Cologne
Tel: +49(0)221-470-7426   Fax: +49 (0) 221-470-7786

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..


rich apodaca wrote:

> I agree that a common method for the representation of molecular=20
> objects is critical for the development of portable and verifiable=20
> cheminformatics protocols.
> =20
> A core principle of object-oriented design is that designs are most=20
> reusable when you program to interfaces, not implementations.
> =20
> I would propose that any discussion of a QSAR framework should take int=
o=20
> consideration the need to first define Java interfaces for core objects=
=20
> such as Atom and Molecule. The QSAR framework would be useful to the=20
> greatest number of developers if each developer is free to provide thei=
r=20
> own implementation of the core interfaces that will work without=20
> modification in the QSAR framework. Defining these interfaces means tha=
t=20
> the irreducible core functionality of Molecule, Atom, etc. with which=20
> the framework will neeed to work must be decided on.
> =20
> The advantage of this approach is true design reuse. Because the QSAR=20
> framework only knows about Java interfaces, all a developer needs to do=
=20
> to use all of the functionality of the framework is to provide an=20
> implementation of those interfaces. Of course, reference implementation=
s=20
> should be provided by the framework as well.
> =20
> I've taken this approach in a cheminformatics framework called "Octet"=20
> (http://octet.sourceforge.net <http://octet.sourceforge.net/>) and in a=
=20
> 2-D molecular visualization framework called "Structure"=20
> (http://structure.sourceforge.net <http://structure.sourceforge.net/>).=
=20
> The approach in these frameworks differs significantly from both JOELib=
=20
> and CDK in that a developer is never required to use my reference=20
> implementations of Molecule or Atom.
> =20
> For example, it is possible to provide performance-optimized=20
> implementations of these interfaces that would be suitable for large=20
> numbers of molecules, or the rapid constrution of molecules. The=20
> framework only knows about interfaces, and this is the key to code reus=
e.
> =20
> I would be willing to provide any code and/or experiences from these=20
> projects to the development of a QSAR framework.
> =20
> cheers,
> rich