thunderroms wrote:Hello, I know what object oriented programming is...
I would respectfully suggest that your other questions indicate that this may not be 100% true.
$objectOrientedProgramming !== $usingClasses
Classes are a mechanism designed to facilitate object-oriented programming, but it is entirely possible (though more difficult) to develop an object-oriented application without them, just as it is possible to develop a procedural application while using classes.
OOP is generally of limited benefit to small, independent, one-off applications (which may be an apt description for many simple PHP web pages). OOP's power becomes more evident as applications become larger and more complex, and as its usage allows you to re-use more and more code both within an application and across many applications.
thunderroms wrote:1-How do you keep your objects? For example if we had a shopping cart, would we create a new shopping cart object and everytime the user adds/removes items update that same object? and how would you keep that object's information as the user browses through the site? Would you use serialize/unserialize session variable functions? or is there a better way?
For something as complex and important as a shopping cart, my inclination would be to store it in the database; possibly just serializing/storing the object itself in the DB, or perhaps using a destruct() "magic method" to save the relevant data, which can then be retrieved by the construct() method in subsequent page visits.
thunderroms wrote:2- For example, if we have a website that has users why would we want to make a "Users" class containing all the user information? Can't we just insert/retrieve data directly from the database? and when we get the data from the database what exactly is the point of creating an object out of them when we can just print it out? I guess my question is why would having a Users class be useful in a php web application? (assume users have name, username, password, address, etc.)
One benefit of a User class would be if there are common actions you perform with a user's data in more than one situation. Those actions would become methods of the User class, immediately giving you reusable code for all your pages that perform those actions. On the other hand, if all you use user data for is access control and have no intentions of expanding user-based functionalities, then it may be sufficient to just have the user data be part of your access control class(es). These are the sorts of decisions that need to be made during the application design process: there are few hard-and-fast rules I know of for such things, as there are almost always gray areas that can be handled in a number of ways. You need to try to pick the best solution, and be prepared to "refactor" your application when you find out later that you chose incorrectly. 🙂
