Implementation of Aggregation within ...locations\__init__.py #383
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note this is for a school project and does not address any bugs, nor does it implement required feature.
Though it migh see like extensive additions were made, I simply introduced the class Locations in order to apply the use of aggregation domain design. This new class now encompassed the previous classes Location and TimelinedLocation. The extensive appearance is due to indetention added throughout the code in order to keep previous indetation format. This addition of aggregation creates a grouping, therefore if one wishes to access location related classes it can be done through the root class Locations. For example the TimelinedLocation class is being acces in app/services/locaiton/jhu.py. I therefore imported the newly added class, created an instance of such root class and used that instance to acces TimelinedLocation since, in aggregation, access is only done through the root. This can also promote encapsulation if seen fit.
The same was done for populations.py, an aggregation pattern was implemented.