Software Development Cross Solution - Index of - Free

switching to test code with the strategy pattern
The strategy pattern provides for multiple
implementations of a single interface
We want to hide how the system gets gift cards, and vary it depending on
whether we’re testing the code or we’re running the system in production. Flip
to Chapter 1 of Head First Design Patterns and you’ll find there’s a ready made
pattern to help us deal with just this problem: the strategy pattern.
We can provide two different
implementations: one for when
we’re testing, that doesn’t really
296 Chapter 8
DBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)
With the strategy pattern
you provide an interface
specification for the
algorithm you want to vary.
hit a database, and.......one that actually hits the
TestDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)
Now we’ve got two different ways of hitting the database, and
OrderProcessor doesn’t need to know which one it’s using.
Instead, it just talks to the DBAccessor interface, which hides
the details about which implementation is actually used.
All we need to do now is add a way to give the OrderProcessor
the correct DBAccessor implementation, based on whether the
test code or the system is providing it.
OrderProcessor
- dbAccessor : DBAccessor
+ setDBAccessor(DBAccessor) : void
+ procesOrder(orderInfo : OrderInformation) : Receipt
Download at WoweBook.Com
database. This class can be
written later, as part of the
database task.
MySqlDBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)
* If your customer was unsure
about what database they
might use in production, this
same approach would make it
easy to swap out database
vendors and implementations.
The strategy pattern
encapsulates a family of
algorithms and makes
them interchangeable.