E1837 refactor review mapping controller: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 9: Line 9:
== New Helpers ==
== New Helpers ==
As part of refactoring, we have introduced several new Helper classes and methods.
As part of refactoring, we have introduced several new Helper classes and methods.
=== Report Formatter Helper ===
This helper now contains isolated methods for each report type that needs to be built from the controller. This helper is implemented as a module, so any/all instance variables are added to the class including it. This allows us to keep the controller logic very small but still populate all needed values for the report views.


=== Strategy Pattern for Automatic Review Mapping ===
=== Strategy Pattern for Automatic Review Mapping ===
Line 23: Line 28:


[[File:ReviewStrategyDiagram.png]]
[[File:ReviewStrategyDiagram.png]]


== Removed Methods ==
== Removed Methods ==
We were able to remove the following methods that were either obsolete or had functionality that could be refactored into other methods.
We were able to remove the following methods that were either obsolete or had functionality that could be refactored into other methods.
:- execute_peer_review_strategy: This functionality simply performed a check that is now in automatic_review_mapping
:- execute_peer_review_strategy: This functionality simply performed a check that is now in automatic_review_mapping

Revision as of 21:58, 28 October 2018

Media:Example.oggThis 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.

Report Formatter Helper

This helper now contains isolated methods for each report type that needs to be built from the controller. This helper is implemented as a module, so any/all instance variables are added to the class including it. This allows us to keep the controller logic very small but still populate all needed values for the report views.


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:

Removed Methods

We were able to remove the following methods that were either obsolete or had functionality that could be refactored into other methods.

- execute_peer_review_strategy: This functionality simply performed a check that is now in automatic_review_mapping