Naming a class representing a collection of objects of another class

Question

This is always a problem for me. Say, in a game, there's a class representing an enemy spacecraft named EnemySpacecraft and there's a class representing some collection of those, say all that exist in the game. This class may be implemented as just an encapsulated array of enemy spacecrafts. Giving this class a name like EnemySpacecrafts is way too similar to the singular form. My other ideas are e.g. AllEnemySpacecrafts or EnemySpacecraftCollection, but I don't know how good I would say those are. What is a proper name to give here? Is there a convention I'm unaware of?

Answer 1

Welcome to the worse part of this job. Naming things.

Here some suggestions

1. Reusability

Let's say you want to reuse the concept of groups for different entities of the game.

You could use a basic name alongside generics

- Raid<>:
  - Raid<EnemySpacecraft>
- Party<>
  - Party<EnemySpacecraft>
- Fleet<>
  ...

They also remain loyal to the game's jargon (God, how I miss MMOs).

2. Concreteness

• EnemySpacecraftRaid
• EnemySpacecraftParty
• EnemySpacecraftFleet

One benefit of omitting the suffix Collection is that you don't tie the name solely to the idea of having just a collection. A Raid<?> might involve behaviours and attributes like any other entity in the game, not only .iterator(), .get(int), add(), remove() and so on so forth.

What I like about this approach is it applies the ubiquitous language of the domain (games) to the code.

On the other hand, if you want everything to be subordinated to the technical language, then...

there's a class representing some collection of those, say all that exist in the game.

The ideal name would be EnemySpacecraftRepository. But I get the feeling that this name doesn't meet your expectations. Right?

Answer 2

I think you need to clearly separate what the list is representing from what a particular instance is being used for. Using Java syntax, a collection of spacecraft could be as simple as

List<Spacecraft> activeEnemies = ...
List<Spacecraft> enemyAttackForce = ...
List<Spacecraft> surrenderedEnemies = ...
List<Spacecraft> destroyedEnemies = ...

If a list of enemy spacecraft has methods that make sense only for enemy craft, then by all means write a class that encapsulates that behaviour. But don't mix the concepts. EnemySpaceCrafts and EnemySpaceCraftCollection are OK names, if a little clumsy (I don't have a better suggestion). AllEnemySpaceCraft is not so good, as it suggests you should not reuse the class when you need another unrelated collection of enemy spacecraft.

Answer 3

Why is it way to similar to the singular form? I much prefer plural and singular forms to differentiate - I guess I have my mind trained to look for the 's', but I'm also a big fan of keeping junk out of names.

I wouldn't want to see 'Collection' post-fixed to a name... That's a big word. skimming through my code and my mind's going to want to think hey that's a big word, we should pay attention to it before I have a chance to think 'oh that's just a plural form represented with 9 more letters than necessary. It's clutter.

enemySpacecraft
enemySpacecrafts

One is singular, the other is plural. I don't think it can get much more simple than that!

Keep in mind that code context also helps:

craft.Fire();
crafts.Each(x => x.Fire());

Adding anything more is just getting in the way. Less is more, as they say.

(disregard the fact that 'spacecraft' is actually a singular and plural word... perhaps a poor example for the topic, but you get the idea)

Answer 4

I love to think of an item as a collection of one. I support this notion by implementing methods that work on collections with supplemental methods to handle scalars; purely for syntactic sugar. The scalar method seldom does little more than to call its counterpart. The method that works on the collection does all the work to harness the power if code re-usability, yesss!

If I implement this.rows([] item) I will more likely also have this.row(int item). I have used this design pattern for almost two decades and no complaints yet. The reason is not brevity, coolness or magic but rather consistency. If you have the discipline to be consistent you cannot go wrong with any reasonable style that you choose.

I find simplicity to be of utmost elegance so i save all my energy for super elaborate documentation :-)