5

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?

16
  • 2
    It seems pretty subjective and I can see the reasoning either way. I would try to resolve the issue by renaming it to a singular noun that encompasses both amounts, like SalesGroupBudgetSummary or something like that.
    – Eric King
    Sep 26 '19 at 14:39
  • 1
    Please explain BudgetFk and ItemSalesGroupFk. More importantly, please describe the intent of this class. Also, It's it an abstraction or a data structure? Public ints makes me think data structure. Sep 26 '19 at 15:30
  • 2
    What does the question have to do with tuples? The title is confusing me.
    – David Arno
    Sep 26 '19 at 15:34
  • 1
    What is a "BudgetAmounts"? How is it different from a "Budget"?
    – John Wu
    Sep 26 '19 at 17:58
  • 2
    "This class represents a table". Ok, so what is the name of the table? Sep 26 '19 at 18:22
6

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'.

4
  • Probably not a bad idea but can't really tell without seeing the new design. Sorry my current network isn't allowing chat. Sep 26 '19 at 19:05
  • @candied_orange No worries. Short answer is that UnitAmount and DollarAmount are 100% separated from each other - DollarAmount is monetary amount we plan to sell. UnitAmount is number of units we plan to sell. Unit value may vary, so there's no conversion. Either or neither may be 0.
    – Sarov
    Sep 26 '19 at 19:11
  • You plan to sell a monetary amount... you're selling money? Nope still not getting it. Is this how much you plan to make from sales? Net? Gross? I really think you shouldn't tack "amount" on because it really doesn't make anything clear and seems to be distracting. Sep 26 '19 at 19:17
  • Gross amount we plan to make from sales. Might make sense to include that in the column name, actually.
    – Sarov
    Sep 26 '19 at 19:40
3

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.

0

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

0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.