هذه المقالة يتيمة إذ تصل إليها مقالات أخرى قليلة جدًا. فضلًا، ساعد بإضافة وصلة إليها في مقالات متعلقة بها. (فبراير 2021)

في هندسة البرمجيات، يعتبر كائن جافا القديم البسيط (POJO) كائن جافا عادي، غير ملزم بأي قيود خاصة. صاغ هذا المصطلح مارتن فاولر وريبيكا بارسونز وجوش ماكنزي في سبتمبر 2000:^[1]

«تساءلنا عن سبب رفض الناس استخدام الأشياء العادية في أنظمتهم وخلصنا إلى أن السبب هو أن الأشياء البسيطة تفتقر إلى اسم منمق. لذلك أعطيناها واحد (اعطيناها اسم منمق)، وتم اخذه بشكل جيد للغاية.» ^[1]

يشير المصطلح "POJO" في البداية إلى كائن جافا لا يتبع أيًا من نماذج كائنات جافا الرئيسية أو الاصطلاحات أو الأطر؛ في الوقت الحاضر، يمكن استخدام "POJO" كاختصار لكائن جافاسكربت عادي أيضًا، وفي هذه الحالة يشير المصطلح إلى كائن حافا سكربت من نفس النسب.^[2]

يستمر المصطلح في نمط المصطلحات القديمة للتقنيات التي لا تستخدم ميزات جديدة فاخرة، مثل كائن روبي القديم البسيط (PORO) في روبي، وخدمة الهاتف القديم البسيط (POTS) في المهاتفة والتوثيق القديم البسيط (pod) في بيرل. ما يعادل POJO على . NET Framework هو كائن CLR قديم عادي (POCO).^[3] بالنسبة إلى PHP ، فهو كائن PHP قديم عادي (POPO).^[4][5]

حظيت ظاهرة POJO في الغالب على قبول واسع النطاق بسبب الحاجة إلى مصطلح شائع يسهل فهمه يتناقض مع أطر عمل الكائنات المعقدة. 

من الناحية النظرية المثالية، فإن POJO هو كائن جافا غير ملزم بأي قيود بخلاف تلك المفروضة بواسطة تخصيصات لغة جافا؛ أي يجب ألا تضطر POJO إلى

1. توسيع الأصناف المحددة مسبقًا، كما في

   public class Foo extends javax.servlet.http.HttpServlet { ...
   

2. تنفيذ واجهات محددة مسبقًا، كما في

   public class Bar implements javax.ejb.EntityBean { ...
   

3. احتواء أي تعليقات شرح برمجية محددة مسبقًا، كما هو الحال في

    @javax.persistence.Entity public class Baz { ...
   

ومع ذلك، نظرًا للصعوبات التقنية وأسباب أخرى، فإن العديد من منتجات البرامج أو أطر العمل الموصوفة على أنها متوافقة مع POJO لا تزال تتطلب في الواقع استخدام التعليقات الشرح البرمجية (annotations) المحددة مسبقًا لميزات مثل المثابرة على العمل بشكل صحيح. الفكرة هي أنه إذا كان الكائن (صنف في الواقع) عبارة عن POJO قبل إضافة أي تعليقات شرح برمجية، وسيعود إلى حالة POJO إذا تمت إزالة تعليقات الشرح البرمجية، فلا يزال من الممكن اعتباره POJO. ثم يبقى الكائن الأساسي POJO لأنه لا يحتوي على خصائص محددة (مثل واجهة مطبقة) مما يجعله «كائن جافا متخصص» "Specialized Java Object" (SJO أو (هكذا) SoJO).

JavaBean (حبوب جافا) هو POJO قابل للتسلسل، وله مُنشئ بدون وسيطة (no-argument)، وتسمح بالوصول إلى الخصائص باستخدام طرق getter جالب و setter المعيّن التي تتبع اصطلاح التسمية البسيطة. بسبب هذا الاصطلاح، يمكن عمل مراجع توضيحية بسيطة لخصائص جافا بينز التعسفية. لا يلزم أن يعرف الكود الذي يستخدم مثل هذا المرجع التعريفي أي شيء عن نوع بين (bean type)، ويمكن استخدام bean مع العديد من الأطر دون الحاجة إلى معرفة النوع الدقيق للحبة. مواصفات جافا بينز، إذا تم تنفيذها بالكامل، تكسر قليلاً نموذج POJO حيث يجب أن يقوم الصنف بتنفيذ واجهة Serializable لتكون جافا بينز حقيقية. لا تزال العديد من اصناف POJO تسمى JavaBeans لا تفي بهذا المطلب. نظرًا لأن Serializable عبارة عن واجهة علامة (بدون طرق)، فإن هذا لا يمثل عبئًا كبيرًا.

يُظهر ما يلي مثالاً على مكون JavaServer Faces (JSF) له ارتباط ثنائي الاتجاه بخاصية POJO:

يمكن أن يكون تعريف 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) "طريقة لتحديد القيمة.

نظرًا لأن التصميمات التي تستخدم POJOs أصبحت أكثر شيوعًا، فقد نشأت الأنظمة التي تمنح POJOs الوظائف الكاملة المستخدمة في الأطر والمزيد من الخيارات حول مجالات الوظائف المطلوبة بالفعل. في هذا النموذج، لا يقوم المبرمج بإنشاء أكثر من POJO. يركز برنامج POJO بشكل بحت على منطق الأعمال وليس له أي تبعيات على أطر عمل (مؤسسية). تضيف أطر البرمجة الموجهة إلى الجانب (AOP) بعد ذلك مخاوف شاملة مثل المثابرة والمعاملات والأمان وما إلى ذلك.^[6]

كان سبرينغ تطبيقًا مبكرًا لهذه الفكرة وأحد القوى الدافعة وراء تعميم هذا النموذج.

مثال على أن حبة (bean) EJB هي POJO:

• Enterprise JavaBeans (EJB)،
• Java Persistence API (JPA) (بما في ذلك وضع هايبرنت)
• CDI (السياقات وحقن التبعية لمنصة Java EE)

يوضح ما يلي أحد وحدات برامج EJB الدالي المتكامل، مما يوضح كيفية قيام EJB3 بتعزيز نموذج POJO:

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

كما هو موضح، لا تحتاج الحبة 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 ، العديد من الأطر (على سبيل المثال سبرينغ و EJB و JPA) تسمح باستخدام التعليقات التوضيحية بدلاً من XML أو بالإضافة إليه. يوضح ما يلي نفس وحدة برامج EJB كما هو موضح أعلاه ولكن مع إضافة تعليق توضيحي. في هذه الحالة لم تعد هناك حاجة إلى ملف XML:

@Stateless
public class HelloWorldService {

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

بتعليق الشرح البرمجي كما هو مذكور أعلاه، لم تعد الحبة bean عبارة عن POJO نقي حقيقي بعد الآن، ولكن نظرًا لأن تعليقات الشرح البرمجية هي مجرد بيانات وصفية سلبية، فإن هذا يحتوي على عيوب ضارة أقل بكثير مقارنةً بالضطر إلى توسيع الأصناف و / أو تنفيذ الواجهات.^[6] وفقًا لذلك، لا يزال نموذج البرمجة يشبه إلى حد كبير نموذج POJO النقي.

تعد واجهة Java القديمة البسيطة (POJI) نموذجًا أساسيًا لواجهة Jaجافا ومقبولة في النقاط التي لا يُسمح فيها بواجهات Java الأكثر تعقيدًا. ^{:57,572,576,579,1340}

• كائن نقل البيانات (DTO)