Что такое pojo в java
Является ли класс POJO обьектом?
Не совсем пойму в чем так удобен POJO объект и как понять, что он POJO.
По определению это объект, который ничего не расширяет, ничего не имплементирует и не имеет конструктора, все переменные приватные + геттеры и сеттеры. Просто такой себе простой объект.
Значит, если я правильно понимаю, что если допустим выкинуть с этого класса конструктор то он как бы уже POJO?
И я не нашел, можно ли использовать логические методы в таких классах? Допустим метод какого нибудь вычисления.
Ну и если кто нибудь приведет примеры, где такие объекты использовать лучше всего (так как не сомнительное преимущество выкинуть конструктор и поставить сеттеры), то будет совсем понятно))
1 ответ 1
Как правило, такие классы не наследуют от других классов (наверное, можно сделать исключение для классов POJO из того же пакета), не реализуют интерфейсов (иногда делается исключение для маркерных интерфейсов из стандартной библиотеки), не используют аннотаций в определениях и не зависят от сторонних библиотек. Т.е. у POJO могут быть и методы с бизнес-логикой, и произвольного вида конструкторы.
Если делать исключение для Serializable, то к POJO могут быть отнесены JavaBeans. Если разрешить аннотации, не меняющие семантику класса (т.е. без которых назначение объекта и логика его работы не изменятся), то к POJO могут быть отнесены сущности JPA и объекты DTO, сериализуемые в XML или JSON, правила для которых заданы в аннотациях.
Java Beans
Я тут подумал и решил устроить тебе еще одну маленькую лекцию, которая будет тебе очень полезна. Пока ты не работал программистом, ты, скорее всего, не сталкивался со специальной терминологией, и я хочу тебя сейчас познакомить с несколькими распространёнными понятиями.
Лет 10 назад массовое распространение получила концепция EJB – E nterprise J ava B eans.
— А что значит Java Beans?
— Bean по-английски боб. А Java Beans – это, стало быть, кофейные бобы (Java – сорт кофе). Такой айтишный юмор.
Бизнес-логику программы представляли в виде набора высокоуровневых объектов – бинов, которые умели обмениваться сообщениями, сохранять себя, находить друг друга по имени, и еще кучу всего. Обычно это достигалось за счет специального супер-навороченного родительского класса, хотя были и другие подходы. Поведение таких объектов очень регламентировалось.
Три самых известных вида EJB-бинов:
Entity Bean – бин, цель которого — хранить некоторые данные. В логику такого бина встроен механизм сохранения себя и своих полей в базу данных. Такой объект может быть уничтожен, а потом воссоздан из базы заново. Но кроме хранения данных у него нет никакой логики.
Session Bean – это функциональный бин. У каждого Session Bean есть своя функция. Один делает одно, другой другое. Такие бины работают с другими объектам и бинами, а не со своими данными.
Session Beans делятся на две категории.
Stateless Session Bean – это бин, который не хранит во внутренних переменных важных данных, нужных для его работы. Такой бин можно уничтожить, а затем заново создать, и он будет выполнять свою функцию, как и раньше.
Statefull Session Bean – это бин, который хранит у себя внутри данные, которые использует при работе. Если мы вызываем методы этого бина, то в каждом следующем вызове он может использовать часть данных, переданных ему в предыдущих. И все равно этот бин – это не то же самое, что обычный объект.
Но в использовании бинов тоже было не все так радужно, поэтому скоро маятник качнулся в обратную сторону. И разработчики стали все чаще использовать обычные объекты. Им даже придумали специальное название.
POJO ( P lain O ld J ava O bject) – старый обычный Java-объект. Такие объекты не обладали какими-то суперфункциями и не наследовались от суперобъектов. Самые обычные Java-объекты.
Со временем в назначении объектов/классов возникла специализация. Как результат – выделились некоторые роли, объекты которых получили новые названия.
DTO — Data Transfer Object – объект, который создается с целью быть использованным при транспортировке данных. Обычно к таким объектам два требования: а) уметь хранить данные, б) уметь сериализоваться. Т.е. их используют только для пересылки данных.
Создал объект, записал в него нужные данные из бизнес-логики, сериализовал в JSON/XML и отправил куда-надо. Или наоборот – пришло сообщение – десериализовал его в DTO-объект и вытягивай из него данные.
Entity – это объект, который хранится в базе данных. Но они не содержат никакой бизнес-логики. Можно сказать, что это – данные бизнес-модели.
Есть еще DAO – Data Access Object. Задача DAO — сохранять объекты в базу и доставать их из нее. Entity сам такой работой не занимается – он не содержит никакой логики и, следовательно, не может ничего никуда сохранять.
Пусть это и небольшая ознакомительная лекция, но больше ты сейчас все равно не поймешь. Каждую из этих тем можно днями рассказывать, а EJB – годами.
Но я хочу, чтобы ты хотя бы представлял, о чем речь, если столкнёшься с такими вещами в разговоре, переписке, на форуме или на собеседовании.
— Гм. Спасибо, Билаабо. Да, думаю, технических терминов мне не хватает. Спасибо большое тебе еще раз.
Классы poji, pojo и Java Beans в Java
POJI в Java
Является аббревиатурой от Plain Old Java Interface, который соответствует стандартному интерфейсу Java, что означает, что эти интерфейсы находятся в контексте предоставления услуг в JEE. Например, услуга OSGI предлагается через POJI в JEE
Другими словами, мы можем сказать, что POJI – это обычный интерфейс без какой-либо специальности, которая не унаследована от какого-либо специального API-интерфейса технологии или интерфейсов платформы.
Пример 1
Оба интерфейса будут называться POJI, поскольку они не наследуют какой-либо технологический интерфейс.
Пример 2
Оба интерфейса не будут называться POJI, поскольку они наследуют специфический для технологии интерфейс.
POJO против Java Beans в Java
Как мы знаем, в Java POJO ссылается на простой старый объект Java. POJO и класс Bean в Java имеют некоторые общие черты, а именно:
Единственное различие между обоими классами состоит в том, что Java делает объекты Java-бинов сериализованными, чтобы в случае необходимости можно было сохранить состояние класса бинов. Поэтому из-за этого класс Java-бинов должен реализовывать интерфейс Serializable или Externalizable.
В связи с этим указывается, что все JavaBean-компоненты являются POJO, но не все POJO-объекты являются JavaBean-компонентами.
Пример класса Java Bean
Пример класса POJO
Средняя оценка / 5. Количество голосов:
Или поделись статьей
Видим, что вы не нашли ответ на свой вопрос.
Что такое pojo в java
POJO – это plain old Java object, простой Java-объект, не ограниченный какими-либо запретами, специфичными для того или иного фреймворка (за исключением спецификации самой Java, разумеется) и пригодный для использования в любой среде.
POJO используются для универсальной и наглядной сериализации и десериализации данных, так что основное их назначение в тестировании с RestAssured – это обработка Json в теле запросов и ответов.
Они позволяют достаточно гибко настраивать содержимое Json-объектов, отправляемых в теле запросов – например можно использовать один POJO-класс для составления Json-объектов с разным набором значений, избежав при этом многократного повторения одного и того же кода, или легко создавать Json-объекты с многоуровневыми вложениями, сохраняя при этом простую и наглядную структуру.
При обработке входящих ответов POJO позволяют извлекать любые необходимые значения для дальнейшего использования, а также дают (как уже было сказано выше – простой и наглядный) доступ к вложенным значениям.
Как их создать и как с ними работать? #
Конструктор, как и любой другой метод, можно перегружать. Таким образом можно определить несколько допустимых наборов параметров при создании экземпляра класса. Например, следующие конструкторы позволят создать только книгу без названия и автора или книгу с названием и автором, но не с чем-то одним:
Впрочем, ничто не мешает нам создать книгу пустым конструктором, а затем назначить ей только один параметр с помощью сеттера.
Создание экземпляра класса Book происходит следующим образом:
Использование на практике #
Для демонстрации работы POJO будет использован API Restful Booker, с его документацией можно ознакомиться здесь: https://restful-booker.herokuapp.com/apidoc/index.html
И в исходящих запросах, и во входящих ответах в этом API используется json-объект следующего вида:
Для того чтобы описать этот json, нам нужно создать класс Booking, в котором мы объявим все необходимые переменные, таким же образом, как в приведенном выше примере.
Вы можете заметить, что поле bookingdates содержит в себе два вложенных значения, и у нас нет готового типа данных, который можно было бы присвоить соответствующей ему переменной. Это проблема решается крайне просто: нам всего лишь необходимо создать класс BookingDates:
Теперь у нас есть тип данных, подходящий для поля bookingdates, так что у нас есть все необходимое, чтобы создать класс Booking.
Точно таким же образом можно описывать и более сложные многоуровневые вложения.
Так как все переменные в обоих классах приватные, а нам понадобится доступ к хранящимся в них значениям, напишем для каждой из них Getter:
На этом подготовка POJO заканчивается, и мы можем переходить непосредственно к сериализации и десериализации.
Cериализация #
В качестве примера сериализации с помощью POJO мы сформируем json-объект, который необходимо отправить в POST-запросе на эндпойнт /booking для создания новой брони.
Для этого создадим экземпляры классов Booking и BookingDates со всеми необходимыми для формирования Json-объекта данными:
Rest Assured прекрасно умеет преобразовывать POJO в Json, так что никаких дополнительных манипуляций над созданным объектом нам не потребуется. Все, что нужно сделать после этого – поместить созданный объект booking в тело нашего запроса:
Таким образом мы отправляем запрос со следующим содержанием:
Десериализация #
Для изучения работы десериализации с помощью POJO мы создадим такую же бронь, как до этого, десериализуем ответ от API, извлечем значение bookingid, а затем запросим данные о брони с этим bookingid и сравним из с отправленным json-объектом.
Для начала посмотрим на то, как выглядит ответ на отправленный нами запрос о создании новой брони:
Как мы видим, структура json стала чуть сложнее и к ней добавился еще один уровень. По аналогии с предыдущими классами, создадим класс BookingInfo:
Также добавляем в уже существующие классы пустые конструкторы:
Теперь мы можем сохранить ответ на POST-запрос в переменную, одновременно с этим десериализовав его:
Как видите, процесс десериализации практически идентичен сериализации – Rest Assured можно преобразовать Json в POJO без каких-либо дополнительных действий и библиотек.
Теперь у нас есть экземпляр класса BookingInfo, который содержит в себе всю полученную информацию. Чтобы проверить, что данные действительно сохранились, используем полученный bookingid, чтобы получить информацию о созданной нами брони:
В ответе мы получили верные данные, но чтобы не полагаться на визуальную проверку, сравним полученный Json с тем, который мы создали при формировании POST-запроса.
Самый простой способ это сделать – это привести POJO к строке. Для этого перепишем метод toString() в Booking и BookingDates следующим образом:
А затем сравним полученные строки:
Полезные библиотеки #
Геттеры и сеттеры занимают довольно много места – особенно в POJO с большим количеством переменных, – не привнося с собой никакой полезной информации. Библиотека Lombok позволяет заменить методы для геттеров и сеттеров аннотацией.
@JsonInclude #
Например, аннотация @JsonInclude(JsonInclude.Include.NON_NULL) для всего POJO позволяет использовать один класс для нескольких вариантов json-схем. Для этого нужно просто передать null в тех параметрах, которые не нужны для конкретной схемы, и они будут исключены из финального json.
@JsonProperty #
Аннотация @JsonProperty позволяет указать, к какому параметру относится геттер или сеттер в том случае, когда по какой-то причине необходимо использовать метод с нестандартным именем:
@JsonAlias #
@JsonAlias позволяет сохранять параметры с разными вариантами написания в одну переменную.
В данном случае в переменную firstname может быть записано значение с любым из трех указанных выше ключей: firstname, firstName и name.
Аннотация @JsonAlias отлично помогает справляться с не консистентными json-схемами, в которых одни и те же значения записаны под разными ключами.
@JsonIgnoreProperties и @JsonIgnore #
Обе эти аннотации указывают на переменные, которые должны быть проигнорированы при сериализации или десериализации.
@JsonIgnoreProperties используется для всего класса:
@JsonIgnore используется над переменной, которую необходимо исключить:
hasProperty #
Метод hasProperty() позволяет проверить, есть ли в экземпляре класса указанный параметр:
samePropertyValuesAs #
Метод samePropertyValuesAs() позволяет сравнить два экземпляра одного или разных классов.
Однако стоит отметить, что этот метод корректно работает только с простыми POJO без вложенных классов.
Увидел(а) ошибку в тексте? Нет нужной информации или она не полная?
Скорей же исправь данный недочет и облегчи жизнь себе и своей команде!
Обязательно ознакомься с тем как заполнить bugаж знаний и после создавай МР в проекте bugаж знаний на своего QA Team Lead.
Урок 9. Создание POJO объекта User. Работа с View из java кода
Видео версия урока
Создание View объектов в java коде. Связывание их с xml объектами
Зачем нам это необходимо? На этапе создания layout файла мы можем не обращаться к java коду вообще. Но в обычном приложении все данные поступают в layout динамически из java кода. Поэтому давайте создадим метод displayUserInfo() и там просто присвоим нашим View какое-то временное содержимое. Этот методм нам нужно будет вызывать всякий раз, когда мы захотим обновить информацию на нашем экране:
Добавление POJO объекта User.
Единственное, что нам осталось сделать – это добавить объект, который будет представлять все данные, которыми обладает пользователь. В нашем случае нам нужны следующие поля:
Назовём наш пакет pojo :
Видим, что у нас создался класс и мы можем добавлять в него свой код:
Отлично, давайте добавим поля, которые мы перечислили:
Поэтому, чтобы установить значения полям, мы создадим конструктор.
После этого необходимо выбрать поля, которые мы хотим получать в конструкторе. В нашем случае – это все поля, поэтому выбираем все:
В появившемся окне нажимаем OK и видим, что конструктор сгенерировался автоматически.
Также (т.к. поля у нас private ) нам необходимо создать getter методы для всех полей. Давайте тоже сделаем это автоматически.
По аналогии с генерацией конструктора:
Наш класс теперь выглядит так:
Таким образом, у нас сгенерировались эти два метода:
Если вы не переопределите эти два методы, то объекты будут сравниваться по ссылке, иначе по тому алгоритму, который описан в этих методах.
Использование POJO User в UserInfoActivity
Видим, что в этом методе мы просто возвращаем в этом объекте все те же самые значения, которые мы использовали до этого.
Также нам надо немного изменить метод отображения данных пользователя. Надо добавить объект User как входной параметр и отображать данные из его полей:
Итоговый код нашей UserInfoActivity :
Запустим приложение и увидим, что все поля объекта успешно отобразились:
