API_REVIEW_BT72_BGS21.md

Front end external API peer review (bt72) :

Part 1:
1) What about your API/design is intended to be flexible? We are going to generalize the functionality of our public methods (i.e. the turtle view class will have a method called update() but all the specific aspects of the view that are being updated will be implemented in the private helper methods). This way we will be able to very easily change what entails updating the turtle without having the change the code where we want the turtle to update. Essentially, our approach is going to be using broad public methods with specific and compartmentalized private methods. 2) How is your API/design encapsulating your implementation decisions? I think the idea of using general public methods and specific and compartmentalized helper method aids in encapsulation. Specific functionality such as how to move the turtle to the desired location/how the "pen" is put down will be encapsulated in the private helper methods in a way such that the user will never have to know/care about how it happens. All he/she will have to know is the update method will update the turtle appropriately by calling methods to update the pen/turtle location/turtle rotation. 3) What exceptions (error cases) might occur in your part and how will you handle them (or not, by throwing)? We decided that having all the error checking in the back end would be more appropriate since we wanted to compartmentalize functionality as much as possible. After all, what's the difference from error checking in the front end versus sending the invalid command to the back end and having it check for errors there. We saw invalid commands as the only possible error we would have to handle (including trying to move the turtle with a valid command to an invalid location) and that it would be very possible to have the back end handle all of that. So, we made the back end handle all of that. 4) Why do you think your API/design is good (also define what your measure of good is)? I think our front end API is good because of how extendable it is. If we wanted to change what it meant for the turtle to update itself, we don't have to change any part of our code besides the private helper methods called by update. If we made each aspect of update its own public method, we would have to go through every single line of our code and check here we call them and change that. Our compartmentalization makes this a lot easier. I defined a good API as something that is extendable and easy to understand. Methods like update and setTurtleLocation are named so that their function is extremely obvious, and, as I said before, the specific private helper methods and general public methods allow for a great deal of flexibility.

Part 2: 1) How do you think Design Patterns are currently represented in the design or could be used to help improve the design? When we implement our code, we will definitely use the chain of responsibility design pattern. This is so that we can easily send commands from the back end to the front end to update the turtle. Depending on the command, it'll be handled differently by the front end (i.e. putting the pen down/moving without the pen will require different things to happen in the front end). Another design pattern we will use is command. We plan to use a TurtleInfo class to send commands from the back end to the front end so that we can pack as much as we want to into a command/be able to change what is inside our commands very easily. 2)How do you think the "advanced" Java features will help you implement your design? We will definitely use binding to implement accessing the history of commands. This will make it much easier to keep track of all the past commands since all we will have to do is add the commands to a List which will be bound to the history combo box. We will also use Reflection to create the appropriate command objects when the correct string is typed in. 3)What feature/design problem are you most excited to work on? I'm definitely most excited to work on the turtle functionality. Besides Breakout, I haven't done that much with JavaFX in terms of creating something on a screen that actually moves. Most of my coding until now has been very abstract in that you can't actually see what's going on in the application. I'm extremely excited to create something where I can actually see a visual affirmation of my work. 4)What feature/design problem are you most worried about working on? I'm worried about the options menu and help bar because that's something I have absolutely no experience with, so I have no idea what to expect. I feel like it won't be that bad because all that it would require is binding a list to a certain pain (or at least what I think it'll require), but I'm not sure how I'll be able to make it so the option they click on from the pull down menu changes what occurs after it's clicked. Basically, I'm worried about dynamically creating panes (or nodes?) in Java FX and implementing their functionality. 5)Come up with at least five use cases for your part (it is absolutely fine if they are useful for both teams).

1. 'Fd 30' The front end would take in the command through the CommandPromptView. The back end would use the getCommand method to get the String and check if its a valid command and parameter. If so, it creates a TurtleInfo class and sends it to the front end so that the front end knows how to appropriately update the turtle.
2. 'Cereal 270' The front end would take in the command through the CommandPromptView. The back end would use the getCommand method to get the String and check if its valid. The back end would see that Cereal isn't a valid command and wouldn't tell the front end to do anything. It also wouldn't save the command in the List of past commands so that the comboBox bound to this list wont represent it (after all we want the history to be a history of valid commands).
3. UpdateVariableDisplay(listOfVariables) The model controllers would call this on its instance of SLogoView and it would call this on its instance of VariablesView. This method will communicate with the back end by taking in the list of variables as a parameter (given to it from the back end) and will change the variable pane in the frame so that it accurately represents all the new variables.
4. Someone clicks on a button The SLogoController's event listener would tell its instance of SLogoView which would tell its instance of MenuBarView that a button has been clicked and the ButtonSelected method would be called. Depending on which button is clicked, the implementation of ButtonSelected will cause the appropriate actions to be taken.
5. 'Pen down' The front end would take in the command through the CommandPromptView. The back end would use the getCommand method to get the String and check if its a valid command and parameter. If so, it creates a TurtleInfo class and sends it to the front end so that the front end knows how to appropriately update the turtle. (Same as 'Fd 30' but the TurtleInfo instantiation would be hold different information).

Written with StackEdit.