From 094845f2a7c8d2c286093226f0f84fef108c9818 Mon Sep 17 00:00:00 2001 From: Chris Davoren Date: Tue, 10 Oct 2023 11:59:17 +1000 Subject: [PATCH] Refinement of Design section of README. --- README.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index f781246..919c0b7 100644 --- a/README.md +++ b/README.md @@ -70,11 +70,17 @@ REPORT Output: 3,2,NORTH ``` -### Design Decisions +### Design -The library (module in Python terminology) `toyrobot` contains just one class, `Robot`, that is aware of both its movement limits (configurable, but defaults to the 6x6 space in the original description) and can also interpret text commands. This monolithic design is appropriate given the simplicity of the problem as provided, but further separation of concerns may be desirable in a more complex application or context. +This is a relatively simple programming problem that one might expect to find as part of an introductory tertiary programming course. It focusses mainly on data representation, state tracking and modification, constraint checking, and some text processing in a text-based environment. Error handling is de-emphasised as most invalid inputs are discarded and one may assume that initial invalid states are not considered. File handling is not required, though it has been used in this implementation for static test data. -As per the spirit of the description, most methods are designed to "fail silently" (i.e. leave the Robot state unchanged) if they are invalid or are given invalid inputs. The one exception to this is the ``__init__`` constructor - if numerically invalid maximums are provided for movement limits then a `ValueError` exception is thrown. This ensures that a Robot instance cannot exist with an invalid initial state or configuration. +Initial thoughts on approach included the use of a basic state machine, but movement and coordinate tracking don't lend themselves neatly to a state machine architecture, and so a more tradaitional encapsulated state was used instead. + +The following additional considerations were made: + +- Command-line Python was chosen as the language of choice simply due to my familiarity with it. This problem could likely be implemented in any language or environment that supports an equivalent concept of "library", including functional languages. +- The library (module in Python terminology) `toyrobot` contains just one class, `Robot`, that is aware of both its movement limits (configurable, but defaults to the 6x6 space in the original description) and can also interpret text commands. This monolithic design is appropriate given the simplicity of the problem as provided, but further separation of concerns may be desirable in a more complicated context. For instance, if the problem were to require tracking of more than one robot, it may make sense to abstract out the movement domain and command interpreter as independent entities. +- As per the spirit of the description, almost all methods are designed to "fail silently" (i.e. leave the Robot state unchanged) if they are invalid or are given invalid inputs. The one exception to this is the ``__init__`` constructor - if numerically invalid maximums are provided for movement limits then a `ValueError` exception is thrown. This ensures that a Robot instance cannot exist with an invalid initial state or configuration. ## Installation and Pre-requisites