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.
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.
And that may be specific to the #java #programming #language. The proposed architecture uses #lambda function forms. And if those have to change a value that needs to live on outside their scope, then java insists that the reference to value must be effectively final, immutable.
And that causes us to code some odd structures that are neither elegant nor simple to understand.
So if you find a way to implement #UnconditionalCode in an elegant manner, please share?
Invite-only Mastodon 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!