I was working with tree-based regression systems. Most techniques– Bagging Tree regression, Random Forest regression, AdaBoost.R2 regression, Gradient Boost regression — use a collection of simple Decision Tree regressors. But AdaBoost.R2 and Gradient Boost can also use a collection of even simpler Extra (“extreme random”) Tree regressors.

The only difference between simple Decision Tree regressors and Extra Tree regressors is in a helper BestSplit() method that is used to build/train a tree regressor. Therefore, it might make sense to define a BaseTreeRegressor and then use object inheritance to define a derived DecsionTreeRegressor and a derived ExtraTreeRegressor.

Nope. Let me explain why I don’t use object inheritance unless I’m forced to by legacy code.

The idea that “code reuse via inheritance is automatically superior” was popular and virtually unquestioned in object-oriented programming (OOP) for decades from 1980 to 2010. But over the last 15 years, the software industry has finally gotten some common sense and shifted away from deep class hierarchies.

The trade-off between the two approaches — class inheritance vs. separate classes with some duplicated code –breaks down as follows:

1. The Real Cost of Inheritance

* When you introduce a base class, you trade code duplication for coupling (specifically, tight spatial and logical dependency).

* The Fragile Base Class Problem: Any tweak to BaseTreeRegressor (like changing how Node is represented, modifying state during Train(), or fixing a subtle bug in tree traversal) risks breaking both models simultaneously in unexpected ways.

* Indirection / Mental Overhead: To understand how DecisionTreeRegressor works, a reader can’t just read one file. They have to jump back and forth between the child class and the parent class to mentally piece together execution flow.

* Leaky Abstractions: The base class has to expose internal state (like trainX, trainY, and rnd) to its derived classes via protected or public modifiers, which breaks encapsulation.

2. The Case for Separate Classes Instead of Inheritance (“Copy-Paste-Modify”)

* While duplicate code (DRY — Don’t Repeat Yourself) is often treated like a mortal sin, the wrong abstraction is far more expensive than duplication.

* Self-Contained & Readable: Each class file is 100% self-contained. Anyone reading ExtraTreeRegressor.cs can start at line 1 and read straight down to the end to understand the complete algorithm.

* Independent Evolution: If you want to optimize ExtraTreeRegressor (e.g., by changing its data structures or adding parallel thread execution for splits), you can refactor it freely without worrying about breaking DecisionTreeRegressor.

* Zero Abstraction Tax: You don’t have to worry about virtual, override, or abstract method lookup costs, object slicing, or base constructor chaining.

I have been a professional software developer for decades. When I was new to the field in the 1980s, I didn’t like object inheritance but I didn’t say anything, because I figured I just must be wrong because “Inheritance is Good” was an unquestioned principle. But I finally learned that dogma of any kind, and drinking the associated intellectual Kool-Aid, is not the best way to live ones life.

I try to avoid being overly-influenced by others’ opinions. For movies, I generally ignore all reviews until after I see a particular movie.

I have a strange theory that the name “Hugo” has a weird vibe and if the boy had been named something like “Arthur” (a common boy’s name in both France and the U.S.) and the movie had been titled something like “Arthur and the Automaton”, it could have made an enormous positive difference in public perception. Sometimes a tiny difference in the words in a movie title can have a huge impact.