You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Large parts of the source code is just awkward. There is a lot of code duplication and a general lack of structure.
The text was updated successfully, but these errors were encountered: