Factory and Adapter Patterns Project
VerifiedAdded on 2019/09/13
|10
|1460
|601
Project
AI Summary
This project focuses on implementing the Factory and Adapter design patterns in Java. Students are tasked with developing a configurable Blob game using these patterns. The project involves creating different game configurations using a GameFactory interface, which determines how blobs and points are created and how blobs are adapted to become GameStateObservers. Specific requirements include creating a BoundedLimitedVisionGameFactory and a SimpleGameFactory, each with its own implementation for creating points, blobs, and adapting blobs to observe game state changes. The project also requires adding a BlobAsObserverAdapter to enable blobs to observe game state. Students are provided with a Maven project setup and a BlobAPI.jar containing necessary interfaces and classes. Thorough testing is emphasized, requiring students to write additional tests to ensure the correctness of their implementation. The project aims to solidify understanding of design patterns and their application in building flexible and maintainable software.

Factory and Adapter
Patterns
The goal of this project is to give you experience with
the factory and adapter patterns.
Note: The assignment must be completed in the
specific manner described in the instructions. Any
deviations from the instructions will possibly cause
the automated grading to fail and will be considered
incorrect. Following the instructions includes, but is
not limited to:
•Do not change the test code in any way. If the test
code does not compile, change your
implementation of the classes being tested, not
the tests! (you may add additional tests)
•Do not modify interfaces and abstract classes
provided to you in any way unless specifically
instructed to do so.
•Do not modify class constructors, method
signatures, or local field names unless
specifically instructed to do so.
•Do not add fields to any classes unless specifically
instructed to do so.
Patterns
The goal of this project is to give you experience with
the factory and adapter patterns.
Note: The assignment must be completed in the
specific manner described in the instructions. Any
deviations from the instructions will possibly cause
the automated grading to fail and will be considered
incorrect. Following the instructions includes, but is
not limited to:
•Do not change the test code in any way. If the test
code does not compile, change your
implementation of the classes being tested, not
the tests! (you may add additional tests)
•Do not modify interfaces and abstract classes
provided to you in any way unless specifically
instructed to do so.
•Do not modify class constructors, method
signatures, or local field names unless
specifically instructed to do so.
•Do not add fields to any classes unless specifically
instructed to do so.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

High Level Goal
We will again be continuing development of our Blob
game by using the factory pattern to create different
game configurations which will determine how blobs
and points are created and how blobs are turned into
GameStateObservers. By using the factory pattern
we can ensure that the game remains consistent.
For instance, in previous versions of the code we
allowed users to create Blob objects and provide
them to the game. This means that the user could
also initialize the Blob with a SimplePoint or
BoundedPoint. If we wanted all objects to remain in a
bounded game space, this would not work.
To get around this, we could, for example, create a
factory that performs the actual Blob creation and
code it to use BoundedPoint objects and guarantee
that all blobs created using this factory are bounded!
We will apply this principle to a few other cases and
then we will make our Game configurable by passing
it a factory providing the functionality it needs to
create Point object, Blob objects and for creating
GameStateObserver objects which adapt Blob
objects so that they can observe the game state
changes in a consistent way.
As with previous projects, some of the classes you
have used in the past have changed slightly, so be
sure to pay attention to the specifics of this project
We will again be continuing development of our Blob
game by using the factory pattern to create different
game configurations which will determine how blobs
and points are created and how blobs are turned into
GameStateObservers. By using the factory pattern
we can ensure that the game remains consistent.
For instance, in previous versions of the code we
allowed users to create Blob objects and provide
them to the game. This means that the user could
also initialize the Blob with a SimplePoint or
BoundedPoint. If we wanted all objects to remain in a
bounded game space, this would not work.
To get around this, we could, for example, create a
factory that performs the actual Blob creation and
code it to use BoundedPoint objects and guarantee
that all blobs created using this factory are bounded!
We will apply this principle to a few other cases and
then we will make our Game configurable by passing
it a factory providing the functionality it needs to
create Point object, Blob objects and for creating
GameStateObserver objects which adapt Blob
objects so that they can observe the game state
changes in a consistent way.
As with previous projects, some of the classes you
have used in the past have changed slightly, so be
sure to pay attention to the specifics of this project

