Separate out API of LighteningModule into a few classes?
Is your feature request related to a problem? Please describe.
I think LighteningModule has identified a great set of APIs to separate research logic from training/evaluation infrastructure. This is an absolutely crucial first-step.
However, IMHO the current LighteningModule is too many things. It is at least:

A nn.Module with bells and whistles, such as GradInformation, ModelIO, etc.
An "algorithm" implementation, in terms of training/validation steps.
A statistics aggregator, because most likely you'd save metrics on self in validation_step and do something to it in validation_end.
A dataset provider, including possible data augmentation, etc.

I can appreciate the "this class has everything for this paper" sentiment, but IMHO, especially given the research work pattern of trying many things, it seems likely this class would grow quite large with lots of flags that toggle functionality as a research project grows.
Describe the solution you'd like
I think some of these functionality can be separated into a few separate classes, and still aggregated in a top-level Lightening class to give the "everything is here" feel.

A LighteningModule class that serves the same purpose as a nn.Module (forward pass, parameter management) with the current bells and whistles that are added.
A Algorithm class that implements the training/validation steps and aggregation.

Perhaps we can abstract some aggregation using the Metrics style in ignite.


A DataProvider class that returns DataLoaders for training/validation.
Finally, a Lightening class that gathers the above, and can still be provided to the trainer.

The separated classes provide better code reusability, eg:

Data augmentation you might want to do can be abstracted in the DataProvider classes. For example, one class that provides the vanilla CIFAR dataset, a mixin for some data augmentation, and any research projects that use CIFAR can reuse these implementations.
Swap out training algorithms without having to change the rest.
Some of the monitoring and metrics code can likely be reused more.

This is basically a refactoring suggestion. All of the above can be done currently by subclassing LighteningModule, or otherwise decomposing it, this is basically just a suggestion for the library to choose a best-practice.
Describe alternatives you've considered
Keeping the class in the library as-is, users can implement the methods in any way they wish, including my suggestions above with and use a mixin style to aggregate them into a LighteningModule subclass.
But IMHO the separation is better design.
Additional context
Happy to help with implementation if there's any interest in this, not just suggesting someone else make the change.