Цепочка методов в Java [закрыта]

Эх. Есть аргументы в пользу читабельности в обоих направлениях — есть такая вещь, как попытка поместить слишком много в одну строку.

Но, честно говоря, я подозреваю, что это связано с историческими причинами: широко распространенное «цепное» поведение не стало популярным или широко известным, когда, например. Свинг развивался. Вы можете возразить, что его следовало добавить позже, но подобные вещи, как правило, создают бинарную несовместимость и другие проблемы, к которым Sun/Oracle исторически относились крайне осторожно.

Более свежие библиотеки JDK - см., например. ByteBuffer для основного, хорошо известного примера -- < em>предоставили поведение цепочки и тому подобное, где это имеет смысл.

Еще одна причина, которую я могу придумать, — это производительность, или, точнее, не платить за то, чем вы не пользуетесь. return this после каждого метода не очень затратно, но все же требует нескольких дополнительных циклов ЦП и одного реестра ЦП.

Была даже идея добавить неявный return this в каждый метод, объявляющий возвращаемое значение void, но от нее отказались.

Хотя мы можем только догадываться об истинной причине, одна из них может заключаться в том, что, строго говоря, это не очень ОО.

Если вы рассматриваете методы как действия, представляющие действие смоделированного мира, цепочка методов не вписывается в эту картину.

Другой причиной может быть хаос, который может возникнуть, когда вы пытаетесь переопределить связанный метод. Представьте себе такую ​​ситуацию:

class Foo {
   Foo chainedMethod() {...}
}

class Bar extends Foo {
   Foo chainedMethod() {...} //had to return Foo for Java versions < 1.5
   void doStuff();
}

Поэтому, когда вы пытаетесь сделать new Bar().chainedMethod().doStuff(), он не скомпилируется. И ((Bar)new Bar().chainedMethod()).doStuff() выглядит не очень хорошо, не так ли :)

Цепочка методов обычно используется с шаблоном Builder, и вы можете увидеть это в классе StringBuilder. Помимо этого, цепочка методов может сделать разделение команд и создания менее четким, например, должен ли repaint() также быть частью свободного интерфейса? Тогда я мог бы:

container.add(label).repaint().setMaximumSize(new Dimension(100,200)));

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

Причина, по которой не реализована цепочка методов, может заключаться в следующем:

• Самая большая проблема для цепочки методов — проблема завершения. Хотя есть обходные пути, обычно, если вы сталкиваетесь с этим, вам лучше использовать вложенную функцию. Вложенные функции также являются лучшим выбором, если у вас возникают проблемы с контекстными переменными.

• Нет никакой гарантии, что объект вне цепочки действительно вернет допустимый, ненулевой объект. Кроме того, отладка этого стиля кода часто намного сложнее, поскольку многие *IDE* не оценивают вызов метода во время отладки как объект, который вы можете проверить.

• Это может запутать, когда вы вызываете подпрограммы в другие классы для передачи аргументов одному из методов цепочки, когда нужно передать много параметров, главным образом потому, что строки становятся очень длинными.

• Существует также проблема с производительностью, которая будет сильно влиять на память.