title: Should a constructor parse input?
body: <p>Often, I find that I must instantiate a bunch of objects, but I find it easier to supply the parameters for this instantiation as a human-readable text file, which I manually compose and feed into the program as input.</p>
  
  <p>For instance, if the object is a <code>Car</code> then the file might be a bunch of rows, each containing the name, speed and color (the three mandatory constructor parameters) delimited with tabs:</p>
  
  <pre><code>My car          65       Red
  Arthur's car    132      Pink
  Old junk car    23       Rust brown
  </code></pre>
  
  <p>This is easy for me to inspect visually, modify or generate by another program. The program can then load the file, take each row, parse out the relevant parameters, feed them into a <code>Car(string name, int speed, uint color)</code> constructor and create the object.</p>
  
  <p>Notice how there is some work that must be done on the input before it is compatible with the constructor: The speed must be converted from <code>string</code> to <code>int</code> with a call to <code>int.Parse</code>. The color must be matched to a RGB value by looking up the English color name (perhaps the program would access Wikipedia to figure out each color's value, or consults a predefined map of name -> RGB somewhere).</p>
  
  <p>My question is, from an OOP standpoint, who should do this parsing? The constructor, or the method calling the constructor?</p>
  
  <p>With the first option, the advantage is simplicity. The calling function must only do:</p>
  
  <pre><code>foreach(var row in input_file)
       list_of_objects_that_i_am_populating.Add(new Car(row));
  </code></pre>
  
  <p>And all the ugly parsing can be nicely contained in the constructor, which doesn't have much other code anyhow, so the parsing code can be easily read and modified without being distracted by non-parsing code.</p>
  
  <p>The disadvantage is that code reuse goes out the window because now my object is joined at the hip to an input format (worse, because the input format is ad-hoc and manually composed, it is ephemeral and potentially not guaranteed to stay the same). If I reuse this object in another program, where I decide that it is convenient to slightly change the formatting of the input file, the two versions of the object definition are now divergent. I often find myself defining input formats in the comment section of the constructor, which seems a bit code-smelly.</p>
  
  <p>Another disadvantage is that I have lost the ability to do batch operations. Recall the earlier example problem of mapping color names to values: What if I was using a web service that takes 1 minute to process every individual request, regardless of whether that request is asking to convert one color name or a million. With a very large input file, I would drastically slow down my application by accessing the service once for each row, instead of submitting one big request for all rows, and then instantiating the objects according to the reply.</p>
  
  <p>What is the "correct" way to handle a situation like this? Should I parse input the constructor and treat the problems above as exceptional issues that must be dealt with on a case-by-case basis? Should I let my calling method do the parsing (even though it may already be bloated with much convoluted program logic)?</p>