Eelco, But that's the whole point - class names that end in Impl are "not a names that communicates what things do well". The point of each implementation is that it is a specialisation of the supertype. So the name should illustrate that - ie HashMap (not a MapImpl). The good news is, this form of ridiculous naming is not a prevalent pattern in the Wicket code base hardly appearing at all, and nowhere public.
The reason people argue against the I prefix on interface names is a similar argument but not quite so strong. But still worth making. You should not need such a naming convention to identify something that is clear from the declaration (and the IDE and/or JavaDoc will show you that). What if I have a class for the iPlayer (a BBC service for watching already broadcast TV programs online). If I call my class IPlayer do I need to worry that half the world is going to think it's an interface. I find it extremely illogical to introduce such arbitrary naming conventions with unsound justifications that don't stand up to logical argument and just feel wrong anyway. Here's a discussion on this if anyone is still awake http://www.bigroom.co.uk/blog/the-i-in-interface . Again, having such a naming convention in the code is certainly not the end of the world, but to my mind it's a convention that does more harm than good (and don't get me started on Java(Beans) "getters" and "setters"!). Regards - Cemal jWeekend OO & Java Technologies, Wicket Training and Development http://jWeekend.com Eelco Hillenius wrote: > >> And good, consistent naming of classes and >> other identifiers is a non-trivial aspect of good design and coding, >> especially in publicly used parts of frameworks > > True, but imho that has more to do with choosing names that > communicate what things do well, not so much whether there are certain > prefixes or postfxes. > >> understanding from the original posts on this thread is that the >> technique >> described to incrementally get rid of I* interfaces by deprecating and >> eventually removing "offending" I* interfaces is exactly the right way to >> make such an improvement with minimal disruption. > > There's one thing I hate more than making unnecessary API breaks, and > that is accompanying them with annoying deprecation warnings :-) > > Eelco > > -- View this message in context: http://www.nabble.com/taking-the-I-out-of-Interface-tp25723691p25762172.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
