All of the J2EE patterns rely heavily on common software design principles you’re probably very familiar with. In the next few pages, we fling around several terms for these design principles. Different people and books might have different perspectives on the same terms, so we’re giving you our definitions now, so that you’ll know what we mean.
As you recall, an interface is a kind of a contract between two objects. When a class implements an interface, it’s saying in effect: “My objects can speak your language.” Another huge benefit of interfaces is polymorphism. Many classes can implement the same interface. The calling object doesn’t care who it’s talking to as long as the contract is upheld. For example, the web container can use any component that implements the Servlet interface.
We all know that when we specialize the capabilities of our software components, they get easier to create, maintain, and reuse. A natural fallout of separating concerns is that cohesion tends to increase. Cohesion means the degree to which a class is designed for one, cohesive, task or purpose.
Hiding complexity often goes hand in hand with separating concerns. For instance if your system needs to communicate with a lookup service, it’s best to hide the complexity of that operation in a single component, and allow all the other components that need access to the lookup service to use that specialized component. ...