Java Reference
In-Depth Information
Creating multiple interfaces
The service provider can support a new interface. This approach works pretty
well for the first change, but it breaks down with multiple changes. Let's con-
sider first going from a five-digit to a nine-digit
ZIP
code. We can solve this
problem by adding a second full interface, with a new communications area
that supports the nine-digit
ZIP
code. We'll continue to support the old inter-
face. Now, if we also want to add a country code before all of our clients have
adopted the new interface, we have a problem. Depending on the priorities of
our clients, we'll probably be forced to support multiple versions of each inter-
face. At the worst, we'll need to support four interfaces instead of one: ver-
sions for the old
ZIP
with and without the country code, and versions for the
new
ZIP
with and without the new country code, as in figure 7.7. Because
we're dealing with only a single interface, it is easy to appreciate how quickly
these combinations can explode.
Communications
buffer
Communications
buffer
First name
Middle initial
Last name
Street address 1
Street address 2
City
State
Zip
Credit card no.
Expiration date
Communications
buffer
First name
Middle initial
Last name
Street address 1
Street address 2
City
State
Zip
Communications
buffer
First name
Middle initial
Last name
Street address 1
Street address 2
City
State
9 digit Zip
Credit card no.
Expiration date
First name
Middle initial
Last name
Street address 1
Street address 2
City
State
9 digit Zip
Service
requester
Service
provider
Country code
Credit card no.
Service
requester
Service
requester
Service
requester
Expiration date
Country code
Credit card no.
Expiration date
Figure 7.7 Dealing with tightly coupled interface changes through maintaining old versions can
lead to a proliferation of interfaces. Here, we are going from five- to nine-digit ZIP codes and adding
a country code in independent changes. To satisfy all of our clients, we keep back-level interfaces.
