A Service-Oriented Mindset

Data-oriented methods, such as the accessor methods that appear in the data-oriented Matrix, are 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 messengers, in Guideline 5.

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 Matrix calculates 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.