php oop and database

You could use the row to create an instance or have the object wrap the row. In either event, you could add logic for dealing with the database row. Eg. a recipe object might define a method called containsGluten, or one which creates a formatted representation of the recipe. Sometimes you might not gain much, but other times, you might be able to get something that is more user friendly and abstract (represents an interface, with options to alter implementation details). Most objects are just simple data, rewritten to give you bundled functionality and a logical entity that's easy to think about. You can think of the Recipe as a recipe, not a table row. The organisation of an object can help with composition, and avoiding creating god objects. Alena Holligan also posted a long answer on when to use object code vs procedural at https://teamtreehouse.com/community/when-to-use-oop-over-procedural-coding if that helps.

The database just stores the data. When you retrieve that data you'll need to put it into SOME type of variable so you can actually do something with it. This variable would be either an array or an object, depending on how you decide to retrieve that data. So if your data is in a database, you would retrieve that data (with something like PDO) which would create the object for you. So the recipe object would use the PDO class, not the recipe class we wrote in the course. But if you wanted to add specific "methods" (functions) to the class, you could create your own class. That class could either extend the PDO class (which we haven't covered yet, but check the link to learn more), or pulls the data from the PDO object. Then your data and functionality could be wrapped together.