ในวิศวกรรมซอฟต์แวร์อ็อบเจ็กต์Java ธรรมดา ( POJO ) คืออ็อบเจ็กต์Java ทั่วไป ซึ่งไม่ได้ถูกผูกมัดด้วยข้อจำกัดพิเศษใดๆ คำนี้ถูกบัญญัติโดยMartin Fowler , Rebecca Parsons และ Josh MacKenzie ในเดือนกันยายน พ.ศ. 2543: ^{[ 1 ]}

เราสงสัยว่าทำไมผู้คนถึงต่อต้านการใช้สิ่งของธรรมดาในระบบของพวกเขา และสรุปได้ว่านั่นเป็นเพราะสิ่งของธรรมดาเหล่านั้นไม่มีชื่อเรียกที่ดูหรูหรา ดังนั้นเราจึงตั้งชื่อให้พวกเขา และมันก็ได้รับความนิยมเป็นอย่างดี

เดิมทีคำว่า "POJO" หมายถึงอ็อบเจ็กต์ในภาษา Java ที่ไม่ปฏิบัติตามโมเดล อ็อบเจ็กต์ ข้อกำหนด หรือเฟรมเวิร์กหลักใดๆ ของ Java แต่ต่อมาคำนี้ได้รับการยอมรับอย่างกว้างขวางในฐานะคำที่ไม่ขึ้นกับภาษาใดๆ เนื่องจากความต้องการคำที่ใช้กันทั่วไปและเข้าใจง่าย ซึ่งแตกต่างจากเฟรมเวิร์กอ็อบเจ็กต์ที่ซับซ้อน

คำนี้ยังคงใช้ รูปแบบ ตัวย่อเพื่อสร้างคำใหม่ย้อนหลังสำหรับโครงสร้างที่ไม่ใช้คุณสมบัติใหม่ที่ซับซ้อน:

• "อ็อบเจ็กต์ JavaScript ธรรมดา" ในJavaScript ^{[ 2 ]}
• "Plain old Ruby object" (PORO) ในภาษา Ruby
• "เอกสารธรรมดา" (pod) ในภาษา Perl
• อ็อบเจ็กต์ CLR ธรรมดา (POCO) ^{[ 3 ]}ใน.NET Framework
• "Plain old PHP object" (POPO) ^{[ 4 ] [ 5 ]}ในPHP
• บริการโทรศัพท์พื้นฐาน (POTS) ในระบบโทรศัพท์

ตามหลักการแล้ว POJO คืออ็อบเจ็กต์ Java ที่ไม่ถูกจำกัดด้วยข้อจำกัดใดๆ นอกเหนือจากข้อจำกัดที่กำหนดโดยข้อกำหนดของภาษา Java กล่าวคือ POJO ไม่ควรต้องมีคุณสมบัติดังต่อไปนี้:

• ขยายคลาสที่กำหนดไว้ล่วงหน้า เช่น

