Re: Fw: Re: [Cdk-devel] data objects as interfaces

[Egon W. <eg...@us...>]

On Thursday 25 August 2005 03:59, Rich Apodaca wrote:
> By the way, I'm coincidentally in the process of refactoring CDKTools
> (http://cdktools.sf.net). One change I wanted to make is to introduce the
> Builder Pattern with respect to AtomContainer/Molecule construction. My
> current interface is the following:

Ack... 

<snip>

> Concrete implementation of CDKBuilder provide their own methods to retrieve
> the representaiton that was created. In other words, CDKBuilder doesn't
> necessarily have to build an AtomContainer. It can, for example build any
> other representation such as ASCII text in a molfile. (This is essentially
> the approach I've taken in Rosetta - http://rosetta.sf.net). The beauty is
> that clients using the CDKBuilder interface have no idea about what the
> builder is building.
>
> This decoupling is extremely powerful. The Builder Pattern, once it is set
> up, opens up many possiblilities for code reuse and optimization that can
> not be realized otherwise.

Right indeed. Now that CDK has interface setup as well, we can start 
converting all code in CVS, to take interfaces instead of classes, allowing 
competing data class implementations too, e.g. full CMLDOM or Octet based...

(Though I still have to write up a reply on your interesting CDK/Octet 
article, wrt delocalized bonds... the CDK data classes *do* support 
multicenter/multielectron bonds, though most algorithms do not...)

> If this is a direction you think makes sense for CDK, I'd be happy to do
> what I can to help make it happen.

Come to CDK5AW :)

Seriously (I know you can't make it), your article made me read the Dietz 
article, and the PhD report of Susanne which I had on my desk for some months 
already, with a pile of other interesting things to read :(...

I know the CDK is on the right track... all (published) applications show 
that, but I'm deeply aware of the limitations the CDK still has. But we are 
steadily extending functionality, while improving/formalizing/stabilizing 
things we have done in the past.

And, as a final (Blue Obelisk) note: it's open source that allowed you to 
fundamentally comment on choices Dan, Christoph and I made in september 2000 
in South Bend, IN, USA. Back then, it was just about getting a combined code 
base for Jmol and JChemPaint. But we're way beyond that right now.

Egon

-- 
eg...@us...
GPG: 1024D/D6336BA6