Pojo java что это

Pojo java что это

POJO classes

POJO stands for Plain Old Java Object. It is an ordinary Java object, not bound by any special restriction other than those forced by the Java Language Specification and not requiring any classpath. POJOs are used for increasing the readability and re-usability of a program. POJOs have gained the most acceptance because they are easy to write and understand. They were introduced in EJB 3.0 by Sun microsystems.

A POJO should not:

1. Extend prespecified classes, Ex: public class GFG extends javax.servlet.http.HttpServlet < … >is not a POJO class.
2. Implement prespecified interfaces, Ex: public class Bar implements javax.ejb.EntityBean < … >is not a POJO class.
3. Contain prespecified annotations, Ex: @javax.persistence.Entity public class Baz < … >is not a POJO class.

POJOs basically define an entity. Like in your program, if you want an Employee class, then you can create a POJO as follows:

The above example is a well-defined example of the POJO class. As you can see, there is no restriction on access-modifiers of fields. They can be private, default, protected, or public. It is also not necessary to include any constructor in it.
POJO is an object which encapsulates Business Logic. The following image shows a working example of the POJO class. Controllers interact with your business logic which in turn interact with POJO to access the database. In this example, a database entity is represented by POJO. This POJO has the same members as the database entity.

Java Beans

Beans are special type of Pojos. There are some restrictions on POJO to be a bean.

1. All JavaBeans are POJOs but not all POJOs are JavaBeans.
2. Serializable i.e. they should implement Serializable interface. Still, some POJOs who don’t implement a Serializable interface are called POJOs because Serializable is a marker interface and therefore not of many burdens.
3. Fields should be private. This is to provide complete control on fields.
4. Fields should have getters or setters or both.
5. A no-arg constructor should be there in a bean.
6. Fields are accessed only by constructor or getter setters.

Getters and Setters have some special names depending on field name. For example, if field name is someProperty then its getter preferably will be:

and setter will be

Visibility of getters and setters is generally public. Getters and setters provide the complete restriction on fields. e.g. consider below the property,

If you set visibility of age to the public, then any object can use this. Suppose you want that age can’t be 0. In that case, you can’t have control. Any object can set it 0. But by using the setter method, you have control. You can have a condition in your setter method. Similarly, for the getter method if you want that if your age is 0 then it should return null, you can achieve this by using the getter method as in the following example:

Урок 9. Создание POJO объекта User. Работа с View из java кода

Создание View объектов в java коде. Связывание их с xml объектами

Первое, что нам надо сделать сегодня – это создать все наши View -компоненты в java коде и связать их с элементами в layout файле. Для этого в Activity нам необходимо для каждого View -компонента вызвать метод findViewById(int id) (рус. найти элемент по идентификатору), на вход которому необходимо передать идентификатор (id) элемента, который прописан нами в xml -файле. Выглядит это так:

Зачем нам это необходимо? На этапе создания layout файла мы можем не обращаться к java коду вообще. Но в обычном приложении все данные поступают в layout динамически из java кода. Поэтому давайте создадим метод displayUserInfo() и там просто присвоим нашим View какое-то временное содержимое. Этот методм нам нужно будет вызывать всякий раз, когда мы захотим обновить информацию на нашем экране:

Мы используем обычный метод setText() , чтобы установить какой-то текст в наши TextView . Этот код уже больше похож на реальный, потому что именно так мы и будем устанавливать данные в наши View , когда получим ответ от сервера.

Добавление POJO объекта User.

Простые объекты в java называют POJO . POJO (англ. Plain Old Java Object) — «старый добрый Java-объект», простой Java-объект, не унаследованный от какого-то специфического объекта и не реализующий никаких служебных интерфейсов сверх тех, которые нужны для бизнес-модели.

Объекты нужны для того, чтобы хранить информацию в удобном для нас виде. Т.е. когда у себя в коде мы представляем данные в виде объектов реального мира. Есть пользователь User , у которого есть имя (поле name ) и т.д.

Единственное, что нам осталось сделать – это добавить объект, который будет представлять все данные, которыми обладает пользователь. В нашем случае нам нужны следующие поля:

