I think the whole idea of using NullObject is taken from Option type, which holds None or Some. When they is no null you don't think it exists. E.g. while Some holds a real not null value, which can be mapped, None always returns None. This approach is called "Railway programming".
I have great experience in IT over 12 years: front / back - ends, mobile, system administration and deployment cycle. I implement effective and great software products.
As I know, the pattern was a long time before Optionals (some, none).
And what author proposes – it’s a big difference from it.
Using optionals you stop the execution flow, while the topic about redundant objects creation.
I think the whole idea of using NullObject is taken from Option type, which holds None or Some. When they is no
nullyou don't think it exists. E.g. while Some holds a real not null value, which can be mapped, None always returns None. This approach is called "Railway programming".nullis avoided and the program doesn't crash. Just different way of thinking when there is no null.As I know, the pattern was a long time before Optionals (some, none).
And what author proposes – it’s a big difference from it.
Using optionals you stop the execution flow, while the topic about redundant objects creation.
2 examples I've seen in Minecraft:
Air blocks - they are blocks like any other, rather than nulls to represent a block not being present in a location
Also added in the last few versions (replacing null) - "Empty" item stacks - there is a singleton "ItemStack.EMPTY" and a method "ItemStack#isEmpty()"