So my current understanding of classes are:
Singleton for a class that will only ever be instantiated once.
Static for a class that doesn't get instantiated but just exists.
Regular? For a class that can get instantiated over and over.
So I'm doing a small open source project and as for dealing with users, I thought of how I could deal with it, for example:
Creating a user - I could instantiate a users object and then call a method create on it. Or I could have a singleton so the users object always exists and call create on that?
I just think it seems sort of sloppy to create an object for each user related action, like updating a users credentials, would I want to instantiate another user object and then call a method update on it?
Just confused about how to actually apply OOP, and the best way to do.
Thanks for any/all help you guys can provide.
You should make sure the necessary objects are created in constructors. Then you can call the appropriate methods to complete the actions.
To be honest, I would suggest reading several books on OOD/OOA/OOP before continuing forward.
Are you using a particular framework for this such as CodeIgniter or Zend?
I would recommend using some sort of MVC framework for this project . Within this I would then define a user controller and model.
A singleton may work for the user object have a look at this article for some more details on developing a good singleton in PHP.
I don't think I've ever actually created a singleton personally. I know that they've had their uses historically, but I've never actually touched one. I have built some static classes but they're rare, and unless you really understand threading, you can't guarantee your singletons and/or static classes are truly unique. This is only becoming more and more of a problem as multi-core PCs and servers proliferate.
Now, me myself personally, this is how I would probably think of this. If you create a static class with a CreateUser() function, then that doesn't seem like a User class. That's a class that creates User classes, so it's probably a UserManager/UserFactory class. That's one pattern I've used. Having a class to manage object creation is a good choice when the creation is a complex issue (e.g. factory classes encapsulate object creation when you change the object a lot, and / or you have many versions of an object that you have to choose between. a factory would only contain code for object creation though, if you create an object and do other things with it as well, then it's not really a factory, it's a more general purpose manager)
The alternative, like praveenkv1988, is to write whatever code you need to create a user in the constructor logic. It doesn't make sense to me to instantiate a user object and then call a Create() function against it. If you asked me to explain instantiation to a non-programmer, I would probably explain it as "creating an object". Therefore, any creation code should be written into the constructor because that's the function which is automatically run when the object is instantiated. This is a good choice when a manager or factory class just seems like overkill.
Once your User is created, then absolutely, you can start calling methods against it. In your example, if you change the data in it, it makes total sense to have an Update() function to run which saves the changes back to the database. But you can also create a pair of users and compare them to see if they're the same (that would be one way to approach authentication), or whatever else you want to do.
Cant you just do this:
$user = new User();
private $_user = array();
public function __construct()
$this->db = Registry::get('database');
public function create($name)
$this->_user[$username] = 'i dont know';
public function delete($name)
public function get($name)
// or if you wanted to get their db creds...
//this->db->query("select * from users where name = '$name'");