and do not assume that you know what all the
interfaces, classes, etc. look like already! The
changes from the previous project include, but are
not necessarily limited to the following:
•The SimpleBlob no longer implements
GameStateObserver in order for a Blob to
observe game state, we must use an adapter.
•To join the game, you no longer provide a Blob.
Instead, you will simply provide a MoveStrategy
and the Game will actually create the Blob using
a factory, then the Blob will be returned to the
caller
Testing
You are provided with a very inadequate test suite
and will need to write additional tests in order to
make sure that your code works properly. To help
with this task, I have added testing notes below to
get you thinking in the right direction.
interfaces, classes, etc. look like already! The
changes from the previous project include, but are
not necessarily limited to the following:
•The SimpleBlob no longer implements
GameStateObserver in order for a Blob to
observe game state, we must use an adapter.
•To join the game, you no longer provide a Blob.
Instead, you will simply provide a MoveStrategy
and the Game will actually create the Blob using
a factory, then the Blob will be returned to the
caller
Testing
You are provided with a very inadequate test suite
and will need to write additional tests in order to
make sure that your code works properly. To help
with this task, I have added testing notes below to
get you thinking in the right direction.
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Add API Dependency
The classes from Projects 1, 2 and 3 are now
packaged as a BlobAPI.jar. This class will provide you
with interfaces, abstract classes, etc. that you will
need for the rest of the assignment. Before you can
do this, you need to add the BlobAPI artifact to your
dependencies by following the instructions here:
Maven
Repository for storing maven artifacts.
Add New Maven Repository
You will need to add the following to your pom.xml
file so that Maven will know to search this repository
for artifacts:
<repositories>
<repository>
<id>BlobAPI-mvn-repo</id>
<url>https://raw.github.com/MSUCSC430/Maven/mvn-
repo/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
Once you have added this repository, you must add a
dependency on the BlobAPI artifact itself.
The classes from Projects 1, 2 and 3 are now
packaged as a BlobAPI.jar. This class will provide you
with interfaces, abstract classes, etc. that you will
need for the rest of the assignment. Before you can
do this, you need to add the BlobAPI artifact to your
dependencies by following the instructions here:
Maven
Repository for storing maven artifacts.
Add New Maven Repository
You will need to add the following to your pom.xml
file so that Maven will know to search this repository
for artifacts:
<repositories>
<repository>
<id>BlobAPI-mvn-repo</id>
<url>https://raw.github.com/MSUCSC430/Maven/mvn-
repo/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
Once you have added this repository, you must add a
dependency on the BlobAPI artifact itself.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Add Maven Dependency
In the dependencies section of your pom.xml file, you
will need to add the following:
<dependency>
<groupId>info.phillipwright.blobs.api</groupId>
<artifactId>BlobAPI</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
This tells Maven that your code will not compile and
execute properly without the code in the BlobAPI.jar
artifact. Accordingly, Maven will search the
repository we added above (as well as some other
built-in default repositories) until it finds version 1.0-
SNAPSHOT of the file BlobAPI.jar. It will then
download this file and add it to your classpath as
necessary when compiling, executing, etc.
In the dependencies section of your pom.xml file, you
will need to add the following:
<dependency>
<groupId>info.phillipwright.blobs.api</groupId>
<artifactId>BlobAPI</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
This tells Maven that your code will not compile and
execute properly without the code in the BlobAPI.jar
artifact. Accordingly, Maven will search the
repository we added above (as well as some other
built-in default repositories) until it finds version 1.0-
SNAPSHOT of the file BlobAPI.jar. It will then
download this file and add it to your classpath as
necessary when compiling, executing, etc.

BlobAsObserverAdapter
First, we will use the adapter pattern to create an
adapter that allows us to use a Blob as a
GameStateObserver.
Implementation Details
•Add a constructor to initialize the given fields
•Implement all methods in the GameStateObserver
interface. Remember, you need to adapt the
Blob, so when implementing these methods you
need to make sure that the behavior is
ultimately determined by the Blob object.
Testing
•What happens if the input to updateLocations is
null?
•Are the getX and getY methods returning the x and
y coordinates of the Blob?
•What happens if the list passed to updateLocations
is empty?
First, we will use the adapter pattern to create an
adapter that allows us to use a Blob as a
GameStateObserver.
Implementation Details
•Add a constructor to initialize the given fields
•Implement all methods in the GameStateObserver
interface. Remember, you need to adapt the
Blob, so when implementing these methods you
need to make sure that the behavior is
ultimately determined by the Blob object.
Testing
•What happens if the input to updateLocations is
null?
•Are the getX and getY methods returning the x and
y coordinates of the Blob?
•What happens if the list passed to updateLocations
is empty?
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

