Class abstraction - how far to go?

I’m throwing myself into the world of object orientation and refactoring some old shoddy code, and I’m faced with the question: how far do you go with bundling things into classes? So far I’ve largely been led by my database tables - if there’s a table for something, then it has properties so let’s make it into a class - but the table structure is largely determined by cardinality, and there’s other ways to represent that in php, so is this really the way to go?

And obviously one object can contain multiple instances of another eg. an order object will contain ordered_product objects. So would you separate their behaviours to the point where database writing is the responsibility of each object? It certainly seems logical but, if there were a large number of ordered_product objects writing themselves to the database, it would be less efficient (more queries) than if the order object were to write all of its ordered_products to the database, if you know what I mean.

I can see that there’s pros and cons each way, and it’ll depend on circumstances, but I was just wanting to open it up for discussion.

It’s a big question and there is no simple correct answer.

You might consider skimming through Doctrines ORM manual. Especially the section on object manipulation and associations.
http://www.doctrine-project.org/docs/orm/2.0/en/index.html#reference-guide

It will give you an idea of what the more extreme approaches do and why.

how far do you go with bundling things into classes? So far I’ve largely been led by my database tables - if there’s a table for something, then it has properties so let’s make it into a class - but the table structure is largely determined by cardinality, and there’s other ways to represent that in php, so is this really the way to go?

Thats one step, albeit very rudimentry example of what OOP can do. How far you go is a mostly a matter of personal taste. My projects, almost everything is an object abstraction. There are probably 100+ objects created and used in every request.

Some might argue it’s unnecessary overhead I would argue the application will run just as fast or faster than a clunky poorly designed procedural application. Add caching and scalable practices to the mix and suddenly performance isn’t an issue but software maintenance still is.

There is no magic bullet in what should/could be an object or not. It’s a matter of experience and preference and project policy.

Cheers,
Alex

Hi,

I used to use about 60% class and 40% procedural code - truth be told almost 100% was procedural because my classes were really procedural code wrapped in classes.

Now I favour writing very class based works with composting classes together - it allows me more reuse and to build robust componets with thes modular classes.

i’m going to sound like a broken record, but one of the best ways to learn to better code is learn programming patterns, learn to unit test (SimpleTest), and learn how to refactor. If you don’t understand a patterns best use or implementation then ask and we on this forum will help.

Regards,
Steve

My opinion is that you should go all the way! Object oriented design uses less resources because the same object can be held by multiple objects. My table objects in the virtual web platform were using an insane amount of memory at one point because I was holding data in arrays and each row objected ended up with copies of data from the entire table. The minute I moved the data out of the table $_data array and into the row objects the memory problems vanished. There is no reason that your row’s cannot save themselves, and the table “can” tell each row to save itself, but there is nothing stopping you from adding a saveModified() function in the table object which updates every modified row in a single query. As a general rule, if the data is going to be used in multiple places than its better to encapsulate it in an object so that the same data is being worked with at all times instead of each process working on a copy of the data. If you have no use for PHP v4 than you can “protect” your data and use __get and __set to control access to it. This is how I’ve been developing lately and I’ve had incredible results speed wise, and resource usage wise.