title: Dependency Injection for Procedural Programming
body: <p>Suppose I've decided to write a large application in C, or any other procedural programming language.  It has functions with call-dependencies that look like this:</p>
  
  <pre><code>A
  |
  +-------------+
  |             |
  B1            B2
  |             |
  +------+      +------+
  |      |      |      |
  C11    C12    C21    C22
  </code></pre>
  
  <p>Obviously, unit-testing the leaves functions, C11, C12, C21, and C22 is very easy: Setup the inputs, invoke the functions, assert the outputs.</p>
  
  <p>But what is the proper strategy to enable good unit-testing for B1, B2 and A?</p>
  
  <p>Would <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="noreferrer">Dependency Injection</a> suggest that <code>B1</code> (and <code>B2</code> also) be declared as followed?</p>
  
  <pre><code>// Declare B1 with dependency injection for invoking C11 and C12.
  int B1(int input, int (*c11)(int), int(*c12)(int));
  </code></pre>
  
  <p>But that strategy does not seem scalable if I have many layers of calls.  Just imagine what the declaration for <code>A</code> would look like:</p>
  
  <pre><code>int A(int input, int (*b1)(int, int (*)(int), int(*)(int)), 
                   int(*b2)(int, int (*)(int), int(*)(int)),
                   int (*c11)(int),
                   int (*c12)(int),
                   int (*c21)(int),
                   int (*c22)(int));
  </code></pre>
  
  <p>Yuck!  There has to be a better way.</p>
  
  <p>Sometimes, I feel that DI and other similar patterns that purport to promote modularity and ease of maintenance actually hampers code clarity and complicates what should be straightforward coding into nonsense abstractions and convoluted indirections.</p>
  
  <p>How do large software projects in C, like Perl and Ruby, deals with unit-testing?</p>