|
Introduction to Design Techniques
This first installment of the new Design Techniques column introduces the column and discusses the larger issues involved in designing Java programs. In addition, I'll examine the software development process in general, describe the role of design within that process, and look at the various and competing goals of a "good" software design
|
|
Why extends is evil
Most good designers avoid implementation inheritance (the extends relationship) like the plague. As much as 80 percent of your code should be written entirely in terms of interfaces, not concrete base classes. The Gang of Four Design Patterns book, in fact, is largely about how to replace implementation inheritance with interface inheritance. This article describes why designers have such odd beliefs.
|
|
Designing Object Initialization
This installment of the Design Techniques column begins with a quick look at object-design fundamentals, then goes on to discuss various approaches to designing initializers and constructors so as to facilitate the proper initialization of objects.
|
|
A Type System for Object Initialization
|
|
Constructors and Object Initialization
OBJECT TYPES IN JAVA ARE VERY DIFFERENT from the primitive types. Simply declaring a variable whose type is given as a class does not automatically create an object of that class. Objects must be explicitly constructed. For the computer, the process of constructing an object means, first, finding some unused memory in the heap that can be used to hold the object and, second, filling in the object's instance variables. As a programmer, you don't care where in memory the object is stored, but you will usually want to exercise some control over what initial values are stored in a new object's instance variables. In many cases, you will also want to do more complicated initialization or bookkeeping every time an object is created.
|
|
Object Finalization and Cleanup
This installment of the Design Techniques column discusses the design guidelines that pertain to the end of an object's life. I give an overview of the rules of garbage collection, discuss finalizers, and suggest ways to design objects such that finite resources aren't monopolized
|
|
The Hotspot Virtual Machine
This article, while not part of the Design Techniques column, discusses a topic that is closely related to the column's focus: performance. This article describes the "popular lore" that aims to improve the performance of Java programs in ways that reduce the flexibility of the code, and describes Sun's Hotspot JVM in technical detail. The article shows how Hotspot attempts to eliminate the performance bottlenecks that gave rise to the "popular lore" in the first place
|
|
Class and object initialization
Jeff celebrates Java 101's first anniversary by exploring class and object initialization. During this exploration, Jeff introduces you to the strange concepts of the and methods. For answers to last month's Java 101 Challenge, for this month's homework, and for additional material related to this article, visit this article's associated study guide.
|
|
Study guide: Class and object initialization
Welcome to the Java 101 study guide. This guide complements "Class and Object Initialization." It provides a glossary of terms specific to that article, new homework, solutions to last month's Java 101 Challenge, Jeff Friesen's answers to questions from your fellow students, additional examples, and miscellaneous notes and thoughts.
|
|
Java performance programming, Part 1: Smart object-management saves the day
Excessive object creation can be a huge problem in Java programs. Despite continuing improvements in JVM technology for memory management, the object creation and garbage collection cycle is still a very expensive operation. If frequently used code creates excessive numbers of objects, performance can be slowed to a crawl as the JVM churns through, repeatedly creating and garbage collecting the objects. By understanding how to reduce the volume of object creation in your code, you can put an end to object churn and maximize the useful work you're getting out of the JVM.
|
|
The Canonical Object Idiom
In this installment of the Design Techniques column, I propose "the canonical object" as a Java idiom. The article discusses the fundamental services that all objects in general should offer, shows how objects can offer these services, and names such objects "canonical."
|
|
Composition versus Inheritance
In this installment of my Design Techniques column, I analyze the flexibility and performance implications of inheritance and composition, and I give guidelines on the appropriate use of each.
|
|
Sensible Sanitation -- Understanding the IBM Java Garbage Collector, Part 1: O
This article is the first of three in a series on the IBM Java Garbage Collector (GC), a storage manager for the IBM Java development kits and runtime environments. The series will cover: storage areas used by GC; object allocation; garbage collection; how external interfaces work; and verbosegc and other command line parameters
|
|
Sensible sanitation -- Understanding the IBM Java Garbage Collector, Part 2:
This is the second of three articles in a series on the IBM Java Garbage Collector (GC), which is a storage manager for the IBM Java development kits and runtime environments.
|
|
Designing with Dynamic Extension
In this installment of Design Techniques, I give advice on using runtime class information in Java programs. I talk about the method area of the JVM and the structure of Java objects, upcasting and downcasting, polymorphism and dynamic binding, java.lang.Class and reflection, and -- perhaps most importantly -- I reveal how best to ask a hippopotamus to dance
|
|
Sensible sanitation -- Understanding the IBM Java Garbage Collector, Part 3:
In this article Sam Borman explains how to interpret verbosegc, and how some of the command-line parameters work. He uses examples to illustrate verbosegc output, and describes the command line parameters that influence GC and when to use them. Information in this article reflects the Java 1.2.2 through 1.3.1 release levels.
|
|
Java theory and practice: 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.
|
|
Java theory and practice: 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
|
|
Mutable or immutable?
Immutability in a "weak" sense (for lack of a better term) means creating a temporary read-only view of otherwise modifiable data. A typical case is implementing an accessor method: one must avoid giving out writable handles to internals of the class implementation.
|
|
Java theory and practice: Safe construction techniques
The Java language offers a flexible and seemingly simple threading facility that makes it easy to incorporate multithreading into your applications. However, concurrent programming in Java applications is more complicated than it looks: there are several subtle (and not so subtle) ways to create data races and other concurrency hazards in Java programs. In this installment of Java theory and practice, Brian looks at a common threading hazard: allowing the this reference to escape during construction. This harmless-looking practice can cause unpredictable and undesirable results in your Java programs.
|
|
Eye on performance: Referencing objects
Intrepid optimizers Jack Shirazi and Kirk Pepperdine, Director and CTO of JavaPerformanceTuning.com, follow performance discussions all over the Internet, expanding and clarifying the issues they encounter in this column. This month, they set their sights on the Java Games Web site to see how game developers identify and then resolve problems that appear when their application doesn't release objects for garbage collection.
|
|
Garbage collection on Java 1.1.8 JVMs
In Java applications, the programmer has explicit control of how objects are created but cannot explicitly give back the memory that these objects occupy when they are no longer needed. The process of garbage collection takes care of freeing up space that is no longer used to store objects. This paper gives a short description of garbage collection, why it is needed, and how it works.
|
|
"Heap of trouble" with the wrong heap size
Many Java implementations provide options related to the size and growth of the Java heap. This brief article discusses proper usage of the minimum, ms, and maximum, mx, heap size. Because the minimum parameter is the starting size of the heap, correct (or incorrect) usage of this parameter, as well as the maximum parameter, can significantly impact the performance of your Java application.
|
|
Unit testing with mock objects
Mock objects are a useful way to write unit tests for objects that act as mediators. Instead of calling the real domain objects, the tested object calls a mock domain object that merely asserts that the correct methods were called, with the expected parameters, in the correct order. However, when the tested object must create the domain object, we are faced with a problem. How does the tested object know to create a mock domain object instead of the true domain object? In this article, software consultants Alexander Day Chaffee and William Pietri present a refactoring technique to create mock objects based on the factory method design pattern.
|
|
Guidelines for using the Java 2 reference classes
The Java 2 platform introduced the java.lang.ref package, which contains classes that allow you to refer to objects without pinning them in memory. The classes also provide a limited degree of interaction with the garbage collector. In this article, Peter Haggar examines the functionality and behavior of the SoftReference, WeakReference, and PhantomReference classes and recommends programming idioms for their use.
|
|
Java programming dynamics, Part 2: Introducing reflection
Reflection gives your code access to internal information for classes loaded into the JVM and allows you to write code that works with classes selected during execution, not in the source code. This makes reflection a great tool for building flexible applications. But watch out -- if used inappropriately, reflection can be costly. In Part 2 of his series on Java platform internals, software consultant Dennis Sosnoski provides an introduction to using reflection, as well as a look at some of the costs involved. You'll also find out how the Java Reflection API lets you hook into objects at run time.
|
|
Reflection: A new way to discover information about Java classes
Most people think of reflection as the return of an image in a mirror or as serious thought. Developers using the Java programming language can include another meaning: a way to discover information about Java classes.
|
|
Best Practices for Object Design
By Bill Veners
|
|
Implementing many-to-many object relationships
Relationships -- when I use the term relationship, I mean the Unified Modeling Language (UML) concepts of association, aggregration, and composition -- are implemented via the combination of attributes and methods (operations). The attributes describe the relationship, and the methods define and update the relationship. In An overview of relationships, I discussed the fundamentals of object relationships. We have described implementation strategies in both Implementing object relationships with a singular multiplicity and Implementing one-to-many object relationships. Now I would like to describe how to implement a bidirectional many-to-many relationship.
|
Appreciate the significance of the object
Objects are for people, not for computers. The point of objects is not to help computers run software, but to help people develop software. Computers are just as happy running assembly language programs as object-oriented programs. But people are happier writing object-oriented programs. OK, if not always happier, then hopefully at least more productive. The main aim of advances in software technology, from machine language to assembly to procedural languages to object-oriented languages, has been to help programmers do their jobs. In particular, objects help programmers manage complexity and change in their software.
By Bill Veners
|
See objects as bundles of behavior, not bundles of data
One of the most basic object-oriented ideas is encapsulation -- associating data with code that manipulates the data. The data, stored in instance variables, represents the object's state. The code, stored in instance methods, represents the object's behavior. Because of encapsulation, therefore, you can think of objects as either bundles of data, bundles of behavior, or both. To reap the greatest benefit from encapsulation, however, you should think of objects primarily as bundles of behavior, not bundles of data. You should think of objects less as carriers of information, embodied in the data, and more as providers of services, represented by the behavior.
By Bill Veners
|
Design Service-Oriented Objects that use their state to decide how to behave
When I was first struggling to understand object-oriented programming, I happened to leaf through a copy of Object-Oriented Design with Applications by Grady Booch. In this book I found a sentence that gave my my first real insight into what an object is.
By Bill Veners
|
Understand the relationship between mutable Service-Oriented Objects and state machines
In Guideline 1, I said that objects are machines. The kind of machine that service-oriented objects resemble, mathematically speaking at least, is the state machine
By Bill Veners
|
Use Messengers to transmit information
Guideline 2 encourages you to think of objects of bundles of services, not bundles of data. This guideline irreverently suggests that sometimes its OK to design objects that are bundles of data.
By Bill Veners
|
An overview of object relationships
Objects have associations to, or relationships with, other objects. Understanding the nuances of relationships in object modeling is the first step to understanding how to implement them in your Java source code.
|
Use Flyweights as pluggable nuggets of behavior
This StampDispenser really offers the same service to clients as the StampDispenser in example 1, but through a different interface and with an implementation that is more code-heavy than example 1. Were I to have to implement a StampDispenser, I would do it the way I did in example 1. With example 2, I wanted to show how state machines and service-oriented objects are similar, and I wanted to have a launching point for using the state pattern.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|
Use Immutables to represent values of abstract data types
With a mutable object like the StampDispenser in Listing 3-1, identity is important. If I have 3 stamp dispenser machines and I enter a dime in one and a dime in another, I don't get a stamp. I have to insert at least 20 cents in a particular stamp dispenser to get the stamp. The identity of the machine into which I insert that second dime matters -- it has to be the same machine in which I inserted the first dime.
By Bill Veners
|
Unidirectional object relationships
Implementing object relationships where one of the two multiplicities is singular (either one-to-one or one-to-many relationships) is simple once you understand the fundamentals.
|
Implementing one-to-many object relationships
One-to-many relationships are a bit harder to implement than relationships with a singular multiplicity, because many aspects of the relationship cannot be implemented simply as the combination of an attribute, a getter, and a setter (as you can a singular multiplicity). Instead, to manage the many parts of a one-to-many relationship, you must use a collection object (such as an instance of Java's Vector or HashSet classes) to track the relationship to potentially several other objects
|
An introduction to object prevalence
One-to-many relationships are a bit harder to implement than relationships with a singular multiplicity, because many aspects of the relationship cannot be implemented simply as the combination of an attribute, a getter, and a setter (as you can a singular multiplicity). Instead, to manage the many parts of a one-to-many relationship, you must use a collection object (such as an instance of Java's Vector or HashSet classes) to track the relationship to potentially several other objects
|
An overview of object relationships
Objects have associations to, or relationships with, other objects. Understanding the nuances of relationships in object modeling is the first step to understanding how to implement them in your Java source code.
|
Member function visibility in Java programs
The visibility of a Java member function defines a Java object's level of access to it. My experience has been that the choice of visibility is an important design decision as well as an important implementation decision because it is one way to reduce the coupling within your system. This week's topic is modified from Chapters 7 and 8 of The Object Primer 2nd Edition.
|
Member function visibility in Java programs
The visibility of a Java member function defines a Java object's level of access to it. My experience has been that the choice of visibility is an important design decision as well as an important implementation decision because it is one way to reduce the coupling within your system. This week's topic is modified from Chapters 7 and 8 of The Object Primer 2nd Edition.
|
Effective field visibility in Java programs
Fields, also known as attributes or member attributes, are the data aspects of objects. A field's visibility defines the level of access to it by Java objects. This week's discussion, modified from Chapters 7 and 8 of The Object Primer 2nd Edition, focuses on the types of field visibility, how to implement fields, and how to access them.
|
Fine-tuning Java garbage collection performance
Is your Java-based application fully using the capabilities of the IBM eServer hardware it's running on? In this article, the author shows how to find out whether garbage collection, the task carried out by Java Virtual Machine in the background to reclaim unusable space, is finely tuned. He then provides several recommendations to address your garbage collection issues.
|
Objects, Instance Methods, and Instance Variables
OBJECT-ORIENTED PROGRAMMING (OOP) represents an attempt to make programs more closely model the way people think about and deal with the world. In the older styles of programming, a programmer who is faced with some problem must identify a computing task that needs to be performed in order to solve the problem
|
Programming with Objects
THERE ARE SEVERAL WAYS in which object-oriented concepts can be applied to the process of designing and writing programs. The broadest of these is object-oriented analysis and design which applies an object-oriented methodology to the earliest stages of program development, during which the overall design of a program is created
|
Inheritance, Polymorphism, and Abstract Classes
A CLASS REPRESENTS A SET OF OBJECTS which share the same structure and behaviors. The class determines the structure of objects by specifying variables that are contained in each instance of the class, and it determines behavior by providing the instance methods that express the behavior of the objects
|
this and super
ALTHOUGH THE BASIC IDEAS of object-oriented programming are reasonably simple and clear, they are subtle, and they take time to get used to. And unfortunately, beyond the basic ideas there are a lot of details.
|
Strings, Objects, and Subroutines
THE PREVIOUS SECTION introduced the eight primitive data types and the type String. There is a fundamental difference between the primitive types and the String type: Values of type String are objects
|