Three questions about the IOSP

An interview with Stefan Lieser about the Integration Operation Segregation Principle (IOSP) and its application

Flow Design is considered a very useful design methodology because it improves team communication and promotes a shared understanding of the problem. By graphically representing the data flow, it enables an early, language-independent modelling of the solution. The Integration Operation Segregation Principle (IOSP) supports the creation of easily testable methods, while the structured decomposition of requirements and parallel processing in the team increase efficiency.

Stefan Lieser is an expert in Clean Code and Flow Design and co-founded the Clean Code Developer Initiative at the end of 2008. He works as a trainer and consultant on the topics of Clean Code Developer, design with Flow Design and software architecture. In his book ‘Mit Flow Design zu Clean Code’ [1], the managing director of CCD Akademie GmbH describes a software development process that prioritises the systematic decomposition of requirements and design. This makes him the right person to answer the following three questions:

What is the IOSP?

Stefan Lieser: The abbreviation stands for Integration Operation Segregation Principle. The principle states that the two aspects of integration and operation are to be separated.

We use the term operation to describe methods and functions that contain logic. This is therefore code that is rich in detail. The following are allowed in an operation:

• expressions such as x + 42 (arithmetic) or also y == 7 (Boolean),
• calls to external methods and functions, i.e. those from the runtime and from frameworks or libraries.

What is important here is the distinction between our own and external methods. External methods are those that we only call but for whose source code we are not responsible. These are methods from frameworks and runtime that we integrate into our software project. We don’t need to understand the method in detail and it usually has nothing to do with our domain.

However, we have to take responsibility for our own methods. And unfortunately, they are often not so easy to understand at the point of call, so we are often forced to look at the source code. So, own methods are at a higher level of abstraction.

An operation should also comply with the Single Responsibility Principle (SRP). This ensures that a good name can be found for the method. It also ensures that the methods are short and easy to understand.

In an integration, logic is combined into a larger whole. Therefore, only own methods may be called in an integration. These can be other integrations or operations. Only the calling of foreign methods and expressions is prohibited in integrations, since this is reserved for operations.

There are different opinions on whether control structures such as if, while, for, foreach and switch are allowed in an integration. On the one hand, control structures can overload the code with details. On the other hand, a dogmatic ban can make the code difficult to understand.

Of course, an if-statement must not contain an expression (e.g. if(x == 42)) in the integration. This would then not be testable in isolation. It is therefore better to move the expression to a function (e.g. if(IsMagic(x)). This improves readability, since the expression no longer needs to be interpreted. The name of the function should convey the meaning. Furthermore, the expression can be tested in isolation by moving it to a separate function. This is a great advantage, especially with complicated expressions.

As a rule, loops do not cause problems if they iterate canonically over all elements of an enumeration. Here, too, a loop should not contain any expressions, except for the for loop over all elements: for(i = 0; i < n; i++) { … }

As with all principles, the IOSP should not be applied dogmatically. The most important step is always the unequivocal recognition of a possible violation of the principle. It is then important to consider whether the values of correctness or changeability are endangered by the violation of the principle. When in doubt, adhering to the principle is safer.

Why should you follow the IOSP?

Stefan Lieser: Since operations do not call their own methods, they are independent of other parts of the code base. They are therefore leaves in the dependency graph. This makes it easier to test them automatically. No mockups are needed because the operations are already free of dependencies. Since an operation does not call any other methods of its own, it is at a low level of abstraction. To be more precise: it is exclusively at a low level of abstraction. It’s all about details. This fulfils the principle of the Single Level of Abstraction (SLA), which states that a method should only be at one level of abstraction. This makes an operation easier to understand. It is also easier to keep the operations short because they are not allowed to call other methods of their own.

The same applies to integrations. They also fulfil the SLA because they are only at a high level of abstraction. An integration only calls other of its own methods. It contains no details. This also makes them easy to understand.

The extraction of the integration code summarises the process that is necessary to solve a problem. At a high level of abstraction, it is possible to see how the problem is approached. When integration and operation are mixed, this abstract summary is not available in one place. Instead, all the details have to be read to distil the process.

Adherence to the IOSP provides optimal support for the test pyramid. This states that the number of tests should increase from system tests to integration tests to unit tests. So there should be few system tests, a little more integration tests and many unit tests.

If you divide your code according to the IOSP, you get a dependency tree that optimally supports testing. System tests are always possible, more or less independently of the internal structure. For the integration tests, it is helpful that the integration methods themselves do not contain any logic of their own. Therefore, a few integration tests are sufficient, since these only have to ensure that all paths through the integration methods are executed at least once.

The operations are units in the sense of the definition of unit tests. They are not dependent on other custom methods. This makes writing unit tests easy, since mock objects rarely need to be used. In principle, the IOSP does not contradict the Dependency Inversion Principle (DIP), so mock objects can also be used in tests by means of dependency injection.

However, if you rely solely on DIP, you will need to work with mock objects in the test in many places. These tests are less readable, often fragile and use internal implementation details.

And who invented it?

Stefan Lieser: Not the Swiss and also not the Americans. In fact, Ralf Westphal and I invented the IOSP.

In the 2010s, we asked ourselves how software development could be radically simplified. In addition to Flow Design as a design methodology, the IOSP was also developed. We found that when the Dependency Inversion Principle (DIP) is applied, two other principles are violated:

• the Single Responsibility Principle (SRP) and
• the single level of abstraction (SLA) mentioned earlier.

Methods that comply with DIP are responsible for two responsibilities: they contain the detailed logic for their actual responsibility (operational responsibility). In addition, they integrate calls of other methods, even if this is done indirectly via an interface (integration responsibility).

The SLA is violated if the DIP is adhered to, because the method contains the detail logic on the one hand, but on the other hand it also contains high-level calls of other of its own methods.

Notes:

Would you like to discuss flow design and the integration operation segregation principle with Stefan Lieser? Do you have any questions or comments? For more information, see https://ccd-akademie.de/.

[1] Mit Flow Design zu Clean Code

Here you will find information on the topic Flow Design.

If you like the article or want to discuss it, please share it in your network.

There are more articles in the t2informatik Blog series ‘Three Questions…’: