Re: THREDDS Catalog Library
- To: Travis Stevens <address@hidden>
- Subject: Re: THREDDS Catalog Library
- From: John Caron <address@hidden>
- Date: Wed, 15 Dec 2004 10:36:25 -0700
Travis Stevens wrote:
I have been looking at the java implementation of the catalog library
and I would like to offer some constructive criticism of the design.
It seems to me that the goal of this library is to allow developers to
create InvCatalog objects which can be rendered as THREDDS catalog XML
files. I believe that certain changes to the interface could make
implementing the API a bit easier (feel free to sing along
The main package is thredds.catalog. Unfortunately, this package
contains multiple abstractions -- the base API and some
implementations of the base API, conversion APIs and creational tool.
The base API consists of these classes:
I have chosen these because they are the only classes that are
directly related to the Dataset Inventory Catalog Specification
. These classes should be in the thredds.catalog package by themselves.
I would suggest these classes be interfaces and not abstract classes.
Remember that in Java, one can not extend more than one class, but
they can implement more than one interface. This is really the
difference between being an object (abstract class) and having a
particular behavior (interfaces). What you really want is for an
object to have InvCatalog behavior not to be an InvCatalog.
I would suggest creating a package which contains abstract
implementations of the thredds.catalog API. Maybe a
thredds.catalog.impl package. In this package you would put those
convenient abstract classes.
I would suggest creating a package for the conversion API maybe
...and now that these converters are in an API based package, there is
no need to add "IF" to the end of the name. I find it clearer to say
"Object o has Metadata Converter behavior" instead of "Object o has
Metadata Converter Interface behavior".
The JaxpFactory seems more of a tool, maybe it belongs in
thredds.catalog.tool and InvCatalogFactory is a creational object that
might belong in thredds.catalog.factory.
Thinking in terms of each abstraction would alleviate method
signatures like "thredds.catalogInvDataset.findDatasetByName(String
name): InvDatasetImp". Having an abstract object return a concrete
object limits what one can do when implementing the API.
Anyway, thats just my $0.02.
Travis, thanks for your thoughts on this.
I dont particularly like the abstract/impl dichotomy either. The
previous design used interfacces, but that has tradeoffs also. Package
placement and finding the right balance of abstraction and detail
hiding is a black art.
When I can, I will think harder about the details of your message and
try to say something more intelligent.
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web. If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.