This structure enables a project to create a local shipping.repository
module, and optionally subclass the class from
oscar.app.shipping.repository. When Oscar tries to load the
Repository class, it will load the one from your local project.

This way, most classes can be overridden with minimal duplication, as only
the to-be-changed classes have to be altered. They can optionally inherit from
Oscar’s implementation, which often amounts to little more than a few lines of
custom code for changes to core behaviour.

Seen on a bigger scale, this structures enables Oscar to ship with classes with
minimal assumptions about the domain, and make it easy to modify behaviour as
needed.

The get_class function looks through your INSTALLED_APPS for a matching
app and will attempt to load the custom class from the specified module. If the
app isn’t overridden or the custom module doesn’t define the class, it will
fall back to the default Oscar class.

For get_class to pick up the customised class, the Oscar apps need to be
forked. The process is detailed and illustrated with examples in
Customising Oscar. It is usually enough to call oscar_fork_app
and replace the app in INSTALLED_APPS.

Generally, there is no need for get_class in your own code as the location
of the module for the class is known. Some Oscar developers nonetheless
use get_class when importing classes from Oscar. This means that if someday
the class is overridden, it will not require code changes. Care should be taken
when doing this, as this is a tricky trade-off between maintainability and
added complexity.
Please note that we cannot recommend ever using get_model in your own code.
Especially pre-Django 1.7, model initialisation is a tricky process and it’s
easy to run into circular import issues.