title: Given a function with several logical steps, each step requiring reference to N shared objects, how can this function be optimally deconstructed?
body: <p>When using the coding practice of decomposing functions into smaller functions which each do "one logical thing", it appears as though the approach sometimes leads to code which is hard to debug. </p>
  
  <p>As an example, imagine I have the following code:</p>
  
  <pre><code>Function Foo(Class1* p1, Class2* p2, Class3* p3)
  {
     Function InitializeStuff(Class1* p1, Class2* p2, Class3* p3)
     Function DoFirstBlockOfWork(Class1* p1, Class2* p2, Class3* p3)
     Function DoSecondBlockOfWork(Class1* p1, Class2* p2, Class3* p3)
     Function FinishStuff(Class1* p1, Class2* p2, Class3* p3)
  
  }
  </code></pre>
  
  <p>In this example, there are 3 object references needed in each logical block.  Now, when the debugger stops inside one of these blocks, it is difficult to know where the inputs came from within the code file (especially if not familiar with the codebase).</p>
  
  <p>In this case, there is the added benefit of understanding when reading top-down, but when debugging bottom-up, it seems this method is actually more cumbersome than placing all the functionality in Foo.  </p>
  
  <p>So, in the case of a function with highly coupled logical blocks, what is the argument for splitting the functionality into smaller functions?  </p>
  
  <p>(Note:  I have been living with the assumption that it's <em>always</em> best to deconstruct functions to the smallest logical block.)</p>