Most Powerful Open Source ERP

Guideline Never Hardcode Interactions

Use interaction workflows instead.
  • Last Update:2017-04-05
  • Version:001
  • Language:en

Never Hardcode Interactions

Hardcoded interactions may require extensibility so use interaction workflows each time you have to implement something such as whenever X is called on A, invoke Y on B, even it may be a bit harder to debug at first.

Imagine that you want to call a method (eg. 'expand') each time an order or an order line is reindexed so that the simulation takes into account changes in that order. A simple (but wrong) approach consists in invoking expand from the overloaded reindex method defined on the Order or Order Line classes. The problem with this approach are multiple. First of all, there is no single point where this interaction pattern is explicitly defined. If there are a few interactions in the system, this is fine. But in an ERP system with many interactions, it leads to spaghetti code and no way to understand what happens.

Second, if one wants to extend the Order model and allow the user, let us say, to add a Resource instance inside certain orders, and at the same time a Rule which changes the invoicing based on parameters defined on that Resource instance, it is necessary to call 'expand' each time the Resource instance is modified. If we follow the simple approach, we must overload also the 'reindex' method of the Resource class (by creating for example a local Resource class with portal_classes). In the end, implementing interactions in a complex system may lead to overload most classes.

With interaction workflows, extending an interaction becomes much more simple. Adding an interaction definition for the Resource class each time the resource is part of an Order can provide a straightforward solution without having to overload any method.

Do not however overuse interaction workflows or create too many interaction workflows. It is better to have a couple of well defined interactions than dozens of small interactions. Also, if an interaction really does not need to be extended, it is acceptable to use interaction classes, decorators and/or method wrapper classes to achieve at the level of the python source code the same result as interaction workflows.

Good Example:

Bad Example: