I have been using Programming Ruby as a reference for a Ruby on Rails course I provide. Yesterday I was preparing a lab class around the BookInStock example. Before introducing the definition of the CsvReader class, Dave Thomas states that whilst in OO design the classes normally map onto external entities, there is “another source of classes in your designs. These are the classes that correspond to the things inside your code itself.” He then introduces CsvReader. However, I would assert that this does indeed map onto an external entity. Although I have retained the same name in the above in order to make it very clear that I have reused his example, I personally believe that this class is in fact a representation of the BookShop. It has an internal instance variable that maintains a catalogue of the books in stock, and two attributes that capture important aspects of the external state of a shop: the total value of books in stock, and the numbers of copies of books for each isbn in stock. It does not represent anything about a Csv reader – the read_in_csv method is merely a utility method for initialising the state of a BookShop using a set of csv files. This issue will become clearer when we move to Rails where we can dispense with the csv files and build a model that persists in a database. Then we will see that a “BookShop has many BooksInStock” and we can maintain a clean representation of the internal and external views of the state of a BookShop without needing the read_in_csv method; Rails’ Active Record will populate the models with data in the background.