BoundedLimitedVisionGameFactory
Now we will start working with our GameFactory
interface and creating our first game configuration.
The factory that we want to create should have the
following characteristics:
•createPoint should create a BoundedPoint object
with the given coordinates if possible.
•createBlob should use a given
PointGenerationStrategy to get a tuple of x and
y coordinates that should be used to create a
BoundedPoint (you should reuse the method
above!) that will be used (along with the
provided strategy) to create a SimpleBlob object.
•makeBlobObservable should take a Blob and return
a LimitedVisionObserver that ultimately
delegates to the provided Blob. Note:
LimitedVisionObserver is a decorator for the type
GameStateObserver, so you can't use it to
decorate a Blob! You must first adapt your Blob
so that you can then decorate it!
To understand why we are doing this, let's look at the
code in the Game class:
public Optional<Blob> joinGame(final MoveStrategy
Now we will start working with our GameFactory
interface and creating our first game configuration.
The factory that we want to create should have the
following characteristics:
•createPoint should create a BoundedPoint object
with the given coordinates if possible.
•createBlob should use a given
PointGenerationStrategy to get a tuple of x and
y coordinates that should be used to create a
BoundedPoint (you should reuse the method
above!) that will be used (along with the
provided strategy) to create a SimpleBlob object.
•makeBlobObservable should take a Blob and return
a LimitedVisionObserver that ultimately
delegates to the provided Blob. Note:
LimitedVisionObserver is a decorator for the type
GameStateObserver, so you can't use it to
decorate a Blob! You must first adapt your Blob
so that you can then decorate it!
To understand why we are doing this, let's look at the
code in the Game class:
public Optional<Blob> joinGame(final MoveStrategy
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

strategy){
return gameFactory.createBlob(strategy).map(blob
->{
blobs.add(blob);
gameFactory.makeBlobObservable(blob).ifPresent(this::
subscribe);
return blob;
});
}
When we want to join the game, we provide a
MoveStrategy and then the code uses the
GameFactory to create a blob with this strategy
which is adds to the internal list of Blob objects in the
game. Afterwards, we again call the GameFactory
and use it to adapt the newly created Blob to be a
GameStateObserver so that we can add it to the list
of subscribers observing the game state.
If we did not use a factory, we would have to
hardcode the specific Point subclass to use, the
specific GameStateObserver, etc. If we wanted to
create different variations of the game, we would
have to then create new Game classes for each
variation.
Implementation Details
•You need to add a constructor to initialize the local
fields
•You need to implement the GameFactory interface
as described above.
•Be sure that all points you create a BoundedPoint
objects
return gameFactory.createBlob(strategy).map(blob
->{
blobs.add(blob);
gameFactory.makeBlobObservable(blob).ifPresent(this::
subscribe);
return blob;
});
}
When we want to join the game, we provide a
MoveStrategy and then the code uses the
GameFactory to create a blob with this strategy
which is adds to the internal list of Blob objects in the
game. Afterwards, we again call the GameFactory
and use it to adapt the newly created Blob to be a
GameStateObserver so that we can add it to the list
of subscribers observing the game state.
If we did not use a factory, we would have to
hardcode the specific Point subclass to use, the
specific GameStateObserver, etc. If we wanted to
create different variations of the game, we would
have to then create new Game classes for each
variation.
Implementation Details
•You need to add a constructor to initialize the local
fields
•You need to implement the GameFactory interface
as described above.
•Be sure that all points you create a BoundedPoint
objects

•Be sure that you use the LimitedVisionObserver
class
•Be sure that you use the PointGenerationStrategy
to get the coordinates for creating a Blob
Testing
•Be sure that you are using the parameters passed
in the constructor to parameterize your
BoundedPoint and LimitedVisionObserver
objects.
SimpleGameFactory
One of the goals of using a factory was that we could
create different game variations, so now you will
create a second GameFactory for a different
variation.
This GameFactory should have the following
characteristics:
•createPoint should create a SimplePoint
•createBlob should create a SimpleBlob
•makeBlobObservable should simply adapt the Blob
to a GameStateObserver
In other words, this configuration will have an
unbounded game space with blobs that have
class
•Be sure that you use the PointGenerationStrategy
to get the coordinates for creating a Blob
Testing
•Be sure that you are using the parameters passed
in the constructor to parameterize your
BoundedPoint and LimitedVisionObserver
objects.
SimpleGameFactory
One of the goals of using a factory was that we could
create different game variations, so now you will
create a second GameFactory for a different
variation.
This GameFactory should have the following
characteristics:
•createPoint should create a SimplePoint
•createBlob should create a SimpleBlob
•makeBlobObservable should simply adapt the Blob
to a GameStateObserver
In other words, this configuration will have an
unbounded game space with blobs that have
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

unlimited "vision" of other blobs.
Implementation Details
•You need to add a constructor for setting the
PointGenerationStrategy field
•You need to implement the GameFactory interface
Testing
Good Luck!
Implementation Details
•You need to add a constructor for setting the
PointGenerationStrategy field
•You need to implement the GameFactory interface
Testing
Good Luck!
1 out of 10
Related Documents
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
Copyright © 2020–2025 A2Z Services. All Rights Reserved. Developed and managed by ZUCOL.




