Bank Of England

Problem: The common way to protect methods and fields that are at design-time not used by other classes is to define them private (see CreatePrivatelyPublishLater). However, if somebody gets this code as part of a distribution, it is a bad idea for them to change it, even if they get the source. So if they extend such a class, and they need access to some methods or fields that are private - Oops! The methods and fields are (too) well guarded; hence I call it the "Bank of England".

Solution: Make all variables accessible to subclasses, either through a protected get/set pair of accessor methods, or by making the variables themselves protected.

Comment: In Smalltalk and Eiffel, all instance variables are protected, so this idiom merely transfers common practice from those languages to Java.

Comment: Many Java books recommend making the variables private and using the get/set pair. This is an option not available to Smalltalk. The advantage is that it gives you a chance to keep subclasses working even if you later rename or eliminate the variables.

Comment: If you are bothered about the runtime efficiency costs of a get/set pair, you can declare them to be final so that they can be automatically inlined. Although final methods are usually worse than non-final methods, they are usually better than accessing variables directly or not having access at all.

Hints: If you can, define the set/get accessor-pairs final, so the java compiler can inline them to improve performance.

Comment: Recall that protected attributes and members are visible within the package and to all descendants. Since anyone can add classes to any package, 'protected' in Java pretty much means 'wide open' :-(. Use accessors and mutators to control the manner of modification of attributes.

Comment: If you don't like the way a class is implemented, reimplement it (possibly calling the original), don't extend it. Inheritance isn't a good way of fixing bugs. -- RickyClarkson

This page mirrored in JavaIdioms as of April 29, 2006