Background
I made this change to apply the aggerate pattern in the open-source project we chose in the lab. And the goal of this lab is to find the place that can apply aggeration. Therefore we are asked to make 2 pull request
Abstract
The code in people.py contained several functions such as check_inds, check_infectious, check_symptomatic, schedule_quarantine, etc. However, the functions were can be hard to understand if they are not grouped together. This creates obscurity in the code and makes it hard to read. Hence, I created two new classes healthState and actionRequired to aggregate their respective operations.
Explanation
The people module contained several functions that operate on certain data types, which were not aggregated together. For example, all the check_* functions are used to check the state of the people objects. These functions help construct data on states, so we can aggregate them into a healthState class to make the code easier to read and understand.
Applying Aggregate Design Pattern to people.py
Background I made this change to apply the aggerate pattern in the open-source project we chose in the lab. And the goal of this lab is to find the place that can apply aggeration. Therefore we are asked to make 2 pull request
Abstract The code in people.py contained several functions such as check_inds, check_infectious, check_symptomatic, schedule_quarantine, etc. However, the functions were can be hard to understand if they are not grouped together. This creates obscurity in the code and makes it hard to read. Hence, I created two new classes healthState and actionRequired to aggregate their respective operations.
Explanation The people module contained several functions that operate on certain data types, which were not aggregated together. For example, all the check_* functions are used to check the state of the people objects. These functions help construct data on states, so we can aggregate them into a healthState class to make the code easier to read and understand.