Diagnosing Java code: Designing Extensible Applications, part 3rd

For the transparent box extensibility discussed in our previous "Diagnostic Java Code", black box extensibility refers to the way the software system can be extended when the source code is neither viewable nor modified. This is typically done through system configuration or by using an application-specific scripting language. In this topic, Eric Allen discusses the significance of when designing a system for black box extensibility and provides some ideas on how to implement this design effectively. After reading this article, you will know when to use a black box and learn some tips on how to implement it.

I've talked about the importance of code reuse design strategies in previous articles (mainly because of the differences in information processing tasks and the corresponding cost increases), so if you've identified the scalability of your system as your goal, ask yourself, "What is the scalability of the system and what scalability can I achieve?" "Then consider the following:

Trade-offs to add scalability, because adding extensibility can degrade performance or test capabilities.

Often, the most testable system is the simplest system; adding extensibility often adds complexity.

A key knowledge of planning a successful extensible design is to know how you plan to extend the system in the future.

In the first article in this series, I outlined various forms of scalability that the system can render-black box design and two white box designs (transparent boxes and open boxes). In the second article, I introduced in detail the use and implementation of the transparent box extensibility, which is an appropriate design method between black box and open box design.

This month, I want to continue our "travel" and discuss the black box scalability.

Explore the direction in the black box

Black box design is an extensibility that involves customizing the application's user configuration so that the application executes in the most useful way for a particular environment. When you extend an application in this way, you don't have to look at the original source code.

We've all used applications that provide this scalability. For example, the following two applications:

Netscape's plug-in features

Emacs has unlimited capabilities in the use of Emacs Lisp configuration

Recently, almost every new application provides some degree of black box scalability.

How to identify a configuration script

Before continuing, let me try to distinguish between the configuration script and other input from the program. Unfortunately, there is really no obvious difference here. A set of inputs accepted by the program (and the method by which the program interprets these inputs) can and should be treated as a language. But you should understand several notable features of the configuration script.

Unlike other program inputs (which can change program input every time you use an application), configuration scripts tend to be more stable. These scripts typically have default values that will initially be set by the user and will not reset these values for a long time. In fact, this script is often set when the program is initially installed. Changing the default value of a script is likely to have a significant effect on the behavior of the program on other inputs. Also, because the values of these inputs are stored permanently, they are retrieved in subsequent program calls.

Select Configuration wisely

Now, the next question you might ask is "when is it meaningful to add this extensibility to an application?" ”

The answer is not to add as much extensibility as possible. After all, the end result of this approach is that, given the appropriate script (similar to berapplikation), a single application performs each task required by the user.

Arguably, the development environment is in this category, but the "scripts" required by the user/developer can be very long and complex. This extreme example illustrates the fundamental trade-off between black box scalability-the more black box scalability The application provides, the more work the user has to do to configure it for a particular environment.

Generally, it is better to have a narrower range of requirements for application determination, but it can still be generic and then targeted at more specific environments. As many of the "extreme Programming (Extreme programming)" Teams demonstrate, shrinking the scope of your project is likely to enable you to actually successfully complete the project (and be on time!). ）。