#Assignment 2 Write Up ##Part 1: Reflection on pair programming Our group has resolved two challenges through the pair programming technique. The first one occurred at the beginning phase of our assignment. Prior to our meeting, each team member read through the requirements and wrote down key ideas that we could use to design our code.
The first obstacle we faced was designing a class that can handle the files and sends the required data back to the controller. We agreed that since Zhao Tingji first investigated this problem, he volunteered to be the driver. Gareth Chen was the navigator.
At first, the driver wanted to implement a class called DataUtil. This class will handle the request sent from the controller and service level and store, update the data to file or query data and return them back to the controller and service. He argued that it is necessary to manage files and process data in the same class because many methods need to modify the file and process the data frequently. Naturally, it is most convenient to hold all the data processing and file managing methods together into one class.
As the driver starts coding, the class gets longer and many methods are irrelevant to each other. The navigator soon points out that there is a problem with this design. The navigator discovered that while this design is viable, it would lead to low cohesion. The one DataUtil class will be doing too much work, some of which are unrelated or have very little correlation with the other. Specifically, all the work of IO can be done independently of all the data processing. Data processing looks at the existing data and modifies them into the desired value, while IO stores, reads, and updates the data as files onto the hard drive. The navigator guides the driver to implement them into separate CsvManager and DBManager. This design allows the CsvManager to focus on processing the data in memory. Once its job is done, it can simply send the data to DBManager. DBManager, on the other end, only needs to achieve functionalities such as creating, updating, and accessing files. The driver agrees that this design is certainly better since it leads to high cohesion and better encapsulation.
The second challenge we faced was how to handle bad inputs. Gareth Chen will be the driver this time since he worked on this part at first. Zhao Tingji will be the navigator. The driver’s original design was to handle them at the highest level. (i.e. the controller level) He argues that the controllers are the first classes to interact with the request input, so it should be dealt with as soon as possible. The driver started writing codes that check the user’s input and response back to the user. However, the navigators find a weak point of this design and a better design so that this problem could be resolved. The navigator contends that there could be other problems when running the code. The controllers simply cannot handle all the problems. For example, what if there is a problem when writing into a file in DBManager? DB managers will need a method to handle the problem as well. A better design would be having the lower level classes such as DBManager throw exceptions including when it encounters a bad request. Then, using the controllers to handle these exceptions and respond to the respective information back to the user. The driver admitted this is a better design and implemented code accordingly.
In conclusion, the pair programming experience has its downsides. It often requires high concentration from the navigator. Since he is not coding, it is very easy for him to get distracted and lose track. However, our group discovered the pair programming’s advantages are much larger than its disadvantages. The technique allows the teammate to work in synchronization, which will save the time we have to explain the code to each other after coding on our own. It also allows us to find problems on the spot, and since the navigator is not coding, he often has a clearer mindset to figure out a suitable solution. Overall, it is an amusing experience and would form a closer relationship between the classmates. Ultimately, our group enjoyed it so much that we ended up writing most of our project together with this technique. ##Part 2: The design We designed the endpoint following the REST controller standards to meet the requisition proposed by the assignment. The methods that modify the database such as update, upload, and overwrite would be using the POST method while querying and data and having them returned to the User would be using the GET method. For each update, upload, and overwrite, we return a JSON response back to the user indicating that the operation has been executed successfully or an error has occurred with a detailed description of the problem.
We have implemented most of the error checking in lower-level classes such as the Util classes so that the controller class only needs to handle the different errors thrown by the lower-level classes. Then it can focus on the path, passing the parameters and body to the use cases and returning the response back to the user. The controller also does not need to call methods from Utils constantly to check whether the user’s input is valid and correctly formatted. This is an example of lowered coupling and better encapsulation.
In Util, we divided up the work of processing data and other works into independent classes. CSVFormatCheck will check all the CSVFormated input from the request before CSVManager processes it. DateUtil is responsible for all the data operations as well as validating the format of a date. DBManager only focuses on managing the files, receiving and returning data in the file back to CSVManager. QueryParser focuses on parsing the processed data by CSVManager into a format that is suitable to be returned to the user. Dividing the roles of an Util class into these subclasses is an instance of increased cohesion.
Overall, we follow the MVC design. The entity contains the most basic structure such as types of the objects we defined and the structure of the Request body and Conditions. The util is responsible for most of the work such as processing the data and storing them into files. The service class parses the user’s input into a usable format and calls the methods in utils, and parses the data processed by Utils. The controller passes all the user's inputs into lower-level classes and responds to the user according to the processed information passed from the lower-level classes such as whether the operation was successful and the queried data. Dividing the work into different levels of classes is an example of higher cohesion. ##Part 3: API documentations: **If you do not want to pass a parameter, please uncheck that key in postman, or leave it black. Here are some sample test cases in Postman. More thorough tests are done by codes in the GitHub repository.\

• PostMan import by link: https://www.getpostman.com/collections/7819c2066b775a1de9cd
• API Documentation by link (Swagger), Swagger code in API_Documentation.yaml: https://app.swaggerhub.com/apis/ZtjdavidGaredArc/CSC301A2CovidDatabase/1.0.0