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

Question

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

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

Inside him I have the IsValid and the DownloadTypeID, Downloadtypeid can either return 1 or 2, 1 to download and 2 to 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 within the return of that my 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 right for me to do this in this kind of situation? I wonder if it hurts any concept of object orientation.

Answer 1

I talk a lot about malpractice. I say how much this means little or nothing. You have to do what you need to do to meet the need in the best way possible. This varies from case to case.

Can you think of a better solution than not to do that?

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 datum (optional). It is questionable whether this is better or not.

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

In a database you can do everything like 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 anything OO, and get hurt but solve your problem well, hurt. One of the mistakes one makes is to think that just follow a specific methodology and everything will be beautiful. Doing right is what matters and this no methodology says as it is in each case.

You may have a problem with your case, but nothing to do with object orientation.

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

I’m not a fan of anything null, and luckily C# 8 should allow you to avoid its use. But there are cases that null makes a lot of sense. In C# 8 it will be interesting because even where it needs to be null the compiler will force you to treat properly.

In C# 8 it can be interesting to do so:

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

I put in the Github for future reference.