Why I can't see a real point for using OOP? [duplicate]

Question

Possible Duplicate:
Classes. Whats the point?

I've read tons of tutorials, wrote many classes, used them, but I still can't figure out some OOP points.

I mean, I think I got the theory. It's a paradigm, a different way to think and solve a problem. I know all commom points: code reuse, encapsulation, better error handling, easier maintenance, inheritance, design by contract, better documentation, aggregation, composition, some design patterns...

That said, let's go to the real deal. Let's say I have the following:

• a database, and a class to access and query it.
• I have a table named person and another table named address
• Simple business rule: one person can have one or more address (home, work, delivery...), a simple one to many relationship
• I have a highlevel class for commom operations (CRUD). Each table has a class that is a extension from this one.
• Of course, each class (person and address) have their own methods: eg, getAddressByLocation or getPersonsByAge.
• Also there are a dozen views and a couple forms

All this is awesome and sure useful but... I can't stop thinking in the simplest case: listing some people. Yes because every row on the output table is made upon one class instance. I can't stop thinking on how much memory and cpu is used on not used resources.

Listing 50 people means creating 50 instances, full of resources like crud, filtering processing uploads, validating rules and so on when what I need is to run a query and just output results with a simple loop.

This confuses me a lot. And not just confuse, as I already saw some apps where runtime increases exponentialy with database when business rules are a little more complex.

I think, is the case to create new classes or plain scripts to just handle the outputs and reports? If yes, so this mean double effort, making use of OOP pointless, once I would need to create many different classes for same database entity. Coding turns harder, maintenance turns no cool.

Am I missing something? Or this is a drawback of OOP approach?

Should we sacrifice a straight to the point, thin, faster code in order to get faster development and maintenance?

EDIT

As expected, some points I put before were misleading for some guys...

First, I'm seasoned to really really big projects (I worked at IBM vendoring for Sprint/Nextel USA and Directv North America, so I'm used to see some terabytes being processed daily).

When I said 50 people being retrieved from database, I don't mean strictly 50 people, I just want to gave the idea of many records. I know 50 records is nothing to today's servers. 50 million are. Imagine this last number if appropriate.

Answer 1

Here's the crux of the issue. As has been said before, there are tradeoffs to each and every paradigm. OOP has a lot of benefits, but it also has some negatives as you point out. The key is weighing them.

OOP is founded on the principal that developers are expensive and hardware is cheap. It uses this principal to lead towards highly maintainable (easy to fix in the long run) and highly adaptable code (easy to change in the long run). And if you buy the 60/60 Rule (which says that 60% of development time is in maintenance and 60% of that time is due to enhancements), then maintainability is the ultimate goal for professional programming.

If you get your head around how OOP works (I'm talking to the point of where you are thinking in a OOP paradigm) everything becomes really easy. I think you're still getting confused because you don't fully understand OOP. But then again, it's not the holy-grail of programming either, so if you're more comfortable using another paradigm, by all means use it. Choices exist because we are not all identical. Use what you're best at and what fits what you are trying to do best. If the only tool you have is a hammer, every problem looks like a nail...

Oh, and contrary to popular opinion, OOP is not about never coding anything twice. That's the DRY (Don't Repeat Yourself) principal. While it's often used with OOP, it's not directly attached to. In fact, I'd suggest while developing that you don't follow DRY as a rule. Shoot for it as a goal, but let it be a guideline more than a rule. As Fred Brooks said, plan to throw one away; you will, anyhow. (From The Mythical Man-Month ). If you strictly never repeat yourself, you're going to wind up re-doing a lot of work when it comes time to throw something away that you didn't get right the first time around. Only when it's built and running good should you start slimming it down and really making the code DRY. (personal opinion at least)...

Answer 2

It's as you said, a paradigm. It has strengths and weaknesses like any other paradigm. Where I think you're mistaken is the notion of what is materially significant. What makes 50 instances a big number? Perhaps to you keeping track of 50 discreet things is difficult (likely so for all humans), but that doesn't mean it's difficult for a computer. That 50 isn't big just because it seems big to you. It is certainly big compared to your example of a simple script to retrieve the data and collate the results, but the tradeoffs should be obvious, you listed most of them when you pointed out the strengths of OOP. The more interesting point to consider is when those strengths outweigh the weaknesses. Much more goes into that judgment call than what you've identified here, including the size of the codebase, the number of developers involved, their relative skill to each other, how long the code will remain in production, and much more.