import javax.servlet.http.HttpServlet ;คลาสสาธารณะFoo สืบทอดมาจากHttpServlet { // ... }

• ใช้งานอินเทอร์เฟซที่กำหนดไว้ล่วงหน้า เช่น ใน

import javax.ejb.EntityBean ;public class Bar implements EntityBean { // ... }

• ประกอบด้วยคำอธิบาย ประกอบที่กำหนดไว้ล่วงหน้า เช่น

import javax.persistence.Entity ;@Entity public class Baz { // ... }

อย่างไรก็ตาม เนื่องจากปัญหาทางเทคนิคและเหตุผลอื่นๆ ผลิตภัณฑ์ซอฟต์แวร์หรือเฟรมเวิร์กจำนวนมากที่อธิบายว่าสอดคล้องกับ POJO นั้นยังคงต้องใช้คำอธิบายประกอบที่กำหนดไว้ล่วงหน้าสำหรับคุณสมบัติต่างๆ เช่น การจัดเก็บข้อมูล เพื่อให้ทำงานได้อย่างถูกต้อง แนวคิดก็คือ หากวัตถุ (จริงๆ แล้วคือคลาส) เป็น POJO ก่อนที่จะมีการเพิ่มคำอธิบายประกอบใดๆ และจะกลับคืนสู่สถานะ POJO หากลบคำอธิบายประกอบออก ก็ยังคงถือว่าเป็น POJO ได้ ดังนั้นวัตถุพื้นฐานจึงยังคงเป็น POJO ในแง่ที่ว่าไม่มีลักษณะพิเศษใดๆ (เช่น อินเทอร์เฟซที่ถูกนำไปใช้) ที่ทำให้มันเป็น "วัตถุ Java เฉพาะทาง" (SJO หรือ SoJO)

JavaBean คือ POJOที่สามารถซีเรียลไลซ์ได้ มี คอนสตรัคเตอร์ที่ไม่รับอาร์กิวเมนต์และอนุญาตให้เข้าถึงคุณสมบัติโดยใช้เมธอด getter และ setterที่ใช้รูปแบบการตั้งชื่อที่เรียบง่าย เนื่องจากรูปแบบนี้ จึงสามารถสร้างการอ้างอิงแบบประกาศ (declarative reference) ง่ายๆ ไปยังคุณสมบัติของ JavaBean ใดๆ ก็ได้ โค้ดที่ใช้การอ้างอิงแบบประกาศดังกล่าวไม่จำเป็นต้องรู้เกี่ยวกับประเภทของ bean และ bean สามารถใช้งานร่วมกับเฟรมเวิร์กต่างๆ ได้โดยที่เฟรมเวิร์กเหล่านั้นไม่จำเป็นต้องรู้ประเภทที่แน่นอนของ bean ข้อกำหนดของ JavaBean หากนำไปใช้งานอย่างสมบูรณ์ จะทำให้โมเดล POJO เสียไปเล็กน้อย เนื่องจากคลาสต้องใช้งาน อินเทอร์เฟซ Serializableเพื่อให้เป็น JavaBean ที่แท้จริง คลาส POJO จำนวนมากที่ยังคงเรียกว่า JavaBean ไม่ตรงตามข้อกำหนดนี้ เนื่องจากSerializableเป็นอินเทอร์เฟซแบบ marker (ไม่มีเมธอด) จึงไม่ใช่ภาระมากนัก

ต่อไปนี้เป็นตัวอย่างของ คอมโพเนนต์ JavaServer Faces (JSF) ที่มี การผูกข้อมูล แบบสองทิศทางกับคุณสมบัติของ POJO:

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

นิยามของ POJO สามารถเป็นได้ดังนี้:

คลาสสาธารณะMyBean { ส่วนตัวString someProperty ;public String getSomeProperty () { return someProperty ; }public void setSomeProperty ( String someProperty ) { this.someProperty = someProperty ; } }​​

เนื่องจากข้อกำหนดการตั้งชื่อของ JavaBean somePropertyการอ้างอิง " " เพียงรายการเดียวสามารถแปลงเป็นเมธอด " getSomeProperty()" (หรือ " isSomeProperty()" หากคุณสมบัติเป็นประเภทบูลีน ) สำหรับการรับค่า และเมธอด " setSomeProperty(String)" สำหรับการตั้งค่าค่าได้ โดยอัตโนมัติ

ไลบรารีProject Lombokช่วยให้สามารถแก้ไขโค้ดแบบไดนามิกเพื่อผสานรวมข้อกำหนดเหล่านั้นได้โดยไม่ต้องเสียเวลาเขียนโค้ดเอง โค้ดต่อไปนี้จะสร้าง bean ตัวเดียวกัน โดยเพิ่ม constructor ว่างเปล่าเข้าไปด้วย:

@NoArgsConstructor public class MyBean { @Getter @Setter private String someProperty ; }

ไลบรารีหรือเฟรมเวิร์กอื่นๆ สร้างโค้ด (หรือไบต์โค้ด) โดยใช้ข้อกำหนดเหล่านั้นโดยตรง การเพิ่มเครื่องมือเหล่านั้นช่วยลดโค้ดซ้ำซ้อนซึ่งจะช่วยลดความถี่ของข้อผิดพลาดและค่าใช้จ่ายในการบำรุงรักษา

เนื่องจากการออกแบบโดยใช้ POJO เป็นที่นิยมมากขึ้น ระบบต่างๆ จึงเกิดขึ้นมาเพื่อให้ POJO มีฟังก์ชันการทำงานครบถ้วนเหมือนที่ใช้ในเฟรมเวิร์ก และมีตัวเลือกมากขึ้นเกี่ยวกับฟังก์ชันการทำงานที่จำเป็นจริงๆ ในโมเดลนี้ โปรแกรมเมอร์สร้างเพียงแค่ POJO เท่านั้น POJO นี้มุ่งเน้นเฉพาะตรรกะทางธุรกิจและไม่มีการพึ่งพาเฟรมเวิร์ก (ระดับองค์กร) เฟรมเวิ ร์ก การเขียนโปรแกรมเชิงแง่มุม (AOP) จะเพิ่มความกังวลที่เกี่ยวข้องกับส่วนต่างๆ เช่น การคงอยู่ การทำธุรกรรม ความปลอดภัย และอื่นๆ อย่างโปร่งใส^{[ 6 ]}

Springเป็นการนำแนวคิดนี้ไปใช้ในยุคแรกๆ และเป็นหนึ่งในแรงผลักดันสำคัญที่ทำให้โมเดลนี้เป็นที่นิยม

ตัวอย่างหนึ่งของ EJB bean ที่เป็น POJO:

• Enterprise JavaBeans (EJB)
• Java Persistence API (JPA) (รวมถึงHibernate )
• CDI (Contexts and Dependency Injection for the Java EE platform)

ต่อไปนี้คือตัวอย่าง EJB bean ที่ใช้งานได้อย่างสมบูรณ์ ซึ่งแสดงให้เห็นว่า 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> stateless </session-type> </session> </enterprise-beans>

ในทางปฏิบัติ บางคนมองว่าคำอธิบายประกอบมีความสง่างาม ในขณะที่บางคนมองว่า XML เยิ่นเย้อ น่าเกลียด และดูแลรักษายาก ในขณะที่บางคนมองว่าคำอธิบายประกอบทำให้โมเดล POJO สกปรก^{[ 7 ]}

ดังนั้น เพื่อเป็นทางเลือกแทน XML เฟรมเวิร์กหลายตัว (เช่น Spring, EJB และ JPA) จึงอนุญาตให้ใช้แอนโนเทชันแทนหรือควบคู่ไปกับ XML ตัวอย่างต่อไปนี้แสดง EJB bean ตัวเดียวกันกับที่แสดงด้านบน แต่มีการเพิ่มแอนโนเทชันเข้าไป ในกรณีนี้ ไฟล์ XML จึงไม่จำเป็นอีกต่อไป:

@Stateless public class HelloWorldService {public String sayHello () { return "สวัสดีโลก!" ; } }

ด้วยคำอธิบายประกอบตามที่ระบุไว้ข้างต้น บีนจึงไม่ใช่ POJO ที่แท้จริงอีกต่อไป แต่เนื่องจากคำอธิบายประกอบเป็นเพียงเมตาเดต้าแบบพาสซีฟ จึงมีข้อเสียที่เป็นอันตรายน้อยกว่าเมื่อเทียบกับการแทรกแซงที่ต้องขยายคลาสและ/หรือใช้งานอินเทอร์เฟซ^{[ 6 ]}ดังนั้น รูปแบบการเขียนโปรแกรมจึงยังคงคล้ายกับรูปแบบ POJO ที่แท้จริงมาก

อินเทอร์เฟซ Java แบบธรรมดา (POJI) เป็นรูปแบบพื้นฐานของอินเทอร์เฟซ Javaและยอมรับได้ในจุดที่อินเทอร์เฟซ Java ที่ซับซ้อนกว่าไม่ได้รับอนุญาต^{[ 8 ] : 57, 572, 576, 579, 1340}

• วัตถุถ่ายโอนข้อมูล (DTO)
• แบบจำลองโดเมนโลหิตจาง
• หลักการ KISS (Keep It Simple, Stupid)