Skip to Content

A typical scenario: Software component A, providing some function a may depend on some other software component B of which it comsumes function b. Business as usual

Now, what happens, if there are circular functional dependencies, i.e. component A calls a function of component B, which calls within the same context some function A back again?

I will give a simple example which shows that such a design can lead to some sort of symbiosis in a sense that neither of both components may be changed in isolation any more, but both have to be changed together.

The example is the mathematical faculty function, which is defined by the two mathematical expressions:

faculty(0) = 1 and faculty(n) = n*faculty(n-1)

for arbitrary natural number n.

It is calculated by each of the following two computational functions fac1 and fac2, which are assumed to belong to different components but are designed to depend on each other. With a C-style syntax they are described as:

int fac1(int i){
if (i<=1) return 1; else return i*fac2(i-1);
int fac2(int i){
if (i<=1) return 1; else return i*fac1(i-1);

First we see that both functions do indeed calculate correctly the faculty function up to a maximal value, which is due to the maximum value of the int data type.

Now, let us assume that we want to extend the domain of our faculty calculation and therefore change the data type of i in function fac1 to ‘long’. Because of its dependence on fac2, this would have no effect on its effective domain. A very ordinary effect that a system depends in its functionality on the functionality of some subsystem and as long as the subsystem is not enhanced, the system itself cannot be enhanced. However, the situation is identical, if we only change the data type of i in the other function fac2 to ‘long’.

Obviously, we cannot enhance the functionality of either component without changing the other component as well. Thus, the circular functional dependency becomes relevant for compatibility and version management, especially if the components are intended to be deployed separately.

It might be that the symbiotic character of software component relations due to circular functional dependencies are the main reason, why distributed object orientated approaches modelling peer-to-peer relations seem to encounter enormous practical difficulties.


Circular functional dependencies should be avoided between components, which are intended to be deployed separately.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. David Halitsky
    the Zeno of SDN.  Or maybe the Bertrand Russell, since he solved at least one of Zeno’s paradoxes (if I am recalling correctly).

    A very nice use of a simple mathematical example to illustrate a comples point.  Of couse, most people will accuse you of making the same mistake that mathematicians make when they announce their analysis of a difficult problem by saying:  “Consider a perfectly spherical cow …”.  (That’s an old joke, not mine originally.)

    Anyway, don’t listen to them.

    Nothing is worse than false formalities, as the US structural linguists found out when Chomsky published Syntactic Structures in 1956.

    1. Johannes Reich Post author
      Hi David,
      you seem to like my writings – thanks. As to my knowledge, most (or all?) Zeno’s paradoxes are solved by the continuums hypothesis, i.e. by assuming that a sum of some infinite number of things can be something finite.
      Russell instead reduced naive set theory ad absurdum by providing an example for a property, for which no set could exists, namely to not contain itself. However, the solution to this mathematical earthquake was due to a large number of mathematicians and not just him.

      Providing a function means providing a directed form of cooperation. It is therefore not a big surprise – and by the way a well known phenomenon – that circular functional dependency leads to quite a tight coupling between components and thus should be avoided.
      E.g. JDepend ( explicitely checks for dependency cycles of packages.
      I just found the simplicity of the example worth mentioning it. That might be where at least some parallel to Russel can be seen. A single counter example can provide evidence for a false theory. This example, simple as it is, definitively shows that circular functional dependencies lead to compatibility issues.

      In addition to it, I completely agree, that there are few worse things than false formalities, but not only in informatics as Sumantra Ghoshal (2005)shows convincingly in his article “Bad Management Theories Are Destroying Good Management Practices”,

      Kind regards, Johannes

      1. David Halitsky
        Hi Johannes – thanks for taking the time to reply.

        Yes – I like your posts very much.  That’s why I nominated you for an SDN “Maverick” award here:

        Re: Best Of 2006 …

        Please keep on posting the kind of posts you post.  They are about the “ding” of IT and not the “bling”. 

        I refer here Kant’s “ding an sich”, a little inaccurately.

        I say inaccurately because Kant would asser that we cannot know the “noumenon” of the machine unless we are the ones who wrote its micro-code.

        But we can at least know a lot more than those who are satisified to point, click and generate something that badly approximates real code.

        And that’s why I like to contrast “ding” and “bling” when talking about IT, even though I am using “ding” in a technically inaccurate way.


Leave a Reply