Oo Is Hard

Is this redundant? See ObjectOrientedDesignIsDifficult

I work at a big company with lots of coders. Most of the coders are smart, hard-working people who want to leave work at work and don't think about code after 5. (I, on the other hand, am a code-obsessed geek typing into a software development wiki at 10pm...) Anyway, the point is that despite occasional OO training, none of my coworkers really grok OO. They can put together a good relational db schema with ease, and can program in a solid structured programming style, but object-oriented programming is beyond them.

I suspect my company is not unusual. Given this, is it possible that OO is just too hard? By asking large numbers of average and above-average coders to do OO, are we overreaching? I suspect that in many places programmers could produce better software faster by dropping the object pretense and doing straight relational and procedural programming. - JimHughes

OO is like any other skill, it's hard when you don't know how to do it, and it's easy when you do. But I agree with you, I think OO is simply beyond many programmers, but I think those people need to find another career because strait relational and procedural programming quickly leads to a big mess in every shop I've ever seen. But that's just my opinion.

I think there is already a topic on this somewhere. My 2-cents is that "proper" OO is poorly defined and hard to justify in a transparent manner. It's alleged power seems to be promoted using "eastern" techniques instead of western reductionalism. It may perhaps be the greatest paradigm on Earth, but it resists documenting like the devil. Procedural/relational on the other hands has pretty simple rules: 1. divide code up by tasks, 2. factor out common stuff into shared libraries, 3. Normalize your tables, 4. Put info and about biz nouns in the tables. If you want to premote OO, get rid of it's damned "Zen Factor". And if p/r naturally leads to a "mess", as claimed above, I would like to see specific examples of something that cannot be fixed, and put it under FundamentalFlawsInProceduralDesigns. -- top

Sorry, I've proven it to myself, I don't need to prove it to you, and I did say in my opinion.

That is not very useful for people who want specifics or evidence. It could be the case that if we saw your non-OOP code along with the description of the problems with it, we could offer suggestions for improving it. Finding un-repairable maintenance headaches with non-OOP paradigms could be very useful as both a training tool and as a paradigm comparison example. But, we cannot improve what we cannot see.

People weren't asking... topmind was asking, and history has shown that no level of evidence or sample code or help will alter his opinion, so I won't waste my time. For reasonable people, there is a ton of evidence and sample code to be found on this site, no need to duplicate it.

Well...it's still a not-very-useful response.

I'm kinda wondering how serious Top was about his offer, though. Because I've got a couple projects that I started as P/R and either rewrote as OO or wished that I had. They're in the 1000-line ballpark, though, so I dunno how easy they would be to critique. -- JonathanTang

I'd love to see top critique a real procedural program, toss it up if you don't mind Jonathan, could be interesting.

Bring it on! -- top

Code is posted, along with problem description, in FictionPublishingExample. -- jt