Rajarshi is at the EBI (or at least was yesterday), talking about his\nrcdk package (his excellent slides).\nOne slide is about how to create a new atom; he mentions not to use new Atom() but the\nDefaultChemObjectBuilder\ninstead (slide 73). I do not entire agree with the message given.
\n\nThe slide seems to favour the DefaultChemObjectBuilder, but there like are more suitable builders for a particular application.\nCurrently, I am aware of two alternative builders: the DebugChemObjectBuilder, and the NoNotificationChemObjectBuilder.
\n\nThe reason the CDK has a builder pattern is the following. It is cleaner to write against interfaces than against\nimplementations, because it allows alternative implementations. I just listed all three provided by the CDK library itself,\nbut other implementations may exists too; they might have a completely different data model, e.g. fully CMLDOM-based, or\nfully SQL-based. By programming against interfaces, changing the implementation becomes easy.
\n\nNow, by using new Atom() you choose a particular implementation (in this case, the one around the DefaultChemObjectBuilder.\nHowever, you like the user to pick the implementation. This is why the CDK library itself uses builders all over the place:\nit assumes a IChemObjectBuilder is predefined and that is used.
For example:
\n\nIChemObjectBuilder builder = new DefaultChemObjectBuilder();\nIMolecule molecule = builder.newMolecule();\nIAtom atom = builder.newAtom();\nmolecule.addAtom(atom);\nIf your method actually has an IChemObject as input, it can retrieve the builder from there:
\n\npublic IMolecule addToMolecule(IAtom atom) {\n IChemObjectBuilder builder = atom.getBuilder();\n IMolecule molecule = builder.newMolecule();\n molecule.addAtom(atom);\n}\nThis latter situation is what exists most in the CDK library, actually. In some cases, this is not the case, and sometimes\nyou may need to pass an IChemObjectBuilder to a constructor. This is, for example, the case with the constructor of the\nSmilesParser.
Now, reconsider the first code example. By defining a builder only once, and reusing that builder in the rest of your code,\nyou only have to change one line to use a different implementation. For example, the DebugChemObjectBuilder that sends\ndebug messages for each set and get call to one of the data classes. I used this in the past, and solved several nasty bugs\nwith this; just by seeing in what order data was set and read. And I only needed to change one single line of code for that.
", "summary": "Rajarshi is at the EBI (or at least was yesterday), talking about his rcdk package (his excellent slides). One slide is about how to create a new atom; he mentions not to use new Atom() but the DefaultChemObjectBuilder instead (slide 73). I do not entire agree with the message given.", "date_published": "2010-05-15T00:00:00+00:00", "date_modified": "2010-05-15T00:00:00+00:00", "tags": ["cdk","java"], "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ] } ] }