I'm just in a mood today.
A friend and I were discussing dependancy injection and I got off the subject talking about Impl classes. If you are not familiar with what I'm talking about some typical examples would be:
ProcessImpl
BusinessImpl
FactoryImpl
ImplementationImpl
And it goes on like this.
If you've ready any book on software development and object oriented programming and didn't just get out of college with your CS degree and are on your first job, then you should know two things. One that a class is representing an object, and two that code (things like class names) should be self describing (this is one of the golden rules). So let's look at an example:
BirdImpl
By looking at the name, this object is suppose to represent a bird implementation - say a Robin, or a Blue Jay, or a Cardinal. Just looking at this alone, how could this be more self describing? How about instead of calling it BirdImpl we call it Robin, BlueJay or Cardinal; novel idea I know.
What I'm saying is it's either a Bird or it is not a Bird; putting Impl on it doesn't add any extra value, but let's play devils advocate. Let's say the reason I named the object BirdImpl is because it a generic (abstract) class that can represent any type of bird, so if I use it in a factory, in my code I know that this can be any type of bird:
BirdImpl bird = BirdFactory.Create("Robin");
//or:
BirdImpl bird = BirdFactory.Create("Stork");
Well to that I would say have your generic (abstract) class called Bird instead of BirdImpl. To drive home my point, I drive a Car, to be specific a Saturn, to be more specific a SaturnL200; I DO NOT drive a CarImpl (Saturn), and I DO NOT specifically drive a SaturnImpl (SaturnL200)...if I want to speak to someone about my Saturn in GENERIC terms I say things like 'My Car is painted black', NOT 'My CarImpl is painted black'. If I want to go for a drive and I had to write this in code I might say:
Car _car = CarFactory.Create("Saturn");
Brian.Drive(_car);
//Or:
//Saturn _saturn = CarFactory.Create("SaturnL200");
//Brian.Drive(_saturn);
I would not say:
CarImpl _car = CarFactory.Create("Saturn")
Brian.Drive(_car);
//Or:
//SaturnImpl _saturn = CarFactory.Create("SaturnL200");
//Brian.Drive(_saturn);
I hope I have made my point in naming conventions and self describing code.
You may also say I could of named the variable carImpl or saturnImpl for the variable, but this would be redudant - or stating the obvious:
Car carImpl = CarFactory.Get("Saturn");
You mean carImpl is an implementation of an instance of Car???? Really??? No joke??? I thought carImpl was an instance of a Tree object. Like I said, redudant - if you write self describing code at least..
Some may say the reason use 'impl' is because it's an implementation of an interface called Car, so something that implements this interface is a CarImpl. But this again is confusing an not self describing. How about naming the interface ICar rather than Car, of if you're working with something more specific such as a Saturn object that implement ICar you can continue to just call it a Saturn.
ICar _car = CarFactory.Get("Saturn");
Any questions?