Chapter 15. The Open APIs
Part of the process of designing software is deciding what
functionality needs to be abstracted and exposed for extensibility
and what should be encapsulated and invisible to someone extending
the system. One good example is
Presenters are NetBeans’
abstraction for components such as menu items and toolbar
buttons—usually the default implementation is sufficient, and
you simply specify an icon and display name and the runtime takes
care of actually creating a user-interface component for them, but
you can override this behavior if necessary.
The simplest way to let someone extend menus and toolbars is to give
them access to a
JMenu and let them add components
to it. However, this is unmaintainable—if five third-party
modules all add items to the File menu, the resulting interface is
not likely to be very usable. In such a situation different modules
might do things to the menu that interfere with each other working
correctly, because there is no contract for how they should behave.
The solution is, appropriately, an abstraction that wraps concepts such as presentation of functionality, and even the Action abstraction for user-invokable behaviors. The goal is to give someone the ability to add functionality, not menu items per se. So we have the Actions, Menus, and Toolbars hierarchies in Tools → Options → IDE Configuration → Look and Feel. As a result, it becomes possible to consistently integrate new functionality—the core takes care of presenting ...