I'm wondering where variables used by class methods are best defined. I have a bunch of "working" variables that do not need to be part of the class interface. Given that, the private section would seem to be the place for variables that are shared between two or more methods. If a variable is only used in one method, then it can be defined in the method itself to avoid complicating the private section.
What's giving me pause is that I have a fair number of variables (a dozen or more) that are related, but some are only used in a single method, while others are shared. So it feels like I'm mucking up the private section if I put them all there, but if I define variables in the methods (where possible) then I sort of lose the "big picture" which would be to have all the related variables defined and documented together.
As I was typing it occurred to me that a struct in the private section might be a good way to go. This perhaps would best portray the relationships. There are still other variables that could be defined in the methods, simple and obvious things, return values and such, that are not related to the data in the struct.
My own preference is to keep variables that are only used within a method defined within that method. If I need to define variables that must be shared between methods, and passing them is burdensome, then I define them privately within the class. Just as you try to minimize coupling between classes, I think a good design minimizes coupling between methods within the class.
My own feeling is that programmers often try to design methods with the intent of creating a Swiss Army knife: "If I add just one more parameter to the method's signature, I can give it the flexibility to do two things rather than just one." This is almost always a bad idea. A cohesive method is one that you can describe to another programmer in two sentences or less. If it takes more than that, it's probably not cohesive and might benefit from breaking into two (or more) methods. If you're too worried about the interplay of your private variables, perhaps you're losing some cohesion for those methods.
As I was typing it occurred to me that a struct in the private section might be a good way to go.
That's an indication that you have the granularity too course: you may need to break the large class into a few smaller classes. When you're the only one using the code it's typically a tough call. There is a great deal of convenience to a large monolithic class but they can be difficult to maintain, enhance, and sometimes debug.
…if I define variables in the methods (where possible) then I sort of lose the “big picture” which would be to have all the related variables defined and documented together.
You’ve answered your own question. If you lose the big picture then they belong in the class declaration because they are part of the big picture.
Your reference to the Swiss Army knife brings to mind a Microsoft syndrome of loading an entire DLL to use one class.
Thanks guys, very helpful. Had not thought of more than one class but that definitely deserves consideration, I do get the feeling that it's difficult to see the forest for the trees at this point.
It seems to me, there is not a lot of room for the variables that represent the properties or state of a particular instance of a class, to be variables which are only used in one function of the class.