Вывод: такая практика вполне приемлема.
Я считаю, что это обычно то, что происходит, когда у вас есть неизменяемый объект. Вместо изменения исходного объекта создается и возвращается новый с заданным значением. Аргументы за и против использования цепочки методов примерно такие же, как при использовании изменяемых и неизменяемых объектов.
Единственное, что меня беспокоит, это то, что это ясно для вызывающих классов - они не могут зависеть от идентичности с привязанным объектом, и должно быть ясно, что вызов не изменяет исходный объект. Хотя, если бы они действительно связывали вызовы, они бы не назначали промежуточные объекты, поэтому большого риска этого не было бы. Важно то, что они только используют последний объект в цепочке методов.
Чтобы использовать java.lang.String в качестве примера, клиент String делает следующее:
myString.trim().replace("a", "b").substring(3, 9);
... ничего не значит и обычно указывает на недоразумение программиста. Они должны делать следующее:
String myNewString = myString.trim().replace("a", "b").substring(3, 9);
... а затем использовать myNewString
в последующих операциях. Интересно, что инструмент статического анализа для Java, Findbugs, может обнаруживать случаи этого недоразумения и сообщать о них как о вероятной ошибке.
Понимание клиента - это главный случай. К другим недостаткам относится то, что создание объекта-значения очень дорогое, поэтому создание нового объекта в каждой цепочке приведет к снижению производительности. Вы должны быть в состоянии определить по собственному сценарию, является ли это проблемой. В этом случае вместо создания нового объекта в каждой цепочке методов вы можете реализовать шаблон Builder.
Кроме этого, я не могу думать ни о каких других проблемах.
person
Grundlefleck
schedule
30.12.2009