Ivan

Programming in the small - access levels.

Following on from the previous article, another programming habit I see frequently is using access levels (e.g. in Java, private, package, protected and public) that are less restrictive than possible. For example, declaring a method public that could be private.

In this article, I'll call the access levels that are less restrictive as being "more public" or "less private" etc.

Declaring class members "too public".

Probably the most frequent example of this habit is that of declaring class members as protected when they could be private. I believe that people do this because of past experiences where they wanted to be able to override some method and found they couldn't - I'll address that later.

Something that I've noticed in my travels around many client sites is a suprisingly large number of Java developers who think protected means something different than it actually does (in fact, even that private means something different than it actually does - it's class based not instance based). I won't describe what these access levels actually mean - it's well documented.

The consequences

Class members with "less public" access levels can be referenced in fewer classes than members with "more public" access levels - that's the point of access levels. That means that when reading some code, if you see that it is declared "more public" you know instantly that there are more classes that might reference (hence more dependencies) than if it's "more private".

You might guess that, for example, if you change a public method, it'll probably have an effect on some other code (in a different class) because the chances are that there is some other code (in a different class) calling the method, because it's declared public. Therefore, before changing a public method, you might want to look at references to the method and check that callers of the method are OK with the changes you are making.

If a member is declared private, then you know that only methods of that class can be using the member, so you are free to refactor private methods by only looking at code in that class.

Therefore, if a class member is declared to be "more public" than it could be, you might be put off refactoring it because of possible effects on code in other classes, or you might waste time looking for references, when if it was private you might see immediately the only references.

You could, of course, look for all references to the member, but because it's not immediate you won't do that all the time.

What about my experience where I couldn't override something because it was declared private?

This experience is often a symptom of something else:

Lack of collective code ownership

If the code that you are dealing with is all in-house, then you should be able to make a member more public when you need to. That is, make everything as private as it can be for your current needs - making it more public only if you find you need to. This fails if there is rigid partitioning of a code base. Collective code ownership is needed for this to work well in practice.

Closed source libraries

If you are writing or using a closed source library, there may be times when members have to be declared more public in order to allow for future unforseen uses of the code.

Use of inheritance instead of composition for customisation

One of the reasons libraries may need members to be declared more public than possible is if the way the library is designed is for users to extend classes using inheritance. There are many cases where using composition would be a better design.

I'll tell you what I want, what I really, really want.

It would be great if Eclipse (or other IDEs) spotted that members could be more private than they have been declared and offer to change them for you. I'm sure something like this must exist - please post here telling me. Note that I want a tool to tell me immediately, not one that has to be run separately, because any lack of immediacy will mean it won't be as useful.

A few years ago I thought of writing a tool to do this that I was going to call "Thatcher" - it would privatize as much as possible. I haven't got around to it...

Posted by ivan at March 4, 2006 2:49 PM