Getters and Setters
- Use getters and setters by default except for very good reason
- Internal Local Entity Classes do not need (but may) use getters/setters
- Internal collections may be returned from classes, but it MUST be clearly indicated whether the returned value MUST not be changed (then an immutable view should be returned) or whether a user of a class MAY change the collection (in which case the class must ensure that the behavior is well defined, for instance using an observable collection)
Class member visibility
By default all fields and methods should be private
. For any field or method with a visibility higher than private
(visible from the outside) there MUST be a detailed JavaDoc explanation. Thus, especially making something public
should be a deliberate and conscious act.
To facilitate testing, you may be tempted to make members more accessible. This is fine up to package-private (no modifier). But it is not acceptable to make a member part of a package's API (protected
or public
) solely for testing purposes.
Final members and variables
- For class variables: By default, make them final, unless you find a good reason not to. It makes the code easier to understand when you know where changes are expected to happen.
- For local variables and parameters: In principle, the same rule applies as for class variables. But since local variables and parameters have a limited scope, the additional information gained through the presence of a final modifer is not tremendous. Therefore, we tend to not use the final keyword here.
- For methods: By default, don't make them final, unless you have good reason not to. After all, we want to use object-oriented programming.