Java Reference
In-Depth Information
Figure 4.2
Using CRC to place responsibilities can be like playing pass-the-parcel.
cards try to push work out to other components wherever possible, which leads to lean,
well-defined, maintainable components. Think of this like a game of pass-the-parcel
(see figure 4.2), where each developer is trying to pass parcels of work to other devel-
opers—except in this game, when the music stops, you want the smallest pile of parcels!
A service-oriented approach also promotes
Less coupling between providers and consumers, so it's easier to reuse components
■
More emphasis on interfaces (the abstract) rather than superclasses (the concrete)
■
Clear descriptions of dependencies, so you know how it all fits together
■
Support for multiple competing implementations, so you can swap parts in and out
■
In other words, it encourages a plug-and-play approach to software development, which
means much more flexibility during development, testing, deployment, and mainte-
nance. You don't mind where a service comes from, as long as it does what you want. Still
not convinced? Let's see how each of these points helps you build a better application.
LESS COUPLING
One of the most important aspects of a service is the
contract
. Every service needs some
form of contract—otherwise, how could a consumer find it and use it (see figure 4.3)?
The contract should include everything a consumer needs to know about the service,
but no more. Putting too much detail in a contract tightens the coupling between pro-
vider and consumer and limits the possibility of swapping in other implementations
Our robot needs legs!
Service contract
Interface leg
=
Description:
Bends at knee
[etc…]
?
Figure 4.3
Why you need contracts
