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.

2 Answers 2


Wouldn’t it make sense to have an interface (Java speaking) OrderedSet and the classes BinaryTree and RedBlackTree implement that interface?

If you are implementing a library and introduce the interface later, this will require a new major version. In this new major version, it could also be possible to rename the class OrderedSet to BinaryTree and introduce the interface OrderedSet to make library updates more convenient. It will only require users of the library to change constructor calls. This is good, because they have to decide at that point which implementation they prefer.


Addressing the question from a different perspective, I'd say that providing a domain-oriented abstraction may be the best answer. Rather than describing the properties (abstract or concrete) of the implementation, define an abstraction that is directly domain-relevant to its users, and limited to the specific capabilities they need. This means you provide only the exact capabilities they need, in raised up to domain terminology, rather than all the capabilities of either the OrderedSet or the BalancedOrderedSet, but instead something domain oriented, like submissions of some type (which we may implement with an ordered set).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.