• Идентификатор пользователя id
• Ссылка на фотографию imageUrl
• Имя пользователя name
• Ник пользователя nick
• Описание пользователя description
• Местоположение пользователя location
• Количество тех, кого читает пользователь followingCount
• Количество тех, кто читает пользователя followersCount

Давайте создадим новый файл User.java . Только давайте перед этим создадим новый пакет, где будем хранить все сущности нашего приложения. Для этого нажмите правой кнопкой по пакету (папке) colibri.dev.com.colibritweet и выберите New -> Package :

Назовём наш пакет pojo :

Затем создадим новый класс. Для этого нажмите правой кнопкой по пакету pojo и выберете New -> JavaClass . Введите имя User :

Видим, что у нас создался класс и мы можем добавлять в него свой код:

Отлично, давайте добавим поля, которые мы перечислили:

По умолчанию в сущностях используем модификатор доступа private , для того, чтобы не нарушать инкапсуляцию класса, чтобы внешний код не имел прямого доступа к значению этих полей. Т.е. инкапсуляция – это просто приём сокрытия данных от внешнего вмешательства. Никто кроме класса User не получит доступ к его полям, если только в классе не будут объявлены соответствующие механизмы (например, конструктор, setter -методы, getter -методы).

Поэтому, чтобы установить значения полям, мы создадим конструктор.

Конструктор мы можем создавать либо вручную, либо использовать функции AndroidStudio , чтобы она сделала эту рутинную работу за нас. Для этого надо зажать клавиши Alt + Insert , выбрать из контекстного меню Constructor :

После этого необходимо выбрать поля, которые мы хотим получать в конструкторе. В нашем случае – это все поля, поэтому выбираем все:

В появившемся окне нажимаем OK и видим, что конструктор сгенерировался автоматически.

Также (т.к. поля у нас private ) нам необходимо создать getter методы для всех полей. Давайте тоже сделаем это автоматически.

По аналогии с генерацией конструктора:

• зажимаем клавиши Alt + Insert ,
• выбираем из контекстного меню Getter .
• выбираем все поля
• нажимаем OK .

Наш класс теперь выглядит так:

Мы можем работать с таким классом, но для POJO классов есть ключевое правило: всегда переопределять методы equals() и hashcode() . Если вы не знаете, зачем это нужно, то прервитесь и изучите эту статью.

Эти методы мы тоже сгенерируем автоматически. Для этого снова зажимаем клавиши Alt + Insert , выбираем equals() and hashcode() . После этого перед вами появится окно такого вида:

Здесь мы можем выбрать какой-то кастомный template для генерации методов, но пока будем пользоваться Intellij Default .

Нажимаем Next . После этого видим форму, в которой надо выбрать поля, которые будут включены в метод equals() . Выбираем все поля и нажимаем Next :

После этого видим форму, в которой надо выбрать поля, которые будут включены в метод hashcode() . Снова выбираем все поля и нажимаем Next :

В следующей форме нужно отметить, какие поля у нас всегда будут not null . Это необходимо для того, чтобы во время выполнения методов equals() и hashcode() приложение не сломалось с null pointer exception . В нашем случае у пользователя обязательно должны быть поля id , name , nick . Т.к. поле id является примитивом (типом long ), то оно не может быть null не при каких обстоятельствах. Поэтому мы выбираем поля name , nick :

Таким образом, у нас сгенерировались эти два метода:

Если вы не переопределите эти два методы, то объекты будут сравниваться по ссылке, иначе по тому алгоритму, который описан в этих методах.

Использование POJO User в UserInfoActivity

Теперь давайте добавим объект User в нашу Activity . Это необходимо, потому что от сервера мы получим именно такой объект. Т.е. на самом деле процесс получения данных пользователя делится на два действия:

• Получение данных(объекта User ) от источника данных (сервер, база данных, или заглушка для тестов).
• Отображение данных.

Давайте создадим метод getUser() , в котором пока будем возвращать тестовый объект. В будущем мы заменим этот метод на взаимодействие с реальным сервером.

Видим, что в этом методе мы просто возвращаем в этом объекте все те же самые значения, которые мы использовали до этого.

Также нам надо немного изменить метод отображения данных пользователя. Надо добавить объект User как входной параметр и отображать данные из его полей:

