Exercise $-$ Behavioral Patterns

$$ For this first exercise you$$ll be

focusing on a set of classes

that represent pets. The main

classes and their members can

be represented in a UML class

diagram shown

$$ In this exercise, you$$ll be

extending and then refactoring

the codebase to explore how

behavioral patterns can

simplify the process of adding

new functionality, and can

remove the need for duplicate

code

Exercise $1$a $-$ The Strategy Pattern

$$ Add a new Pet class CuddlyToy that requires new algorithms for

the growth, feeding, hunger, and crying

$$ Consider how one might use sub$-$class$/$super$-$class relationships to

avoid duplicate code

$$ Implement an abstract GrowthStrategy that provides method

signatures for growth$-$related algorithms

$$ Implement the three concrete implementations of

GrowthStrategy encountered so far

$$ Modify the existing Pet classes to use the newly created strategy

classesStage $1-$ Add a new Pet class

$$ You$$ve been asked to add a new Pet, CuddlyToy, for

players that $($for example$)$ have allergies or just don$$t

want the effort of looking after a real$-$life creature. The

requirements for CuddlyToy are as follows:

$$ A CuddlyToy should not grow, they are ADULT$\_$SIZE at

instantiation

$$ A CuddlyToy does not eat, and should not get hungry

$$ A CuddlyToy squeaks, its cry is generated by a plastic

squeaker

Stage $2-$ Design sub$-$class$/$super$-$class

relationships to avoid duplicated code

$$ It$$s clear that many of our Pets have

quite different algorithms for growth.

Some, like Goats and Cats grow

steadily, increasing by a fixed amount

over a constant time interval. Others,

like MagicDragons, increase by a fixed

amount but at irregular intervals $$

their growth stagnates for a while and

then they undergo a growth spurtStage $3-$ Introduce a GrowthStrategy

$$ A Strategy pattern defines a encapsulates a family of

interchangeable algorithms $$ here, our

interchangeable algorithms describe different patterns

of growth.

$$ The first step in refactoring to a Strategy will be to

create an abstract class GrowthStrategy.

$[$ACTION$]$ Create a new GrowthStrategy class, with

abstract method signatures for canGrow$()$ and Grow$()$

Stage $4-$ Implement concrete growth

strategies

$$ You now need to create concrete implementations of your

GrowthStrategy class, each representing a different growth

algorithm. So far, we$$ve encountered three growth algorithms:

$$ Steady growth $$ Grows by a fixed amount every time the grow

method is called.

$$ Random growth $$ Grows by a fixed amount some random subset

of times that the grow method is called.

$$ No growth $$ Does not grow, even when the grow method is

called.

$[$ACTION$]$ Create three subclass implementations of

GrowthStrategy, one for each of the growth algorithms

encountered so far.

Stage $5-$ Modify the codebase to use

our GrowthStrategy

$$ Now we have a selection of implemented GrowthStrategy

classes, we need to modify the Pet subclass to utilise these new

classes. To do this, we$$ll add an attribute growthStrategy of

type GrowthStrategy to the Pet class. We$$ll also need to add a

set method for the new attribute, and modify the existing

canGrow$()$ and grow$()$ method in Pet and it$$s subclasses to

make calls to the new strategies.

$[$ACTION$]$ Make the remaining code changes needed to have Pet

and its subclasses use GrowthStrategy. This should now mean

that there is no special$-$case grow$()$ implementation in

MagicDragon and CuddlyToy