Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java Tip 84: Customize scoping with object keys

Java's standard scopes may be insufficient for some projects

By Mark Roulo, JavaWorld.com, 12/06/99

Correct scoping is one of the keys to success when developing large-scale programs. Paying too little attention to scoping often leads to spaghetti code that is difficult to understand, extend, or maintain. Java provides four standard scopes to restrict access to the data and methods in a class. However, custom-tailored scoping is occasionally desired on large projects, usually to avoid a choice between speed and safety. I'll show you how you can create custom scoping to avoid this tradeoff. Following the techniques described here, you should be able to do so without a significant increase in complexity.

Why scoping?

Scoping controls the depth of access to data and methods, and is one of the tools used to control large software projects. In a program with hundreds of thousands of lines of code, allowing one piece of code to modify any piece of data it wants rapidly leads to chaos. More restrictive scoping of data and methods -- private versus public, for example -- makes programs easier to understand, extend, and maintain, because you don't need to examine as much code when making changes. For small projects, scoping is often not critical -- if a program is only 10,000 lines long, it's easier to keep track of everything. For large projects with many programmers, however, scoping can be the difference between long-term success and failure. Keep in mind, then, that the techniques I present to you work for programs of all sizes, but are most appropriate for large applications.

Some scenarios

When is standard scoping insufficient -- and when is it not? I know of three cases when tailoring a scope to do exactly what you want is more practical than using a standard Java scope. Custom scoping can help you out when you want to:

• Disallow certain scripting capabilities
• Control mutability across packages
• Boost performance

We will consider each use in turn.

Disallowing certain scripting capabilities

A scripting language can add value to applications by allowing users to extend and tailor applications themselves. Occasionally, your application will have functionality that must be used cautiously, such as the ability to reset remote systems. You can restrict access to the GUI by adding a password and warnings to prevent accidents. However, you may wish to prevent scripting from making use of this capability entirely. In such a case, you would place the GUI and the forbidden functionality in the same package, and then create a reset function-package scope.

Sometimes, however, this isn't acceptable. In such cases, you need an approach that doesn't require packaging the GUI and the functionality together. Custom scoping allows the two to be separate, and still protects the functionality from scripting.

Controlling mutability

Creating objects in Java is slower than creating stack objects in C++. Because the cost of object creation in Java is higher than in C++, well-designed Java programs pay close attention to object creation than well-designed C++ programs. One way to safely create fewer objects in Java is to make them immutable -- to not provide a way for the object's state to be changed, in other words. An example of this in the standard libraries is the String class. If an object's state cannot change, references can be safely passed to the object throughout the application.

However, this doesn't always work. A data-processing program might start with an object containing raw data and slowly add information to the object as it passes through the application. A good example of this would be a stock-screening application that starts with objects containing raw stock data, and then adds more information -- the performance of a single stock relative to the industry, say -- as the objects are processed.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.