I’m trying to learn PHP OOP “properly”, and I was wondering, should the constructor grab all the information in the database and store it in the object?
To use an example I’m trying to create using PHP OOP, an internet comic website (much like XKCD’s), would have two classes:
- Catalogue (list and order of all the episodes)
- Episode (data relating to that particular episode)
So, in this situation, should the Catalogue object get an array of all the episodeIDs (presumably this would be gotten in the constructor)? And if so, does that mean I have to update both the Object’s array and the Database’s array? And if so, what’s the most common way of implementing this (presumably very common) action?
0
There are a few different approaches you can use to do this, depending on the data set, performance needs, and your general preference.
If there’s an object that is used almost exclusively for display, you would probably want to query the dataset beforehand in some sort of Factory and then create the object by passing the data into the constructor.
If there’s an object that touches a bunch of data sources and is used for different things, loading all of the data at instantiation might take a long time, and all of the object’s data might not be needed every time that object is instantiated. You can leverage lazy loading to accomplish this goal.
If performance is a major concern, and the object stores a ton of data but is mostly immutable, you can use something like the Flyweight pattern, which allows you to actually treat a single object like a collection.
I highly recommend you try a few different ways of doing things. For a project such as yours, how you choose to instantiate and populate the object will probably matter little, but it will be a good and fun exercise in different object instantiation patterns.
As a final note, much of the knowledge you’re gaining now about OOP can be applied to nearly any language you learn in the future.
I am a huge fan of the way Magento has abstracted their database layers into multiple levels and collection model relationships.
This may not answer the question directly but could open the door to thinking about data base objects a bit differently.
The way you would call a single customer is something like:
$customer = Mage::getModel('customer')->load('20');
Where the getModel method instantiates a class that is magically loaded from an XML definition file. In this case let’s say that it is called Mage_Core_Model_Customer.
Your basic model almost always extends from a parent class which handles database abstraction and that class extends from a generic object class which sets up magic getters and setters for all model classes. So if anything extends from the database abstraction it also picks up the getter and setter methods.
In doing load('20') you are specifying that you would like to load the database object with the key id being 20.
Now specifically on your question. Magento also uses relational mapping between each entity and their seed object. For example a customer can have many addresses. Their address is not naturally returned back as a part of the object, however if you wanted to get a particular attribute not included in the seed table you would do something like this:
$collection = $customer->getCollection()
->addAttributeToSelect('address1')
->addAttributeToSelect('address2');
$collection->load();
A collection is basically just a list of database objects.
This becomes a well designed solution because the objects are not coupled to each other as a single entity. Instead, you can filter each association separately.
Please no comments about how none of the code here would work in Magento. This was for illustration