Java Fluent Wrapper [closed]

Yes, your implementation is sound and possible...however, it doesn't make any sense to have it in the first place, at least not for your example.

final MenuItem item = new Fluent<>(new MenuItem("Foo"))
                                   .with(o -> o.setAccelerator(accelerator))
                                   .with(o -> o.setOnAction(this::callback)).get();

Compared with:

final MenuItem item = new MenuItem("foot");
item.setAccelerator(accelerator);
item.setOnAction(this::callback);

That's less code to type, easier to type and a little bit easier to read.

And if you wanted to be a little bit more...uh...fancy, you could simply use the double-brace initialization for non-final classes at least:

final MenuItem item = new MenuItem("foot") {{
    setAccelerator(accelerator);
    setOnAction(this::callback);
}};

No need to comment on null-checks. I have omitted them in this post for the sake of simplicity.

Please don't the next time.

I get the feeling you just want to call the setters in a chain to spare you from writing item. and ; before and after every call, instead of actually having a fluent interface.

Does this actually make your code more fluent and more maintainable or are you introducing foreign concepts that confuse the people who read it the future? Will you even remember what that code does in 6 months?

I would say that your gut feeling is right here. You're jumping through hoops to not make much of an improvement.

I wrote code like the question once for a Fluent Builder which also accepted Consumer as parameter to allow callers to provide a set of opaque modifications determined earlier. In a menu example this might be:

new Fluent<>(new Menu("File")))
  .with(o -> o.setAccelerator(accelerator))
  .with(contextSensitiveMenuItem)

This rapidly required a varargs call as the opaque-items are variable in number

public Fluent<T> with(Consumer<T>... consumers) {
  for (consumer in consumers) {
    consumer.accept(object);
  }
  return this;
}

Generically, I'm not sure how useful final parameters are in this context. THe compiler will figure that out itself.

You seem to have grasped some of the mechanics of a fluent interface without grasping the fundamentals around purpose or fit (maybe your gut has, but your mind has not yet reached this understanding). When Evens and Fowler first document this pattern, their intent was to make code clearer and more readable by allowing methods to be chained together.

Your code, while technically correct, is not clearer or more readable. It adds extra verbiage and doesn't remove the object.setter() syntax at all. It simply obfuscates it by hiding these calls in the heart of a functional interface. Carefully consider the point in bold and italics because it's really important here -- you haven't removed the thing you were trying to remove. This code fails in its most basic purpose, as well as making things considerably worse.

This is a very bad idea. As @Bobby said:

final MenuItem item = new MenuItem("foot");
item.setAccelerator(accelerator);
item.setOnAction(this::callback);

Is much simpler, clearer, and easy to read. If you wanted to make this fluent you would change the setters to return this and then you could get something like:

final MenuItem item = new MenuItem("foot").setAccelerator(accelerator).setOnAction(this::callback);

However, in this specific case, you would be better off with one or more constructors to cover the most common use-cases.

The purpose of code is 2-fold. First, it has to execute correctly, and second, it has to communicate its purpose clearly to future engineers. Code is read many more times than it is written, and it is this fact that is constantly prominent in a senior developer's mind while coding.