05 октября 2010

Apache Commons. Вывод всех "пропертей бина"

Работа программиста полна рутинных задач, которые делают её скучной и не интересной. Одной из таких задач есть переопределение стандартных методов: equals, hashCode, toString и др.
Не знаю как вы, но я метод 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() {
return ToStringBuilder.reflectionToString(this);
}
}
П.С.: По аналогии с ToStringBuilder в указанной библиотеке есть EqualsBuilder, HashCodeBuilder, CompareToBuilder которые также являются весьма полезными.

6 комментариев:

remal комментирует...

А что с производительностью этих методов, работающих через reflection?

Не лучше ли воспользоваться чем-нибудь типа lombok - http://projectlombok.org/?

Rumoku комментирует...

Спасибо, изучил, довольно интересный проект.
Но я скажу ему нет по 2м причинам:
1. 1.9Мб!
2. Дебажытся с генерирующимся на этапе компиляции кодом - это к любителям садо-мазо.

Andrew Fink комментирует...

Ещё интересный вариант "умные" плугины в IDE (в IDEA такой, например).

Он генерирует toString (всё тюнится) и потом подсвечивает поля не включенные в toString

Rumoku комментирует...

Точно, в IDEA есть такое, а вот про такой плугин для Eclipse не знаю.

remal комментирует...

Спасибо, изучил, довольно интересный проект.
Но я скажу ему нет по 2м причинам:
1. 1.9Мб!
2. Дебажытся с генерирующимся на этапе компиляции кодом - это к любителям садо-мазо.


1. А большая разница? Если веб приложение - на размер пофиг. Если standalone, то там размер будет тоже не так существенен относительно размера всей проги. Это актуально только если мы рассматриваем маленькие программы, но для них из jar-ника lombok'a можно вырезать все лишнее.
2. Можно подробнее. Просто я в java себя спецом не считаю.

Rumoku комментирует...

1. Размер имеет значение. Всегда, будь то веб-приложение или standalone, не важно. Помните эти дополнительные 2мб будут всегда за вами волочится:
- при копировании на сервер,
- при старте приложения (2Мб архив должен быть распакован),
- при работе приложения (дополнительных 2мб классов которые используются постольку поскольку будут висеть в памяти. Сборщик мусора будет счастлив.
и т.д.

Выпиливание же "ненужных" классов - это студенческий хак, который повлечёт ненужную работу и неожиданные ошибки. В промышленных решениях таким никто не занимается.

2. При "дебаге" (отладке приложении во время работы) сопоставляется бинарный код приложения и сорсы по которым происходит отладка. При использовании "ломбока" сорсы будут отличатся от бинарников, так как аннотации на-генерят дополнительных методов. Соответственно вы не будете иметь никакой возможности ни поставить брейкпоинт ни по шагам пройти по методам аннотированного ломбоком класса.