Explanation of re-usable structures in OO PHP

Question

Can someone please explain "re-usable structures" for me? I was working on making some db objects in php, but was told I was using too much processing from the computer cause I made stuff to complicated with the below objects:

My DB objects:

$db = new Database;
$db->db_connect();

$post_content = new DbSelect;
$post_content->select('id', 'title', 'firstName', 'created', 'catName', 'tagName');
$post_content->from('content');   
$post_content->join('inner');
$post_content->on('category','cat_id','id');
$post_content->where('id','1');
$post_content->order('created');

$db->db_close();

Normal PHP:

mysql_connect();
mysql_db_select();

$query = 'SELECT id, title, s_name, created, cat_name, tag_name
                FROM content
                JOIN INNER category, cat_id, id
                WHERE id=1
                ORDER created';

mysql_close();

So to reiterate my questions: 1. A quick explanation of re-usable structures? 2. why is the first method using objects "wrong"?

please note: I'll be googling this as well as hoping for feedback I know there a "tools" like Zend and other's that have plenty of db objects built into them, but I'm trying a DIY approach

Answer 1

I'm not sure where to start on this one. Object Oriented design is not a trivial subject, and there are many ways it can go wrong.

Essentially, you want to try to make logical indepedent objects in your application such that you can swap them out for other modules with the same interface, or reuse them in future projects. In your database example, look at PEAR::MDB2. PEAR::MDB2 abstracts the database drivers away from your application so that you don't need to worry about which specific database you're using. Today, you might be using MySQL to run your site. Tomorrow, you might switch to Postgresql. Ideally, if you use a proper OO design, you shoudn't need to change any of your code to make it work. You only need to swap out the database layer for another. (Pear::MDB2 makes this as simple as changing your db connect string)

May I suggest reading Code Complete by Steve McConnell. There's a whole chapter on Classes. While the examples are primarily C++, the concepts can be applied to any programming language, including PHP.

Answer 2

It seems that your solution involves more typing to achieve the same thing as the "normal" way. The string SQL would be more efficient than allocating memory for your object.

You should check out the Active Record pattern if you want to create a data abstraction layer with more features than just a select.

Answer 3

Don't confuse object-oriented-programmed with "class-oriented" or "object-based" programming. They both, on the surface, can look like OOP but are not.

These are when you take structured code and wrap in a bunch of classes, but don't change the fundamentals of how it operates. When you program with objects in mind, but don't leverage any of the special conventions that OOP affords you (polymorphism, aggregation, encapsulation, etc). This is not OOP.

What you may have here is some of this type of code. It's a little hard to tell. Is the purpose of your DbSelect class to abstract away the raw SQL code, so that you can use connect to any database without having to rewrite your queries? (as many DBAL solutions are wont to do) Or are you doing it "just because" in an effort to look like you've achieved OOP because you turned a basic SQL query into a chain of method calls? If the latter is closer to your motivation for creating this set of classes, you probably need to think about why you're making these classes and objects in the first place.

I should note that, from what I can tell by your simple snippet, you actually have not gained anything here in the way of re-usability. Now, your design may include code that gives flexibility where I cannot see it, but kind of suspect that it isn't there. The procedural/structured snippet is really no more or less reusable than your proposed class-based one.

Whomever you were talking to has a point - developing a complex (or even simple) OOP solution can definitely have many benefits - but to do so without regard to the cost of those benefits (and there's always a cost) is foolish at best, and hazardous at worst.

Answer 4

If you are using DbSelect objects to build queries from complicated Forms, then you are doing the right thing.

Query Object pattern