REF: add skeleton for strategy pattern in describe
- [ ] xref #36833
- [ ] tests added / passed
- [ ] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [ ] whatsnew entry

Added a skeleton for the strategy pattern in ``pandas/core/describe.py``.
Currently the methods ``describe`` simply delegate to the corresponding ``describe_`` functions.
In the next steps I plan on moving the ``describe`` functions into each of the strategy classes.
Finally, these functions can be unified, since a lot there has a common pattern.
> * [ ]  xref #36833
> * [ ]  tests added / passed
> * [ ]  Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
> * [ ]  whatsnew entry
> 
> Added a skeleton for the strategy pattern in `pandas/core/describe.py`.
> Currently the methods `describe` simply delegate to the corresponding `describe_` functions.
> In the next steps I plan on moving the `describe` functions into each of the strategy classes.
> Finally, these functions can be unified, since a lot there has a common pattern.

can you not unify these w/o using this pattern? this looks like a lot of extra boilerplate > can you not unify these w/o using this pattern? this looks like a lot of extra boilerplate

It is possible, but I imagine may not be an improvement over the current state.

The idea was to make an abstract strategy with the method ``describe`` like this
```
def describe(self):
    return Series(
        self.array,
        index=self.names,
        name=self.data.name,
        dtype=self.dtype,
    )
```
and then only re-define ``self.array``, ``self.names`` and ``self.dtype`` in each of the concrete strategy classes.
This way it will probably be more readable and maintainable.
Please let me know what you think.

Currently the code is heading somewhat close to xref #36833.
If you consider that this is a wrong direction, then I am OK on closing this PR. yeah the code looks pretty good as is. i am not sure we need to greatly expand it. I am closing this as it was decided not to proceed with such type of refactoring.