I've worked on projects where, if you touch just one small part of the code, other developers cringe because it's so fragile. The sub-system works almost on accident, and any changes to it run the risk of total application collapse. I call this the "bowl of jello theory," because if you touch it in one place, the whole thing jiggles and wobbles, so to speak. Go too far, and the whole thing will collapse.

This is a sign of poor application architecture, and Java can help in so many ways here. For instance, Java's use of classes, data hiding, and abstraction, offer obvious ways to avoid this. But the strict use of interfaces, and the JavaBean programming model for business logic, go a long way towards helping avoid the Jello disaster.

I wrote an article years ago (http://www.ddj.com/architect/184405103) on using an event agent in Java to help hide the classes that implement interfaces and source events. This is an easy pattern to implement, and helps to reduce the rippling effect changes often have in applications.

Another way to help avoid the Jello Effect, albeit a more complex one, is to use a messaging sub-system such as JMS. This also allows you to transparently distribute your application across servers, and better take advantage of multiple cores even on one server. 

This works by separating the components of your application using a more abstract concept than interfaces: the message. Some call this an event-driven architecture, but having application components live their lives in silos, happily sending a receiving messages (events) to do all of their work, helps to achieve an extremely robust system.

To learn more about these patterns and approaches, read the following:

Happy coding!

-EJB