"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.
Why should you think of objects as bundles of services? If data is exposed, code that manipulates that data becomes spread across the program. If higher-level services are exposed, code that manipulates the data is concentrated in one place: the class. This concentration reduces code duplication, localizes bug fixes, and makes it easier to achieve robustness," says this guideline from API Design:
This guideline arises out of my experience going into different companies and seeing their designs. One of the most common things I find is data-oriented design and data-oriented thinking. Data-oriented design is great when you're desiging an XML DTD or a set of relational database tables, but in an OO design, service-oriented thinking is more appropriate. In this guideline, I try to explain why I think that. I try to demonstrate that the benefit of encapsulation is a chance for improved robustness, which you get to the extent that your objects are bundles of services, not bundles of data.
There are many objects that are bundles of data, and should be. I call a big category of these "Messengers," which I talk about a few guidelines later in the chapter.
The linkage of services and behaviors of object are powerful concepts. If one extends behavior to services, it prevents packing an object with too many services, adding to an objects complexity both internally and externally.
A "Service_Oriented Mindset" adds clearity to an objects services and its responsibilities.
I've seen the net results of this in bug ridden code as a direct results of poor design and imporper use of objects.
In a side note, I sometimes wish I had your material a year and half ago. Conceptually, undestanding an object and its underlying class structure appears easy. But there is a subtlety which is not that obivious. "a bundle of services" brings it home nicely.
In another note, I have found tackling object design early in my devleopment as a Java programmer, has actually improved and sped up my learning; not to mention the quality of my coding.
Previous Topic
