Click here to Skip to main content
13,896,397 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


2 bookmarked
Posted 19 Apr 2017
Licenced CPOL

Oh! The Irony ...

, 19 Apr 2017
Rate this:
Please Sign up or sign in to vote.
Oh! the irony...

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..."


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Architect SACC
United States United States
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.

You may also be interested in...

Comments and Discussions

QuestionIt's Design vs Development Pin
RandyBuchholz3-May-17 6:38
memberRandyBuchholz3-May-17 6:38 
QuestionFully agreed! Pin
irneb23-Apr-17 22:56
memberirneb23-Apr-17 22:56 
QuestionIt's good Pin
bdsnhaviet19-Apr-17 23:30
memberbdsnhaviet19-Apr-17 23:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web05 | 2.8.190306.1 | Last Updated 20 Apr 2017
Article Copyright 2017 by GrumpyPants
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid