Defining models: Inheritance, composition, or duck-typing?

[cmutel]

Warning: This text has not been proofed by an actual programmer 😛

When someone new comes to the platform and wants to define a model, they will need all the help they can just to get something running. Even for experienced developers, having example code or libraries to build on can help make things work on the first try. So there are good arguments for have a very prescriptive model framework, where any model on the platform has to inherit from a base class, and the base class defines the methods and inputs arguments needed to implement all the necessary model functionality.

In addition to being fed input data and generating a result, we expect models to be able to:

• Run validation checks against input data, and log metrics and outliers
• Run data quality checks against input data
• Call for gap-filling models if sufficient primary input data is not present
• Create diagrams of their internal logic and data flow
• Conduct sensitivity analysis and produce reports in a defined format
• Run unit tests and participate in integration tests

There are significant downsides to requiring very detailed base classes, however. One big problem is that smart computer use the phrase "composition over inheritance" a lot. If you are one of those people, please comment below on what this would specifically mean in the context of our inventory models (and why it matters!). Base classes can be quite rigid, and lock users into patterns or libraries which aren't always the most convenient. Finally, base classes and inheritance are the core of object-oriented programming, but there are some good reasons to think a more functional paradigm without state might be better for the calculations we want to do, especially at scale.