[EMAIL PROTECTED] a écrit : > Martin Desruisseaux ha scritto: >> 2) Rename "AbstractParamCalculator" as "TransformParameterCalculator" >> or just "ParameterCalculator" (or what about "MathTransformBuilder"?). >> I believe that the "Abstract" prefix is not required here since we are >> not implementing an interface. For example java.io.InputStream, >> java.awt.Component, etc. doesn't have an "Abstract" prefix. >> > I disagree on this one. If a class is abstract better make it clear from > the beginning, or people > will loose time trying to use it without noticing it's just infrastructure.
But this is actually the class that I expect to be used. For example InputStream, while abstract, is the class that we use most of the time in method arguments, return type, class fields, etc. Concrete classes like FileInputStream usually appears only on the right side of the "new" operator, and from that point we don't care anymore about which actual implementation we are using. This is true that AbstractButton do not implements a 'Button' interface. Other exceptions that I found in JSE 5 API includes AbstractColorChooserPanel, AbstractLayoutCache, AbstractWriter, etc. (mostly Swing classes). But most "AbstractFoo" classes actually implement a "Foo" interface in JSE 5: I counted between 15-20 such cases, against about 5-10 (depending how we class some ambiguious cases) where "AbstractFoo" doesn't have a corresponding "Foo" class/interface. On the other hand, the amount of abstract classes without an "Abstract" prefix in JSE is quite significant. Some that just popup from my head in the small portion of JSE API I'm familiar with include: InputStream, OutputStream, Reader, Writer, ImageReader, ImageWriter, SampleModel, ColorModel, Buffer, Charset, Component, Format, Formatter, Handler, Number, Calendar, TimeZone, Reference, Preferences, etc. For all the above-cited classes, those abstract classes are usually the one I work with in most piece of code after the "new" instruction. There is also some example of strange hierarchy in JSE. For example AbstractPreferences, which is a subclass of Preferences! http://java.sun.com/j2se/1.5.0/docs/api/java/util/prefs/AbstractPreferences.html Here, both "Preferences" and "AbstractPreferences" are abstract classes. The "Preferences" class is more abstract than the "AbstractPreferences" class, but its name still a plain "Preferences" because it is really the class that most peoples should use. Actually, I guess that Sun would have make an interface of "Preferences" if interfaces in Java allowed static methods. I agree that it is somewhat convolved and unusual hierarchy, but it is not the only one. Other examples: http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/spi/AbstractSelector.html http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/spi/AbstractSelectionKey.html http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/spi/AbstractSelectableChannel.html I guess that in all those examples, the parent class would have been an interface if Java interfaces were more flexible. P.S. Just a side note a little bit out of this email topic: it is interresting to note that one of Sun's next language, Fortress (http://research.sun.com/projects/plrg/) merges abstract classes and interfaces into a single concept, "trait". A proposal for extending the Java language with traits can been found there: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469144 In summary, I think that the entity which is expected to be used (often an interface, sometime an abstract base class) doesn't need an "Abstract" prefix. I believe that the "Abstract" prefix is rather reserved for classes to be used as a base for implementors, but not expected to be referenced by users. In the context where it may not be worth to create an interface, a plain name for the base class like "ParameterCalculator" seems a common practice... Cheers, Martin ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
