FIGURE 6-1: The class diagram shows the structure of the factory method pattern.
You can see how the object creation is encapsulated in the subclasses.
At one time, I was developing a desktop application with a friend. At the beginning,
we were not sure if we needed a full‐blown database or not. This was long before
no‐SQL and document‐based data stores, so our only option was to use XML.
Nevertheless, we were not sure if XML i les would be sufi cient to store the data.
Meanwhile, we had already started developing the application and needed a
concrete persistence implementation to save data. Because we wanted the l exibility
to change the system from using XML to using SQL, we decided to create all the
data access objects (DAOs) via the implementation of the factory pattern. This
way we could easily switch from XML to SQL or vice versa. Within a few weeks,
we realized that we really underestimated the data needs of the system. XML was
dei nitely an adequate solution and was now out of question, so we were stuck with
an SQL‐based database for the rest of the project. In the end, we didn't really use
our DAO factory.
However, as we were completing the application, our clients asked for a demo
platform. It was not enough to demonstrate the capabilities of the application and
let them play for a day or two. They wanted more time to evaluate the application.
This meant we needed to install a functioning application on the network to allow
the clients time to properly evaluate the application and see that it rocked. We
didn't want to install the full application because there was no way to ensure that
the client wouldn't make a copy, and we dei nitely didn't want to build a demo
application from scratch. Suddenly, I came up with a brilliant idea. The demo
application needed to persist the data in order to function sufi ciently, so that the
client could evaluate it, but not enough that the client could make a pirate copy of
the application. The idea was to temporarily store the data in memory. If we could