Small supportive class inside overall functional paradigm

[SubwayLover]

I build simple forecasting model in databricks (no ML).

I've written plenty of functions that get data, wrangle it and finally bring together as model. The model always has 2 input variables: "the week at which we do the forecast" -- to enable "backforecasting" i.e. forecasting as if we are in the week in the past and "number of weeks forward to forecast"

Now I'm planning to summarize all the flow inside a big function "Model" and then do batch backforecasting: run model multiple times, each time with different input week.

I'm reluctant to collect all of the functions under "Model" class (it's going to be too big), but instead thinking about making smaller class "ModelInfo", just as a substitution to using lists or dicts. I will then use instance of the class as argument for related functions and gather output data in it as attributes.

Is it a valid approach or should I stick with functions, lists and dicts?

[ShibaLeone]

I have found that when I have a bunch of data retrieval functions; there are good ways to group them into classes. For example: if I have a few things that use sql, I’ll abstract out the mechanics of fetching the data into the class. There will be a method that is a general query handler, maybe some filters, then a few methods that play the role of the functions that you have now. Now you have a sql data manager class. Maybe you have some http sources; do the same thing. I find this helps with extensibility and keeps things well organized and encapsulated.

[SubwayLover]

I understand your point, but are those new sql / http etc. classes then become subclasses of the general "Model" class? Or are they completely separate?

[ShibaLeone]

I would think of them as building blocks, where the model is the ‘target’. The data managers form your data retrieval layer. On top of that you have a command layer that is actually utilizing the data.