Question on the best way to set up OOP class relationships

[dgruetter]

Hi, I was wondering if anyone would be able to give me some ideas on how I should structure the classes for a website I am re writing (this time in OOP).

 

The website is a bridal website where brides can register an account and search for vendors by category, regional area and various other ways. They can interact with the vendors by bookmarking them, writing reviews, etc. The vendors can register and also have actions they can perform.

 

I was planning on writing an abstract class "user" and extending two classes from it, "vendor" and "bride". The commonalities would be things like "name" "email" etc.

 

My question is how to present the search functionality. Should I have a class called vendor search that lists the vendors found by the MySQL query? Would this make logical sense?

 

If so should the vendor class be responsible for displaying it's information (example vendor->DisplayListing()) or should the search object do this (vendorsearch->displayVendors)?

 

I have a good understanding of classes but thinking through the logic of who does what always trips me up. There are more classes I was considering like "admin" and "geography" assuming it makes sense to do this.

 

Any ideas would be much appreciated.

 

P.S. the website is here: http://www.thebridalvine.com/vendors.php

 

I plan on to set up

[ignace]

The website is a bridal website where brides can register an account...

 

$brides = new BrideRepository($db);
$brides->addBride($_POST);

 

..and search for vendors by category, regional area and various other ways.

 

$vendors = new VendorRepository($db);
$vendors->findByCategory($_POST['category']);
$vendors->findByRegion($_POST['region']);
$vendors->findByRegionAndCategory($_POST['region'], $_POST['category']);

 

OR

 

$vendors = new VendorRepository($db);
$find = new VendorSpec;
$find->whereCategoryIs($_POST['category']);
$find->inRegion($_POST['region']);
$find->matchAny();
$vendors->findBySpec($find);

 

They can interact with the vendors by bookmarking them, writing reviews, etc.

 

$brides = new BrideRepository($db);
$brides->find($id)->bookmarkVendor($_POST['vendor']);

 

$brides = new BrideRepository($db);
$brides->find($id)->publishReview($_POST['title'], $_POST['body']);

 

The vendors can register..

 

$vendors = new VendorRepository($db);
$vendors->addVendor($_POST);

 

..and also have actions they can perform.

 

$vendors->find($id)->..

 

I do not encourage though that you will start to use this as it's serious overkill for your needs. OOP should only be used when your application has some serious business rules that are harder to accomplish/maintain when programming procedural.

 

The above may seem to be not that much work, but that's because you are only looking at the abstracted layer. The BrideRepository for example communicates through different Table Data Gateway's to retrieve it's data: bride table, bride_bookmarked_vendor table, and bride_published_article table.

 

I have a good understanding of classes but thinking through the logic of who does what always trips me up.

 

defining/finding new responsibilities and boundaries are easy for me, it's always figuring out a damn name that clearly communicates what the class does that trips me up. Having conventional names kinda helps but not entirely.

[dgruetter]

These are some great ideas. I think the concept of having the vendor and vendorsearch as two different classes. Maybe I can even expand on the vendorsearch class and make it abstract too. Since people can search for more than just vendors (for other brides for example). Maybe I can have just a search class and extend it for vendors, brides, articles, etc. Or.. maybe I don't need the vendor class at all.

 

You say that OOP might be overkill for my needs, perhaps this is true. I have the foundation of the site already written in mostly procedural code. The problem is that moving forward has been very challenging. Since it contains a lot of if/then/else code it makes even the simplest changes affects the entire site. This is where I hoped to benefit from OOP. I was hoping to cut some of the spaghetti code and make it more elegant.

 

Lots to think about.

 

Thanks for the reply. These ideas will be extremely valuable when weighing out options for my re-write.