In some programming languages, order does matter because you can't utilize things until after they've been declared. But barring that, for most languages it doesn't matter to the compiler. So then, you're left with it mattering to humans.
My favorite Martin Fowler quote is: Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
So I'd say that the ordering of your class should depend on what makes it easy for humans to understand.
I personally prefer the step-down treatment that Bob Martin gives in his Clean Code
book. Member variables at the top of the class, then constructors, then all other methods. And you order the methods to be close together with how they are used within the class (rather than arbitrarily putting all public then private then protected). He calls it minimizing the "vertical distance" or something like that (don't have the book on me at the moment).
Edit:
The basic idea of "vertical distance" is that you want to avoid making people jump all around your source code just to understand it. If things are related, they should be closer together. Unrelated things can be farther apart.
Chapter 5 of Clean Code (great book, btw) goes into a ton of detail on how Mr. Martin suggests ordering code. He suggests that reading code should work kind of like reading a newspaper article: the high-level details come first (at the top) and you get more detail as you read down. He says, "If one function calls another, they should be vertically close, and the caller should be above the callee, if at all possible." Additionally, related concepts should be close together.
So here's a contrived example which is bad in many ways (poor OO design; never use double
for money) but illustrates the idea:
public class Employee {
...
public String getEmployeeId() { return employeeId; }
public String getFirstName() { return firstName; }
public String getLastName() { return lastName; }
public double calculatePaycheck() {
double pay = getSalary() / PAY_PERIODS_PER_YEAR;
if (isEligibleForBonus()) {
pay += calculateBonus();
}
return pay;
}
private double getSalary() { ... }
private boolean isEligibleForBonus() {
return (isFullTimeEmployee() && didCompleteBonusObjectives());
}
public boolean isFullTimeEmployee() { ... }
private boolean didCompleteBonusObjectives() { ... }
private double calculateBonus() { ... }
}
The methods are ordered so they are close to the ones that call them, working our way down from the top. If we had put all the private
methods below the public
ones, then you'd have to do more jumping around to follow the flow of the program.
getFirstName
and getLastName
are conceptually related (and getEmployeeId
probably is too), so they are close together. We could move them all down to the bottom, but we wouldn't want to see getFirstName
at the top and getLastName
at the bottom.
Hopefully this gives you the basic idea. If you're interested in this kind of thing, I strongly recommend reading Clean Code
.