<snip> > AbstractEngine > AbstractDieselEngine > AbstractTurbineEngine > AbstractPistonEngine > > .... > > At least that's the convention I generally go with.
What if later you have a DieselEngine class (probably implementing AbstractDieselEngine), how can you tell the semantic difference between the two? I'm not sure I understand what you're asking here. When we're reading API type code we're likely to run into either: AbstractDieselEngine anEngine = (AbstractDieselEngine) MotorPool.getNext(); Or (more rarely in code using an API) DieselEngine d = new DieselEngine(); In the former context, we don't care what the concrete class name is because we're casting the class as abstract. We do however get a useful hint that anEngine is an abstraction which we wouldn't get without the leading Abstract in the classname. In the latter case we know its concrete because we can see the constructor. So in each case we have sufficient information to understand the code. Or are you hoping to develop a naming convention that includes a hint for concreteness in the name e.g. ConcreteDieselEngine? (I've read code like that before and never liked it. It seems easier and more natural to me at least to assume concreteness in the absence of other modifiers, but as others have pointed out ymmv). --- Pat --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
