Description
Use Linux to create a user-defined Abstract Data Type (ADT) using C++ classes named Warrior and View along with an appropriate set of C++ header/implementation files as discussed in class. • The Warrior class describes the current state of an individual Warrior class instance. • The View class displays the current state of an individual Warrior class instance. • The Warrior and View classes define the CharacterNS namespace. o The Warrior and View classes do NOT use this namespace.
The View class needs to see the Warrior class, but the Warrior class does not need to see the View class.
The UML diagram does not show: • access specifies: public, protected, private • default values: arguments, attributes, … • use of the const keyword • function inlining implementations: explicit, implicit • enumeration implementations: public, private
The Warrior/View ADT must define and implement the following data types and operations. • Do not add to or modify the public interface (exportable components – public components). • Do not add to or modify any attributes or data types (storage components). Warrior class Exportable Operations: (declared .h file and defined .cpp file) Warrior default/overloaded/parameterized constructor • 150 is the default lifeForce value • 25 is the default resistance value • SWORD is the default equipped weapon • MALE is the default gender Warrior copy constructor – creates an exact copy of an existing Warrior class instance ~Warrior destructor – displays the message: Warrior class instance destroyed setters each private attribute is supported by an appropriate standard setter method exception gender – see GenderType use explicit function inlining implementation techniques getters each private attribute is supported by an appropriate standard getter method exception gender – see GenderType use explicit function inlining implementation techniques
Warrior class User-Defined Data Types: GenderType FEMALE, MALE use private enumeration implementation techniques use implicit function inlining implementation techniques WeaponType DAGGER, MACE, SWORD use public enumeration implementation techniques
View classes Exportable Operations: (declared .h file and defined .cpp file) View default constructor View overloaded/parameterized constructor – accepts a Warrior class instance View copy constructor – creates an exact copy of an existing View class instance ~View destructor – displays the message: View class instance destroyed setWarrior Warrior class instance to be viewed implemented using the Warrior class setters and getters viewWarrior displays the state of the currently contained Warrior class instance on the screen
viewWarrior Only apply function inlining implementation techniques where stated. • All other functions are declared and defined using standard techniques supporting implementation hiding. Apply Setter and Getter function reuse “wherever” possible. • Act as helper functions for Warrior class function implementation // E.g. constructor functions Apply the const keyword “wherever” appropriate. • functions, arguments, … // E.g. getter, view, … functions
Make sure to completely document the header/implementation files. • The header (.h) file tells the user exactly how to use your ADT o General descriptions only – do not include implementation details • The implementation file (.cpp) tells the implementer/programmer exactly how the ADT works o Detailed descriptions – include implementation details Add appropriate guards to prevent multiple inclusions of the individual ADT modules.
The Warrior/View ADT exists entirely within the CharacterNS namespace. • “Using Directive” to access the CharacterNS namespace members – outside the Warrior/View ADT only. • “Accessing Members Directly” to access the std namespace members: cin, cout, endl, etc… I will write a test program that will include your Warrior/View ADT so all header/implementation files tested must use common names. So you MUST use: • the EXACT same names for each data type and function in the header/implementation files. • the EXACT same function argument sequence in the header/implementation files.
Zip together and e-mail your Project Folder using the following naming convention. • Do not e-mail your main/driver program used for testing purposes o I will create my own main/driver program to test your ADT Archieve Name: Lastname3.zip or Lastname3.7z // I would use Gamradt3.zip Project Folder: Lastname3 // I would use Gamradt3 • Warrior.h Warrior class header file • Warrior.cpp Warrior class implementation file • View.h View class header file • View.cpp View class implementation file • main.cpp driver program file // I will use my own • CMakeLists.txt // No C++ 11 o Project name: Lastname3 // I would use Gamradt3 o Executable name: dragon List the class number, your lastname, and assignment number as the e-mail message subject: SUBJECT: csc346 – gamradt – a3 // I would use
Warrior/View ADT include sequence with multiple modules: // Never include .cpp files
Warrior.h Warrior.cpp
main.cpp View.h View.cpp
Warrior/View ADT building with multiple modules: // Using cmake 1. Place all files in the project folder (see above) // I would use Gamradt3 2. cmake -G “Unix Makefiles” // Generate Makefile 3. cmake –build . // Build project – create executable 4. ./dragon // Run project
Note: when submitting remove all files and folders created by the build process • See above for require files in the submitted project folder
