|
Using Immutable Types to Insure Program Safety in Java
One very important aspect of Object Oriented Programming (OOP) is that there are characteristics of an object and the way it is used that can help insure a program is correct. These characteristics, if properly used, can greatly reduce the likelihood of bugs appearing at every stage of the lifecycle of a program.
|
|
To mutate or not to mutate?
Immutable objects have a number of properties that make working with them easier, including relaxed synchronization requirements and the freedom to share and cache object references without concern for data corruption. While immutability may not necessarily make sense for all classes, most programs have at least a few classes that would benefit from being immutable. In this month's Java theory and practice, Brian Goetz explains some of the benefits of immutability and some guidelines for constructing immutable classes.
|
|
Avoid JavaBeans style of construction
Some argue that to construct an object in many steps, first by calling a no-argument constructor, and then by calling a series of setXXX methods, is something to be avoided, if possible :
|
|
Immutable objects
Immutable objects are simply objects whose state (the object's data) does not change after construction.
|
|
Immutable Objects In Java
The term immutable simply means unchangeable in object-oriented parlance. Immutable objects do not change once their constructor has executed. You may already know that the java.lang.String class is immutable, despite the appearance that it is not due to its convenient operator overloading.
|
|
When Private and Final Don’t Mix
The final modifier in a method declaration is designed to prevent it from being overridden in a subclass.
|
|
The final keyword
The final keyword has slightly different meanings depending on the context, but in general it says “This cannot be changed.” You might want to prevent changes for two reasons: design or efficiency. Because these two reasons are quite different, it’s possible to misuse the final keyword.
|
|
Watching for holes in Immutables
Immutability, or the design of a class to prevent it from being changed after creation, can accidentally be left mutable if it’s not carefully checked. Immutability is a somewhat complex subject whose reasons and details are covered in Immutable Objects in Java.
|
|
The Final Word On the final Keyword
Some features of the Java language simply cannot be ignored. Consider for example interfaces, used extensively by every Java specification; or try/catch blocks, that form the basis for exception handling. Other features are more obscure – useful, but ignored by the masses. Without looking as far as volatile (probably the most obscure Java keyword), think about final. When was the last time you used final in your code?
|
|
Is that your final answer?
The final keyword is often misused -- it is overused when declaring classes and methods, and underused when declaring instance fields. This month, Java practitioner Brian Goetz explores some guidelines for the effective use of final.
|
|
Performance tips for the Java final keyword
Contrary to the implication of many tips, methods declared as final cannot be safely inlined by the compiler, because the method could have a non-final declaration at runtime.
|
|
Fixing the Java Memory Model, Part 1
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM). Several serious flaws were found in the original JMM, resulting in some surprisingly difficult semantics for concepts that were supposed to be simple, like volatile, final, and synchronized. In this installment of Java theory and practice, Brian Goetz shows how the semantics of volatile and final will be strengthened in order to fix the JMM. Some of these changes have already been integrated in JDK 1.4; others are slated for inclusion in JDK 1.5.
|
|
Fixing the Java Memory Model, Part 2
JSR 133, which has been active for nearly three years, has recently issued its public recommendation on what to do about the Java Memory Model (JMM). In Part 1 of this series, columnist Brian Goetz focused on some of the serious flaws that were found in the original JMM, which resulted in some surprisingly difficult semantics for concepts that were supposed to be simple.
|
|
Swing model filtering
This article discusses the technique of model filtering. You can use this technique with the Swing component set to provide alternative views of model data without altering the underlying data. Filters can alter the apparent content of data elements, exclude data from being viewed, include extra elements in a set of data, or present elements in a different order. You can apply filters to either data or state models, and you can layer filters to combine their effects.
|
|
Whose object is it, anyway?
In a language without garbage collection, such as C++, significant attention must be paid to memory management. For each dynamic object, you must either implement reference counting to simulate the effect of garbage collection, or manage the "ownership" of each object -- identifying which class is responsible for deleting an object. Such ownership is usually not maintained declaratively, but rather by (often undocumented) convention.
|
|
Intelligent data keeps Swing simple
The Swing architecture allows Java developers to create complex displays that present a lot of data. Unfortunately, maintaining that data within large Swing components can be a coding nightmare. In this article, Jonathan Simon presents a technique called iData, or intelligent data. You can use the iData architecture to create a central repository of data within your application.
|
|
Rendering cells in Swing's JTable component
The book Professional Java Programming covers a variety of advanced Java topics, such as the Java 2 security model, internationalization, performance tuning and memory management, printing, help, drag-and-drop operations, and cut-and-paste operations. It also contains chapters on JTree and JTable, two of the more complex components provided with Swing.
|
|
criticisms of the Java hashing model
Java, a new object oriented programming language, includes primitive hash functions in the language for each of the base types. However it provides no clues on how to combine hash values to produce a new hash value. This paper surveys hash function research in computer science emphasising recent developments, and then it critiques the hash facilities provided by Java followed by a proposal for an enhanced Java hash facility. The Java code for a generally applicable Hash class is given in the appendix.
|
|
how hash-based containers work
When you create your own key object for use in a Hashtable, you must override the Object.equals() and Object.hashCode() methods since Hashtable uses a combination of the key's hashCode() and equals() methods to store and retrieve its entries quickly. It's also a general rule that when you override equals(), you always override hashCode().
|
|
Unconstructive Constructors
This gotcha has nailed at least a couple of people I know of with hours of debugging time. It's a very upsetting one too, because you'd think that the Java compiler would catch something so obviously unintentional. Unfortunately, it is completely legal in Java.
|
|
Watching for holes in Immutables
Immutability, or the design of a class to prevent it from being changed after creation, can accidentally be left mutable if it’s not carefully checked. Immutability is a somewhat complex subject whose reasons and details are covered in Immutable Objects in Java.
|
|
Validate state with class invariants
Class invariants are methods which check the validity of an object's state (its data). The idea is to define validation methods for fields, and to perform these validations whenever the fields change. As usual, this should be done without repeating any code.
|
|
Use final liberally
Use the final keyword liberally to communicate your intent.
|
|
Defensive copying
A mutable object is simply an object which can change its state after construction. For example, StringBuffer and Date are mutable, while String and Integer are not.
|
|
Java Object Cloning
As is the case with most object-oriented languages, objects in Java are passed by reference. This means that any action taken on that object in the called method will affect the object that the calling method has because, in effect, they both have the same object.
|
|
Encapsulate collections
Collections are in general mutable objects. As such, one must often exercise care that collection fields are not unintentionally exposed to the caller.
|
|
Copy constructors
provide an attractive alternative to the rather pathological clone method.
|
|
Avoid clone
clone is very tricky to implement correctly in all circumstances, nearly to the point of being pathological.
|
|
Fields should be private
Declaring fields to be public is usually the wrong thing to do, since it does not protect the user of the class from changes in class implementation.
|
|
Factory methods
can return a subtype of their return type - in particular, can return an object whose implementation class is unknown to the caller; this is a very valuable and widely used feature in many frameworks which use interfaces as the return type of static factory
|
|
Data access objects
can return a subtype of their return type - in particular, can return an object whose implementation class is unknown to the caller; this is a very valuable and widely used feature in many frameworks which use interfaces as the return type of static factory
|
|
Value Objects
The term Value Object is an informal term, with no widely accepted definition. Here, Value Objects (VOs) refer to data-centric classes which encapsulate closely related items.
|