Не знаю как вы, но я метод toString в своих классах использую в основном для логгирования всей возможной информации об экземпляре класса. Так вот, в классах с большим числом пропертей (бинах) зачастую метод toString выглядит ужасно архаично. Кроме того при добавлении новых пропертей зачастую забывается добавить его вывод в toString, что добавляет проблем при будущих исследованиях ошибок. Рассмотрим на примере класса Student.
class Student {
String name;
Integer course;
public String toString() {
return "Имя: " + name + "Курс: " + course==null?"":course.toString();
}
}
Всё просто и примитивно, но не красиво, сложно и не сразу понято.
Специально для решения данных проблем в Apache Commons был создан класс ToStringBuilder, который самостоятельно соберёт строку или несколько строк из всех пропертей вашего класса. В результате использования данного класса наш пример примет следующий вид:
class Student {П.С.: По аналогии с
String name;
Integer course;
public String toString() {
returnToStringBuilder.reflectionToString(this)
;
}
}
ToStringBuilder в указанной библиотеке есть
EqualsBuilder, HashCodeBuilder, CompareToBuilder которые также являются весьма полезными.
6 комментариев:
А что с производительностью этих методов, работающих через reflection?
Не лучше ли воспользоваться чем-нибудь типа lombok - http://projectlombok.org/?
Спасибо, изучил, довольно интересный проект.
Но я скажу ему нет по 2м причинам:
1. 1.9Мб!
2. Дебажытся с генерирующимся на этапе компиляции кодом - это к любителям садо-мазо.
Ещё интересный вариант "умные" плугины в IDE (в IDEA такой, например).
Он генерирует toString (всё тюнится) и потом подсвечивает поля не включенные в toString
Точно, в IDEA есть такое, а вот про такой плугин для Eclipse не знаю.
Спасибо, изучил, довольно интересный проект.
Но я скажу ему нет по 2м причинам:
1. 1.9Мб!
2. Дебажытся с генерирующимся на этапе компиляции кодом - это к любителям садо-мазо.
1. А большая разница? Если веб приложение - на размер пофиг. Если standalone, то там размер будет тоже не так существенен относительно размера всей проги. Это актуально только если мы рассматриваем маленькие программы, но для них из jar-ника lombok'a можно вырезать все лишнее.
2. Можно подробнее. Просто я в java себя спецом не считаю.
1. Размер имеет значение. Всегда, будь то веб-приложение или standalone, не важно. Помните эти дополнительные 2мб будут всегда за вами волочится:
- при копировании на сервер,
- при старте приложения (2Мб архив должен быть распакован),
- при работе приложения (дополнительных 2мб классов которые используются постольку поскольку будут висеть в памяти. Сборщик мусора будет счастлив.
и т.д.
Выпиливание же "ненужных" классов - это студенческий хак, который повлечёт ненужную работу и неожиданные ошибки. В промышленных решениях таким никто не занимается.
2. При "дебаге" (отладке приложении во время работы) сопоставляется бинарный код приложения и сорсы по которым происходит отладка. При использовании "ломбока" сорсы будут отличатся от бинарников, так как аннотации на-генерят дополнительных методов. Соответственно вы не будете иметь никакой возможности ни поставить брейкпоинт ни по шагам пройти по методам аннотированного ломбоком класса.
Отправить комментарий