Is it a bad practice to use an "optional" variable within an object?

Question

Is it a bad practice to use an "optional" variable within an object?

Navigation

#1 by (3 votes)

4

When I download a photo on my system, the download process passes through a security method that returns an object called DownloadResponse .

public class DownloadResponse{
    public bool IsValid{get; set; }
    public int DownloadTypeID { get; set; }
}

Within it I have IsValid and DownloadTypeID , DownloadTypeID can either return 1 or 2, 1 for download and 2 for re-download .

When the value is 2 I would need to return a value from my bank called license-key but I wanted to insert this license-key into the return of that object by inserting an "optional" variable:

public class DownloadResponse{
    public bool IsValid{get; set; }
    public int DownloadTypeID { get; set; }
    public string LicenseKey { get; set; } //Só tera valor quando o DownloadTypeID == 2
}

Is it okay for me to do this in this kind of situation? I am in doubt if it does not hurt some concept of object orientation.

c#

asked by anonymous 16.10.2017 / 15:41

1 answer

What is Chainability? Align HTML + CSS component

score 3 · Accepted Answer

I talk a lot about bad practice . I mean how little or nothing this means. You have to do what you need to fulfill the need in the best possible way. This varies from case to case.

Can you think of a better solution that does not do this?

I think of one that has different types (probably inherited from a common base) depending on the state of another variable, which in practice will make this property disappear from these types since the type would already indicate what it would have in its value. This solves the question of having a variable with a null die (optional). It is questionable whether this is better or not.

The most purists will say that they have to do so. The more pragmatic will say that it is not quite so and can complicate the application without need.

In a database you can do everything as NOT NULL , but it can complicate modeling. It's the same thing. Understand that you will only have a null there in LicenseKey .

Do not hurt OO, and if you hurt but solve your problem well, that hurts. One of the mistakes that is made is to think that just follow a specific methodology and everything will look beautiful. Doing right is what matters and this no methodology says as it is in each case.

It may have some problem for your case, but nothing to do with object orientation.

Note that having a null becomes part of your domain definition. You need to know that you can only take this information to see if it is valid. This can even be abstracted into the object itself. If you did different objects there would be a guarantee that is always valid, but would have to treat everything differently for each type, would have method to handle an object that has a key and another that can deal with the object that does not have. p>

I'm not a fan of anything, and luckily C # 8 should allow you to avoid using it. But there are cases where the null makes a lot of sense. In C # 8 it will be interesting because even where it needs to be null the compiler will require you to handle properly.