Naming multiple Entities of same collection (with different sets of fields, few less, few more)

Question

Say I have a complex entity (class) called Quote.

We have one representation that has just 3-4 fields used to hold minimal amount of data to identify a quote. Is there any convention to call an entity that does the latter? We were considering QuoteGet (data to "get" a quote), QuoteDef, QuoteDefinition or QuoteReference.

What is the suggested name for the class with all the fields? We have three such entities, Quote is one of them. Is there a general answer for this or do we need to take into account which fields are there in the specialized entity class, with fewer attributes projected, to help us find a name?

Another representation does not have all the fields but does have enough to identify the quote and a few of the BOM and price fields so we call it QuotePrice, this is just FYI that we have about 4 classes that are derivatives of this one entity.

I did look at:

1. Naming standards or conventions for ecommerce

2. Dealing with entities customization

But these do not answer my question. What do you call such classes?

• Doc Brown: Do the fields of "QuoteDefinition" reappear in "Quote", and the fields of "Quote" in "DetailedQuote"?
• Mehdi Charife: Is it possible to have the Quote class be composed of a QuoteIdentifier that has the 3-4 identifying fields and a QuoteExtraDetails that has the details-adding fields?
• Mehdi Charife: Do you use QuoteGet to get an instance of your Quote class? If so, that can be considered a factory. You mention something about a collection in the title. Do you intend to use these different classes in some sort of collection?
• tgkprog: QuoteGet is not a factory, its a DTO/ value class that holds information like the ID, tenany (client) version of a quote @mehdi-charife
• Alexander: How about: "QuoteRequest", "QuoteSummary", "QuoteHandle", "QuoteStub", or "QuoteMetadata"?

Answer 1

Is there any convention to call an entity that does the latter?

Short answer: No, there is no such convention.

Finding "the right" names for such classes depends always on

• the specific purpose and details of the classes

• the abstraction the author of the classes had in mind

• the audience, which means: the developers which will use the classes

• the use cases for which those classes will be used

• the surrounding system with its established conventions, naming constraints, layers and prexisting classes

• the education, school of thought and personal preference of the author.

Hence, your best bet for choosing the class names is to take the above into account and ask another person in your team what they think about the name you chose. Call this a "design review", if you like.

Answer 2

I agree with @DocBrown's general answer.

Only thing I would add is that the accepted term for fields which identify a particular record is a "key". That term is well-known.

A "QuoteKey" would be a reasonable name in this case, assuming there is no ambiguity in your context with any other meaning of the word.

Maybe "QuoteLookup", as an alternative term to consider.

Answer 3

If your language supports namespaces, then that can tidy up your naming. So you could create a Quote namespace, then the classes within it can drop the "Quote" prefix, becoming Quote::Detailed, and so on.

No guideline will tell you what name you should choose for a class. It's up to you to come up with something meaningful.

Make sure you distinguish between verb phrases (e.g. QuoteGet) for methods and noun phrases (e.g. QuoteDefinition) for both classes and class member fields.

• tgkprog: Sadly they dont, it does support packages. But we use these classes in another class so would like to have a unique name for them.
• Simon B: @tgkprog If you don't have namespaces, then you don't have much choice but to fake it by adopting a naming convention.