And don't automatically make a getter & setter for every field, unless you're in a specific situation like a Data Transfer Object where that's the whole point. Most objects are better with a "tell, don't ask" design. Don't ask an object what all it's fields are, just tell it what to do with those fields. Often that means putting more code into the class instead of outside. It might be a theoretical ideal if an object has all private data and only "behavior" methods that do useful things for you.
Kent Beck says it's a warning sign if you get two or more fields from an object and do something with them. It's an even bigger warning if you put the result back into the object. See the entertaining Knight's Principles for examples. [ July 20, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi