Avoid Letting Object-Oriented Programming Get out of Control

(Read this really fast.) Let’s see, I’m writing a really cool program, so I need a class called Cool, and from that I’m going to derive a class called ReallyCool, but both of those are abstract, actually, so from ReallyCool I’m going to derive six classes, one called CoolA, one called CoolB, and so on through CoolF. But each of these needs to hold some members, and so I’m going to invent my own Integer class and call it JeffInteger (yeah!), and I’m not happy with the standard library’s implementation of string, so I’m going to create a class with another great name, JeffString. But JeffInteger actually encapsulates several different types of integers, so from JeffInteger I’m going to derive JeffLongInteger, JeffShortInteger, JeffSuperShortInteger, JeffSuperLongInteger, and JeffSeriouslyIncrediblyLongInteger. The JeffString class, in turn, can hold both Unicode and multibyte strings, and so from JeffString I will derive JeffUnicodeString and JeffMultibyeString. And, of course, I’ll overload the usual operators, including +=, −=, /=, *= for JeffInteger, and similar operators for JeffString as well as [].

Wait! Stop! This is getting just a little out of hand, wouldn’t you say? But I have, in fact, witnessed this kind of thing going on. Let’s backtrack just a little here. I’m not going to turn this into a course on OOP with a section on discovering objects, because you can find that in standard texts on object-oriented programming. But I will say this: Slow down, take a deep breath, and don’t let your object discovery get out of hand. Why? Because if you have way too many classes, most likely you will lose control of the code and end up with bugs.

Also, besides going overboard on the class creation, another fundamental mistake here is in believing that the basic types and the standard classes are, in some way, inferior to your needs. Do you really need to reinvent the string class?

Now I won’t suggest that you’re not as good as the people who wrote the string class for the standard library. Instead, I’ll suggest that you have more important things to worry about than rewriting the string class (don’t you?). Your job is to create your application, and you probably have a deadline. Why spend the next two weeks perfecting a string class, when the current one works just fine?

What’s going to happen when suddenly somebody using your string class needs to write out a string to stderr, and you suddenly realize you forgot to overload the insertion operator? (You know, the insertion operator is the << thing.) And what if somebody needs a function that will find the last instance of a character within a string? Are you going to spend a couple of days writing these two missing functions when your boss is looking over your shoulder to finish up the application? The standard string class has these functions in it already. Therefore, I encourage programmers to remember this:

RULE

Don’t reinvent the wheel. Use the classes in the standard library and the built-in types.

I’ve said this many times throughout this book, but I’ll say it again: Your goal is to create highly useable software, and that includes software that is bug-free. The classes in the standard library have been tested and tested ad nauseam, and the chances of them having bugs are next to nothing. If you spend a few days throwing together your own string class, do you really want to stand behind it? I consider myself an expert C++ programmer, and yet, I know better than to attempt such a thing, if for no other reason than a lot more people spent a lot more hours on the standard classes than I could spend on my own classes. I’m not saying that they’re better than you or me; I’m saying that a lot more work has gone into them.

And with reinventing the wheel comes some other issues. For example:

RULE

Don’t feel like you must use every last feature in OOP just because it’s there. Don’t templatize, virtualize, and polymorphize your code into a royal mess.

Some time back, I had a client who was developing a telecommunications library. They had previously brought in a self-proclaimed C++ guru, who told them that if they would rewrite their library using templates, they would be able to “snap out” the current communications protocol and “snap in” another protocol. And so the guru left, and they went to work, changing every last class in their library into a template class. By the time I got there, they had a royal mess on their hands. They had piles upon piles of templates, and they were forced to learn everything they could about template instantiation under different compilers, and they got to see firsthand just how long templates take to compile. And long after the self-proclaimed guru had moved on, the whole reason for creating this mess didn’t even succeed: They were unable to “snap in” a new protocol. Instead, they were left with a bizarre set of templates that served no real purpose. I call this “templatizing, virtualizing, and polymorphizing your code into a royal mess.”

RULE

Don’t get carried away with creating a huge number of classes.

This idea has a very practical reason: While we’d all like to believe that this class must be broken up into two classes, including an abstract base class so that the class can be used in many other applications over the next several decades, in fact, we know better. Unless you’re actually building a class library and not an application, the reality is that your class probably won’t find its way into other applications.

Yikes. I can see the Object-Oriented Purists getting ready to string me up with an object that is definitely not abstract for that statement I just made. But let’s be serious: Your job is to create software that is on schedule and free of bugs. The more time you spend building abstract classes hoping and believing that these classes will find their way into other applications, the less time you can spend on more important issues such as usability. Who are you writing this code for? Your own personal glory or for the end users? As much as we like to think that our work is for our own personal glory (hey, I always enjoy seeing my name on the cover of a book or in the credits of a software application), the truth is that our software is for the end users. Yes, we work because we need the money, and that’s usually the real reason we’re grinding out those hours before the computer screen and keyboard. But like it or not, this software is not for us. It’s for the users. So don’t get carried away as you create the most amazing class library that the world has ever beheld. Skip it and write some good software instead.

Note

But before I end this discussion and move on to the next section, I want to add a bit of a disclaimer. I’m not saying to forget all you know about sound OOP principles. Yes, please use OOP properly. What I am saying is that you don’t need to go overboard and use every last feature OOP allows for, such as creating a million abstract classes.