E1837 refactor review mapping controller: Difference between revisions
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
== New Helpers == | == New Helpers == | ||
As part of refactoring, we have introduced several new Helper classes and methods. | |||
=== Strategy Pattern for Automatic Review Mapping === | |||
The previous implementation for the Automatic Review mapping method (automatic_review_mapping) was lengthy and overrode specific arguments within the Automatic Review Mapping Strategy method (automatic_review_mapping_strategy) before actually assigning reviews. We decided to implement an actual Strategy pattern here. | |||
We created a simple ReviewStrategy class with the following subclasses: | |||
:- StudentReviewStrategy | |||
:- TeamReviewStrategy | |||
Each of these strategies determines the number of reviews per team, the number of reviews per student, and the total number of reviews needed. After implementing this pattern, we were able to simply use the methods provided on the ReviewStrategy class in the algorithm that assigns reviews with minimal refactoring. | |||
Below is a simple UML diagram of these new classes: | |||
[[File:ReviewStrategyDiagram.png]] | |||
== | == Removed Methods == | ||
Revision as of 21:41, 28 October 2018
This work was to refactor the review_mapping_controller.rb file to be more maintainable and to separate concerns for higher-cohesion and lower coupling.
Goals
- - remove unused controller methods
- - remove SQL statements from the controller into models/helpers where applicable
New Helpers
As part of refactoring, we have introduced several new Helper classes and methods.
Strategy Pattern for Automatic Review Mapping
The previous implementation for the Automatic Review mapping method (automatic_review_mapping) was lengthy and overrode specific arguments within the Automatic Review Mapping Strategy method (automatic_review_mapping_strategy) before actually assigning reviews. We decided to implement an actual Strategy pattern here.
We created a simple ReviewStrategy class with the following subclasses:
- - StudentReviewStrategy
- - TeamReviewStrategy
Each of these strategies determines the number of reviews per team, the number of reviews per student, and the total number of reviews needed. After implementing this pattern, we were able to simply use the methods provided on the ReviewStrategy class in the algorithm that assigns reviews with minimal refactoring.
Below is a simple UML diagram of these new classes:
