2

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?

  • 2
    It might be helpful to explain why you need a new class for this collection, rather than using a built-in collection type. (Also the platform you're working on.) – Josh Caswell Jul 8 '17 at 13:25
  • 1
    Adding an 's' to the end of a class name is a perfectly good way to indicate a collection of them. – Robert Harvey Jul 8 '17 at 22:01
1

Welcome to worse part of this job. Naming things.

Here some suggestions

1. Reusability

Let's say you want to reuse the conocept of group for different entities of the game.

You could use a basic name alongside with generics

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

They also remain loyal to the games 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 only to the idea of having just a collection. A Raid<?> might involve behaivors and attributes as any other entity of the games.

What I like of this approach is that you are moving the ubiquitous language of the domain (games) to the code.

If you think that the domain specific (yours) language doesn't matter and everything can 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 EnemySpacecrfatRepository. But I get the feeling that it doesn't meet your expectations regarding this subject.

1

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.

0

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)

-2

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 :-)

  • Could the downvotes explain themselves? In many cases this is a good idea. Note that it also allows for a collection of zero. Depending on your language, varargs can help with this. – user949300 Jul 8 '17 at 19:25
  • 1
    Maybe, because the answer doesn't respond the question. What is a proper name to give here? Is there a convention I'm unaware of? – Laiv Jul 8 '17 at 21:32
  • I apologize for the lack of clarity, "no there is not". Document and be consistent. – chelista Jul 8 '17 at 21:40
  • 1
    That's a better answer :-) – Laiv Jul 8 '17 at 23:43

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.