كائن جافا عادي قديم

الموسوعة الحرة

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

تساءلنا عن سبب معارضة الناس الشديدة لاستخدام الكائنات العادية في أنظمتهم، واستنتجنا أن السبب هو افتقار الكائنات البسيطة إلى اسم مميز. لذا أطلقنا عليها اسمًا، وقد لاقى رواجًا كبيرًا.

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

يستمر هذا المصطلح في اتباع نمط الاختصارات لصياغة مصطلحات قديمة للبنى التي لا تستخدم ميزات جديدة متطورة:

تعريف

من الناحية المثالية، يُعتبر كائن POJO كائن جافا غير مقيد بأي قيود أخرى غير تلك التي تفرضها مواصفات لغة جافا؛ أي أنه لا ينبغي أن يكون كائن POJO مقيدًا بما يلي:

  • قم بتوسيع الفئات المحددة مسبقًا، كما في
import javax.servlet.http.HttpServlet ;public class Foo extends HttpServlet { // ... }
  • قم بتنفيذ الواجهات المحددة مسبقًا، كما في
استيراد javax.ejb.EntityBean ؛public class Bar implements EntityBean { // ... }
  • تحتوي على تعليقات توضيحية محددة مسبقًا ، كما في
استيراد javax.persistence.Entity ؛@Entity public class Baz { // ... }

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

الاختلافات السياقية

جافا بينز

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

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

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

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

تتيح مكتبة Project Lombok تعديل الكود ديناميكيًا لدمج هذه الاصطلاحات دون عناء كتابتها. سيُنشئ الكود التالي نفس الكائن (bean)، مع إضافة مُنشئ فارغ:

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

تقوم المكتبات أو الأطر البرمجية الأخرى بإنشاء التعليمات البرمجية (أو التعليمات البرمجية الوسيطة) وفقًا لهذه الاصطلاحات مباشرةً. يُسهم إضافة هذه الأدوات في تخفيف عبء التعليمات البرمجية المتكررة ، مما يقلل بدوره من تكرار الأخطاء وتكاليف الصيانة.

إضافة الخدمات بشفافية

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

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

مثال على كون عنصر EJB عبارة عن كائن POJO:

يوضح المثال التالي نموذجًا كامل الوظائف لـ EJB bean، موضحًا كيف يستفيد EJB3 من نموذج POJO:

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

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

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

واجهة جافا عادية قديمة

واجهة جافا البسيطة (POJI) هي شكل أساسي من واجهات جافا ، وهي مقبولة في الحالات التي لا يُسمح فيها باستخدام واجهات جافا الأكثر تعقيدًا. [ 8 ] : 57، 572، 576، 579، 1340

انظر أيضاً

مراجع

  1. ^ "إم إف بليكي: بوجو" . مارتن فاولر.كوم .
  2. ↑ ألماير، ديون (17 يوليو 2006). "عودة كائن POJO: جافا سكريبت البسيطة" . أجاكسيان . مؤرشف من الأصل في 13 سبتمبر 2014. تم الاطلاع عليه في 19 أغسطس 2014 .
  3. ↑ "دعم POCO" . microsoft.com . تم الاطلاع عليه بتاريخ 27-05-2012 .
  4. ↑ كنيشكه، يان (19 فبراير 2007). "كائنات آمنة من حيث النوع في PHP" . kneschke.de . مؤرشف من الأصل بتاريخ 26 مارس 2012. تم الاطلاع عليه بتاريخ 27 مايو 2012 .
  5. ↑ تشيونغ، جيم (26-06-2011). "وحدة تحكم باستخدام كائن PHP عادي بسيط (POPO)" . jym.sg. مؤرشف من الأصل بتاريخ 26-03-2012 . تم الاطلاع عليه بتاريخ 27-05-2012 .
  6. 1 2 مارتن، روبرت سي؛ (2008)؛ الكود النظيف ، الفصل 11، أطر عمل البرمجة الموجهة نحو الجوانب في جافا النقية
  7. ↑ باندا، ديبو؛ رحمن، رضا؛ لين، ديريك؛ (2007). EJB 3 قيد التشغيل ، منشورات مانينغ، شيلتر آيلاند (نيويورك)، ISBN 978-1-93-398834-4(www.manning.com/books/ejb-3-in-action). الفصل 11، واصفات النشر مقابل التعليقات التوضيحية
  8. ^ واهلي، أولي؛ فييرا، ميغيل؛ جوميز، فيريرا لوبيز؛ هيني، بريان. محرم، أحمد؛ نابولي، خوان بابلو؛ رور، ماركو. كوي، هنري. غان، باتريك. جونزاليس، سيلسو؛ أوجورلو، بينار؛ زيوسي ، لارا (29 يونيو 2009). دليل برمجة الإصدار 7.5 لمطور التطبيقات الرشيد . آي بي إم ريدبوكس. رقم ISBN 978-0738432892.