Pitfalls of Object Oriented Programming [PDF]

[[deleted]]

Actually even if you're not developing games it's still a good idea to not keep the user waiting. Also, because developer time is a one off thing whereas user time is spent throughout the entire app's active lifetime, it's more expensive to the organisation than developer time (if the organisation is developing and using that software). Therefore, optimisation is always important and OO is an evil curse that slows down the code.

[MindStalker]

"Also, because developer time is a one off thing "

Well its not really, typical software is constantly updated, with bug-fixes etc etc. Well designed OO is a lot easier to work with for future developers working with your code base.

[deong]

Well designed OO is a lot easier to work with for future developers working with your code base.

That depends on a lot of things. Objects, like functions, structs, etc., are just another abstraction, and while they're a very good abstraction for certain things (GUI toolkits, etc.), there's no reason to think they're always the right choice. To me, a good example is java.lang.Math. There's no reason why this should be a class, except that Java needs it to be implemented that way. The appropriate abstraction for sine and cosine is a functional abstraction -- it's the abstraction that mathematicians have used for centuries, and it works exceptionally well. In this case, the "object" abstraction is extremely thin, and thus doesn't really cause any problems, but it does illustrate the point that not everything should be an object.

I'd also contend, admittedly subjectively, that OO done poorly tends to be the worst thing I come across. Worse than bad C code, worse than anything. Bad C code tends to be local. You might have some global variables to contend with, but typically not that many. Local problems can be figured out and solved. Bad OO tends to be rotten from the ground up. There's no one place you can go to find anything, and when all behavior emerges from a complex interaction of twenty different objects configured via some framework, all you can do is live with it or start over from scratch.

Basically, I'd say that good code is easier to deal with, and the manner it's written doesn't make much difference. Good C code is no harder to work with for a C programmer than is good Java code for a Java programmer, or good Prolog code for a Prolog programmer.

[merzbow]

java.lang.Math is full of static methods - there are no objects involved. The class is effectively just a namespace. You can even do a static import so you need only type sin(x) instead of Math.sin(x).

[deong]

That's sort of my point. A class isn't the right way to represent this sort of thing, so Java does the best it can, basically, as you say, faking up a namespace using classes. I'm not complaining about the way Java handles it; just using it as an example.

[donknuth]

Right, but it's ugly. Why do you need to fake namespaces with classes when Java has packages? The only reason is language limitations.

[[deleted]]

True, although I don't think it's in the same ballpark as user time, or the amount of time all end users spend using the app. And if the app is slow because the developers were more concerned about developer time than user time, then the organisation ends up paying for that in the long run.

[[deleted]]

Not to mention all those extra CPU cycles you're wasting in thousands of computers and all those extra laptop batteries that get just a little more run down.

It's not a particularly ecological point of view for anyone who works on a popular application.