Здесь практически ничего не изменилось. Единственное, что поля followingCount и followersCount имеют тип int , а метод setText() принимает только String входным параметром. Поэтому нам нужно сделать явное приведение к типу String .

Добавим ещё один метод loadUserInfo() , который будет вызывать метод getUser() и передавать его результат в метод displayUserInfo(user) .

How to create a POJO?

Recently I’ve started hearing about «POJOs» (Plain Old Java Objects). I googled it, but still don’t understand the concept well. Can anyone give me a clear description of a POJO?

Consider a class «Person» with variables «id, name, address, salary» — how would I create a POJO for this scenario? Is the code below a POJO?

11 Answers 11

A POJO is just a plain, old Java Bean with the restrictions removed. Java Beans must meet the following requirements:

1. Default no-arg constructor
2. Follow the Bean convention of getFoo (or isFoo for booleans) and setFoo methods for a mutable attribute named foo; leave off the setFoo if foo is immutable.
3. Must implement java.io.Serializable

POJO does not mandate any of these. It’s just what the name says: an object that compiles under JDK can be considered a Plain Old Java Object. No app server, no base classes, no interfaces required to use.

The acronym POJO was a reaction against EJB 2.0, which required several interfaces, extended base classes, and lots of methods just to do simple things. Some people, Rod Johnson and Martin Fowler among them, rebelled against the complexity and sought a way to implement enterprise scale solutions without having to write EJBs.

Martin Fowler coined a new acronym.

Rod Johnson wrote «J2EE Without EJBs», wrote Spring, influenced EJB enough so version 3.1 looks a great deal like Spring and Hibernate, and got a sweet IPO from VMWare out of it.

Here’s an example that you can wrap your head around:

POJO:- POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification.

Properties of POJO

1. All properties must be public setter and getter methods
2. All instance variables should be private
3. Should not Extend prespecified classes.
4. Should not Implement prespecified interfaces.
5. Should not contain prespecified annotations.
6. It may not have any argument constructors

Example of POJO

From the wikipedia article I linked to:

In computing software, POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean

Your class appears to already be a POJO.

POJO class acts as a bean which is used to set and get the value.

When you aren’t doing anything to make your class particularly designed to work with a given framework, ORM, or other system that needs a special sort of class, you have a Plain Old Java Object, or POJO.

Ironically, one of the reasons for coining the term is that people were avoiding them in cases where they were sensible and some people concluded that this was because they didn’t have a fancy name. Ironic, because your question demonstrates that the approach worked.

Compare the older POD «Plain Old Data» to mean a C++ class that doesn’t do anything a C struct couldn’t do (more or less, non-virtual members that aren’t destructors or trivial constructors don’t stop it being considered POD), and the newer (and more directly comparable) POCO «Plain Old CLR Object» in .NET.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk, we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.

Generally, a POJO is not bound to any restriction and any Java object can be called a POJO but there are some directions. A well-defined POJO should follow below directions.

1. Each variable in a POJO should be declared as private.
2. Default constructor should be overridden with public accessibility.
3. Each variable should have its Setter-Getter method with public accessibility.
4. Generally POJO should override equals(), hashCode() and toString() methods of Object (but it’s not mandatory).
5. Overriding compare() method of Comparable interface used for sorting (Preferable but not mandatory).

And according to Java Language Specification, a POJO should not have to

1. Extend pre-specified classes
2. Implement pre-specified interfaces
3. Contain pre-specified annotations

However, developers and frameworks describe a POJO still requires the use prespecified annotations to implement features like persistence, declarative transaction management etc. So the idea is that if the object was a POJO before any annotations were added would return to POJO status if the annotations are removed then it can still be considered a POJO.

A JavaBean is a special kind of POJO that is Serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention.

Name already in use

Java-Interview-Questions / Terms / terms.md

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Описать простыми словами термины, встречающиеся при разработке web-приложений:

из браузера

• передаем HTTP-запрос , который попадает в

web (controller, view, ui) layer

