Static Methods

[moon 111]

I'm not totally sure, but I think I've figured out when to have static methods (besides in things like Singletons).

 

If for example I have a class for storing information about a user and then acting on it, it wouldn't be static. However, if I had a class that, for example, is a collection of methods for adding and deleting users it would be static.

 

Am I getting it right?

 

Thanks

[rhodesa]

Yup, that is another example. For example, whenever I have a user class, I usually have a getAll static method that will return all the users as an array of user objects. But, anything more complicated then that (as far as collections of objects), I would create another class. So, for instance, if you had families that the users were in, that would probably warrant it's own class.

[nloding]

My best example is form processing.  My Process class handles the validation and processing of a handful of my forms.  For the validation, it calls the Validation class, which is entirely static.  Validation::Password, Validation::Username, Validation::Email, etc., are all called and return true or false.  They don't need anything other than the one variable that is passed to them.  However, my Process class has many other objects inside it, as well as private variables, and more, and it would be weird to make it static.  To me, it's always been about flexibility.  Validation will never need anything more than the single input variable.

[KevinM1]

I think a good rule of thumb is to ask yourself whether or not you need direct possession of an object for it to do its job.

 

For instance, a lot of factories (classes used to construct objects out of raw data) use static methods.  Why?  Because you don't want your hands on the factory, you want them on the object(s) the factory creates.

 

The same goes for nloding's validator.  He doesn't need to have possession of a validator object, he just needs the boolean return value (whether the data passed in is valid or not).

 

Keep in mind, though, nothing is set in stone.  You could very well need to create a validator object, for example.  One such reason would be to count the number of failed inputed values.  It makes more sense to keep that functionality as part of the object than to litter the client code with the incrementation of those values.

 

I hope this helps and hasn't muddled things further.

[moon 111]

OK, I've figured it out.

 

Thanks