Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Your own easy refactoring of member visibility
Initially when writing code, I don't worry too much about categorizing method visibility as default (package), private, public, or protected. As I create methods, I make them all public. Only once I've finalized the organization of packages and finished refactoring methods -- whether that be by extracting new methods from existing code, pulling up or pushing down methods in the hierarchy, or moving them to another class entirely -- do I then review method visibility. I figure that until I know the final class shapes and have a little practical usage of the code, I don't want to declare what my "clients" might need. In other words, before sharing a new framework, one must decide what is implementation detail and what is necessary so others can extend it.
It would be handy if you could merely select methods in the Outline view, Hierarchy view, or wherever you see methods -- and with a click of a menu choice, set one or more methods to the desired visibility. Admittedly, I am accustomed to this capability from my VisualAge for Smalltalk days. Figure 1 shows an extension to Eclipse's Java development environment in the context of the Java editor's Outline view.
)
Figure
1 Extension of a method's context menu
This is subtle, from a user's perspective, because of the natural way this was introduced into the user interface. There is no inkling that these new menu choices weren't part of Eclipse's original Java Development Tools (JDT). In fact, that's why the menu cascade is prefixed with "soln" -- so you can tell it's an extension! What's more, the developer doesn't have to remember that these choices are only available in a particular view or editor, because they will be shown anywhere a method is shown.