Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Assignment
Dungeon Crawler
Introduction
This document specifies the requirements for the first assignment of the Software Development with C++ course,
SP5 2018. This assignment will develop your skills by allowing you to put into practice what has been taught in
class during the first 5 weeks of the course.
The assignment will require you to design, implement, test, and debug a text-based Roguelike dungeon crawler
game using object-oriented methods and the application of appropriate design patterns. In addition, it will
require you to use version control to keep track of your implementation as you progress through the assignment
and to document your classes appropriately using Doxygen comments. The work in this assignment is to be
performed individually and will be submitted via LearnOnline at the end of week 8: due by 14 September 2018
11:59 PM. Refer to section Submission Details for specific instructions.
If any parts of this specification appear unclear, please ensure you seek clarification.
Learning Outcomes
After completing this assignment, you will have learnt to:
? Design a class hierarchy using UML
? Apply Object-Oriented principles (encapsulation, reuse, etc.) and Design Patterns to the software design
? Implement the software design in C++ using class inheritance and polymorphism features
? Write well-behaved constructors and destructors for C++ classes
? Use C++ pointers (including smart pointers) and dynamic memory allocation and management
? Use stream I/O and manipulators for formatted input and output
? Write code adhering to coding standards, guidelines and good programming practices
Design Patterns
In developing the class design for the Dungeon Crawler game, the following the Design Patterns must be
incorporated:
? Singleton
? Builder
? Decorator
? Strategy
This section provides brief descriptions of each relevant design pattern in turn. For more information refer to the
book from which these summaries are derived:
Gamma, E, Helm, R, Johnson, R and Vlissides, J 1995, Design patterns: elements of reusable object-oriented
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 2 of 22
software, Addison-Wesley, ISBN: 978-0-201-63361-0.
1 Be aware that the C++ examples from the book are for an
older version of C++. If using them for guidance, they must be updated to C++ 14.
Adequate descriptions of the above patterns along with some code examples can also be found on Wikipedia:
? Singleton: https://en.wikipedia.org/wiki/Singleton_pattern
? Builder: https://en.wikipedia.org/wiki/Builder_pattern
? Decorator: https://en.wikipedia.org/wiki/Decorator_pattern
? Strategy: https://en.wikipedia.org/wiki/Strategy_pattern
Singleton
The Singleton pattern addresses the problem of ensuring that a class has only one instance. Moreover, the one
instance is easily accessible but in a controlled fashion. Such a pattern arises in situations where a single, globally
accessible interface to a system or subsystem is required and, hence, is often used with other patterns such as
Fa?ade and Abstract Factory. An example of singleton a singleton is an application wide configuration. Rather
than parsing the configuration file multiple times and storing multiple copies in memory, the configuration file
should be read once and stored once. Moreover, since various parts of the application may need to access
different settings, the configuration should be globally accessible to ensure the configuration is accessible when
needed. Other examples include: a single print spooler governing access to the printer resources, a single
thread/connection pool handing out connections or threads to clients that request them, etc.
When to Use
The Singleton pattern should be applied to a class when:
1. Exactly one instance of the class must exist
2. A well-known access point to the instance is required
In general, the extensibility of a Singleton through subclassing should also be considered. It will not be required
for this assignment; however, it is important to note as a common criticism of the Singleton pattern is that it
becomes tied to implementation and makes testing difficult due to the inability to replace the singleton instance
with a mock (i.e., a test specific class that is not a complete implementation).
General Structure
A simple representation of the Singleton pattern includes only a Singleton class, i.e., the class that should be a
Singleton, containing: a static member function instance() that returns the unique instance of the class, a
hidden constructor, and a static data member to hold the unique instance of the class.
Note the ‘+’ indicates public accessibility and ‘-‘ indicates private accessibility. If considering extensibility of the
Singleton through subclassing, the constructor should be protected rather than private.
1
Scanned PDFs of the relevant sections are available from the course website as the library has limited copies of the book.
Singleton
+ static instance()
- Singleton()
- static theInstance
return theInstance;
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 3 of 22
Implementation Hints
In C++, the compiler may generate some constructors and operators for you. Ensure you prevent the Singleton
from accidentally being copied or assigned in ways you do not intend by deleting any automatically generated
members that you do not need.
In C++, the static data member can be implemented in two different ways: within the scope of the class or within
the scope of the function. Consider the consequences of each approach and justify your implementation choice in
your comments.
Builder
The purpose of the Builder pattern is to separate the representation of a complex object from the process used to
construct it. Further, such separation allows different representations to be constructed from the same process.
For example, a Parser using a Builder to construct a parse tree in different systems: the recognition of the syntax
is handled by the parser, which calls the builder to create the appropriate parse nodes and retrieves the final
parse tree from the Builder once the parsing is complete. The different representations may or may not be
related, for example, an executable parse tree of the parsed syntax, a parse tree for another language (such as in
code transformation), or a composition of widgets for visualising the text processed by the Parser.
An important aspect of the Builder pattern that differentiates it from other creational patterns is that it supports
the creation of complex objects in a step-by-step process, rather than all-at-once.
When to Use
The Builder pattern should be applied when:
? the construction process is, or should be, independent of the object, its parts, and the way that it is
assembled
? the construction process should allow for different representations to be created.
Note that there does not always have to be multiple representations, only that multiple representations are
possible. One of the motivations for good design is to support future change more easily.
General Structure
The Builder pattern contains several interacting classes, including:
? the Director, which represents the entity that requires the object to be constructed and ‘directs’ the
Builder to construct it;
? the Builder, which specifies an abstract interface for constructing any Product object, this may include
many different member functions for constructing different types of parts;
? one or more ConcreteBuilders, which create specific Products from its parts by implementing the
abstract Builder interface and allows the Product to be retrieved once complete as it maintains the
representation internally during construction;
Revision 1
COMP 3023 Software Development with C++ - Assignment SP5 2018 Page 4 of 22
? the Product class, which represents the complex object being created by a ConcreteBuilder as well as
its parts. Note: this does not mean the classes for the parts are encapsulated by the Product class, only
that the diagram is simplified to not explicitly illustrate any of the Product’s parts.
Implementation Hints
If the representations being constructed by the different ConcreteBuilders are related, the abstract Builder
may declare an appropriate getResult() member function as part of its interface.
The ConcreteBuilder object is not required to be supplied to the Director via a constructor, it could also be a
parameter to a member function.