So, I program in a procedural way for the most part, but have some experience with objects in PHP, Java, and a little C++. For my current project, Im considering making a switch to objects but I'm confused about whether or not this will be beneficial from a performance point of view.

My project deals with online flash cards, and its built in code igniter. The way its set up right now is that I use a function for each thing i need to access, and they are pretty unrelated. So, if I just need to display the title and description of a deck, I might call a function like:

Then, if I'm displaying the deck info along with that deck's tags, votes, comments, individual cards, and some other things, I'll simply call a function for each thing, set the results to an array, and then loop through the array and display those things.

I'm thinking my code would be nicer if I just made a deck object to handle all this, but I'm worried that an Object Oriented approach will use more resources than necessary.

For instance, If I had my deck object, it would take a deckId as a parameter and in the constructor it would get the basic deck info (title, description, dateEdited, etc). Then if I wanted the comments I would call $deckInstance->getComments();

What I'm worried about is that in many cases, like when I update the comments with ajax, I will only need the comments and not the basic deck info. It seems like I'm completely wasting a query in the constructor to get the basic info if i'm only going to use the comments. Is this worth worrying about? Should I not have the constructor get any data, and reserve the basic info for its own method? This seems strange though, for a deck object to exist, and not even store its title or the id of the user who created it.

Also, I have considered getting all the data in the constructor, so that I could access it all easily after making an instance of the object, but I feel like this would be a major waste of resources.

If I go the route where the constructor does not go to the database at all, then I feel like I'm not benefiting much from the Object Approach, I'm just grouping together a series of procedural functions.

Sorry this is so long, but I never know when or how to best use objects. Any thoughts?

__________________
Something interesting... If you visit one of my sites today, you'll probably double my unique visitors for the day! Shameless Plugs:
My Blog My Octopus Game My Flash Card Website

Explaining how to use objects right is a task I have tried to do numerous times over the past few years. I have never been able to do it and I really have never been able to find anyone who could. I have come to believe that experience is the only way to do this. You will have to make some apps where objects end up get in your way and make things difficult (obviously do not plan to this from the get go). You will eventually begin to think in objects and begin to know what to do from the planning stage.

__________________

Hey, thanks for the response. I think you're right. I'm planning to go for the object approach take the route which minimizes queries. It should still be helpful to have the object, I think, since it will make my controllers cleaner and move more of the logic out of them. I hope it will be good.

Your answer was actually helpful, and I've been kicking this design around in my head for the last few days, so I'm to the point where I think I've got a pretty logical way of doing everything.

Programming gets weird at this point, now that I no longer struggle to simply make something work, but I struggle to make it work in the best possible way... Thanks again

__________________
Something interesting... If you visit one of my sites today, you'll probably double my unique visitors for the day! Shameless Plugs:
My Blog My Octopus Game My Flash Card Website

Village Idiot hit the nail on the head pretty much - in most circumstances you aren't going to know what the best method to use is, until you've had enough experience under your belt to visualize the process and desired results without even putting a finger to your keyboard.

One of the problems a lot of newcomers to OOP face is that after they've learned the ropes, they go OOP crazy, and find some reason to turn everything they've done into some form of object oriented programming. Right down to the loneliest of procedural functions. Avoid this peril at all costs! OOP is an amazing construct, but it's not always the best construct - the beauty of PHP is that you can mix and match to your hearts content, and since I learned that fact, most of my major apps have since wound up being a hybrid of both.

When you use OOP, think of it as a container. What needs to be in the container? What doesn't? If you turned your car into a program you could make an amateur mistake and make one huge object that controls every aspect of your engine operation. This would quickly equate to failure, as you would find it was so complicated and convoluted that you didn't know your blinkers from your spark plugs. Now (and this is greatly simplified of course) the better idea would probably be to make three primary classes. Intake, Combustion, and Exhaust. These would handle their departments seperately, but could easily be put together to make your car move. Now what about fuel management? This aspect is usually controlled by sensors installed in all three major elements of your cars engine. So why not make this functionality procedural, so it can be called from anywhere inside the other three objects, or outside of them if necessary? The biggest thing you would want to avoid is putting an exhaust related function in your intake class.

The makings of a good programmer right there. I've dealt with too many scripts written by 'experienced' programmers that make mistakes I made on day one, simply because they've never strived to improve performance (or their own understanding of what makes things tick).