You should have very few (ideally none) pure mutators -- greater encapsulation is achieved when any state is maintained only through the use of methods which perform some higher-level concept, rather than for there to be the possibility that state is directly modified from the outside.

This is not to say that its always wrong to have state which is directly modifiable from the outside, sometimes its simply the right tool for the job. However, better designs should tend to shy from such things and an over-reliance on externally-modifiable state, especially between classes which are not otherwise logically coupled in the design space, would indicate that the developer has probably failed to demarcate the lines of responsibility clearly. More plainly stated, and over-reliance on such pure mutators is a code-smell.

Most people, I think, fall into this trap when they design their classes around data, rather than around responsibilities. Think of a class first as the role it fulfills in the design, what methods it needs to perform its work, and only towards the end begin to think about what state it needs to maintain to achieve those goals and what state is should expose to clients.

Therefore, there is no budget or allowance that can be recommended to you. Try to avoid pure mutators and accessors as best you can, use them when it *really* makes sense, and don't loose any sleep over it.

I've noticed as I get better at designing/coding my classes have gone from usually having many accessors/mutators to having almost none - objects should just "do things". Too many accessors is, in my opinion bad design. Whats too many completely depends so that itself is not very useful. I wouldn't be afraid of bloating the class with methods, I'd be afraid of bloating its interface (which many accessors/mutators do). If you can encapsulate parts of an object in further objects (and combine with composition) then even better. Just my opinion of course.

I find it quite rare to use accessors/mutators, usually the constructor is enough to setup the object once. If I do need alot of access, such as creating a loader type object (and not wanting to add loading functionality directly to the class) I'll just friend the loadeer object rather than making alot of accessor/mutators.

What language are you using / do you intend to use? This can sometimes make a rather large difference in the way you implement an interface, or, indeed, even what is or is not a part of the interface. In Java, for instance, you are forced into the mentality that "everything is a class, or belongs to a class" -- that is, there are no free-standing functions. C# is similar, but has the concept of "extension methods" which exist as part of a class outside of the class they operate on, and can only use that class's public interface, but which appear, syntactically to be a part of the class it operates on (This is how they implemented the LINQ stuff, for example). Then there's C++, where free-standing functions in the same namespace as a class are considered to be a part of the class's interface, due to the way lookup resolution works (Koenig Lookup).

Then you have still more dimensions which affect interface design -- does your language support anonymous functions (the cool kids call them lambdas)? Those can sure be used in a lot of creative ways that can provide flexibility without breaking encapsulation. What about C++ Templates/Java Generics/CLR Generics? Same idea, very different implementations, and different capabilities.


None of that probably helps you -- in fact, it might give your head cause to spin, but these are some of the things you think about while dreaming up an interface.

As for generic design advice, I think I didn't quite communicate clearly when I said to design in terms of "higher-level concepts" in that "high-level" might have implied methods which do a lot of work-- it would have been more clear for me to say to design in terms of "actions" -- think in terms of the things you want to "do" first, and don't get bogged down early in terms of what state is required to achieve it. If we think first of classes as a collection of actions/abilities, its easier to see how classes should be broken down into subclasses and what relationships they hold with other classes, than if we think of classes as a collection of data.

Ideally a class should do precisely one "logical unit" of work or represent one conceptual entity (often through composition of smaller, more-focussed classes). In software engineering this is known as the Single Responsibility Principle, or SRP for short. The essence of SRP is that each unit of functionality, whether it be data, methods, classes, modules, or entire libraries should fill exactly one well-defined role. Obviously, when we talk about data or methods a "single responsibility" probably best corresponds to a single, atomic unit of work -- you can think of these as the "leaves" of your program. As we move up the "branches" of the program a "single responsibility" becomes something which is still "singular" at that conceptual level, but which is implemented in terms of the "leaves" which do all the detailed work. Likewise, the "trunk" of the tree pulls all those branches together to do one grand, useful thing by leveraging all the code in those branches and leaves. Whatever conceptual level you are working at, you are always thinking about one responsibility -- its just that the scope of responsibility increases as higher-level concepts are built on the backs of lower-level concepts. You should always strive to keep the idea of "one responsibility" in mind.

The Liskov Substitution Principle, or LSP for short, is also something that you should always bare in mind. LSP basically says to use inheritance only when one class"is-a(n)" more-refined version of the another class, and that composition should be preferred when one class "has a(n)" (or, "is-made-of") another class. Inheritance is sometimes (ab)used to locate some common code in a base class -- which is the most common violation of this principle.

In general, less is more in the world of programming. Smaller interfaces and small inheritance hierarchies demonstrate strong encapsulation and cohesion. Seasoned programmers, at least the good ones, develop an instinct about how requirements break down into the necessary components, as well as a sort of gut-feeling that things are veering off-course when its faults start to show through. If you keep at it, you will be there one day too, but for now you should read and understand the research to help guide your designs.

Also, if you're not already -- learn how to use "const" correctly to ensure that client code doesn't have unexpected access to your class internals. Use it on parameters, use it on return values, use it on method signatures (const methods) use it on pointer declarations (constant pointers, pointers to const data, and const pointers to const data) -- everywhere you can that is appropriate. Constness is every bit as much a part of the interface as the method calls themselves. It helps clients know what they can or cannot do, discourages unintended side-effects, and also gives the compiler a little more leeway to perform optimizations.

I use it religiously. So should you. So should everyone.

I only use getters. If the member variable needs to be read and modified as is by *any* class I drop it public and that's it. There is no point in bloating the declaration with accessors to achieve the same result as making the variable publicly accessible.