#java #pojo
Не совсем пойму в чем так удобен POJO объект и как понять, что он POJO.
По определению это объект, который ничего не расширяет, ничего не имплементирует
и не имеет конструктора, все переменные приватные + геттеры и сеттеры... Просто такой
себе простой объект.
Значит, если я правильно понимаю, что если допустим выкинуть с этого класса конструктор
то он как бы уже POJO?
public final class CardFriend {
private String friendName;
private String friendPhoneNumber;
private Bitmap friendPhotoBitmap;
private String friendEmail;
private String Uid;
private int chanel;
public CardFriend(String friendName, String friendPhoneNumber, Bitmap photoBitmap,
String friendEmail,
int chanel) {
this.friendPhotoBitmap = photoBitmap;
this.Uid = "test";
if (friendName == null){
this.friendName = States.NO_NAME;
}else {
this.friendName = friendName;
}
if (friendPhoneNumber == null){
this.friendPhoneNumber = States.WITHOUT_PHONE_NUMBER;
}else {
this.friendPhoneNumber = friendPhoneNumber;
}
if (friendEmail == null) {
this.friendEmail = States.WITHOUT_EMAIL;
} else {
this.friendEmail = friendEmail;
}
this.chanel = chanel;
}
public String getFriendName() {
return friendName;
}
public String getFriendPhoneNumber() {
return friendPhoneNumber;
}
public Bitmap getFriendPhotoBitmap() {
return friendPhotoBitmap;
}
public String getFriendEmail() {
return friendEmail;
}
public int getChanel() {
return chanel;
}
public String getUid() {
return Uid;
}
}
И я не нашел, можно ли использовать логические методы в таких классах? Допустим метод
какого нибудь вычисления.
Ну и если кто нибудь приведет примеры, где такие объекты использовать лучше всего
(так как не сомнительное преимущество выкинуть конструктор и поставить сеттеры), то
будет совсем понятно))
Ответы
Ответ 1
В докладе Мартина Фаулера, Ребекки Парсонс и Джоша МакКензи от 2000 года, когда впервые был употреблен этот термин, POJO - это просто Java-класс без "наворотов", не завязанный на определенный фреймворк. В контексте того доклада POJO - простые объекты, не являющиеся Entity Bean из J2EE. Четкого определения тогда дано не было, поэтому точки зрения на то, что это такое, могут немного отличаться. Как правило, такие классы не наследуют от других классов (наверное, можно сделать исключение для классов POJO из того же пакета), не реализуют интерфейсов (иногда делается исключение для маркерных интерфейсов из стандартной библиотеки), не используют аннотаций в определениях и не зависят от сторонних библиотек. Т.е. у POJO могут быть и методы с бизнес-логикой, и произвольного вида конструкторы. Если делать исключение для Serializable, то к POJO могут быть отнесены JavaBeans. Если разрешить аннотации, не меняющие семантику класса (т.е. без которых назначение объекта и логика его работы не изменятся), то к POJO могут быть отнесены сущности JPA и объекты DTO, сериализуемые в XML или JSON, правила для которых заданы в аннотациях. Примером того, когда удобно использовать POJO, является обыкновенная модель предметной области в DDD, которую вы сохраняете в БД или передаете через REST-сервис клиенту. Можно напихать в нее кучу аннотаций, а можно - вынести все правила отображения на БД или DOM в отдельные компоненты (конфигурации ORM и сериализатора), уменьшив связность вашей архитектуры.
