Is it bad to use the same class or idiom names as in a third-party API that you're using?

Question

FlashPunk is a third-party graphics API for simple game development in AS3, and they take what are effectively sprites or display objects of some sort and refer to them as "Entities". Entity is the actual class name, and it's the predominant class to use to animate something such as a character moving on the screen.

There's a bit of a convention right now in which you refer to things like barriers, enemies, characters, etc. as "entities". So that being said, if you're using FlashPunk for your graphics, is it bad to create a base class to represent such things and name it Entity as well? (In particular, does this violate a widely-held coding convention?)

Obviously it would be in a different package, and most people would probably separate the graphics from the game's actual state, so there's not a lot of overlap there. It's just using the same title.

What about scenarios like this in general with programming? Is there a particular convention?

Answer 1

The primary problem I see with this is that talking about your code you're going to get a lot of "which Entity do you mean?" questions.

Most modern computer languages (and many older ones) provide name scoping to avoid this problem, but English is older than any of them and all it has is weak context hinting. Which means that if you go down this path you're going to add a lot of qualifiers to your discussions to disambiguate the ambiguity you've added.

Much better would be to call your "root descendant" or wrapper class something else. Sprite is possibly a good name.

Answer 2

This problem was essentially solved decades ago.

If your language allows it, simply keep the third party API and your own code in separate namespaces (Packages in Ada, namespaces in C++, modules in Modula-2 etc).

Where it isn't obvious which Entity you are using, refer to all Entities using qualified names, e.g. FlashPunk.Entity or MyApp.Entity (Ada), or MyApp::entity (C++)

Where you are almost exclusively referring to one namespace, that gets too verbose. Then you can use MyApp (Ada) or using namespace MyApp (C++) to make that namespace available in the current scope, then you only need to qualify only the names from the other namespace.

It can sometimes aid clarity to qualify some of the names from the used namespace e.g. when entities from both namespaces are used in the same statement, or any oddity of their use might confuse the reader.

Answer 3

Naming collisions are bound to happen when using third-party libraries because naming objects is not an easy thing to do and there are not many elegant names one can assign to objects to give them representative meaning. With that said, if you won't have many of these collisions that would cause much confusion to anyone reading/using your code, then use the same names. My suggestion is to avoid naming collisions as much as possible.

For your particular example, instead of using the name Entity, you could use EntityBase.