• если — это REST-controller у которого есть внешнее API для сторонних приложений (внешних сервисов), то он принимает информацию снаружи через REST-запросы (по протоколу HTTP ). Переданный в слой запрос (с параметрами) обрабатывается, и результатом его работы являются какие-то сущности ( entities ). Далее, этот слой обращается к

service layer

• в котором находится и выполняется над сущностями некая бизнес-логика. Если по ходу выполнения бизнес-логики Сервисному слою нужны данные из базы данных (или иного места хранения), то для этого он задействует

dao (repository) layer

• который в свою очередь обращается в базу (или другие источники хранения данных). Данный слой работает с сущностями предметной области, т.е. сохраняет или достает из источника хранения данных entities , которые преобразуются в DTO (т.е. объекты, которые приближены по своей структуре к объектам бизнес-логики) и передаются вверх по цепочку слоев, попадая в итоге наружу (клиенту, отправившему запрос)

domain (model, entity) layer

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

Plain Old Java Object, старый добрый Java-объект — это объект, состоящий чаще всего из набора полей, их геттеров/сеттеров и без дополнительной нагрузки в виде:

Extend prespecified classes, as in

Implement prespecified interfaces, as in

Contain prespecified annotations, as in (хотя статья на сайте Спринга допускает наличие аннотаций для POJO-объектов )

Термин POJO возник в качестве ответной реакции на появление платформы J2EE и ее широко распространившееся внедрение в приложениях, из-за чего, в частности, усложнился весь процесс их разработки. Мартин Фаулер с коллегами придумали данный термин для описания класса, свободного от «немого» кода, который требовался лишь для корректной работы среды выполнения

POJO был представлен в качестве альтернативы для Enterprise JavaBeans (EJB) и других «тяжелых» enterprise-конструкций, которые были популярны в 2000-х годах (об этом можно почитать в статье Сергея Немчинского)

POJO — это класс, который не использует специальные возможности различных фреймворков (т.е. он не прибит гвоздями к архитектуре какой-либо библиотеки, а также не привязан к фреймворку, который его использует [вспомним Spring и поулыбаемся]), таких, как Spring , EJB и пр. Данные фреймворки появились позже и поэтому в названии присутствует слово «старый»

Пример:

Основной целью POJO было показать, что сущности могут быть успешно смоделированы без использования JavaBeans . Более того, JavaBeans вообще не должны быть использованы для этой цели

Таким образом, основной посыл POJO — упрощение классов-сущностей насколько, насколько это возможно для моделирования предметной области

Резюмируя все вышесказанное, можно сказать, что POJO — этот класс, который ничего не делает и имеет только состояние

не путать с Enterprise JavaBeans

это класс в языке Java, написанный по определённым правилам:

• должен быть сериализуемыми (реализовывать интерфейс java.io.Serializable )
• должен иметь конструктор без аргументов
• все поля JavaBean должны быть закрытыми (private)
• доступа к полям осуществляется через методы доступа getters (аксессоры) и setters (мутаторы)
• методы equals() , hashCode() и toString() должны быть переопределены

Пример:

«Сущности» — это классы, моделирующие объекты предметной области

По своей структуре они приближены к таблицам базы данных (типы и названия столбцов таблицы == типам и названиям полей в классе, взаимодействующему с конкретной таблицей)

Хранятся в domain слое

Сущности обладают неотъемлемой идентичностью, основанной на эквивалентности их id . Это значит, что если данные в двух сущностях полностью одинаковы (за исключением id поля), они не являются одной и той же сущностью

Сущности почти всегда изменяемы (мутабельны)

«Объект-значение» ⎼ термин из среды DDD ⎼ это объект без специальных методов, имеющий набор свойств (полей) примитивных типов данных или тоже Value object

Объекты данного рода проверяются на равенство исходя не из физической одинаковости (одинаковости ссылок на них), а из значений свойств

Примером VO является любой класс, который реализует равенство через равенство содержащихся в нем данных

В отличие от Entity не обладает идентичностью. На практике это означает, что объекты-значения не имеют поля-идентификатора: если два экземпляра одного объекта-значения обладают одинаковым набором атрибутов, то они равны

Объекты-значения должны быть неизменяемы (immutable). Это значит, что если требуется изменить такой объект, то для этого придется создать его новый экземпляр, вместо того чтобы изменять существующий

Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью

