|[an error occurred while processing this directive]|
Data-oriented methods, such as the accessor
methods that appear in the data-oriented
not inherently bad. In many situations they are appropriate. One common
use of accessor methods is to access data inside objects used to
transmit information. I discuss such data-oriented objects, called
Accessor methods are also commonly used to manipulate an object's properties. I think of properties as a special kind of data used to configure otherwise service-oriented objects. Properties are used heavily in JavaBeans, Java's component model, but also appear in non-JavaBean objects. I discuss configurable objects in Guideline ?.
A third use of accessor methods is to give
client programmers access to an object's internal state, so
they can do something with that state they can't via the object's
methods. For example, no method of the service-oriented
and returns the transpose, the new matrix that results
from interchanging an existing matrix's rows and columns.
Nevertheless, client programmers that need a transpose can get the
elements of the service-oriented
Matrix via its
get method and
calculate the transpose themselves. I discuss this use of accessor
methods in Guideline ?: Make common things easy, rare things possible.
Although many reasonable uses of data-oriented methods exist, you should maintain a service-oriented mindset when designing object methods. In general, you should design methods that do something interesting with the object's data --something more than just providing clients access to the data. In the process, you'll move code that knows how to manipulate data to the object that contains the data. Moving code to data offers you one of the prime benefits of object-oriented programming: a shot at robustness.
Last Updated: Sunday, May 11, 2003
Copyright © 1996-2003 Artima Software, Inc. All Rights Reserved.
Artima.com is created by Bill Venners