Recent events really got me thinking about this (rant):
Most of the cars on the road would be reminiscent of the 1940's where cars didn't have seat belts, air conditioning, power windows, anti-lock brakes, air-bags, radial tires, FM radio, CD/MP3 players, DVD players, navigation systems, On-Star, etc. Why? Because the cost into researching new technology and implementing it wasn't cost effective to the business and therefore the technologies we enjoy so much today wouldn't be around. These also would not be found in the standard automobile because the needs of the driver are secondary to the functionality of the car that the engineers, not the driver, come up with - the driver wasn't even consulted, the CEO of the automotive giants response is 'If the driver has to use a map instead of having an electronic device that directs him where to go so be it - they should know how to use a map anyway!'
You would be lucky to survive a trip to the market because you're brakes weren't tested because there wasn't time to do tests; upper management of the company imposed a dead-line without first asking the engineers how long it would take do something. Furthermore middle management had no spine and put their career aspirations ahead of public safety and willingly and purposefully ignored any design problems mentioned by engineers that were detected and directed them to do spot welding on any problems that came up, and the engineers who had no integrity of their own were more than glad to do so because they wanted to stay on their bosses favorable side and be considered a team player. The ones that did speak up and said anything would be moved to the night-shift to clean the floors because they were rocking the boat and suggesting improvements and trying to implement a continual improvement process rather than sticking with the status quo.
If you're door happened to close because it was the right size and shimmed properly or the steering wheel happened to be in front of you on the left side and not on the right, and not missing you'd be very lucky. There's no time for a busy automotive corporation to sit down and design the car first, there's money to be made, design is a luxury - just 'get 'er done!' People are waiting on us deliver a product that they can drive to their jobs with! They can't wait an extra couple of weeks for you to design a system! Who cares if we have to do it two or three or more times to get it right!
It would be anyones guess how long it would take to get an oil change done because each car manufacturer developed their own custom engine with its own custom lubrication system rather than settling on a standard. They also provided no documentation on how the car was designed or put together so trying to trace an electrical problem or anything beyond the most basic repair would be nearly impossible or take days to do.
So the whole purpose of my rant is that in short, there is no excuse for lack of design, quality of code, testing, or documentation. NONE! If the automotive industry, or other industries in general took the approach that most ITS shops, and many software manufacturers do, most of us would still be riding horses. As a friend of mine said, we need to regulate how we work or the government is going to do it for us.
I've had my hand slapped several times and my rear nearly chewed off for having a spine, but I don't care; I'm going to be a man and stand up for what I believe in. I wish more people were like that.
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?
Click here to view the article.