مرحبا بالجميع!
أكملنا هذا الشهر المجموعة الأولى من
دورة Backend PHP Developer ونقوم
بتوظيفهم بقوة وأهم (قدر الإمكان خلال العطلات). تم تجديد الدورة مع مدرس آخر -
Evgeny Volosatov ، والذي يعرفه الكثيرون على الأرجح. حسنًا ، نحن نشارك الأشياء الشيقة بشكل تقليدي.
دعنا نذهب.
في أي تطبيق ، هناك أجزاء من الرمز "تعبر" عدة أجزاء من الهندسة المعمارية في نفس الوقت.
هذه المشكلة ليست واضحة عند العمل مع إطار عمل كامل. على الأرجح ستنتشر مشكلتك على نطاق واسع ، وستكون هناك فرصة بأن الإطار قد حلها بالفعل من خلال التضحية بتقسيم المسؤولية أو من خلال تقديم فكرة تجريدية أعلى الإطار. تستخدم العديد من الأطر بنية موجهة نحو الحدث لحل مشاكل الأداء من البداية إلى النهاية. ولكن تأتي دائمًا لحظة لا يستطيع فيها الإطار توفير المستوى المطلوب من التحكم في جزء معين من المنطق. وينطبق ذلك بشكل خاص عند استخدام الإطارات الدقيقة أو التطوير مع مكتبات متخصصة. كلما أخذ تطبيقك في الاعتبار مبادئ الفصل بين المسؤوليات ، كلما كان دور الوظيفة من البداية إلى النهاية في بنيتك أكبر.
برمجة PHP الموجهة
البرمجة الموجهة نحو الجانب (AOP) هي نموذج برمجي يركز على تنظيم وتنسيق الوظائف من طرف إلى طرف. حالات التطبيق - قوائم ACL ، وتسجيل الدخول ، ومعالجة الأخطاء ، والتخزين المؤقت.
الافتراضات (الداخلية) المضمنة في PHP (عندما تحدد وظيفة / ثابت / فئة ، تظل محددة إلى الأبد) تجعل من الصعب تنفيذ نموذج AOP.
Li3 كان أول من قام بحل مشكلة الوظيفة من طرف إلى طرف باستخدام آلية تصفية تسمح بترشيح منطق الطريقة من خلال عمليات الإغلاق. لجعل الطريقة قابلة للفلترة ، يتطلب تنفيذ Li3 الإضافة اليدوية لرمز القالب. مع هذه القيود ، تقتصر تقنيات AOP على تقنيات التصفية.
تطبيقات AOP الأخرى المعروفة في PHP:
يعد امتداد PECL AOP مثيرًا للاهتمام ولكنه في الوقت نفسه نهج محفوف بالمخاطر ، لأن دعم ملحقات PECL ليس شائعًا. خيار آخر هو Go! Libraries ، وهي عبارة عن تطبيق AOP يقوم بإصلاح كود PHP بسرعة ، مما يجعل من الممكن استخدام طرق AOP.
هناك تطبيقات أخرى ، ولكن معظمها مبني على أساس الوكلاء (على حد علمي) ، وهذا النهج له العديد من القيود.
شخص جديد في المنطقة
تم إنشاء رمز تلقائي منذ فترة طويلة في PHP ويستخدم في العديد من المكتبات ، على سبيل المثال
ProxyManager. وبفضل اعتماد الملحن ،
اذهب! يظهر أن تعديل التعليمات البرمجية على الطاير ممكن.
إذا كان لا يزال من الممكن اعتبار إنشاء الشفرة بسيطًا ، فإن تصحيح الرمز أكثر تعقيدًا إلى حد ما. أولاً ، في PHP لا يوجد محلل تعليمات برمجية مدمج ، وثانيًا ، هناك عدد قليل جدًا من المكتبات التي تحل مشاكل تحليل كود PHP. الأكثر شهرة هي مكتبة
PHP-Parser . PHP-Parser هي أداة رائعة ، ولكنها حتى تتجاهل تنسيق المسافات في أشجار الجملة المجردة. مما يجعل من الصعب إصلاح الرمز. في الواقع ، الكود الذي يجب إصلاحه هو كود حقيقي قابل للتنفيذ. لذلك ، إذا كنت تريد أن يكون التراجع دقيقًا مع وجود أخطاء ، فيجب مراعاة أرقام الأسطر في الملف الذي تم تصحيحه.
لهذه المهمة ، نستخدم أداة تصحيح كود
Kahlan JIT. Kahlan هو إطار عمل اختبار الوحدة الجديدة و BDD ، وذلك بفضل تقنيات تحرير JIT التي تسمح برمز تصحيح كعب وقرد مباشرة في Ruby أو JavaScript. تحت الغطاء ، نجد أن هذه المكتبة تعتمد على محلل PHP البدائي. ولكن ، مع ذلك ، فهي سريعة بما فيه الكفاية ومستقرة لتناسبنا.
مكتبة التصفية متاحة على
github.com/crysalead/filter ويمكن استخدامها على النحو التالي.
أولاً ، يجب تهيئة أداة تصحيح رمز JIT في أقرب وقت ممكن (على سبيل المثال ، مباشرة بعد تشغيل الملحن التلقائي):
include __DIR__ . '/../vendor/autoload.php'; use Lead\Filter\Filters; Filters::patch(true);
لاحظ أن تحرير الكود ممكن فقط للفصول التي تم تحميلها بواسطة الملحن التلقائي. إذا تمت إضافة فئة باستخدام التعبيرات المطلوبة أو المتضمنة ، فسيتم تحميلها بالفعل قبل استدعاء Filters :: patch (true) ، وبالتالي لن يتم إصلاحها.
بشكل افتراضي ، سيتم تخزين جميع التعليمات البرمجية التي تم تصحيحها في / tmp / jit ، ولكن يمكنك دائمًا تغييرها إلى رمزك الخاص:
Filters::patch(true, ['cachePath' => 'my/cache/path/jit']);
ستتم استعادة الملفات المخزنة مؤقتًا تلقائيًا في كل مرة تقوم فيها بتغيير ملف PHP.
إنتباه!
Filters::patch(true) هي أسهل طريقة لتهيئة أداة
Filters::patch(true) ، ضع في اعتبارك أنه سيتم إصلاح جميع التعليمات البرمجية الخاصة بك. قد يستغرق الأمر وقتًا طويلاً لف جميع الطرق الموجودة في التعليمات البرمجية الأساسية في إغلاق عامل التصفية.
لحسن الحظ ، إذا لعبت الوظيفة من البداية إلى النهاية دورًا حاسمًا في التعليمات البرمجية جيدة التصميم ، فستحتاج إلى طريقتين فقط في المشروع. لذلك ، فإن الأسلوب المفضل هو إصلاح تلك الأساليب التي سيتم تصفيتها فقط:
Filters::patch([ 'A\ClassName', 'An\Example\ClassName::foo', 'A\Second\Example\ClassName' => ['foo', 'bar'], ], [ 'cachePath' => 'my/cache/path/jit', ]);
وبالتالي ، يمكنك اختيار إصلاح جميع طرق فئة معينة ، أو طريقة واحدة فقط أو عدة طرق.
مرشح API
الآن بعد أن تم تمكين JIT patcher ، قم بإنشاء عامل تصفية السجل:
use Chaos\Filter\Filters; use Chaos\Database\Database; use Monolog\Logger; use Monolog\Handler\StreamHandler; $logger = new Logger('database'); $logger->pushHandler(new StreamHandler('my/log/path/db.log', Logger::WARNING)); Filters::apply(Database::class, 'query', function($next, $sql, $data, $options) use ($logger) { $logger->info('Ran SQL query: ' . $sql); return $next($sql, $data, $options); });
ينشئ المثال أعلاه عامل تصفية سجل استعلام SQL لمكتبة قاعدة بيانات Chaos. يمكن العثور على مزيد من المعلومات حول مرشح API على
github.com/crysalead/filter .
الخلاصة
AOP ، في رأيي ، هو الجواب الحقيقي للوظيفة من طرف إلى طرف. جميع التجريدات الأخرى زائدة عن الحاجة ، وفي معظم الحالات تقتصر على إطار معين. لا أفقد الأمل في أن توفر PHP يومًا ما واجهة برمجة تطبيقات مضمنة للبرمجة ذات المنحى الجانبي. ولكن الآن ، أعتقد أن تصحيح رمز JIT هو الخيار الأفضل ، حيث تفوق المزايا بكثير حمل وحدة المعالجة المركزية ، والذي يمكن إهماله عمليًا عندما لا يتم تطبيق تصحيح رمز JIT على مستوى العالم.
النهاية
كما هو الحال دائمًا ، نتوقع ، إذا كان هناك أي شيء ، أسئلة ورغبة وندعوك إلى
درس مفتوح حيث يمكنك الاستماع إلى محاضرة مثيرة للاهتمام والتعرف على
المعلم الجديد بشكل أفضل.