On Sat, 26 Feb 2005 06:24:06 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > On Sat, 26 Feb 2005 14:13:59 +0100, <[EMAIL PROTECTED]> wrote: > > Hmm, i thought it's more or less standart for interfaces in the advanced > > java community... > > > > Baloney. > > HttpServletRequest? HttpServletResponse? ResultSet? List? > > No leading "I" on any of those. > > I am unaware of any interfaces in the JDK that are ISomething. >
Although the JDK and standard Java APIs do not use this convention, there are indeed Java coders who do -- and, outside the Java world, you'll certainly see this in ASP.NET APIs, for example. Personally, I find the "leading I on an interface" rule to hurt readability, but worse is that it also tempts you to an insidious practice of naming an interface with the I, and then an implementation class the same way without the I. Consider the two names: * IThisIsAVeryLongName (interface describing part of your app's API) * ThisIsAVeryLongName (class that implements IThisIsAVeryLongName) Without studying closely, can you instantly tell the difference? I contend that it's easier to do that (although not necessarily trivial with long names) with patterns like: * ThisIsAVeryLongName (interface describing part of your app's API) * ThisIsAVeryLongNameImpl (class that implements ThisIsAVeryLongName) Finally, in my own coding, I also find that I sometimes prefer abstract classes rather than interfaces to model application APIs, particularly where I intend to add new capabilities later (and where adding a method to an interface breaks existing implementations, but you can add a method to the abstract class that provides backwards compatible default behavior). I'd hate to have to rename the interface or abstract class when I changed this decision, even if I'm using an IDE that will do all the grunt work for me. > Larry Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
