It should not be used as a validation check for null. The !! operator is designed to be ugly and shouldn’t be used unless you really, really, really know better than the compiler. Since your request is only two fields you may not benefit from this kind of simple builder. That way you can collect the values more flexibly before the final “build” and validation. Sometimes it helps to have your class, your request class, allow non-final ( var) properties that default to null so it can be used as a simple builder. if your request included shipping options using ShippingOptions.NONE may be more appropriate than null). If you had more complex classes other than String and BigDecimal you would want to compare using null with the other classes possible “empty value” alternatives (i.g. If you want to represent a request with an absence of a value for name or price, I think null is a good solution. receiving them from REST or DB that does not enforce non-nulls)? Is it expected to send a request without a name or price? Is there a natural default (e.x.name = “Unnamed” and price = 0)? Is it always an error for a request to be received missing one of those values? Are you receiving these requests from a source that cannot guarantee the non-nullness of those values (e.g. In this case, it sounds like you could use null to mean the value was not sent as part of the request. It depends on what you choose null to mean and what you think is best for your use case.
0 kommentar(er)
