When to create objects/classes

[chris.cavage]

I'm learning OOP with PHP/MySQL.

I'm creating a CMS. Well, re-creating it. My first attempt at learning PHP taught me all procedural coding, and I'm realizing the benefits of objects as I'm rewriting the project. I have a few questions about what might be best practice.

Upon logging into the system, the USER object is instantiated -> a find() function is called in the user class -> a PHP session is created based on the user.id. The find function places the record data for the user data in an object variable for easy access throughout the website. To get user info, I'd do something like: $user->data()->first_name

The data() function here returns the data record information that was queried upon selecting a contact. So, then that is how I get the fields I need for the session created for my contact.

The user has a certain location they are assigned to. So, upon logging in, a session is created for that specific location's id. The user can change locations by selecting others tied to it's company_id (which is a field also in the users table). I'd display the location name similarly by doing this in my page: $location->data()->name;

On the site, the user can search for contacts. When one is selected, another PHP session is created and stored for the selected contact's id. This way the contact->data() can be referenced and worked with site-wide. The user must deselect the contact, at which point the contact PHP session is deleted. The contact session is also removed and updated when the user selects another contact naturally. Only one contacted can be worked with at a time. I can access only fields from the contacts table right now with: $contact->data()->field

My contact's class, when looking for a contact, does a db query that finds a contact based on a contact.id. It returns the row's data in a data variable.

The point of this system is to keep track of invoices and hearing aid data associated with the patient, really. It's for a hearing aid company. All contacts (aka patients) enter into trials with hearing aids, so I have a trials table that has specific trial fields. Of course, the trials table holds the contact.ID primary key as a reference to the contact. All contacts in the system MAY or MAY NOT have trials, repairs, invoices, etc. Some just have only their names and addresses: affecting only the contacts table which stores that basic info.

I will need to display the contact's trials in a table. I'm guessing a table format is the best way to display this. The trial data can be updated/deleted. I can manage that by using my DATABASE class which has update and delete functions which require the id to be changed.

I have also made the general database class to handle any query to my db.

Should I just use my database class to search for information (using joins when needed) and display it? Or in OOP, should I be thinking of ways to put the trial information in a variable in my CONTACTS class? Like by maybe creating functions in my contacts class that are called get_current_aids(), get_all_trials(), get_all_invoices() and then store the row information somehow in variables to access as I need them? The functions would use the database class to query the db for necessary info.

Or I can just do a raw query using the database class (since it's set up to do that) and display any info I want? Not sure if it matters, but I'd be doing many table joins to get proper names of referenced models, manufacturers, etc. of hearing aid trials, for instance.

I'm also wondering the same thing about invoices created, repairs that have been done on the hearing aids, etc. Get the data in the class or just query the database as I need the info?

Some of this joined data, whether it's repair info, trial info, invoice info, will need to be displayed on various pages within the site. They will be updated, added to, deleted frequently. Especially the appointments table!

Thanks.

Any advice is appreciated. Even if something I said seems like it could be set up or executed better.

[bestellen]

Object-oriented programming is a style of coding that allows developers to group similar tasks into classes. This helps keep code following the tenet "don't repeat yourself" (DRY) and easy-to-maintain.

"Object-oriented programming is a style of coding that allows developers to group similar tasks into classes."

One of the major benefits of DRY programming is that, if a piece of information changes in your program, usually only one change is required to update the code. One of the biggest nightmares for developers is maintaining code where data is declared over and over again, meaning any changes to the program become an infinitely more frustrating game of Where's Waldo? as they hunt for duplicated data and functionality.

OOP is intimidating to a lot of developers because it introduces new syntax and, at a glance, appears to be far more complex than simple procedural, or inline, code. However, upon closer inspection, OOP is actually a very straightforward and ultimately simpler approach to programming.

[chris.cavage]

Wow, that was very well said. Thank you.

You clarified a lot of things by saying that.

I never really looked at OOP as a group of 'common tasks' in a class. I can understand why that's so important vs procedural code.

I really liked your response. Thanks.

[kfcSmitty]

Not sure if bestellen, is actually the "Jason" from this blogpost, but if you like bestellen's explanation and would like more detail, it was pulled from the following link, and it goes into much more detail.

http://code.tutsplus.com/tutorials/o...ers--net-12762

[chris.cavage]

That's great, thanks!