Should we split up the large classes?

[wkearn]

Problem

GridObject has surpassed 1000 lines of code, triggering a pylint warning. I am not so worried about the number of lines, but the file is getting somewhat hard to work with. We have not been focused on adding functionality for FlowObject and StreamObject, but they will also grow in the future.

Context

Our architecture generally follows the MATLAB TopoToolbox v2 architecture, which has a few classes each with lots of methods. MATLAB supports this style by allowing methods to be defined in separate files. We don't use very many object-oriented features like inheritance or sophisticated abstraction techniques -- each class is largely a bag of functions that operate on that class. One feature that is particularly useful, however, is operator overloading, which lets us apply built-in operators like +, -, < to GRIDobjs.

Originally, pytopotoolbox used mixins, parent classes of GridObject with methods but without any data. We had a FillsinksMixin, and IdentifyflatsMixin, and some others, which implemented the respective functions, and then had GridObject inherit from those classes, which gave it access to the implementation. We switched from that to the current architecture in #39, based on @Teschl's findings (#34) that mixins complicated the documentation and that having large classes is not uncommon in Python packages.

Possible options

1. Keep what we have, work on organizing GridObject.py better so that it makes more sense.
2. Return to the mixin strategy.
3. Define functions like fillsinks as standalone functions that take GridObjects (see graphflood.py for an example).
4. Create an interface (an abstract base class?) for GridLike objects that includes methods like data() to return an array with the data values and cellsize() to return the horizontal resolution. Implement processing functions as standalone functions using this interface, subclass GridObject from GridLike and define data and cellsize appropriately.

What other options might help us keep our classes manageable?

[wkearn]

I am somewhat partial to option 4 for GridObject. Among other things it would allow us to interface more easily with many different sources of gridded data, like rasterio or xarray or something like Landlab's field system. One would still need to implement an adapter from each data source, but this turns out not to be so different from converting your xarray data into a GridObject.

The FlowObject and StreamObject are somewhat different because they contain data that we create, and we need them to be in a particular format to apply. We can take a similar approach, however, by keeping FlowObject and StreamObject methods focused on access and manipulating the internal data sources, and using external functions for everything else, such as FlowObject.flow_accumulation or StreamObject.chitransform.