The other day I watched some thinker named Michael talk about . Look it up on that big ad-rich video website.

Unconditional Code is the idea that our 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.

Well. Partly.

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 when we look at the 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:

````java
person.doWithName(my::action);
````

in which doWithName looks like this:

````java
void doWithName(
final Consumer<Name> action
)
{
this.name.ifPresent(action::accept);
}
````

Michael says that this way, we declare what action some value should undergo, and leave the evaluation to the value.

A problem I found when implementing this, is race conditions during on collections.

And that may be specific to the . The proposed architecture uses 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.

Follow

So if you find a way to implement in an elegant manner, please share?

Sign in to participate in the conversation
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!