C#•3mo ago

Property meanings

Hi all I'm discussing with the group leader the meaning of a certain property. We have a property called 'Day', which indicates the duration of a subscription in days. We need to determine the type of subscription, as there are several different subscriptions implied, and we need to adjust the rules of interaction with them. Therefore, in the code, we need conditions that will set the type of subscription for an object. I suggested adding an additional enum field specifying the subscription types, but my team lead wants to check the subscription type based on the 'Day' property. Since he threatens dismissal when I ask questions, I'm turning to you with this question: what is the correct approach and what might I be missing?

6 Replies

Angius•3mo ago

Each subscription should definitely be its own thing. Something like

class Subscription
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int DurationInDays { get; set; }
}

class Subscription
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int DurationInDays { get; set; }
}

Storing the amount of days and an enum specifying the subscription type can be fine in a pinch, but you make a state where two things with the same enum value can have a different duration, valid And it should not be In a bigger pinch, yeah, you can have a DurationInDays property and some

var subscription = user.DurationInDays switch {
    7 => "weekly",
    30 => "monthly",
    365 => "yearly",
    _ => throw new Exception();
};

var subscription = user.DurationInDays switch {
    7 => "weekly",
    30 => "monthly",
    365 => "yearly",
    _ => throw new Exception();
};

but what if the duration is 8, 71 or -11? All of those are valid for an integer Assuming the data is stored in a database, the first solution is the one and only proper Any other solution suggests mild brain damage So, without knowing further context, your suggestion is second best Your leader's insistence on a sub-par solution is a "let's get you into a nursing home, with a copy of 'Python for Dummies', grandpa"

D.Mentia•3mo ago

I would lean toward checking type based on Duration. It can get very annoying to have to maintain duplicate data in the database, IE to keep user's subscriptions updated so when they change to a monthly subscription, you change both the Duration and the enum, and if you forget one then you break stuff Since that data is already available as the duration, I'd say there's no need for an enum or anything, and just like Z said - any duration >7 days is a monthly subscription

Aleksandr•3mo ago

For clarification, I'll mention that this is a client-server web application, i.e., with a back-end and front-end part, and the front-end also requires type checking of subscriptions. The subscriptions themselves are stored in the database, and recently we've been changing the number of days for the trial version's validity. I assume it would be easier for the front-end to look at static numbers like 1, 2, 3 instead of 7, 14, 30. The project context implies working with real estate and cars, and it can be assumed that subscriptions may be categorized thematically according to categories and have the same number of days but different rights. Another interesting question arises: would the Single Responsibility Principle be violated if we use the 'Days' field both as the type and the duration of the subscription?

Angius•3mo ago

it would be easier for the front-end to look at static numbers like 1, 2, 3

Yes, especially if they were the IDs of different subscription tiers stored in their own database table

D.Mentia•3mo ago

You probably shouldn't trivially modify your database based on what the frontend needs, leave it to the backend to 'translate' to your frontend's DTOs. If the frontend is a huge part of what you do, a larger restructure like a subscription tiers table might make sense, but just adding a random column because the frontend needs it and you don't want to calculate it in the backend, I wouldn't. And single responsibility usually applies to a logic class, not a single parameter of a data model

Angius•3mo ago

If anything, it would break whichever database normal form, the one that has you make the address not be stored in the same row as a person, bur rather in a separate table

Gaming

Programming

Property meanings