В программной инженерии , обычный старый объект Java ( POJO ) — это обычный объект Java , не связанный никакими специальными ограничениями. Термин был придуман Мартином Фаулером , Ребеккой Парсонс и Джошем Маккензи в сентябре 2000 года: [1]
«Мы задались вопросом, почему люди так против использования обычных объектов в своих системах, и пришли к выводу, что это потому, что простым объектам не хватает причудливого имени. Поэтому мы дали им одно, и оно очень хорошо прижилось». [1]
Термин "POJO" изначально обозначал объект Java, который не следует ни одной из основных объектных моделей Java, соглашений или фреймворков. С тех пор он получил распространение как независимый от языка термин из-за необходимости в общем и легко понимаемом термине, который контрастирует со сложными объектными фреймворками. [ необходима цитата ]
Термин продолжает традицию создания аббревиатур для ретронимов конструкций, не использующих новые необычные функции:
В идеале POJO — это объект Java, не связанный никакими ограничениями, кроме тех, которые налагаются спецификацией языка Java. То есть POJO не должен
открытый класс Foo расширяет javax.servlet.http.HttpServlet { ... открытый класс Bar реализует javax.ejb.EntityBean { ... @javax.persistence.Entity публичный класс Баз { ... Однако из-за технических трудностей и других причин многие программные продукты или фреймворки, описанные как совместимые с POJO, на самом деле все еще требуют использования предопределенных аннотаций для таких функций, как сохранение, чтобы работать должным образом. Идея заключается в том, что если объект (фактически класс) был POJO до добавления каких-либо аннотаций и вернется к статусу POJO, если аннотации будут удалены, то его все равно можно считать POJO. Тогда базовый объект остается POJO в том смысле, что у него нет специальных характеристик (таких как реализованный интерфейс), которые делают его «специализированным объектом Java» (SJO или (sic) SoJO).
JavaBean — это POJO , который является сериализуемым , имеет конструктор без аргументов и позволяет получать доступ к свойствам с помощью методов getter и setter , которые следуют простому соглашению об именовании. Благодаря этому соглашению можно делать простые декларативные ссылки на свойства произвольных JavaBean. Код, использующий такую декларативную ссылку, не должен ничего знать о типе bean-компонента, и bean-компонент может использоваться со многими фреймворками без необходимости этих фреймворков знать точный тип bean-компонента. Спецификация JavaBeans, если она полностью реализована, немного нарушает модель POJO, поскольку класс должен реализовать интерфейс Serializable, чтобы быть настоящим JavaBean. Многие классы POJO, все еще называемые JavaBeans, не соответствуют этому требованию. Поскольку Serializable — это интерфейс маркера (без методов), это не такая уж большая проблема.
Ниже показан пример компонента JavaServer Faces (JSF), имеющего двунаправленную привязку к свойству POJO:
<h:inputText value= "#{MyBean.someProperty}" /> Определение POJO может быть следующим:
публичный класс MyBean { частная строка someProperty ; public String getSomeProperty () { return someProperty ; } public void setSomeProperty ( String someProperty ) { this.someProperty = someProperty ; } } Благодаря соглашениям об именовании JavaBean единственная ссылка «someProperty» может быть автоматически преобразована в метод «getSomeProperty()» (или «isSomeProperty()», если свойство имеет логический тип ) для получения значения и в метод «setSomeProperty(String)» для установки значения.
Библиотека lombok позволяет динамически изменять код, чтобы интегрировать эти соглашения без хлопот по их написанию. Следующий код сгенерирует тот же бин, с добавлением пустого конструктора:
@NoArgsConstructor публичный класс MyBean { @Getter @Setter частная строка someProperty ; }Другие библиотеки или фреймворки генерируют код (или байт-код) с этими соглашениями напрямую. Добавление этих инструментов помогает облегчить шаблон , что в свою очередь снижает частоту ошибок и стоимость обслуживания.
Поскольку проекты с использованием POJO стали более распространенными, появились системы, которые предоставляют POJO полную функциональность, используемую в фреймворках, и больше выбора относительно того, какие области функциональности действительно необходимы. В этой модели программист не создает ничего, кроме POJO. Этот POJO сосредоточен исключительно на бизнес-логике и не имеет зависимостей от (корпоративных) фреймворков. Затем фреймворки аспектно-ориентированного программирования (AOP) прозрачно добавляют сквозные проблемы, такие как сохранение, транзакции, безопасность и т. д. [6]
Spring стал одним из первых примеров реализации этой идеи и одной из движущих сил популяризации этой модели.
Пример компонента EJB, являющегося POJO:
Ниже показан полностью функциональный компонент EJB, демонстрирующий, как EJB3 использует модель POJO:
публичный класс HelloWorldService { public String sayHello () { return "Привет, мир!" ; } } Как указано, bean не должен расширять какой-либо класс EJB или реализовывать какой-либо интерфейс EJB, а также не должен содержать какие-либо аннотации EJB. Вместо этого программист объявляет во внешнем XML- файле, какие службы EJB следует добавить к bean:
<enterprise-beans> <session> <ejb-name> helloWorld </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 { public String sayHello () { return "Привет, мир!" ; } } С аннотацией, как указано выше, компонент больше не является по-настоящему чистым POJO, но поскольку аннотации являются просто пассивными метаданными, у него гораздо меньше вредных недостатков по сравнению с необходимостью расширения классов и/или реализации интерфейсов. [6] Соответственно, модель программирования по-прежнему очень похожа на чистую модель POJO.
Простой старый интерфейс Java (POJI) — это базовая форма интерфейса Java , приемлемая в тех случаях, когда более сложные интерфейсы Java не допускаются. [8] : 57, 572, 576, 579, 1340