These are reasonable suggestions. According to the code conventions,
class names should be nouns:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html
As Adrian and Bryan suggested, I will remove the getType() method from
ImportDependency. A module system may need to recognize dependencies in
a module definition from other module system for interoperability (e.g.
recognizes module re-export), so I think we will need to define common
dependency types like ModuleDependency and PackageDependency in the API.
Regarding whether we should use interfaces vs abstract classes, Joe
Darcy has a very good write-up on this topic recently:
http://blogs.sun.com/darcy/entry/api_design_interfaces_versus_abstract
Since these import dependency types are created and used mostly by the
module systems and each module system may have its own set of
implementation for these types, defining them as interfaces is probably
a more sensible thing to do. I will also move the factory methods from
ImportDependency into Modules for now.
I will make these changes in the next revision of the draft API
specification. Let me know if there are other feedbacks on this.
- Stanley
Adrian Brock wrote:
I agree, getType() looks wrong to me
(not very object orientated ;-)
But I'm not sure that the spec should define import module and package
as explicit subclasses or that Import[Dependency] should be a
concrete class?
I'd prefer to see interfaces. The factory methods would
just construct implementations of those interfaces.
Somebody else would be free to implement them in a different way,
e.g. as a wrapper/adapter to the equivalent manifest information of a
291 implementation.
On Wed, 2008-06-11 at 13:11 -0700, Bryan Atsatt wrote:
The design of this class seems broken to me with the addition of two
"types". Why not:
1. Make ImportDependency abstract, removing the getType() and newX methods.
2. Make ImportPackage and ImportModule subclasses, each with their own
newX method.
(I also strongly suggest that we rename ImportDependency to simply
"Import" :^)
This model also obviously enables new subtypes, an extensibility point
that may come in handy in the future.
// Bryan
