失效链接处理 |
NetBeans Platform 6.9 Developers Guide PDF 下载
本站整理下载:
提取码:5dk7
相关截图:
![]()
主要内容:
In this chapter, you will cover the following topics:
• You learn about modules and modular application development
• You examine the role that modules play in NetBeans Platform applications
while creating your first module
• You look at how to configure modules, especially at how to define module
dependencies and versioning data
• You round this topic off by looking at the lifecycle of modules and how to
programmatically access that lifecycle
Modular application development
Modularization becomes more important as an application's complexity increases.
The old and trusted programming methodologies struggle to keep pace with
continually shortened production cycles, gradually increasing feature sets, and the
simultaneously rising importance of software quality. In particular, the pressure
of time to market demands a solid application design, providing clear extension
points, loosely-coupled components, and a reliable versioning mechanism. Without a
strong foundation based on a sustainable architecture, each version increase and new
feature introduces a new level of chaos, leading to a scenario where enhancements
and bug fixes become impossible to implement, as each change causes increasingly
detrimental side effects. An application of this kind can become so problematic
that it needs to be rewritten from scratch but, because the underlying application
architecture remains unchanged, a rewrite of this kind fails to solve the application's
structural defects.
Modules
A solution to this problem entails the introduction of modules. A module is a
self-contained software component with which other modules can communicate
via well-defined interfaces, behind which their implementations are hidden. Each
coarsely-grained feature of an application is created within a module, giving
each module a clearly defined responsibility within the application. The chaos
described above can, of course, continue to exist within a module, exactly as it had
existed in the pre-modular application. However, as the classes within a module
exist to provide a very specific feature, the module, as a whole, needs to function
interdependently with the other modules in the application, meaning that the
chances of complete chaos in your code are smaller than they were before. The
limited responsibility of a module within the application enables it to be more
focused and the application as a whole to be more cleanly designed.
Moreover, the worsening chaos described above is less likely to arise within a
modular application, as the implementation of features can only take place
via publicly exposed interfaces. The dependencies in the whole application are
well-defined and never accidental. Breaking the contract with the interfaces,
thereby introducing the chaos described above, can only be done intentionally.
Besides these advantages to the developer, a modular application also benefits the
end user. As the NetBeans module system is dynamic, modules (that is, features)
can be loaded and unloaded dynamically at runtime. The adaptability and flexibility
of applications and the ease with which features can be added and removed by the
user at runtime is of particular relevance to enterprise applications, which typically
provide support for a variety of user profiles.
Let's now take a more concrete look at modules and their relationship to NetBeans
Platform applications.
Characteristics of a module
Generically, a module needs to have certain characteristics to provide the desired
advantages promised by modular application development.
Deployment format
It must be possible to make all resources required by a module available via a single
deployment package. The closest concept in the Java world is the JAR archive. You
can bundle an arbitrary number of resources into a JAR and provide metadata via
the manifest file. NetBeans modules are packaged in a similar format, together with
module-specific metadata in the related manifest file, into an NBM archive.
[ 8 ]
Chapter 1
Uniqueness
Each module must have its own unique identity. The NetBeans module system
provides an additional key in the manifest, OpenIDE-Module, which you use to
define the application-wide unique name of a module.
Versioning
Each module must be able to specify its version. NetBeans modules differentiate
between specification versions and implementation versions.
• The specification version indicates the version of the officially exposed
interfaces. This version is defined via the OpenIDE-Module-SpecificationVersion key in the manifest file, using the Dewey format. Generally, the
assumption is that new versions are backward-compatible.
• The implementation version indicates the implementation state of a module.
This version is not assumed to be backward-compatible and can be used
only within a specific version of the application. The OpenIDE-ModuleImplementation-Version key in the manifest defines this version.
Exposed interfaces
Each module defines public interfaces, via which features can be accessed. Accepted
methods of accessing dependencies in software rely strongly on conventions. One of
these is that types in packages can only be accessed indirectly via facades. However,
typically, these well-intended conventions are abandoned in the interests of time.
On the other hand, component systems with their own lifecycle environment tend
to demand that conventions of this kind are followed to the letter. Within a module,
any class can be declared public, and thereby, be accessed by any other class within
that module. However, other modules can only access a module's exposed classes,
that is, classes that are found within explicitly exposed packages.
The NetBeans Platform is one of the systems that provide a mechanism of this kind.
The packages that are to be exposed to other modules in the application are declared
via the OpenIDE-Module-Public-Packages manifest key. The NetBeans Platform
provides a system of ClassLoaders that provide access to those classes that are within
the module, as well as those classes that are found within the publicly exposed
packages of other modules upon which the module has declared a dependency.
|