davorian
/
toyrobot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Refinement of Design section of README.

This commit is contained in:
Chris Davoren 2023-10-10 11:59:17 +10:00
parent 5aef482819
commit 094845f2a7
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -70,11 +70,17 @@ REPORT
Output: 3,2,NORTH 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 ## Installation and Pre-requisites