الداخلية الهندسية لإطار عمل RAD ... كمطور PHP مع Nooku

كل شخص لديه مجموعة الأدوات الخاصة به. بصفتي مطور PHP ، فإن أحد مفضلاتي هو إطار عمل تطوير التطبيقات السريع يسمى "Nooku". على حد تعبير مجموعة التطوير: "Nooku عبارة عن مجموعة أدوات لتطوير الويب أكثر من كونها إطار عمل".

في حال لم تكن معتادًا على ذلك ، ألقِ نظرة. إنه مشروع مفتوح المصدر يستخدم بشكل مكثف أنماط التصميم المقبولة في الصناعة لإنتاج تطبيقات عالية المكونات يمكن توسيعها بسهولة وإعادة استخدامها (تم إنشاؤها في البداية بواسطة أحد مطوري Joomla الرئيسيين). من خارج الصندوق ، يمنحك Nooku قدرًا كبيرًا من أدوات تطوير التطبيقات السريعة للمساعدة في بدء المشاريع بشكل أسرع. عينة صغيرة لكنها قوية:

• تطبيق افتراضي لـ MVC حيث كل ما عليك فعله هو كتابة التخطيط (هذا ما شدني)
• توافر HMVC على الفور
• دعم تنسيقات الإخراج المختلفة مثل JSON و XML لجميع بياناتك (على سبيل المثال ، كشف واجهة برمجة التطبيقات الخاصة بك في دقائق)
• عمليات التنفيذ الإدارية والواجهة الافتراضية

