Naming classes representing multiple values - Singular or Plural?

Question

So we've got the following class:

public class BudgetAmounts
{
    public readonly int BudgetFk;//Foreign key to Budget
    public readonly int ItemSalesGroupFk;//Foreign key to the type of product being budgeted
    public readonly decimal DollarAmount;
    public readonly int UnitAmount;
    ...
}

This class represents a table with the above four columns. There is no relation between DollarAmount and UnitAmount - the two values are entirely independent.

I pointed out in a code review that classes should be named as singular - 'BudgetAmount'. Otherwise, you'd have things like:

var amountses = new List<BudgetAmounts>();

However, it was pointed out that since there are two amounts (dollar and unit) in the class, it doesn't make sense to name it as singular.

What is the best way to proceed?

Answer 1

After reviewing the comments from John Wu and candied_orange with my Team, we've agreed that the best approach would be to redesign what the thing is so as to make it singular. Calling it (both in code and database) 'BudgetLine' instead of 'BudgetAmounts'.

Answer 2

I would argue that it depends on whether it is actually multiple amounts or just multiple representations of a single amount. Let’s look at temperatures for instance. I could have the following:

TempCelcius = 100;
TempFahrenheit = 212;
TempKelvin = 373;

All those would be fine in a single instance of a Temperature class, as they are all the same temperature. So if your case is somewhat similar to this, then keep it singular. If they are different amounts, make it plural.

Answer 3

From chat:

Why is DollarAmount decimal and UnitAmount is int? Depending on what the SalesGroup is, they'll generally only use one or the other. You can budget $100 for motors or 5 for boats. In which case, you are expecting to sell $100 worth of motors, regardless of how many motors, and 5 boats, regardless of how much each boat sells for. In rare cases they may budget both, but the two numbers are independent.

I recommend SalesProjection because that's what this data really is. It's not a budget. It's an anti-budget. This is money you'll be taking in not putting out.

A sales projection is the amount of revenue a company expects to earn at some point in the future. It's a prediction that is synonymous with a sales forecast. Both help determine the health of a company and whether sales will trend upward or downward. Small companies use various input to determine sales projections. The initiative usually commences in the sales department. There are certain inherent advantages to calculating and using sales projections.

chron.com - The Definition of Sales Projection

Also, don't load foreign keys. Entities shouldn't access repositories directly

Answer 4

I would keep it singular. It’s probably a representation of your model. A collection of such would be a plural and that’s what your table would be named.

Also, I would call DollarAmount as just Amount and UnitAmount as NumberOfUnits or just Units. Reason: Your field names should have exact, un-ambiguous meaning. Dollar is a currency. UnitAmount is conflicting measure.

Also, if you rename the members it’s no longer two amounts.

Answer 5

The core of your problem

This class represents a table with the above four columns.

A class does not represent a table. It represents a row of the table. One instance of this class is not able to represent more than one row of the table at the same time (and if it is, then you've wrongly designed your class).

A collection of this class would be a better representation of the table, leading us to the following usage of plural/singular:

IEnumerable<BudgetAmount> BudgetAmounts = new List<BudgetAmount>();

---

Semantics

However, it was pointed out that since there are two amounts (dollar and unit) in the class, it doesn't make sense to name it as singular.

The developer is correct that one row contains two budget values.

However, the name of the class needs to represent the whole of the entity, not just two arbitrarily chosen columns of the entity.

If your developer is incapable of thinking of this entity as anything other than "the two budget values", then he's not understanding that what the entity represents (functionality) is not necessarily the same as what the entity contains (implementation).
If this is the case, it might be interesting to have your developer brush up on DDD. Even if you don't use DDD in your codebase, it very much teaches you the difference between your data (entities) and your domain (aggregates) and I think your developer is lacking this perspective.

The singular/plural distinction of a table versus a row is much more important than listing the columns of the row.

Note that this can be contextual. The singular/plural distinction of a table versus a row is much more important than listing the columns of the row in the data layer, but it might make more sense to list the budget values as a plural in the domain or user UI.
That is possible, and then you can make that distinction. However, this is likely going to cause naming confusion between layers and I suspect that it's not going to be worth going through all that trouble for.