В программной инженерии , простой старый объект Java ( POJO ) представляет собой обычный Java объект , не связанный какими - либо особыми ограничением. Этот термин был введен Мартином Фаулером , Ребеккой Парсонс и Джошем Маккензи в сентябре 2000 года: [1]
«Мы задавались вопросом, почему люди так против использования обычных объектов в своих системах, и пришли к выводу, что это произошло из-за того, что у простых объектов нет причудливого имени. Поэтому мы дали им одно, и оно очень хорошо прижилось». [1]
Термин «POJO» первоначально обозначал объект Java, который не следует ни одной из основных объектных моделей Java, соглашений или структур; в настоящее время «POJO» также может использоваться как аббревиатура для простого старого объекта JavaScript , и в этом случае термин обозначает объект JavaScript схожего происхождения. [2]
Этот термин продолжает шаблон старых терминов для технологий, которые не используют причудливые новые функции, такие как простой старый объект Ruby (PORO) в Ruby , обычная старая телефонная служба (POTS) в телефонии и обычная старая документация (pod) в Perl . Эквивалент POJO в .NET Framework - это простой объект Old CLR (POCO). [3] Для PHP это обычный старый объект PHP (POPO). [4] [5]
Феномен POJO, скорее всего, получил широкое признание из-за необходимости общего и легко понимаемого термина, который контрастирует со сложными объектными структурами. [ необходима цитата ]
Определение
В идеале POJO - это объект Java, на который не накладываются никакие ограничения, кроме тех, которые налагаются Спецификацией языка Java; т.е. POJO не должен
- Расширить заранее определенные классы, как в
открытый класс Foo расширяет javax . сервлет . http . HttpServlet { ...
- Реализуйте заранее определенные интерфейсы, как в
публичный класс Bar реализует javax . ejb . EntityBean { ...
- Содержат заранее заданные аннотации , как в
@ javax.persistence.Entity открытый класс Baz { ...
Однако из-за технических трудностей и других причин многие программные продукты или фреймворки, описанные как POJO-совместимые, на самом деле все еще требуют использования предварительно определенных аннотаций для правильной работы таких функций, как постоянство. Идея состоит в том, что если объект (на самом деле класс) был POJO до того, как были добавлены какие-либо аннотации, и вернулся бы в статус POJO, если аннотации были удалены, он все равно может считаться POJO. Тогда базовый объект остается POJO в том смысле, что он не имеет особых характеристик (таких как реализованный интерфейс), которые делают его «специализированным Java-объектом» (SJO или (sic) SoJO).
Контекстные вариации
JavaBeans
JavaBean является POJO , который сериализуемый , имеет без аргументов конструктора , а также обеспечивает доступ к свойствам , используя методы получения и установок , которые следуют за простое именованием. Благодаря этому соглашению можно делать простые декларативные ссылки на свойства произвольных компонентов JavaBeans. Код, использующий такую декларативную ссылку, не должен ничего знать о типе bean-компонента, и bean-компонент можно использовать со многими фреймворками, при этом этим фреймворкам не нужно знать точный тип bean-компонента. Спецификация JavaBeans, если она полностью реализована, немного нарушает модель POJO, поскольку класс должен реализовывать интерфейс Serializable, чтобы быть истинным JavaBean. Многие классы POJO, все еще называемые JavaBeans, не удовлетворяют этому требованию. Поскольку Serializable - это маркерный (без методов) интерфейс, это не составляет большого труда.
Ниже показан пример компонента JavaServer Faces (JSF), имеющего двунаправленную привязку к свойству POJO:
value = "# {MyBean.someProperty}" />
Определение POJO может быть следующим:
public class MyBean { частная строка someProperty ; общедоступная строка getSomeProperty () { return someProperty ; } public void setSomeProperty ( String someProperty ) { это . someProperty = someProperty ; } }
Из-за соглашений об именах JavaBean единственная ссылка someProperty может быть автоматически преобразована в метод getSomeProperty () (или isSomeProperty (), если свойство имеет логический тип ) для получения значения, а также в метод setSomeProperty ( String) »для установки значения.
Прозрачное добавление услуг
По мере того как проекты, использующие POJO, стали более широко использоваться, возникли системы, которые предоставляют POJO полную функциональность, используемую во фреймворках, и больший выбор в отношении того, какие области функциональности действительно необходимы. В этой модели программист создает не что иное, как POJO. Этот POJO ориентирован исключительно на бизнес-логику и не зависит от (корпоративных) фреймворков. Фреймворки аспектно-ориентированного программирования (АОП) затем прозрачно добавляют сквозные проблемы, такие как постоянство, транзакции, безопасность и так далее. [6]
Spring была ранним воплощением этой идеи и одной из движущих сил популяризации этой модели.
Пример EJB-компонента, являющегося POJO:
- Enterprise JavaBeans (EJB),
- Java Persistence API (JPA) (включая Hibernate )
- CDI (внедрение контекстов и зависимостей для платформы Java EE)
Ниже показан полностью функциональный компонент EJB, демонстрирующий, как EJB3 использует модель POJO:
public class HelloWorldService { public String sayHello () { return "Привет, мир!" ; } }
Как указано, компоненту не нужно расширять какой-либо класс EJB или реализовывать какой-либо интерфейс EJB, а также не нужно содержать никаких аннотаций EJB. Вместо этого программист объявляет во внешнем XML- файле, какие службы EJB следует добавить в компонент:
helloWorld com.example.HelloWorldService без состояния
На практике некоторые люди находят аннотации элегантными, в то время как они считают XML многословным, уродливым и сложным в обслуживании, а другие считают, что аннотации загрязняют модель POJO. [7]
Таким образом, в качестве альтернативы XML многие структуры (например, Spring, EJB и JPA) позволяют использовать аннотации вместо или в дополнение к XML. Ниже показан тот же EJB-компонент, показанный выше, но с добавленной аннотацией. В этом случае XML-файл больше не нужен:
@Stateless общедоступный класс HelloWorldService { public String sayHello () { return "Привет, мир!" ; } }
С аннотацией, приведенной выше, bean-компонент больше не является действительно чистым POJO, но поскольку аннотации являются просто пассивными метаданными, у них гораздо меньше вредных недостатков по сравнению с инвазивностью необходимости расширять классы и / или реализовывать интерфейсы. [6] Соответственно, модель программирования по-прежнему очень похожа на чистую модель POJO.
Связанные сокращения
Обычный старый интерфейс Java
Простой старый интерфейс Java (POJI) - это базовая форма интерфейса Java, приемлемая в тех случаях, когда более сложные интерфейсы Java не разрешены. [8] : 57 572 576 579 1340
Смотрите также
Рекомендации
- ^ a b "MF Bliki: POJO" . MartinFowler.com .
- ^ Алмаер, Дион (17 июля 2006 г.). «Возвращение POJO: простой Ole JavaScript» . Аяксиан . Проверено 19 августа 2014 .
- ^ «Поддержка POCO» . microsoft.com . Проверено 27 мая 2012 .
- ^ Кнешке, Ян (19 февраля 2007 г.). «Типобезопасные объекты в PHP» . kneschke.de . Архивировано из оригинала на 2012-03-26 . Проверено 27 мая 2012 .
- ^ Чеонг, Джим (26.06.2011). «Контроллер с простым старым объектом PHP, также известным как POPO» . jym.sg . Архивировано из оригинала на 2012-03-26 . Проверено 27 мая 2012 .
- ^ а б Мартин, Роберт С; (2008); Чистый код , Глава 11, Чистые Java AOP Framework
- ↑ Панда, Дебу; Рахман, Реза; Лейн, Дерек; (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 Redbooks. ISBN 978-0738432892.