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

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

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

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

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

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

Определение

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

Расширьте заранее заданные классы, как в
```
public class Foo extends javax.servlet.http.HttpServlet { ...
```
Реализуйте заранее заданные интерфейсы, как в
```
public class Bar implements javax.ejb.EntityBean { ...
```
Содержит заранее заданные аннотации , как в
```
@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 фокусируется исключительно на бизнес-логике и не зависит от (корпоративных) инфраструктур. Затем структуры аспектно-ориентированного программирования (АОП) прозрачно добавляют сквозные проблемы, такие как сохранение, транзакции, безопасность и т. д. ^[6]

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. ^[7]

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

@Stateless
public class HelloWorldService {

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

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

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

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

Простой старый интерфейс Java (POJI) — это базовая форма интерфейса Java , приемлемая в тех случаях, когда более сложные интерфейсы Java не разрешены. ^[8]^{: 57, 572, 576, 579, 1340}

См. также

Ссылки

^ Перейти обратно: ^а ^б «МФ Блики: ПОДЖО» . Мартин Фаулер.com .
^ Альмаер, Дион (17 июля 2006 г.). «Возвращение POJO: обычный старый JavaScript» . Аяксиан . Архивировано из оригинала 13 сентября 2014 г. Проверено 19 августа 2014 г.
^ «Поддержка POCO» . microsoft.com . Проверено 27 мая 2012 г.
^ Кнешке, Ян (19 февраля 2007 г.). «типобезопасные объекты в PHP» . kneschke.de . Архивировано из оригинала 26 марта 2012 г. Проверено 27 мая 2012 г.
^ Чеонг, Джим (26 июня 2011 г.). «Контроллер с простым старым объектом PHP, также известным как POPO» . jym.sg . Архивировано из оригинала 26 марта 2012 г. Проверено 27 мая 2012 г.
^ Перейти обратно: ^а ^б Мартин, Роберт С; (2008); Чистый код , Глава 11, Платформы AOP на чистом Java
^ Панда, Дебу; Рахман, Реза; Лейн, Дерек; (2007). EJB 3 в действии , Manning Publications Co., Шелтер-Айленд (Нью-Йорк), ISBN 978-1-93-398834-4 (www.manning.com/books/ejb-3-in-action). Глава 11. Дескрипторы развертывания и аннотации
^ Вали, Ули; Гребешок, Майкл; Гомес, кузнец Лопес; Хейни, Брайан; Мохаррам, Ахмед; Неаполь, ДжонПол; Рор, Марк; Кюи, Генри; Ган, Патрик; Гонсалес, Селсо; Угурлу, Пинар; Зиози, Лара (29 июня 2009 г.). Руководство по программированию Rational Application Developer V7.5 . Красные книги IBM. ISBN 978-0738432892 .

[bliki-1] Перейти обратно: ^а ^б «МФ Блики: ПОДЖО» . Мартин Фаулер.com .

[2] Альмаер, Дион (17 июля 2006 г.). «Возвращение POJO: обычный старый JavaScript» . Аяксиан . Архивировано из оригинала 13 сентября 2014 г. Проверено 19 августа 2014 г.

[3] «Поддержка POCO» . microsoft.com . Проверено 27 мая 2012 г.

[4] Кнешке, Ян (19 февраля 2007 г.). «типобезопасные объекты в PHP» . kneschke.de . Архивировано из оригинала 26 марта 2012 г. Проверено 27 мая 2012 г.

[5] Чеонг, Джим (26 июня 2011 г.). «Контроллер с простым старым объектом PHP, также известным как POPO» . jym.sg . Архивировано из оригинала 26 марта 2012 г. Проверено 27 мая 2012 г.

[Martin2008-6] Перейти обратно: ^а ^б Мартин, Роберт С; (2008); Чистый код , Глава 11, Платформы AOP на чистом Java

[7] Панда, Дебу; Рахман, Реза; Лейн, Дерек; (2007). EJB 3 в действии , Manning Publications Co., Шелтер-Айленд (Нью-Йорк), ISBN 978-1-93-398834-4 (www.manning.com/books/ejb-3-in-action). Глава 11. Дескрипторы развертывания и аннотации

[RAD-8] Вали, Ули; Гребешок, Майкл; Гомес, кузнец Лопес; Хейни, Брайан; Мохаррам, Ахмед; Неаполь, ДжонПол; Рор, Марк; Кюи, Генри; Ган, Патрик; Гонсалес, Селсо; Угурлу, Пинар; Зиози, Лара (29 июня 2009 г.). Руководство по программированию Rational Application Developer V7.5 . Красные книги IBM. ISBN 978-0738432892 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]