I have always admired the cleverness of the name Hollywood Principle. I love its name! The essence of this principle is “don’t call us, we’ll call you”. As you know, this is a response you might hear after auditioning for a role in a Hollywood movie. And this is the same concept for the software Hollywood Principle too. The intent is to take care to structure and implement your dependencies wisely.

At its most basic level, the principle is about reducing the coupling in a software system. It gets back to the well known phrase in software development: loose coupling and high cohesion. You can keep classes loosely coupled by ensuring that you don’t have unnecessary references and you are referencing classes and other subsystems properly. Although the Hollywood Principle does not dictate anything about cohesion, it is an important aspect too. Cohesion is about keeping your classes true to their intent and not allowing their behavior to expand beyond its core purpose. Like high coupling, low cohesion doesn’t tend to cause systems to be unstable or not work properly, but will likely lead to difficulty in maintaining the software.

One of the most popular ways to implement, or obey, the Hollywood principle is to use events or callbacks. A well known pattern that follows the Hollywood principle is the observer pattern. This pattern allows one to observe the state of an object in a well defined and non obtrusive manner. It is typically implemented by injecting a callback object (observer) into the class to be observed (subject). The subject simply raises an event in all observers when its state changes. How the observer reacts to the event is outside the scope or care of the subject.

Dependency Injection (DI), which is a form of Inversion of Control (IoC) is another example of the use of the Hollywood principle. Take for example a shopping cart class that requires a reference to a currency conversion service. Traditionally, the shopping cart class would be designed with a reference to the currency convesion service or use a factory to get a reference to the appropriate service implementation. By contrast, using DI, an external mechamism (e.g. Spring or Spring.net) automatically provides a reference to the required currency conversion service at the time the shopping cart class is instantiated.