Getters ought to be present to provide access to well defined attributes of an object. If, for example, the object measures something, I may provide a getter to allow a user of that object to extract the specific value that has been measured. One should always be stingy in offering getters. After all, once you have put it in your public contract, it's a whole lot harder to remove it.

When an attribute is a collection, it gets more "interesting". Fowler, in "Refactoring", describes one called Encapsulate Collection. In that refactoring, you don't return the raw collection with a getter. You return a read-only version, if you must return the collection, and provide add and remove options (as appropriate) to permit modifications. That keeps changes under the control of the object.

Now, Fowler speaks specifically to a Java audience, but the concept here is worth keeping in mind. The key is to contract to provide data in a particular format and then to keep that contract. Try to choose a format that gives you the flexibility to do what you may need to do on the inside without having to go through extra contortions to keep that contract.

I've been doing some Java programming to help firm up the knowledge I gained in a recent class. It's been usefully interesting. I expect my Java experience to inform my Perl programming in useful ways. On the other hand, there are things Perl makes so much easier. I have not yet sorted out if and how to say "foreach my $f (fn_returning_list()){do stuff}" without the structural overhead of creating an iterator and explicitly walking it.