title: Need advice for refactoring a large class
body: <p>Our C# application produces reports of various types. Each type of report has an xml schema defining the options and features that are available, so a user can create an xml document describing the report they want. There are elements that are common to multiple report types, and there are interdependencies among some elements.</p>
  
  <p>We currently have a single class full of static methods to handle the parsing of the xml. It will take a schema-validated document, and return an object representing the type of report and its configured options. The class looks something like this:</p>
  
  <pre><code>public class ReportFactory
  {
      //let's say 4 types of reports
      public static ReportType1 CreateReportType1(XDocument document)
      {
          //logic to create this type of report, calling private methods in this class
      }
      ....
  
      public static ReportTypeN CreateReportTypeN(XDocument document)
      {
          //logic to create this type of report
      }
  
  
      //several dozen private methods, which get called from the public methods or from each other
      private static Feature1 CreateFeature1(XElement element)
      {
          //create some feature of a report 
      }
  
      private static FeatureN CreateFeatureN(XElement element, FeatureM m)
      {
          //create some feature which relies on another previously built feature
      }
  
      private static FeatureX CreateFeatureX(ReportType2 report, XElement elementForX, XElement elementRelatedToX)
      {
          //create some feature, which relies on 
          //more than one element and/or a partially built report of a given type
      }
  
      private static void UpdateFeatureNWithStuffFromFeatureM(FeatureN n, FeatureM m)
      {
          //modify parts of the built report, based on some other parts of the report 
      }
      ...
  }
  </code></pre>
  
  <p>I believe the intention was to encapsulate the details of the xml structure, which I suppose it does.  It also doesn't suffer much from duplicated code.  But it is very large and hard to read, and it gets worse as we add more features.  It's also difficult to test, since it relies heavily on things being done in the correct order.</p>
  
  <p>I'd like to refactor it, but so far the only thing I can think of is to just split it up into multiple classes; say, a class for each report type and an additional helper class for common stuff.  But it will still be messy and possibly even harder to read.  Is there a good way to organize something like this? Any patterns that might help?  I've looked at a bunch of creation patterns and haven't really found anything that seems to fit.   </p>
  
  <p>UPDATE: Sorry I have not had time or budget to actually work on this piece of refactoring, but thanks for the suggestions.  The more I think about it, the more I like (something like) the Chain of Responsibility idea.  The starting point (public function) will create the return object and fill in some basic stuff, then hand off the object and the xml to the next piece.  Each piece will know which parts of the object and the xml it needs, and each piece can be tested independently by looking at the changes to the object.</p>