Graphics Programs Reference
In-Depth Information
For the More Curious: Designing a Store Object
You have built and used a number of different store objects in this topic. In this section, we
will analyze these differences and give you a guide for determining how to build store ob-
jects in your own applications.
When designing a store object you must answer these questions:
• What external source(s) will it work with?
• Should it be a singleton?
• How will it deliver the results of a request?
Determining external sources
When designing a store, you must first consider what the application is trying to accom-
plish. How many external sources will there be and of what type? This, in turn, will help
you determine how many store objects an application needs.
Should applications have one-to-one correspondences between store objects and external
sources? We've seen that's not the case. For example, in
Nerdfeed
, the store originally
worked with one source - the BNR web server. Then we added a request to the iTunes web
server. Even though these are two separate requests made to two separate sources, the code
for interacting with them is very similar. So, it made sense to have a single store object
handle both rather than have two objects with redundant code.
On the other hand, in
Homepwner
, you had two store objects: the
BNRItemStore
for
fetching and saving items and the
BNRImageStore
for fetching and saving images.
These two stores handle different types of data and requests. So the request logic was better
kept separate in two objects. The
BNRImageStore
was meant to deal with saving and
loading images - it wasn't tied to the idea of a
BNRItem
or even
Homepwner
. Bundling it
together with
BNRItemStore
would make for less tidy and reusable code.
