Reasons to drop the I's
- JavaDoc and IDEs like Eclipse differentiate interfaces from classes sufficiently. The Java typing does not also need to be reflected in the type name because our IDEs already give us sufficient visual clues.
- Follow the Sun conventions with the goal of minimizing the "impedance mismatch" between our code-base and the JDK, i.e., our APIs should look like they could be in the JDK. This strategy is helpful pedagogically.
- Keeping with the norm of other open source and java projects.
- For the sake of consistency between different versions
- To make it easier to tell which files represent java interfaces when viewing files in a list outside of JavaDoc or an IDE like Eclipse, or in Eclipse views which do not illustrate the difference with icons.
- To make it easier to identify java interfaces when looking at java code itself.
- Having the extra I doesn't present a real burden.
1 comment:
Some remarks on this:
Reasons to drop the I's
Item (1) is a strong argument.
Item (2) is a VERY strong argument.
Item (3) is a weak argument, because there definitely is no "norm", and many open source projects (e.g. ECLIPSE) have the "I"s.
More reasons to drop the "I"s:
(4) Hungarian notation of any kind is generally unpopular in the Java world, so it would be illogical to recommend the hungarian "I"s.
Reasons to keep the I's
Item (1): Rubbish
Item (2): Whoever uses such lists. Also I know of no ECLIPSE view that wouldn't indicate the difference clearly.
Item (3): Rubbish. The question of interest is: Do I need to know whether the type refers to a class or an interface?
Item (4): Only relevant if you consider removing the "I"s from an existing project.
More arguments to keep the "I"s:
(5) When I derive from "Map", I need to know whether it is a class or an interface, because I have to write EXTENDS or IMPLEMENTS respectively -- Weak argument, because Ctrl+Space tells me very quickly that "Map" is an interface.
(6) When the interface is named "IPartner", then I can declare an implementing class "Partner" in the same package without a name collision -- strong argument.
(7) When designing a class/interface hierarchy in your head or on paper, it is easier to keep an overview if interfaces are distinguishable by name -- medium argument.
(8)
Certain things can only be done with classes (e.g. constructors, non-static fields, nonpublic methods, static methods, nonpublic member types) or interfaces (e.g. "Proxy.newProxyInstance()") -- weak argument, because except for "newProxyInstance()" all these issues relate to the type declaration, not the type reference, and within class and interface declarations it is always very clear whether we're declaring a class or an interface.
(9) {@link Map} in JAVADOC does not give a visible clue whether Map is a class or an interface, so you have to add words like "the interface {@link Map}", if the distinction is relevant -- which is rarely the case.
Arno Unkrig, Versicherungskammer Bayern
Post a Comment