> Hello,
>
> I feel like that is more of an architecture problem than a programming one
> though. Instead of constantly checking if the conditions are right, use php's
> type system instead, so it would read more like:
>
> if ($response instanceof SuccessfulResponse) {
> return $response->data->order->quantity;
> }
>
> throw new UnexpectedResponseException($response);
>
> I'd argue that having an "undefined" aka "null" quantity in a model at all is
> rather strange as that doesn't seem to represent any possible reality outside
> of a computer (unless you are dealing with Schrodinger's cat or other quantum
> effects).
>
> — Rob
Hi,
The thing is I am just a consumer of the API, before implementing I
did have a thought about having Successful and Error DTOs, but for me
that was more work for the same result. First I need to map JSON to
generic Response, then do some checks and map from generic Response to
another DTO. And it's not just success and error, there are about 20
response codes and several variations of response you could get.
And I absolutely agree about null quantity, some of the objects there
have every property nullable, it's insane.
