Что означает термин Plain Old Java Object (POJO)?

Что означает термин Plain Old Java Object (POJO)? Я не мог найти ничего объяснительного.

POJO Wikipedia page говорит, что POJO - это обычный Java-объект, а не специальный объект. Теперь, что делает или что не делает и объект особенный в Java?

На приведенной выше странице также говорится, что POJO не должен распространять заданные классы, реализовывать заданные интерфейсы или содержать предварительно определенные аннотации. Означает ли это также, что POJO не имеют возможности реализовать интерфейсы, такие как Serializable, Comparable или такие классы, как апплеты или любые другие пользовательские классы/интерфейсы?

Кроме того, делает ли вышеуказанная политика (без расширения, без реализации), что нам не разрешено использовать какие-либо внешние библиотеки?

Где именно используются POJO?

EDIT: Чтобы быть более конкретным, мне разрешено расширять/внедрять классы/интерфейсы, которые являются частью Java или любых внешних библиотек?

ОТВЕТЫ

Ответ 1

Обычный старый объект Java Это имя используется для того, чтобы подчеркнуть, что данный объект является обычным Java-объектом, а не специальным объектом, таким как те, которые определены каркасом EJB 2.

класс A {}
класс B расширяет/реализует C {}

Примечание: B не является POJO, когда C является видом распределенного класса framework или ifc. например javax.servlet.http.HttpServlet, javax.ejb.EntityBean или J2EE extn и не является сериализуемым/сопоставимым. Поскольку сериализуемые/сопоставимые действительны для POJO.

Здесь A - простой объект, который является независимым. B является специальным obj, так как B расширяет/реализует C. Таким образом, объект B получает некоторое значение из C и B, ограничивает выполнение правил из C. и B является плотно связанным с распределенной структурой. Следовательно, объект B не является POJO из его определения.

Код с помощью ссылки на объект класса Object не должен знать ничего о его типе и может использоваться со многими фреймами.

Таким образом, POJO не должен: 1) расширять заданные классы и 2) реализовывать заданные интерфейсы.

JavaBean - это пример POJO, который является сериализуемым, имеет конструктор без аргументов и позволяет получить доступ к свойствам с использованием методов getter и setter, которые следуют простому соглашению об именах.

POJO исключительно фокусируется на бизнес-логике и не имеет зависимости от (корпоративных) фреймворков. Это означает, что у него есть код для бизнес-логики, но как создается этот экземпляр, к какому сервису (EJB..) принадлежит этот объект и каковы его особые характеристики (Stateful/Stateless), который он принимает, будут решены с помощью внешних xml файл.

Пример 1: JAXB - это служба, представляющая объект Java как XML; Эти java-объекты просты и выходят с помощью конструкторов-устроителей и сеттеров по умолчанию.

Пример 2: Hibernate, где для представления таблицы будет использоваться простой класс java. столбцы будут его экземплярами.

Пример 3: службы REST. В службах REST мы будем иметь уровень обслуживания и уровень Dao для выполнения некоторых операций над БД. Поэтому у Dao будут конкретные запросы и операции с поставщиками. Уровень обслуживания будет отвечать за вызов, который должен выполнять DAO для выполнения операций БД. Создание или обновление API (методов) DAO будет принимать POJO в качестве аргументов и обновлять POJO и вставлять/обновлять в DB. Эти POJO (класс Java) будут иметь только состояния (переменные экземпляра) каждого столбца и его геттеры и сеттеры.

На практике некоторые люди находят аннотации элегантными, в то время как они рассматривают XML как многословные, уродливые и трудноподдерживаемые, а другие - аннотации, которые загрязняют модель POJO. Таким образом, в качестве альтернативы XML многие фреймворки (например, Spring, EJB и JPA) позволяют использовать аннотации вместо или в дополнение к XML:

Преимущества:
Развязка кода приложения из инфраструктурных инфраструктур является одним из многих преимуществ использования POJO. Использование POJO в будущем подтвердит вашу бизнес-логику приложения, отделив ее от изменчивых, постоянно меняющихся инфраструктурных инфраструктур. Переход на новую версию или переход на другую структуру становится проще и менее рискованно. POJO также упрощают тестирование, что упрощает и ускоряет разработку. Ваша бизнес-логика будет более понятной и простой, поскольку она не будет запутана с кодом инфраструктуры

Ссылки: wiki source2

Ответ 2

По словам Мартина Фаулера, он и некоторые другие придумали это как способ описать что-то, что было стандартным классом, в отличие от EJB и т.д.

Ответ 3

