SOA and Accessor Methods Don't Mix

Accessors (i.e. getter/setter) methods are truly evil, especially when applied to Service Oriented Architectures (SOA). Sure, Allen Holub may have a tough time trying to convince people why they're evil for Object Oriented Programming. However, despite what Don Box says about SOA being different from OOP, it's painfully obvious, accessors truly don't mix well with SOA.

The most obvious problem is that fine grain invocation leads to just too many round trips through the network.

The second problem, that is exposing internal state or rather violating the "Law of Demeter" requires remote object references which is not available by default in web services environments.

Finally, accessor methods sometimes tend to require an invocation sequence. Service interfaces should not require that a client invoke methods in a particular sequence to work. For accessor methods, this happens when all required properties need to be set before the component can be invoked. One way to avoid this is to make the input parameters to methods more granular.

Now Allen Holub's suggestion of using the CRC methodology (classes, responsibilities, collaborations) may just be the ideal method for defining service oriented archictectures (SOA). CRC tends to distribute responsibility more evenly across classes (i.e. services). However, this has to be balanced against the need to make classes (i.e services) more reusable.

In fact, too avoid confusion maybe I should coin a new name for this methodology. Service, Responsibilities and Collaboration (SRC).