My question to the website builders here is, is it at bad idea to create a user system for a website using objects in PHP?
I am not a web developer but I have a reasonable amount of experience with OOP and Java so it makes sense to me to model the user system in this way. I will have a number of different user types and also other objects that each user will interact with.
I am thinking this a bad idea thoough as having large numbers of objects (more than one each user) could get incredibly large and that would suck on RAM. You could use objects for online users only, so users interact with the website as an object, that is created when they log on and destroyed when they log off.
My thought now is, is this kinda pointless? Am I just creating extra work for myself?
I don't have any experience with web backend but typically objects will suck up ram (mostly depends how many people will be on your website). When I think of working with data bases I think of just a simple in, out to write and retrieve data. I wouldn't make it too complicated.
I was going to use the database to pull the info to/from the objects, and so the database calls are built directly into the user class. My hoping is that users are limited (improving security) to only the database calls that are predeteremined by their type.
But your point is why I am worried. Although I think the problem could be limited by creating all of the attributes as objects as well, using the user object as a shell. This way you don't need to create these attribute objects if they are not required, keeping the shell lightweight with only the most relevant data this is constantly accessed.
I could be completely way off on this one and it's a terrible idea. I do like the OOP approach as it makes reading and modifying code way easier. If there was no major downfall then I would think of going this route. The question is though, will objects (even lightweight ones) get too heavy eventually?
You have to understand a huge difference between a system programming environment like Java and a traditional web backend environment like PHP. A Java program is typically written to start execution and then run for long periods of time while performing many different actions and responding to events. PHP on the other hand creates a new worker for each request made to the server, executes the code and then dies. There is nothing left in memory after the execution has finished. If you want to persist some information across multiple requests you will have to use session data stored on the client-side written to a cookie. You can also optionally link this session data to information stored server-side in a database.
This is a good and a bad feature of PHP. Because each request runs all the code from scratch and the thread is killed after execution finishes you do not have to worry about memory leaks at all. You never have to watch out that some guy's account information gets sent to the wrong person because you forgot to overwrite some variable. The downside to this feature is that there is a tremendous amount of "setup" that needs to be done for each and every request. Just look at the huge mountain of code that Wordpress needs to execute for every request. That is where the need for caching comes in.
The slightly more modern approach is to use an event-driven environment such as Node.js as a backend but this is for the slightly more ambitious projects and the PHP frameworks are quite stable and easy to work with.
Howere, to answer your question about using OOP concepts in a user system, I can see no technical reason why this cannot be done and I think it is the right way to go. It certainly is what I would do. I say go for it.
Instantiating an object is not expensive. Don't worry about it.
In the case of a website, which uses the HTTP protocol, each request object is destroyed at the end of the request life cycle and the memory is reclaimed.
If you're going to use classes in this way you might want to look into the MVC pattern if you don't already know about it. I personally used classes in php as structs with the ability to hold functions which may or may not return a user instance. Something like...
class user {
public $name;
public $id;
public $is_admin;
public static function login($name, $password) {
global $con;
$prep = $con->prepare("
SELECT id, is_admin FROM `users`
WHERE name = ? AND password = ?
");
$prep->bind_param("ss", $name, $password);
$prep->execute();
$prep->bind_result($id, $is_admin);
if($prep->fetch()) {
$prep->close();
$user = new user($name, $id, $is_admin);
return $user;
} else {
$prep->close();
return false;
}
}
}
I think using classes is a nice way to keep yourself organised and have a set of functions handy to access your database.
Regarding the performance question, I'd say just take a look at source code to get an idea of how much creating objects really isn't a big deal when it comes to web development. I personally took a peek at phpbb's source code when I started out.
I recommend using objects for users, like for anything else. PHP doesn't use that much RAM, it would take thousands and thousands of users at the same time to really form a problem. I save all user data to the database and use sessions to temporarily save user data.
You should be using an OOP approach in all modern PHP apps. Using/creating an MVC framework is the standard these days in professional web dev, which are entirely OOP-based. PHP is written in C++, but it doesn't necessarily share the same frugality of resources when it comes to OOP. Be wary of running massive amounts of OOP code in PHP. We're talking a system managing many thousands of OOP objects simultaneously in a quick method. If you're making a simple user management class and helper classes, that shouldn't be an issue in the slightest, especially if your site is only going to be handling few users simultaneously anyway.