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

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

«Мы задавались вопросом, почему люди так против использования обычных объектов в своих системах, и пришли к выводу, что это потому, что простым объектам не хватает причудливого имени. Поэтому мы дали им одно имя, и оно очень хорошо прижилось».

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

Этот термин продолжает шаблон аббревиатуры для создания ретронимов для конструкций, которые не используют новые необычные функции:

• «Обычный старый объект JavaScript» в JavaScript
• «Обычный старый объект Ruby» (PORO) в Ruby
• «Обычная старая документация» (pod) в Perl
• Обычный старый объект CLR (POCO) в .NET Framework
• «Обычный старый объект PHP» (POPO) на PHP
• Обычная старая телефонная служба (POTS) в телефонии

Определение

В идеале POJO — это объект Java, не связанный никакими ограничениями, кроме тех, которые наложены Спецификацией языка Java; т.е. POJO не должен этого делать

1. Расширьте заранее заданные классы, как в

   public class Foo extends javax.servlet.http.HttpServlet { ...
   

2. Реализуйте заранее заданные интерфейсы, как в

   public class Bar implements javax.ejb.EntityBean { ...
   

3. Содержит заранее заданные аннотации , как в

   @javax.persistence.Entity public class Baz { ...
   

Однако из-за технических трудностей и других причин многие программные продукты или платформы, описанные как POJO-совместимые, на самом деле по-прежнему требуют использования заранее определенных аннотаций для правильной работы таких функций, как постоянство. Идея состоит в том, что если объект (фактически класс) был POJO до того, как были добавлены какие-либо аннотации, и вернулся бы в состояние POJO, если аннотации были удалены, то его все равно можно считать POJO. Тогда базовый объект остается POJO, поскольку он не имеет особых характеристик (таких как реализованный интерфейс), которые делают его «специализированным объектом Java» (SJO или (sic) SoJO).

Контекстуальные вариации

JavaBeans

JavaBean — это POJO , который является сериализуемым без аргументов , имеет конструктор и обеспечивает доступ к свойствам с помощью методов получения и установки , которые следуют простому соглашению об именах. Благодаря этому соглашению на свойства произвольных JavaBeans можно делать простые декларативные ссылки. Код, использующий такую ​​декларативную ссылку, не должен ничего знать о типе компонента, и компонент можно использовать со многими платформами, причем этим платформам не обязательно знать точный тип компонента. Спецификация JavaBeans, если она полностью реализована, немного нарушает модель POJO, поскольку класс должен реализовывать интерфейс Serializable , чтобы быть настоящим JavaBean. Многие POJO-классы, которые до сих пор называются JavaBeans, не отвечают этому требованию. Поскольку Serializable представляет собой маркерный (без методов) интерфейс, это не составляет большого труда.

Ниже показан пример компонента JavaServer Faces (JSF), имеющего двунаправленную привязку к свойству POJO:

<h:inputText value="#{MyBean.someProperty}"/>

Определение POJO может быть следующим:

public class MyBean {

    private String someProperty;

    public String getSomeProperty() {
         return someProperty;
    }

    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
}

Из-за соглашений об именах JavaBean единственная ссылка "someProperty" может быть автоматически преобразована в метод "getSomeProperty()" (или "isSomeProperty()", если свойство имеет логический тип ) для получения значения, а также в метод "setSomeProperty( String)" для установки значения.

Прозрачное добавление услуг

Поскольку проекты, использующие POJO, стали использоваться все чаще, возникли системы, которые предоставляют POJO полную функциональность, используемую в платформах, и больший выбор в отношении того, какие области функциональности действительно необходимы. В этой модели программист создает не что иное, как POJO. Этот POJO фокусируется исключительно на бизнес-логике и не зависит от (корпоративных) инфраструктур. Затем структуры аспектно-ориентированного программирования (АОП) прозрачно добавляют сквозные проблемы, такие как сохранение, транзакции, безопасность и т. д.

Spring стал ранней реализацией этой идеи и одной из движущих сил популяризации этой модели.

Пример EJB-компонента, являющегося POJO:

• Корпоративные JavaBeans (EJB),
• Java Persistence API (JPA) (включая Hibernate )
• CDI (внедрение контекстов и зависимостей для платформы Java EE)

Ниже показан полнофункциональный компонент EJB, демонстрирующий, как EJB3 использует модель POJO:

public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

Как известно, компоненту не требуется расширять какой-либо класс EJB или реализовывать какой-либо интерфейс EJB, а также не требуется содержать какие-либо аннотации EJB. Вместо этого программист объявляет во внешнем XML- файле, какие службы EJB следует добавить в компонент:

<enterprise-beans>
    <session>
        <ejb-name>helloWorld</ejb-name>
        <ejb-class>com.example.HelloWorldService</ejb-class>
        <session-type>stateless</session-type>
    </session>
</enterprise-beans>

На практике некоторые люди находят аннотации элегантными, тогда как XML они считают многословным, уродливым и сложным в обслуживании, а другие считают, что аннотации загрязняют модель POJO.

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

@Stateless
public class HelloWorldService {

    public String sayHello() {
        return "Hello, world!";
    }
}

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

Связанные сокращения

Обычный старый интерфейс Java

Простой старый интерфейс Java (POJI) — это базовая форма интерфейса Java , приемлемая в тех случаях, когда более сложные интерфейсы Java не разрешены.

См. также

• Объект передачи данных (DTO)
• Анемичная доменная модель
• ПОЦЕЛУЙ принцип