If you peruse any decent book or blog regarding "good" coding practices, "naming things properly" is usually near the top of the list of recommendations to follow. This is actually quite important. Most recently, at a recent client's site, I took over the maintenance of a WPF application. It was part of a suite for a medical device the company was developing. One of the many "state
" properties that were being used was named "hasManufactured
". I was confused by this for reasons below. More importantly, when I asked around, no one else was sure what it meant. The original programmer was long gone.
There are several things wrong with this. First, as a property, it is incorrectly cased. It should have been "HasManufactured
". In a more egregious fashion, the other "state
" properties in the class WERE properly cased. Was there a reason for this one was not?
Second of all, the meaning of "hasManufactured
" was completely confusing to me. "Has
" as a word, generally means possession of something, or else a state of being. "He has a goat
" is an example of possession. "He has been hired
" would be a state. But notice that when "has
" represents a state, it's usually associated with a verb of some tense. A reasonable interpretation of the meaning of "hasManufactured
" was probably "has been manufactured
". Of course, everything that was in the manufacturing process was being manufactured, so ...
Finally, after digging around in the code, it appeared that "hasManufactured
" was being changed from false
to true
when someone clicked the "Finalize
" button on a particular dialog window. As it turns out, this button was clicked as the final step in the manufacturing process. So a good assumption is that "hasManufactured
" really meant "has been through the entire manufacturing process and is ready for sale
". A far better name would have been "IsFinalized
". (And yes, I did refactor this.)
Which gets me to the real point of this post. "Object Oriented Design" and "Object Oriented Programming" are both lousy names.
I've been doing .NET Framework programming for over 15 years at the time of this post. Not once have I ever coded an object. In fact, Visual Studio doesn't create object files, it creates class files.
The following code is syntactically correct and declares a class:
public class MyClass() {}
However, this next statement is syntactically incorrect and it has a completely different meaning and result in C#:
public object MyObject() {}
In the first case, an empty class (no members) is being defined. In the second case, the only reasonable meaning is someone mis-coded a method in a class that was supposed to return an instance of the object class.
Note the distinction here identified by the difference in syntax. We developers are NOT doing Object Oriented Programming. We are doing Class Oriented Programming. And we are doing Class Oriented Design. We don't use diagramming tools that provide "object
" diagrams - they provide "class
" diagrams. Unfortunately, I don't anticipate a successful #hashtag
campaign to change the name of the paradigm ...
So here we have an entire industry that recommends naming things properly that has incorrectly named its industry.
Paraphrasing Colonel Kurtz: "Oh! The Irony..."
CodeProject
A seasoned IT professional with experience designing and developing enterprise class information systems. Experienced in business process and workflow analysis, Object Oriented Design, Object Oriented Development, and Application/Solution Architecture. A Technical Manager of small and large teams, mentor, and experienced in both Waterfall and Agile methodologies. I have instigated and worked with other dev teams to improve processes at my employers including TDD, Continuous Integration, refactoring, improved logging, and Aspect Oriented Programming, resulting in reduced TCO, improved testing, and improved software quality.