Работа с большими фрагментами текста в исходном коде Java

Есть ли хорошие способы работы с блоками текста (строками) в исходном коде Java? Во многих других языках есть синтаксис heredoc, но в Java нет. Это делает довольно неудобной работу с такими вещами, как библиотеки тегов, которые выводят много статической разметки, и модульные тесты, где вам нужно утверждать сравнения с блоками XML.

Как другие люди обходят это? Это вообще возможно? Или мне просто нужно смириться с этим?


person Rob Hruska    schedule 23.04.2009    source источник
comment
См. также: stackoverflow.com/questions/878573/java-multiline-string (тот же вопрос; опубликовано позже , но со многими ответами ОК)   -  person Eirik W    schedule 25.05.2012


Ответы (3)


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

Тенденция в программном обеспечении, как правило, заключается в отделении кода от данных, с которыми он работает. Большие текстовые разделы, даже если они предназначены только для отображения или сравнения, являются данными и поэтому обычно хранятся во внешнем хранилище. Стоимость чтения файла (или даже кэширования результата в памяти) довольно низкая. Интернационализация проще. Менять проще. Контроль версий проще. Можно легко использовать и другие инструменты (например, средства проверки орфографии).

Я согласен, что в случае модульных тестов, когда вы хотите сравнить вещи с макетом, вам потребуются крупномасштабные сравнения текста. Однако, когда вы имеете дело с такими большими файлами, у вас обычно будут тесты, которые могут работать с несколькими различными большими входными данными для получения нескольких больших выходных данных, так почему бы просто не загружать тестом соответствующие файлы, а не встраивать их?

То же самое и с XML. На самом деле, для XML я бы сказал, что во многих случаях вы захотите прочитать XML и построить дерево DOM, которое затем будете сравнивать, а не выполнять сравнение текста, на которое могут повлиять пробелы. И вручную создавать XML-дерево в вашем модульном тесте некрасиво.

person Uri    schedule 23.04.2009
comment
Я думаю, что Роб может описывать большие многострочные строки SQL в java-приложениях, которые не используют ORM, или выполнять множество операций SQL, не поддерживаемых ORM. Они определенно являются частью логики и кода и представляют собой PITA для работы с java. Я не думаю, что хотел бы хранить их в БД. - person r00fus; 19.08.2010
comment
-1 Часто легче читать тестовые фикстуры, которые имеют сценарии XML или SQL непосредственно в коде Java. Очень раздражает переключение между дополнительными файлами или построение дерева DOM вручную, когда оно очень большое. В конечном итоге вам нужно протестировать тестовый код. - person User1; 26.01.2011

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

person Rob Hruska    schedule 23.04.2009

Параметр закрытия в Java для HereDoc — это java.text.MessageFormat. Нельзя встроить логику. Это простая утилита для экранирования значений. Переменные не используются. Вы должны использовать индексацию на основе нуля. Просто следуйте javadoc.

http://download.oracle.com/javase/1,5.0/docs/api/java/text/MessageFormat.html

person Aris Bartee    schedule 07.11.2011