OOP Best Practices Question

Rodney_H_

OK, so I must admit that I am still transitioning to OOP programming, and have been very comfortable in the land of procedural coding. But I think you can teach an old dog new tricks, and I thought I'd give it the old college try... again. And, I have actually been doing pretty well, but I came upon a conceptual question that I wanted to pose to you with more experience:

When working in the MVC design pattern, is it best to create a class/model for each table? Or is it OK to combine similar things into one class?

Here is the example MySQL table structure:

products_names
products_images
products_categories
products_associations

Would I create a class/model for each table and then create an object out of each distinct "product name" and an object out of each "product_image" OR...

Is it best to perform MySQL joins within the class/model, and return an object containing for example, all of the following information about a product:
-Name
-Image(s)
-Category

Any insight that you could share would be greatly appreciated.

Peace + Thanks.

_rod

laserlight

In my opinion (and I am not a seasoned professional developer), we should look at what we want to model in the problem domain. In different parts of the script, we might use different classes that access the same underlying storage, but model the entities slightly differently.

Of course, the rule of thumb is that after we have normalised the database, the tables generally correspond to classes and the columns to the member variables of these classes.

In your example, it looks like there is a one to one relationship between products_names and products_images, so I am guessing that they were not combined for reasons of efficiency. In that case, I might have a Product class that corresponds to the table created from a join of products_names and products_images.

If I wanted to follow the rule of thumb, I would create a Category class that corresponds to products_categories. Then, to link Product objects with Category objects, I would have an array of Category references in Product, and an array of Product references in Category. This models the many to many relationship between products and categories as expressed by the products_associations table. Of course, it means some careful consideration when it comes to removing a product or a category, as one has to follow the links to ensure no dangling references.

Rodney_H_

Hi Laserlight.

Thanks for taking the time to explain your thoughts on the matter. Do I understand what you are said below is that it really depends on what it is we need to model, and what data is needed to provide for a specific view/page?

laserlight wrote:
...we should look at what we want to model in the problem domain. In different parts of the script, we might use different classes that access the same underlying storage, but model the entities slightly differently.

If so, I think then what you are saying is that in some cases, creating JOINs in the classes is certainly acceptable.

Here is another question then: Can I create an object that holds and returns a multi-dimensional array, such as:

$products->get(array(0,1));

Holds...

PRODUCTS[0][name] , PRODUCTS[0][image], PRODUCTS[0][description]
PRODUCTS[1][name] , PRODUCTS[1][image], PRODUCTS[1][description]

OR, is it best that I put each array item into it's own object?

$umbrella = $products->get(0);

Holds...

PRODUCTS[0][name] , PRODUCTS[0][image], PRODUCTS[0][description]

and

$goulashes = $products->get(1);

PRODUCTS[1][name] , PRODUCTS[1][image], PRODUCTS[1][description]

What are your thoughts on this?

Rodney_H_

I think I have an answer to my own question here, Laser Light:

Models are written as classes, BUT, their purpose is specific.

I can have Models and other Classes for slightly different purposes.

In other words, if I need a class for a specific purpose on the site (that utilizes complex joins of MySQL tables when needed), I can.

AND I can still have models for their basic needs of adding and updating/deleting table by table in the DB.

What do you think?