php static functions vs instance functions, basics

I'm trying to learn when static functions should be used, and have had a difficult time finding an answer my questions. I am creating a class User, which is related to a class Group. If I have a user id and I want to get a user object from that, is it better to do something like

$existingUser = User::get($userId); 

where the class is defined like this

class User()
{ 
    public static function get($id){
        $user = new User();
        return $user->findById($id);
    }
    public function findById($id) {
        //find and populate user object
    }
}

or

$existingUser=new User();
$existingUser->findById($userId);

where the class is defined like this

class User()
{ 
    public function findById($id) {
        //find and populate user object
    }
}

---

What about if I were to write a function which returns an array of Group objects based on a user id?

class User()
{ 
    //stuff
    $groupArray = Group::getAllByUserId($this->getId())
    //stuff
}

or

class User()
{ 
    //stuff
    $group = new Group();
    $groupArray = $group->findAllByUserId($this->getId());
    //stuff
}

The second method creates an empty group object which is never used. Does it matter? Am I misunderstanding the concept of static? I know it is useful for not having to instantiate a class, so if the function instantiates one anyway, does that kind of defeat the purpose? If so, what would be an example of when a static function wo开发者_如何学Gould be used?

Anything else I should be considering in this over simplified example?

---

You don't need a static function int he case you show above.

Static functions are really just global functions with a namespace.

Use them when the global state of the application needs to be controlled, or if multiple copies of the function lead to inonsistant results.

Callbacks sometimes need to be static, especially if they are passed as a string.

---

I'm trying to learn when static functions should be used

Oh, it's so simple: never.

To understand it, read:
http://www.objectmentor.com/resources/articles/ocp.pdf
http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

---

I find a good rule of thumb is thinking "If I don't have a [class-name], would I expect to be able to call [method-name]?"

If I don't have a user, would I expect to be able to call findByID? Probably not. This is one of the exceptions I come across; a "load" or a "save" method sometimes makes sense to be static.

A perfect example of when to use non-static methods is (most methods in) a Database class - you should always have a database object before you try to run a query on it.

An example of when to use a static method would be a "helper" class, essentially a collection of handy functions. Say you have some methods that help you output HTML, you might have HTML::image(), HTML::url() and HTML::script(). On these, you shouldn't need a HTML object to create an image, URL, and so on.

As for stopping multiple copies of objects being created (one argument for using static methods), you should use a Singleton pattern instead (Google it) to ensure only one copy of the object ever exists.

---

You should probably check out this question on Active Record vs data mapper:

https://stackoverflow.com/questions/2169832/data-mapper-vs-active-record

One take from this question is that static methods on the class for loading/saving aren't really the core functionality of the class in most cases. Further, storing and loading is a kind of abstract concept that is separate from your class objects in most cases.

Isa "user" a data storage and retrieval object? In most cases, no, it is a person represented in your system that has various properties and functions. When you start tying the persistence of that object into the object, you break encapsulation and make it harder to maintain the code. What if next week you want to load your users out of memcache? It's hardly relevant to if a user can have some property or functionality.