I’ve read way too many blog posts about inheritance versus composition. All of them revolving around the is-a versus has-a relationship. If that subtlety has left you scratching your head, here’s a real life example.

One of my first problems to solve at LendingHome was how to programmatically create reports for our investors. These reports would be used by investors to track a loan’s payment history, view loan information, and project loan performance across their portfolio. In total, I had three reports to create. All of them needed to be in CSV file format because, you know … finance folks love their excel.

Sounds like I need three different type of report generators, right? Since these are types, inheritance was calling my name. I could have a parent class ReportBuilder containing the bulk of the CSV creation. Then 3 sub-classes determining the format of the report, like the columns and the data to display in the column.

Now, like I said, finance people love their excel spreadsheets. It’s not just the investors who are clamoring for reports. Our internal operations need CSV reports. Our third party sub-servicer communicate via CSV reports. Even our scoring engine spits out a CSV report. Lots of CSV reports, and if I wanted a true hierarchal report system, I would need intimate knowledge of each report to properly understand what functionality is common among all the types, and therefore what the sub-classes should be inheriting. Many CSV reports in the system with a high probability of new reports being added. It would, at best, lead to a shallow, wide hierarchal structure, but a real possibility of a deep, wide hierarchal structure (the worst kind).