related : https://refactoring.guru/introduce-null-object
The question is : when should we go for NilObject classes : from the first method to unify the way to handle this kind of things in the code base or wait until you have something a bit complex to do it ?
So let's say we have a Cup model that has tray_uuid and barcode attributes. In one case we want to get a Cup that is linked to a specific barcode and return the uuid of the tray it's stored on.
Of course, sometimes the barcode given doesn't find the related Cup (maybe we don't stock that one) so we want the method to fail nicely and the response to contain an empty string.
So, one way is to use &. operator with a to_s so we get empty string if there is no such Cup.
The other would be to use a NilObject with a tray_uuid
method that returns an empty string. Thus we have the default value, and everything is explicit and clear.
Yet, we traded a single line totally correct Ruby for an extra layer.
Which one would you pick and why ?