title: How to split code into components... big classes? small classes?
body: <p>This is <strong>very basic stuff</strong>, but here goes. I find that I am never able to agree with myself whether the way I <strong>split large classes into smaller ones</strong> make things more maintainable or less maintainable. I am familiar with <strong>design patterns</strong>, though not in detail, and also with the concepts of <strong>object oriented design</strong>. All the fancy rules and guidelines aside, I am looking to pick your brains with regards to what I am missing with a very simple, sample scenario. Essentially along the lines of: "...this design will make it more difficult to", etc... All the things I don't anticipate because of lack of experience essentially.</p>
  
  <p>Say you need to write a basic "file reader / file writer" style class to process a certain type of file. Let's call the file a <strong>YadaKungFoo file</strong>. The contents of YadaKungFoo files is essentially similar to INI Files, but with subtle differences. </p>
  
  <p>There are sections and values:</p>
  
  <pre><code>[Sections]
  Kung,Foo
  Panda, Kongo
  
  [AnotherSection]
  Yada,Yada,Yada
  Subtle,Difference,Here,Yes
  
  [Dependencies]
  PreProcess,SomeStuffToPreDo
  PreProcess,MoreStuff
  PostProcess,AfterEight
  PostProcess,TheEndIsNear
  PostProcess,TheEnd
  </code></pre>
  
  <p>OK, so this can yield 3 basic classes:</p>
  
  <pre><code>public class YadaKungFooFile
  public class YadaKungFooFileSection
  public class YadaKungFooFileSectionValue
  </code></pre>
  
  <p>The two latter classes are essentially only data structures with a ToString() override to spit out a string list of values stored using a couple of Generic lists. This is sufficient to implement the YadaKungFooFile save functionality.</p>
  
  <p>So over time the YadaYadaFile starts growing. Several overloads to save in different formats, including XML etc, and the file starts pushing towards 800 lines or so. <strong>Now the real question</strong>: We want to add a feature to validate the contents of a YadaKungFoo file. The first thing that comes to mind is obviously to add:</p>
  
  <pre><code>var yada = new YadaKungFooFile("C:\Path");
  var res = yada .Validate()
  </code></pre>
  
  <p>And we're done (we can even call that method from the constructor). Trouble is the validation is quite complicated, and makes the class very large, so we decide to create a new class like this:</p>
  
  <pre><code>var yada = new YadaKungFooFile("C:\Path"); 
  var validator = new YadaKungFooFileValidator(yada); 
  var result = validator.Validate();
  </code></pre>
  
  <p>Now this sample is obviously <strong>terribly simple, trivial and insignificant</strong>. Either of the two ways above probably won't make too much difference, but what I don't like is:</p>
  
  <ol>
  <li>The <strong>YadaKungFooFileValidator</strong> class and the <strong>YadaKungFooFile</strong> class seem to be very strongly coupled by this design. It seems a change in one class, would likely trigger changes in the other.</li>
  <li>I am aware that phrases such as "Validator", "Controller", "Manager" etc... indicates a class that is concerned with the state of other objects as opposed to its "own business", and hence violates separation of concern principles and message sending.</li>
  </ol>
  
  <p>All in all I guess I feel that I don't have the experience to understand all the aspects of why a design is bad, in what situations it doesn't really matter and what concern carries more weight: smaller classes or more cohesive classes. They seem to be contradictive requirements, but perhaps I am wrong. Maybe the validator class should be a composite object?</p>
  
  <p>Essentially I am asking for comments on likely benefits / problems that could result from the above design. What could be done differently? (base FileValidator class, FileValidator Interface, etc.. u name it). Think of the YadaKungFooFile functionality as ever growing over time.</p>