Использование термина подразумевает то, что он должен вам сказать. Если, например, инфраструктура внедрения зависимостей говорит вам, что вы можете вводить POJO в любое другое ПОЖО, они хотят сказать, что вам не нужно ничего особенного: нет необходимости выполнять какие-либо контракты с вашим объектом, реализовывать любые интерфейсы или расширить специальные классы. Вы можете просто использовать то, что у вас уже есть.

ОБНОВЛЕНИЕ. Чтобы привести еще один пример: в то время как Hibernate может сопоставить любое POJO (любой созданный объект) с таблицами SQL, в Core Data (Objective C на iPhone) ваши объекты должны расширять NSManagedObject в порядке чтобы система могла сохранять их в базе данных. В этом смысле Core Data не может работать с любым POJO (или, скорее, POOCO = PlainOldObjectiveCObject), в то время как Hibernate может. (Я не мог бы на 100% правильно восстановить основные данные, так как я только начал его подбирать. Любые подсказки/исправления приветствуются:-)).

Ответ 4

Обычный старый объект Java:)

Ну, ты говоришь, что все это ужасные ограничения.

В обычном контексте, где используется POJO, это больше похоже на преимущество:

Это означает, что любая библиотека /API, с которой вы работаете, отлично согласна работать с объектами Java, которые каким-либо образом не были обработаны или обработаны каким-либо образом, то есть вам не нужно делать ничего особенного, чтобы заставить их работать.

Например, XStream XML-процессор будет (я думаю) счастливо сериализовать Java-классы, которые не реализуют интерфейс Serializable. Это плюс! Многие продукты, которые работают с объектами данных, используются для принудительного внедрения SomeProprietaryDataObject или даже расширения класса AbstractProprietaryDataObject. Многие библиотеки ожидают поведения bean, т.е. Получателей и сеттеров.

Как правило, все, что работает с POJO, также будет работать с не-так-PO-JO. Таким образом, XStream, конечно же, также сериализует классы Serializable.

Ответ 5

POJO - простой обычный Java-объект - по сравнению с чем-то, что требуется для Enterprise Edition (J2EE) (beans и т.д.).

POJO на самом деле не является жестким определением и более ручным способом описания "нормальных" не-корпоративных объектов Java. Независимо от того, использует ли внешняя библиотека или инфраструктура объект POJO или нет, это выглядит в глазах наблюдателя, в значительной степени зависящим от библиотеки/структуры WHAT, хотя я бы рискнул предположить, что структура сделает что-то меньшее из POJO

Ответ 6

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

Если библиотека поддерживает POJO, это означает, что объект любого класса допустим. Это не означает, что POJO не может иметь аннотации/интерфейс или что они не будут использоваться, если они есть, но это не является обязательным требованием.

IMHO Вики-страница достаточно ясна. Он не говорит, что POJO не может иметь аннотации/интерфейсы.

Ответ 7

Обычный старый объект Java (POJO), содержащий всю бизнес-логику для вашего расширения.

Exp. Pojo, который содержит единственный метод

public class Extension {
   public static void logInfo(String message) {
      System.out.println(message);
   }
}

Ответ 8

Что означает термин Plain Old Java Object (POJO)?

POJO был придуман Мартином Фаулером, Ребеккой Парсонс и Джошем Маккензи, когда они готовились к разговору на конференции в сентябре 2000 года. Мартин Фаулер в Шаблоны предприятия Архитектура приложений объясняет, как реализовать шаблон модели домена в Java. После перечисления некоторых недостатков использования EJB Entity Beans:

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

Entity beans наиболее полезны при использовании управляемых контейнеров Стойкость (CMP)...

Объект beans не может быть повторно включен. То есть, если вы вызываете из одного entity bean в другой объект, этот другой объект (или любой объект звонки) не могут перезвонить в первый объект bean...

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

Для запуска с сущностью beans вам нужен контейнер и база данных связанный. Это увеличит время сборки, а также увеличит время выполнять тестовые прогоны, поскольку тесты должны выполняться в отношении базы данных. Сущность beans также сложна для отладки.

В качестве альтернативы он предложил использовать регулярные объекты Java для реализации модели домена:

Альтернативой является использование обычных объектов Java, хотя это часто вызывает удивленную реакцию - удивительно, как много людей думают, что вы не можете запускать обычные объекты Java в контейнере EJB. Я пришел вывод о том, что люди забывают о обычных объектах Java, потому что у них нет причудливого имени. Вот почему, готовясь к разговору в 2000 году Ребекка Парсонс, Джош Маккензи, и я дал им один: POJO (простые старые объекты Java). Доменную модель POJO легко собрать, быстро создается, может запускаться и тестироваться вне контейнера EJB, и независимо от EJB (возможно, почему поставщики EJB не поощряют вас использовать их).