في قلب Nooku هو مبدأ التصميم "التركيب فوق الميراث" (في الواقع ، إنه المفهوم الأول في الصفحة التمهيدية لـ Nooku. في سطر واحد: يجب أن تهدف إلى تكوين (أو إضافة) وظائف كائنات متعددة لإنشاء بعض نوع من الكائن المركب ، بدلاً من الاعتماد على التصنيف الفرعي.

يتيح لك هذا المبدأ كتابة كود أقل وغالبًا ما يؤدي إلى بعض الحلول الأنيقة. إذن كيف يتم الترويج لها بالضبط؟ حسنًا ، على مستوى الكود ، تأتي أفضل الأمثلة من خلال استخدام Mixins ومعرفات الموارد / الخدمة. لنلقي نظرة.

ميكسين

قبل PHP 5.4 ، لم يكن للغة مفهوم السمات . هذه هياكل شبيهة بالفئة ، عندما "يستخدمها" كائن ما ، فإنها توفر نوعًا من الوظائف (على غرار الوراثة المتعددة). تقوم Nooku بحل هذه المشكلة لسنوات (منذ PHP 5.2) باستخدام Mixin .

لا يتيح لك Mixin تكوين الكائنات معًا فحسب ، بل يضيف أيضًا أساليب كل كائن مختلط إلى واجهة الكائن المركب. يبدو أن الكائن الذي يستخدم mixin "يرث" طرق الكائن المختلطة.

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

تتمتع جميع الكائنات في Nooku تقريبًا بهذه القدرة لأنها توسع الفئة الأساسية KObject التي حددت طريقة mixin .

تنحدر أيضًا الفئات الرئيسية في بنية وحدة التحكم في Nooku من KObject. وحدة التحكم المجردة هي فئة KControllerAbstract وبواسطة الفحص يمكنك أن ترى أنها تستفيد من قدرة الخلط على الفور. عندما يتم إنشاء مثيل من هذه الفئة ، تتم إضافة وظائف KMixinCommand و KMixinBehavior على الفور إلى واجهتها. وبالتالي ، فإن كل وحدة تحكم في Nooku تتكون من سلسلة الأوامر ووظيفة إدارة السلوك من خلال الكائنات المعنية.

بالعودة إلى وحدة التحكم Nooku: تحتوي فئة KMixinBehavior على جميع القطع لمنح KControllerAbstract القدرة على تحميل سلوكيات معينة في وقت التشغيل. الاستراتيجيات السلوكية هي فئات تصف عملية أو منطق يمكن فصله واستخدامه بواسطة فئات أخرى (على سبيل المثال ، قابل للتحرير ، قابل للترتيب). KMixinBehavior بسيط إلى حد ما وله أربع طرق فقط: getBehavior و hasBehavior و addBehavior و getBehavior. وهذا كل ما نحتاجه لمنح كائن ما القدرة على التعامل مع استراتيجيات سلوكية مختلفة وتغليفها.

وبالمثل ، يحتوي KMixinCommand على ثلاث طرق فقط: getCommandContext و getCommandChain و setCommandChain. إذا لم تكن قد خمنت ، فإن هذه الطرق الثلاث توفر لـ KControllerAbstract مع القدرة على تنفيذ سلسلة أوامر ، ولكنها تتيح لها القيام بذلك في وقت التشغيل.

يمكنك التفكير في هذا المزج كإضافة حسابية بسيطة:

يعطينا واجهة تبدو كالتالي: 

وفقًا للتعريف ، يُقصد من فئات الخلاصة أن يتم توسيعها ، ومن خلال سحر الوراثة ، تكتسب جميع الكائنات التي هي أطفال أو حالات لـ KControllerAbstract أيضًا القدرة على إضافة سلوكيات وسلسلة أوامر في وقت التشغيل.

يبدو جيدا. ولكن ماذا يعني ذلك في الواقع؟ باختصار ، يوفر Nooku وظائف مكونة ؛ وهذا يعني أن Nooku يسمح لك بتقسيم وظائفك وإنشاء وظائف عبر الوحدات في وقت التشغيل.

يعمل هذان المثالان على إثبات التكوين. كما أنها تعمل على إظهار دعم إطار عمل Nooku RAD لمزيد من التكوين في جوهره. هذه ميزة مهمة. الأساليب المضافة إلى KControllerAbstract أعلاه تدعم "نمط تصميم الإستراتيجية" من خلال منح المطورين الأدوات لتغليف ما يختلف قبل كتابة سطر واحد من التعليمات البرمجية. حقيقة أن طريقة mixin () جزء من كل امتداد لـ KObject تعني أنه يمكنك بسهولة تحديد وإضافة واجهات إدارة سلوكية أخرى لمعظم الكائنات في وقت التشغيل.

معرفات ومحددات مواقع الخدمة والموارد: افصل اسم الفصل الخاص بي عن الكائن الخاص بي

توفر معرفات الخدمة والموارد ومحددات المواقع في Nooku أيضًا دعمًا قويًا لفصل الاهتمامات.

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

عندما تذهب إلى محل بقالة وتشتري منتجًا ، فكر في المتجر على أنه الخدمة ، أي مجموعة من العناصر التي يمكنك تصفحها ؛ والمنتج هو المصدر ، أي عنصر واحد / منطق حل يمكن أن يكون:

• نظرت على وجه التحديد ( R ead) (على سبيل المثال ، النظر إلى علبة من حساء الطماطم)
• تحرك في أرجاء المتجر (على سبيل المثال ، انقل الحساء إلى ممر الإنتاج)
• مضاف إلى مخزون المتجر أو إزالته منه ( A dd و D elete) (على سبيل المثال ، أضف نوعًا جديدًا من الحساء وتخلص من الطماطم)

بأخذ هذا المثال إلى أبعد من ذلك ، تخيل أن متجر البقالة لديه قسم امتياز وتريد أن تكون في مجال الأعمال التجارية. في هذه الحالة ، تكون الخدمة هي قسم الامتياز والمورد هو متجر البقالة الذي تشتريه. إنه تصنيف سياقي إلى حد كبير. بشكل عام ، يُعرف هذا باسم نمط إجراء BREAD (سترى كل من هذه ممثلة بين KControllerService و KControllerResource مسبقةً بـ "_action" ، أي _actionRead ()).

يمكن أن يكون النموذج خدمة ، ويمكن اعتبار كائن الجدول كخدمة ، ويتم إنشاء مثيل لـ MVC محدد كمورد أو خدمة ، بينما يمكن اعتبار السجل المحدد الناتج عن استجواب الخدمة كمورد.

كل كائن في Nooku عبارة عن تكوين للكائنات حيث يحتوي كل عنصر منها على مرجع للخدمات التي تم إنشاء مثيل لها للتطبيق بأكمله في "حاوية خدمة" وطريقة للوصول إلى الخدمات المسماة getService (). كل ما تتطلبه طريقة KObject :: getService () هو أننا نقوم بتمرير معرف مورد صالح وسيعيد خدمة تم إنشاء مثيل لها جاهزة للاستخدام.

في التطوير السريع لتطبيق PHP ، تمنحنا معرفات الموارد طريقة قوية لفصل إنشاء مثيل لكائن ما عن اسم صنفه ، وبالتالي توفير أسماء مستعارة لهذا التعريف. هذا له آثار مهمة على قابلية صيانة التطبيق. من خلال الاسم المستعار يمكن للمطور تغيير الفئة التي يستخدمها كل كائن يتم إنشاء مثيل له بمعرف معين عن طريق إضافة سطر واحد من التعليمات البرمجية باستخدام KService :: addAlias ​​().

مثال على معرّف الموارد المألوف لدينا هو URI أو Uniform Resource Identifier:

هذه هي جميع المعلومات اللازمة لـ KService لتحديد وتحميل الفئة المناسبة. تتوافق هذه القطع مع اصطلاحات التسمية والتنسيب الخاصة بفئة Nooku والتي توفر إمكانية التنبؤ بالموضع وإنشاء مثيل لها. يحاول مثال المعرف أعلاه (com: //site/user.database.table.user) تحميل الملف /components/com_user/databases/tables/user.php ، الذي له اسم فئة ComUserDatabaseTableUser. بالمناسبة ، إذا لم يكن الملف موجودًا ، فسيعطيك إطار العمل كائن جدول افتراضيًا ويبنيه بناءً على تسمية قاعدة البيانات واصطلاحات مخطط المعرف (هذا جعلني أكثر صعوبة). كما ذكرنا سابقًا ، تتيح لك KService أيضًا تعيين أسماء مستعارة لمعرفاتك. استخدام KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') ؛ يتيح لنا تحميل كائن db باستخدام KService::getService('maindbaseadapter') .

يمنحنا هذا الفصل الذي تحدثنا عنه ويوفر ميزة ملحوظة في صيانة وتوسيع تطبيقاتنا. نحن أحرار في إنشاء تطبيقات بخلاف "الموقع" و "المسؤول" إذا لزم الأمر ومن خلال المعرفات الموضحة هنا يمكننا استخدام الخدمات الموجودة في التطبيقات الأخرى بسهولة لمساعدة حلولنا على تلبية متطلباتها. مرة أخرى ، هذا مثال آخر على كيفية قيام Nooku بتزويد مطوري PHP و RAD وفرقهم بالدعم ليس فقط لتكوين كائنات فئة واحدة ولكن للخدمات والتطبيقات بأكملها ... مجانًا.

تلخيص لما سبق

مع تكوين فوق الميراث في قلبها ؛ التكوينات والهياكل الذكية الموجودة مسبقًا لدعم المزيد من الحشوات ؛ والبنية المجانية الموجهة نحو الخدمة مع المعرفات الموضحة هنا ، توفر Nooku إطار عمل RAD قويًا مع بداية قوية لأي من أدوات تطوير PHP النظيرة.