Say that I create an ordered set structure, and I choose to implement it as a binary tree. I name my structure OrderedSet
because I feel its underlying implementation isn’t necessarily important to the user, and I go on my way. Later, I come back to my code and decide that implementing it as a red-black tree may have been better. However, there are some users that would for some particular reason prefer that the set remain implemented as a plain binary tree. This would leave me with a few options such as reimplementing the original structure anyway or just creating a new structure named something like BalancedOrderedSet
. However, this entire problem could have been avoided if I had originally given my structures more literal names like BinaryTree
and RedBlackTree
, although their primary use would no longer be as obvious (especially to less experienced programmers).
I realize that there are many libraries (especially standard libraries) that tend to name their classes and structures based on their general purpose rather than their underlying implementation. I wanted to discuss/ask about the pros and cons of each side of this spectrum of abstract/literal naming and when and where it would be best to lean one way or the other, specifically in generic library codebases where the future use of the structures is unknown and very wide-spread.