Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code review and refactoring #109

Open
RKrahl opened this issue Mar 4, 2020 · 1 comment
Open

Code review and refactoring #109

RKrahl opened this issue Mar 4, 2020 · 1 comment
Labels
internal Refactoring or changes that are supposed not to change the behavior
Milestone

Comments

@RKrahl
Copy link
Member

RKrahl commented Mar 4, 2020

Large parts of the source code is just awkward. There is a lot of code duplication and a general lack of structure.

@RKrahl RKrahl added the internal Refactoring or changes that are supposed not to change the behavior label Mar 4, 2020
@RKrahl RKrahl added this to the 2.0.0 milestone Mar 4, 2020
@RKrahl
Copy link
Member Author

RKrahl commented Jan 6, 2021

Some notes on the direction that the refactoring should take and how a better structured code would look like:

  • The general aim should be to move towards a more object oriented design and to avoid code duplication as much as possible.
  • Add an abstract class DataObject to represent all data objects and collections of objects that ids.server needs to deal with. Datafile, Dataset, and DataSelection should be derived classes from DataObject. Obviously that means a DataObject may be a composition of smaller objects that are in turn DataObject instances.
  • Most of the program logic dealing with the data should be implemented at the abstract DataObject level. In particular, it should provide the methods to check the status (ONLINE, ARCHIVED, RESTORING, ERROR). ERROR would be a new status here and corresponds to the failures set in FiniteStateMachine.
  • Class DataSelection should support serialization into and creation out of a preparedId. That would allow the unification of the methods implementing the API calls accepting either investigationIds, datasetIds, and datafileIds or a preparedId as parameter.
  • Implement strict checking and consistent handling of errors, ref. Review error handling #79.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal Refactoring or changes that are supposed not to change the behavior
Projects
None yet
Development

No branches or pull requests

1 participant