Start thinking OOP for ark-analysis

[alex-l-kong]

Currently, the approach we've been taking to ark-analysis (and toffy) has been very functional. This can lead to several inefficiencies in development (etc. repeated parameter passing, complex control flow handling, etc.). In line with industry-practices, we should start thinking about object-oriented approaches to ark-analysis.

Please contribute your ideas as to which projects in ark-analysis can be converted to an OOP approach.

[alex-l-kong]

A few examples on my end:

• Pixie pipeline (currently in Use a class-based/OOP approach for pixel and cell clustering process #576): pixel and cell clustering utils have a lot of shared data, and it's extremely inefficient to require several different file path parameters. These can all be organized into a class, from which objects can be created with all the information we need consolidated into one instance.
• Data loading: currently, all of these functions live in load_utils.py. It's cumbersome to keep track of the paths and various different settings used to load in the data. By implementing a class DataLoader, we can more easily consolidate all this information into one instance of the class.
• Testing: this was mentioned by @srivarra in Improvements to Testing #735, but the same OOP principles discussed here should also apply to tests.

[alex-l-kong]

Some more ideas:

• Visualization: the functions in visualize.py have a lot of derived functionality, sometimes from higher-level matplotlib/seaborn functions. It may be helpful for us to create base and derived classes for visualization so that we can easily define common features across certain visualization types while also allowing us to override them with specific features.
• Spatial analysis/neighborhood analysis/LDA: ideally each of these tasks should have one class serving as the hub for these functions. We can initialize an instance at the beginning of each notebook with the data needed, then use that instance to invoke class methods which drive the analyses.
• Extraction (signal and regionprops): currently we use a fairly messy dict and kwargs based method of indexing these. We can consider organizing these into signal and regionprops classes that allow us to more modularly set the type of extraction used, and therefore which function will be run. This will likely involve changing the cell table generation process to an OOP approach too.