Little to no use of object-oriented interfaces
Update (2020-08-07): This is a republish of my fourth blog post, dated 2006-04-12: Little to no use of object-oriented interfaces. Devblog won't let me backdate this before 2015.
Recently, I've been developing code in an application that is heavily object-oriented. And, in doing so, I have reaffirmed my hatred of the stuff. There are several reasons for this, although I don't care to go into them all right now -- maybe when I have more time.
At least one problem I have with an object-oriented design relates to global variables. Let us examine those first. If you mention the use of "global variables", most software engineers will scold the idea and damn the writer of such code to hell. Why, you ask? Well, to be honest, I forget the official reason we were taught in school, but I can tell you that my reason for hating them is because they increase debugging entropy.
This terminology is what I just now came up with, so bear with me. By "debugging entropy" I basically mean that the chance for bugs goes up, and the difficulty of debugging bugs increases. One reason this is true (and maybe it's THE reason) is because you're adding more inputs and outputs to your code. For every global variable, you might as well be passing it as an argument to your function, nay, every function. That leads to a heck of a lot of potential code paths that have to be accounted for, because anybody could have set your global variable to just about anything (i.e. not just your caller). More code paths lead to more potential bugs, and also makes debugging harder because more things may have to be inspected while stepping through the code.
But what's worse is that programmers tend to use global variables out of laziness or bad code design. They use them because they don't want to pass some value to every single function. So instead of consolidating data structures, or just sucking it up and adding the parameter, they hack in a global variable.
Now, let us go back to how global variables relate to object-oriented design. If you are using classes/objects as an interface, you inevitably end up keeping around state for such objects. That state is kept in class member variables. In my opinion, these members are no different than global variables. They are accessible by all member functions of the class and will likely just increase in number as the lazy programmer needs to access more data.
For example, in a GUI program you might have a "Window" class that represents all there is to do with putting windows on a screen. And in that class you'd probably store things like a list of active windows. But I'm willing to bet that at some point that Window class will want to know what the current screen is. Since the Window object does not have access to that, it will likely be added to the class as a new member variable current_screen. This is just a global variable -- it's a hack! To add insult to injury, I bet the programmer will use set_current_screen() and get_current_screen() accessor functions for it and claim that it is now good programming (see my previous entry about my hatred of those)!