Fluent API. Часть 2 — а оно нам надо?

[surly]

По поводу улучшения читаемости:

bank.transfer(1L, 2L, 1200, 1.2);

При вызове с именованными параметрами мы добиваемся той же читаемости:

bank.transfer(

fromCustomerId: 1L,

toCustomerId: 2L,

amount: 1200,

fee: 1.2

);

Стоит ли усложнять систему билдерами, если язык позволяет пойти таким путём?

[Woodroof]

Или, если не позволяет, bank.transfer(SenderId(1), ReceiverId(2), Amount(1200), Fee(1.2));

[surly]

Как это работает? Что возвращают, например, методы SenderId и ReceiverId?

[Woodroof]

В C++ это explicit конструкторы типов, которые потом не позволят одно к другому неявно привести.

[GFIce]

Вполне годный вариант улучшения читаемости за счет ввода дополнительных абстракций, согласен.

[GFIce]

Соглашусь что если в языке есть поддержка именованных параметров, то их использование снимает часть вопросов с читаемостью. Но не во всех языках это есть, в частности в Java, на которой приведены примеры, к сожалению, такой возможности нет.

[surly]

Вот за это я и невзлюбил Java некоторое время назад и перебрался на C# и Ruby. За "многабукв", отсутствие удобных синтаксических сахаров где удобно, и за "фабрики фабрик" на каждом шагу для создания объектов.

[stepagrus]

А мне нравится юмор.

[GFIce]

Спасибо. Рад что понравилось =)

[korbash1]

хорошая статья, не знал что это называется fluent подходом. Меня тоже всегда тянуло в эту сторону, и главная причина мне кажется вот эта

При Fluent подходе мы будем видеть только те подсказки, которые доступны на конкретном шаге.

тоесть мы можем пользоваться библиотекой как конструктором. Может вы знаете язык/языки которые специально проэктировались для такого подхода?
требования примерно такие:

• можно гибко настраивать возможности следующего шага

• синтаксис заточен под такой подход

[GFIce]

Рад что понравилась статья.

По поводу языков - в целом точно такой подход можно реализовать на С#. На уровне модификаторов методов интерфейсов можно скрыть стандартные методы от Object и останутся только публично объявленные в интерфейсе.

В Java мы в в любом случае будем иметь доступ ко всем методам интерфейса + стандартные методы от Object, но в большинстве случаев это не сильно мешает.

О том как принципиально подходить к реализации подобных интерфейсов в контексте Java я планирую написать в следующих статьях цикла. Переложить подход на другие языки не должно быть сложно.