The other day I watched some thinker named Michael talk about #UnconditionalCode. Look it up on that big ad-rich video website.
Unconditional Code is the idea that our #software #architecture should not be dealing with conditions unless they are part of the problem domain. Our code should not be catching all kinds of exceptions and then break.
It shouldn't do so at first glance. Underneath you'll still perform checks. For safety and self-defense.
We see parts of this in the #Java #programming #language when we look at the #Optional class. Other languages also have optionals and maybes.
Their functionality is conditional: if present, do something. Otherwise, do something else.
With Java specifically, the Optional ability feels like an afterthought. Other languages may fare better. But what Michael advocated, is to make the condition part of the problem domain.
Michael's example was that of having a person object. If that person has a name, some action must be performed. Otherwise, not.
We could set up a domain method like so:
in which doWithName looks like this:
final Consumer<Name> action
Michael says that this way, we declare what action some value should undergo, and leave the evaluation to the value.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!