Java Reference
In-Depth Information
electronic business cards as input and accumulates our address book in some storage mech-
anism.
It's fairly obvious that we can separate this code into three basic modules:
▪ The business card reader that understands an electronic business card format
▪ The address book storage that stores data into a text file
▪ The accumulation module that takes useful information from the business cards and puts
it into the address book
We can visualize the relationship between these modules as shown in
Figure 8-3
.
Figure 8-3. Dependencies
In this system, while reuse of the accumulation model is more complex, the business card
reader and the address book storage do not depend on any other components. We can there-
fore easily reuse them in another system. We can also change them; for example, we might
want to use a different reader, such as reading from people's Twitter profiles, or we might
want to store our address book in something other than a text file, such as a database.
In order to give ourselves the flexibility to change these components within our system, we
need to ensure that the implementation of our accumulation module doesn't depend upon the
specific details of either the business card reader or the address book storage. So, we intro-
duce an abstraction for reading information and an abstraction for writing information. The
implementation of our accumulation module depends upon these abstractions. We can pass in
the specific details of these implementations at runtime. This is the dependency inversion
principle at work.
