DevOps Zone is brought to you in partnership with:

John Cook is an applied mathematician working in Houston, Texas. His career has been a blend of research, software development, consulting, and management. John is a DZone MVB and is not an employee of DZone and has posted 164 posts at DZone. You can read more from them at their website. View Full User Profile

Too Many Objects

07.26.2013
| 7051 views |
  • submit to reddit

Around 1990, object oriented programming (OOP) was all the buzz. I was curious what the term meant and had a hard time finding a good definition. I still remember a description I saw somewhere that went something like this:

Object oriented programming is a way of organizing large programs. … Unless your program is fairly large, you will not see any difference between object oriented and structured programming.

The second sentence is no longer true. OOP is not just a high-level organizational style. Objects and method calls now permeate software at the lowest level. And that’s where things went wrong. Software developers got the idea that if objects are good, more objects are better. Everything should be an object!

For example, I had a discussion with a colleague once on how to represent depth in an oil well for software we were writing. I said “Let’s just use a number.”

double depth;

My suggestion was laughed off as hopelessly crude. We need to create depth objects! And not just C++ objects, COM objects! We couldn’t send a double out into the world without first wrapping it in the overhead of an object.

Languages like C# and Java enforce the everything-is-an-object paradigm. You can’t just write a function; you have to write member functions of an object. This leads to a proliferation of “-er” classes that do nothing but wrap a function. For example, suppose you need a function to solve a quadratic equation. You might make it the Solve method on a QuadraticEquationSolver object. That’s just silly. As John Carmack said,


Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function.


Languages are changing. You can create anonymous functions in C#, for example. You can even create a named function, by creating an anonymous function first and saving it to a named variable. A little wonky, but not too bad.

I imagine when people say OOP is terrible, they often mean that OOP as commonly practiced now goes too far.

Published at DZone with permission of John Cook, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ramon Rivas Diaz replied on Fri, 2013/07/26 - 9:27am

I beg to disagree.

Over-engineering is always a problem, no matter the language. Too much abstraction will kill you no matter what feature you choose to define your abstractions.

I don't see a language problem in changing:

double depth;

by:

Double depth;

In the sense that even numbers can be objects. Ideally the compiler/VM should be smart enough to generate code as efficient in both cases. No extra overhead. We have primitive types and wrapper classes to help the compiler and VM, not because it's more clear or because it's an efficiency problem that cannot be solved. I would much prefer depth.toString() as with any other object than Double.toString(depth) which looks totally disconnected with the rest of my classes. I think that compiler optimizations like escape analysis and tail recursion optimization are a much better solutions than using primitive types, introducing structs on the language or manually changing a perfectly clear recursive method to a more verbose iterative one. I feel the same with lambda expressions. It's perfectly clear for me that they can be seen as a class with only one method so I can assign them to a variable of type Runnable. The compiler should be smart enough to fix everything else.

I'm not saying that functions should not be primary language elements, I'm just saying that pure OOP languages can be perfectly OK too.

dieter von holten replied on Sat, 2013/07/27 - 11:37am

 your example indicates some technical background. when your software is part of some non-trivial system you should consider things like UoM, sensible default formatting, sensible undefined-values, valid lower/upper bounds, implicit rounding and stuff like that.

in my system i have to deal with things like temperature and density. so i have not-too-fat value classes for those. sometimes its cumbersome when it comes to using the values, for example calculating the average temperature. however, the benefits outweigh this.

a plain naked 'double' or 'float' is IMO only usefull for the guys at wolfram or deep inside an EISPACK package.

i would never implement a temperature, length, or density as COM-object.....


Lund Wolfe replied on Sun, 2013/07/28 - 1:07am

Everything is in a class, but not everything has to be a class.  If you just need a variable for a number and it doesn't need to manage itself, then just use a primitive.  Keep It Simple.  Don't over-engineer.

If you need generic methods that don't fit in an existing class, just put them in a Utility class as static methods.  I have a minimal Utility class in almost every application.

William Orange replied on Thu, 2013/08/01 - 3:18am

It appears that the author of this post has invented a problem where none exists. First off, the subject line reads "Too Many Objects". This is like saying that there are too many molecules. Would the author be willing to volunteer for his molecules to disappear into a black hole so that we wouldn't have too many? Unlikely. Yes Dorothy, the world consists of objects and some of them are Wells that have state (depth) and behavior.

What I find especially curious, is that instead of pointing this out, others chimed in as if there were merit to the post. This demonstrates the saying of the American philosopher Vitvan--"Delusional evaluations and self made semantic reactions" or in computer parlance--"garbage in garbage out." This also demonstrates that one can never compensate for not learning the basics of their trade. Lastly, just because one has a mind, doesn't imply that they have learned how to use it.


Cheers

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.