I'm saying they could, not should.
$student1->GetAverageScore() should return a value pertaining to $student1.
Student::GetAverageScore() cannot return the average score for an individual student as it isn't being told which student to get an average score for.
However, it could return an average score for the collective student body, which would make (a certain amount of) sense if the Class Student, represented a permanent storage of all students and Student::new( 'ID' ); returned an instance pertaining to the student who's identifier was 'ID'.
There could be a Class method, Student::count() that returned the number of students enrolled, but $studunt1->count() probably wouldn't make any sense at all.
Equally, a class method, Student::AveAge(); makes sense, but $student17->AveAge(); doesn't.
Like I said, where you put a method really depends upon exactly what it returns (or does) and that in turn depends upon what how you need to use it.
Don't be tempted to implement methods just because you can, whether class or instance. Only implement those you have a need for. You can always implement them later if the need arises, but pre-judging what might become useful has (at least) two downsides;
- It creates work at the start of a project when you are least able to resource it.
- It ties you to a specific implementation (or at least a specific interface), before you really know what the requirements are.
I'm not sure that I've explained myself very well, but that's why I don't write books :)
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
|