Цепочка методов с объектами значений

Является ли приемлемым / хорошей практикой использование шаблона цепочки методов для объектов значений (например, возврат нового объекта вместо этого)? Есть ли случаи, когда это решение реализовано?

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


person Stefano Borini    schedule 30.12.2009    source источник
comment
Предлагаю вашему вниманию окончательное дерево решений метода цепочки решений   -  person rdlowrey    schedule 15.08.2012


Ответы (3)


Вывод: такая практика вполне приемлема.

Я считаю, что это обычно то, что происходит, когда у вас есть неизменяемый объект. Вместо изменения исходного объекта создается и возвращается новый с заданным значением. Аргументы за и против использования цепочки методов примерно такие же, как при использовании изменяемых и неизменяемых объектов.

Единственное, что меня беспокоит, это то, что это ясно для вызывающих классов - они не могут зависеть от идентичности с привязанным объектом, и должно быть ясно, что вызов не изменяет исходный объект. Хотя, если бы они действительно связывали вызовы, они бы не назначали промежуточные объекты, поэтому большого риска этого не было бы. Важно то, что они только используют последний объект в цепочке методов.

Чтобы использовать 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

Да, это прекрасное занятие. Примеры:

  • Строка в Java и .NET
  • DateTime и TimeSpan в .NET
  • Многие типы в Joda Time и Noda Time
  • Списки на функциональных языках, таких как F #

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

person Jon Skeet    schedule 30.12.2009

Многие классы Java предоставляют неизменяемые объекты значений. java.lang.String, java.math.BigInteger и java.math.BigDecimal являются объектами неизменяемых значений, их методы возвращают новый объект. Самый большой недостаток в том, что люди, плохо знакомые с ним, не понимают, что он неизменен, и думают, что они меняют оригинал.

Некоторые языки подчеркивают неизменность больше, чем другие. В Ruby строки являются изменяемыми, и коллекции часто предоставляют версию, которая возвращает копию, и другую, которая изменяет существующую копию (например, Array # sort и Array # sort!). В Clojure неизменяемость - это норма.

person Nathan Hughes    schedule 30.12.2009