Object-oriented programming is a powerful way of modeling the world. Objects encapsulate data and behavior, and can interact and be composed in many useful ways.
As developers, one question we often consider is which types (in both technical and non-technical sense of the word) of objects to privilege by building them into our systems. Is an Address a proper object, or is it just a bit of data that can be encapsulated under a User? Are PowerUsers and NewUsers different enough to merit their own classes? (Probably not.)
But as our systems evolve, it can become difficult for existing object models to respond to new requirements. That’s apparently what is currently happening with tiger species. Because there are nine recognized tiger species, preservation efforts are spread across the six non-extinct species. A new proposal based on examination of DNA suggests that there should only be two tiger species.
As one researcher quoted in the piece says, “It’s really hard to distinguish between tigers…. The taxonomies are based on data from almost a hundred years ago.” Although your object model may not have legacy code that is quite that old, this case demonstrates the importance of reconsidering what traits and behaviors you allow to be first-class citizens in your system.
In the case of tigers, reducing the number of recognized species to two (one inhabiting continental Asia, and another the archipelago of Indonesia) would allow conservationists to try more flexible strategies. One example mentioned in the article is moving tigers within the same (redefined) species from one area to another (the updated definition of a continental Asian tiger would include the Amur tiger of Russia, the Bengal of India, and the South-China tiger). To a non-expert, it seems that interbreeding between these population groups would also help increase their numbers and perhaps increase genetic diversity.
Figuring out how to classify real-life entities can be very difficult. For tigers, what characteristics define a species? A century ago it might have been their physical appearance, while today we can look at the genetic level. In software, we have to think hard about the taxonomies we choose because they quickly become metaphors we live by.
The lesson for developers is that making your object model too fine-grained can introduce unexpected constraints when requirements change. To paraphrase Keynes, “When my information changes, I alter my code.”