CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 14: Line 14:


===  Refactoring ===
===  Refactoring ===
Have a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist.  The waitlist would just enqueue ordered pairs〈team_id, topic_id〉
Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:
# Add themselves to waitlists
# Add another team to a waitlist
# Take a team off a waitlist
# Purge all waitlists of a specific team
# Clear a specific waitlist of all waiting teams


Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist.  The waitlist would just enqueue ordered pairs〈team_id, topic_id〉
=== Design Pattern ===
=== Design Pattern ===
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.  
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.  

Revision as of 22:13, 3 November 2021

Problem Statement

When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉



Control Flow

Solution Approach

Refactoring

Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:

  1. Add themselves to waitlists
  2. Add another team to a waitlist
  3. Take a team off a waitlist
  4. Purge all waitlists of a specific team
  5. Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

Design Pattern

Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.

Tentative list of files to be modified

  1. sign_up_topic.rb
  2. invitation.rb
  3. waitlist.rb
  4. suggestion_controller.rb
  5. signed_up_team.rb
  6. student_teams_controller.rb


Test Plan

This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

Test Files


References

  1. Problem Statement
  2. Forked Repository


Team

  • Ankit Singh (asingh072318)
  • Asrita Kuchibhotla (kAsrita)
  • Neha Kotcherlakota (nehajaideep)
  • Vinit Desai (VinitDesai1998)