When you’re making a class, in what order do you put the fields and methods? We’ll look at several choices and some tradeoffs between them.
Organizing Fields
I’ve seen a few approaches to organizing fields:
- Put them at the top of the class. This is the most common style I’ve seen. It sets some context for what data you’re working with, and conforms to the order UML uses (class name, then fields, then methods). This is what I do by default.
- Put them at the bottom of the class. I see this rarely. But it makes sense in a way: the data is usually a key thing we’re encapsulating, so having it at the bottom puts it in a less visible place.
- Mix field and method declarations. I’ve seen this only a couple times, and both times it’s made me think “I bet there’s a class trying to get out”.
In C#, Swift, and some other languages, you can make something that looks like a field, but is really a code fragment that produces a value. After trying to put those at the top, I’ve come to feel this isn’t so helpful. Instead, I tend to treat them as 0-argument methods.
Organizing Methods
In what order do you put your methods?
Here are some ordering strategies I’ve seen:
(Do you have other strategies?)
Coincidental
You might think of this as “random” but it isn’t really. It’s what happens when you add things wherever they happen to land. When you’re extracting methods, they go wherever the IDE happens to leave them.
I’ve done this often enough. I think it’s because modern IDEs are good at navigation, and usually I’m going to a class because some code called it. This means I don’t notice the randomness unless I’m focused directly on the whole class.
Top-Down
Top-down is like newspapers’ pyramid style, with the high-level view before the details. High-level methods call lower-level methods. This is a sort of “depth-first” ordering.
Bottom-Up
Bottom-up is like a math paper, with lemmas before the main proof. The idea is “if you understand these things, it will be easier to understand the main flow.”
Public to Private
Put the public methods—entry points—at the top, and supporting methods below the entry points. This helps bring focus to the public part of the class.
Alphabetical
In some systems, you end up with long lists of methods, and lack tool support for getting to them. Putting the methods in alphabetical order makes them easier to find. I’ve also seen this when the methods don’t have much cohesion, i.e., they’re not very related to each other. Both these seem less than ideal to me.
But when no other approach seems helpful, I can understand the appeal.
Simple to Complex
Put easy methods first, then hard methods. This lets you work your way into the complexity of the class as you read more.
Levels
In some classes, there are clear distinctions such as policy vs mechanism, or high-, mid-, and low-level. You can organize sections to correspond to these levels. (When I see this, I almost always suspect it’s a class that’s asking to be split apart.)
Organizing by a Standard
For existing code, I tend to follow the approach that code appears to be using already. If an organization has a standard, I follow that. That helps me avoid the temptation to do low-value refactoring.
Tell a Story
I recognize that I’ve let a coincidental style happen too much, so I’m going to experiment with a more conscious approach. I’ll try being more “top-down”; if I feel experimental, I’ll try “public to private” (and then top-down).
My goal is that a class tells a story. I don’t expect a lot of drama, but I do want to feel like I’m taking a sensible tour when I read the code.
Conclusion
We’ve looked at several ways to organize the fields and methods in a class. How do you do it?