[ ] Use the Observer pattern (i.e. Subject and Observer classes) to implement a game log class named
LogObserver that writes every game command read by a CommandProcessor object (or a
FileCommandProcessorAdapter object) into a log file.
[ ] The game log observer should be notified by the CommandProcessor::saveCommand() method that saves the command into the collection of commands, as well as the and Command::saveEffect() method that records the effect of the command into the command object.
[ ] This should result in all the current game’s commands and their effects to be logged into a “gamelog.txt” file.
[ ] In the same way, when any order is put in a player’s OrderList using OrderList::addOrder() the order should
be output to the log file using the Observer notification mechanism. Later, when any order gets executed, its effect
(as stored in the order itself) should be output to the log file, again using the Observer’s notification mechanism.
[ ] Also in the same way, when the GameEngine’s state is changing (e.g. using GameEngine::transition()), a log
line should be output to the log file stating what is the new game state, using the Observer notification
mechanism.
[ ] As part of your design for this solution you must include a class named ILoggable that must be inherited by all
classes that can be the subject of logging mechanism as described above. This class is essentially an interface
that must contain a pure virtual member function name stringToLog() that creates and returns a string to be
output to the log file.
[ ] The Observer, Subject and ILoggable classes must be implemented as part of a single .cpp/.h file duo
named LoggingObserver.cpp/LoggingObserver.h. See below for a snapshot of the diagram used in the video.
You must deliver a driver as a free function named testLoggingObserver() that demonstrates that
(1) The Command, CommandProcessor (see Part 1), Order, OrderList, and GameEngine classes are all a subclass of the
Subject and ILoggable classes
(2) the CommandProcessor::saveCommand(), Order::execute(), Command::saveEffect(), OrderList::addOrder(), and GameEngine::transition() methods are effectively using the Observer patterns’ Notify(Subject) method to trigger the writing of an entry in the log file
(3) the gamelog.txt file gets correctly written into when commands are entered on the console
(4) when an order is added to the order list of a player, the game log observer is notified which results in outputting the order to the log file
(5) when an order is executed, the game log observer is notified which results in outputting the effect of the
order to the log file
(6) when the GameEngine changes its state, the new state is output to the log file. This driver
function must be in the LoggingObserverDriver.cpp file.
[ ] Use the Observer pattern (i.e. Subject and Observer classes) to implement a game log class named LogObserver that writes every game command read by a CommandProcessor object (or a FileCommandProcessorAdapter object) into a log file.
[ ] The game log observer should be notified by the CommandProcessor::saveCommand() method that saves the command into the collection of commands, as well as the and Command::saveEffect() method that records the effect of the command into the command object.
[ ] This should result in all the current game’s commands and their effects to be logged into a “gamelog.txt” file.
[ ] In the same way, when any order is put in a player’s OrderList using OrderList::addOrder() the order should be output to the log file using the Observer notification mechanism. Later, when any order gets executed, its effect (as stored in the order itself) should be output to the log file, again using the Observer’s notification mechanism.
[ ] Also in the same way, when the GameEngine’s state is changing (e.g. using GameEngine::transition()), a log line should be output to the log file stating what is the new game state, using the Observer notification mechanism.
[ ] As part of your design for this solution you must include a class named ILoggable that must be inherited by all classes that can be the subject of logging mechanism as described above. This class is essentially an interface that must contain a pure virtual member function name stringToLog() that creates and returns a string to be output to the log file.
[ ] The Observer, Subject and ILoggable classes must be implemented as part of a single .cpp/.h file duo named LoggingObserver.cpp/LoggingObserver.h. See below for a snapshot of the diagram used in the video. You must deliver a driver as a free function named testLoggingObserver() that demonstrates that (1) The Command, CommandProcessor (see Part 1), Order, OrderList, and GameEngine classes are all a subclass of the Subject and ILoggable classes (2) the CommandProcessor::saveCommand(), Order::execute(), Command::saveEffect(), OrderList::addOrder(), and GameEngine::transition() methods are effectively using the Observer patterns’ Notify(Subject) method to trigger the writing of an entry in the log file (3) the gamelog.txt file gets correctly written into when commands are entered on the console (4) when an order is added to the order list of a player, the game log observer is notified which results in outputting the order to the log file (5) when an order is executed, the game log observer is notified which results in outputting the effect of the order to the log file (6) when the GameEngine changes its state, the new state is output to the log file. This driver function must be in the LoggingObserverDriver.cpp file.