Чтобы распознать объект-значение, мысленно замените его на Integer

Объекты-значения не должны иметь собственной таблицы в базе данных

Пример: Integer , Money , Даты

Data Transfer Object, объект переноса данных ⎼ это паттерн, который предполагает использование отдельных классов для передачи данных (объектов без поведения) между слоями, c целью уменьшения количества запросов к базе данных

Данный класс, если его необходимо передавать по сети, должен быть сериализуемым (в XML , JSON и тд)

Это объект, который собирается из низкоуровневых данных ( entities ), а затем используется на слое service и controller . Те, при обращении к Repository из service , последний получает entity (набор табличных записей, которые возвращаются в результате выполнения SQL-запроса ), преобразует его в DTO и отдает на слой web .

DTO можно рассматривать как хранилище информации, единственная цель которого — передать данные получателю

Примером DTO является любой класс, который содержит только поля и методы по извлечению этих данных

DTO может собираться (состоять) из нескольких entity , взятых из базы данных

Data Access Object, объект доступа к данным — абстрактный интерфейс к какому-либо типу базы данных или иному механизму хранения

Описание проблемы

Способ доступа к данным бывает разным и зависит от источника данных. Способ доступа к базе данных зависит от типа хранилища (реляционные базы данных, объектно-ориентированные базы данных, однородные или «плоские» файлы и т.д.). Унифицированный API для доступа к этим несовместимым системам отсутствует. А использование конкретного способа доступа создает зависимость между кодом приложения и кодом доступа к данным

Такая зависимость кода может сделать миграцию приложения от одного типа источника данных к другому трудной и громоздкой

Для доступа к данным хотелось бы использовать какой-либо универсальный способ (паттерн), позволяющий скрыть процесс их получения

Для решения вышеперечисленной проблемы обычно используют паттерн DAO

Описание паттерна

Данный паттерн абстрагирует и инкапсулирует доступ к источнику данных, а также управляет соединением с ним для получения и записи данных

В самом широком смысле, DAO — это класс, содержащий CRUD-методы для конкретной сущности

DAO полностью скрывает от клиента детали реализации взаимодействия с хранилищем данных. Поскольку при изменениях источника данных представляемый DAO интерфейс не изменяется, этот паттерн дает возможность DAO принимать различные схемы хранилищ без влияния на клиента или бизнес-компоненты. По существу, DAO выполняет функцию адаптера между компонентом и источником данных

Шаблон DAO используется для связи программы, написанной на Java с реляционными базами данных через интерфейс JDBC

JDBC API позволяет в приложениях использовать SQL-команды, являющиеся стандартным средством доступа к таблицам

Также DAO — это промежуточный слой, который скрывает от клиента реализацию взаимодействия с разными хранилищами данных, способы и механизмы хранения, предлагая при этом единые требования по функционалу в виде интерфейса

Паттерн DAO позволяет:

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

Проблемы DAO

Большая часть людей представляет DAO некими вратами к базам данных, беспрепятственно добавляя в него множество методов для доступа к базе. Поэтому нередко можно увидеть слишком раздутое DAO c большим количеством методов на все случаи жизни

Чтобы уйти от этого, предлагается использовать паттерн Repository

«Хранилище» ⎼ паттерн, выполняющий роль коллекции объектов из domain layer в оперативной памяти

Хранилище позволяет добавлять или удалять объекты, как будто мы работаем с обычными коллекциями

Тот факт, что объект из domain layer на самом деле не находятся в хранилище, полностью скрыт от клиентских программ. Для них ⎼ это выглядит, как коллекция в памяти

Данный слой используется в Spring Data JPA

• DAO ⎼ это низкоуровневый слой, который работает с объектами базы
• Repository ⎼ работает с объектами DTO
• Если Entity не переводятся в DTO , то два этих слоя сливаются, выполняя в итоге одну и туже функцию, т.е. Repository становится DAO

REpresentational State Transfer, передача состояния представления

REST определяет набор операций, которые, например User может выполнять над Meals

REST-Controller — способ общения с внешними приложениями через установленный набор методов, за которые они могли бы дёргать наше приложение