C++, How to maintain both data locality and well splitted code structure at every layer of a program?
<p>In my recent project I have a class like this:</p>

<pre><code>class layer1 {
myclassa l1dataa; // layer1 data
...
myclassn l1datan;

public:
void l1datatransformsa()
{
  myotherclassa l2dataa; // layer2 data
  ...
  myotherclassn l2datan;

  many operations; // way too many operations for a single method
}

void l1datatransformsb() {}
};
</code></pre>

<p>The method l1datatransformsa invokes local data and is quite long and robust. I would like to divide its code into smaller meaningful portions (methods) which all work on the same local layer2 data. It can be done in few ways, though none of them seems good enough to me, therefore I'm asking for recommendation on how should it be done:</p>

<ul>
<li>Breaking the code of "many operations" into private methods of class layer1.</li>
</ul>

<p>Cons: I would have to pass as arguments to those new methods references to all layer2 data, which is not very elegant as there is too many of them</p>

<ul>
<li>Rewriting the method l1datatransformsa as a nested class of class layer1 with layer2 data declared as its data members. Then it would be possible to split "many operations" into members of the nested class.</li>
</ul>

<p>Cons: To access layer1 data from nested class I would have to use reference or pointer to the instance of enclosing class. This will make me include many changes in the code of "many operations" and will make the code less clear. It would be even worse if one would think of a need of splitting in the same manner one of methods of nested class.</p>

<p><strong>The basic idea behind all this is to have a comfortable way of keeping your local data close to the functions or methods which use it and only to them at every layer of your program.</strong></p>

<p>ADDED: "many operations" which we we want to split work both on almost all data members of class layer1 and all local data layer2. They work on layer2 data sequentially and that's why they can be splitted easily, though it's a bit awkward 'programistically'.</p>
