thanks max!

But seriously… I don’t know if this has caused actual pain, it’s just totally redundant to name something AbstractXXX or IXXX when the language provides keywords describing the situation. My perspective is that polymorphism makes it possible for you to use an object based upon its public interface, and not care about whether the implementation you are dealing with is Abstract or an implementation of an actual Interface. So, naming things in this fashion to make you think about their implementation when it is irrelevant is a code smell IMO.

For example, we have an analytics application at Highwinds, and it works with various types of data points. The base data point object is called DataPoint, and it does stuff and exposes data. When using DataPoint, I don’t care if it is an abstract base class, an Interface, or a concrete class – it’s totally irrelevant. There are extensions in to FileDataPoint and RegionDataPoint and DmaDataPoint, but the system deals with all of them as DataPoints just the same. At the moment, DataPoint is concrete, but I could refactor its concept to an Abstract class or Interface at any time, which would have absolutely no bearing on the code that operates on these objects so long as the public interface stayed the same. So, forcing the name to be refactored when one of these changes is made is just extra work that provides zero benefit and confuses everybody, since they used to work with DataPoint, but now they have to learn about AbstractDataPoint or IDataPoint instead.

Makes no sense to me, but that’s just my opinion.

- max

Yeah, I still use “BaseXXX” pretty regularly. Somehow I think that defeats my argument, but stylistic choices are rarely logical… :)

Happy New Year!

- max