Обычный старый объект Java - Plain old Java object

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

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

Термин «POJO» первоначально обозначал объект Java, который не следует ни одной из основных объектных моделей Java, соглашений или структур; в настоящее время "POJO" может использоваться как аббревиатура для простой старый объект JavaScript также, и в этом случае термин обозначает JavaScript объект аналогичной родословной.[2]

Этот термин продолжает шаблон старых терминов для технологий, которые не используют новые причудливые функции, такие как простой старый объект Ruby (ПОРО) в Рубин, старая добрая телефонная служба (POTS) в телефония и Обычная старая документация (стручок) в Perl. Эквивалент POJO на .NET Framework является простой Старый объект CLR (POCO).[3] За PHP, это простой старый объект PHP (ПОПО).[4][5]

Феномен POJO, скорее всего, получил широкое признание из-за необходимости общего и легко понимаемого термина, который контрастирует со сложными объектными структурами.[нужна цитата ]

Определение

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

  1. Расширить заранее определенные классы, как в
    общественный класс Фу расширяет javax.сервлет.http.HttpServlet { ...
  2. Реализуйте заранее определенные интерфейсы, как в
    общественный класс Бар орудия javax.ejb.EntityBean { ...
  3. Содержать заранее аннотации, как в
    @ javax.persistence.Entity общественный класс Баз { ...

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

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

JavaBeans

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

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

<ч: inputText значение ="# {MyBean.someProperty}"/>

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

общественный класс MyBean {    частный Строка someProperty;    общественный Строка getSomeProperty() {         вернуть someProperty;    }    общественный пустота setSomeProperty(Строка someProperty) {        это.someProperty = someProperty;    }}

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

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

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

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

Пример EJB-компонента как POJO:

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

общественный класс HelloWorldService {    общественный Строка скажи привет() {        вернуть "Привет, мир!";    }}

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

<enterprise-beans>    <session>        <ejb-name>Привет, мир</ejb-name>        <ejb-class>com.example.HelloWorldService</ejb-class>        <session-type>без гражданства</session-type>    </session></enterprise-beans>

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

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

@Statelessобщественный класс HelloWorldService {    общественный Строка скажи привет() {        вернуть "Привет, мир!";    }}

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

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

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

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

Смотрите также

Рекомендации

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