مرحباً، أنا بورو

سررت بلقائك!

كثير من الناس يتعلمون روبي من خلال البدء بإطار عمل Rails، وللأسف، هذه أسوأ طريقة ممكنة لتعلم هذه اللغة. لا تفهمني خطأ: Rails رائع، فهو يساعدك على بناء تطبيقات الويب بسرعة وكفاءة دون الحاجة إلى الدخول في الكثير من التفاصيل التقنية. فهي توفر الكثير من "سحر Rails" الذي يجعل الأشياء تعمل ببساطة. وبالنسبة للمبرمج المبتدئ هذا أمر رائع حقًا، لأن أكثر اللحظات الممتعة في العملية هي عندما يمكنك أن تقول "إنه حي!"، وترى أن جميع الأجزاء تتوافق معًا ويستخدم الناس تطبيقك. نحن نحب أن نكون "مبدعين" 🙂 ولكن هناك شيء واحد يميز المبرمجين الجيدين عن المتوسطين: المبرمجون الجيدون يفهمون كيفية عمل الأدوات التي يستخدمونها. ولا أعني بـ "فهم أدواتك" معرفة جميع الأساليب والوحدات التي يوفرها إطار العمل، ولكن فهم كيفية عملها، وفهم كيفية حدوث "سحر القضبان". عندها فقط يمكنك أن تشعر بالراحة في استخدام الكائنات والبرمجة مع Rails. إن أساس البرمجة الموجهة للكائنات، والسلاح السري الذي يجعل تطبيق Rails المعقد أسهل، هو ما سبق ذكره في العنوان PORO، أي كائن روبي القديم العادي

ما الذي يكمن حقًا تحت هذا الاسم؟ ما هو هذا السلاح السري العظيم؟ إنها فئة روبي بسيطة لا ترث من أي شيء. نعم، هذا فقط، والكثير.

فئة AwesomePoro
النهاية

كيف يمكنني مساعدتك؟

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

• التحقق من عنوان IP في قاعدة بيانات الرسائل غير المرغوب فيها
• إرسال بريد إلكتروني إلى المستخدم الجديد,
• إضافة مكافأة إلى حساب مستخدم موصى به,
• إنشاء حسابات في الخدمات ذات الصلة,
• وغيرها الكثير...

عينة الكود المسؤول عن تسجيل المستخدم قد يبدو هكذا

صنف التسجيلالمتحكم بالتسجيل <متحكم التطبيق
  تعريف إنشاء
    المستخدم = User.new(registration_params)
    إذا كان user.valid? & & ip_valid? (ip_ip التسجيل)
      user.save!
      user.add_bonuses.user.add_bonuses
      user.synchronize_accounts_accounts ذات الصلة
      user.send_email
    إنهاء
  النهاية
النهاية

حسنًا، لقد قمت بترميزه، كل شيء يعمل، ولكن... هل كل هذا الرمز جيد حقًا؟ ربما يمكننا كتابتها بشكل أفضل؟ أولاً وقبل كل شيء، إنه يخالف المبدأ الأساسي للبرمجة - المسؤولية الواحدة، لذا بالتأكيد يمكننا كتابته بشكل أفضل. لكن كيف؟ هنا يأتي دور PORO الذي سبق ذكره لمساعدتك. يكفي فصل فئة RegistrationService، والتي ستكون مسؤولة عن شيء واحد فقط: إخطار جميع الخدمات ذات الصلة. من خلال الخدمات سنأخذ بعين الاعتبار الإجراءات الفردية التي سبق أن أفردناها أعلاه. في نفس وحدة التحكم، كل ما عليك فعله هو إنشاء كائن RegistrationService واستدعاء طريقة "أطلق!" عليه. أصبحت الشيفرة أكثر وضوحًا بكثير، وأصبحت وحدة التحكم لدينا تشغل مساحة أقل، وكل فئة من الفئات المنشأة حديثًا مسؤولة الآن عن إجراء واحد فقط، لذا يمكننا استبدالها بسهولة إذا دعت الحاجة إلى ذلك.

صنف خدمة التسجيل
  تعريف إطلاق!(بارامز)
    المستخدم = User.new(params)
    إذا كان user.valid? && ip_validator.valid?(registration_ip)
      user.save!
      بعد_تسجيل_الأحداث (المستخدم)
    إنهاء
    مستخدم
  النهاية
  خاص
  تعريف بعد_تسجيل_الأحداث(المستخدم)
    BonusesCreator.new.fire!(المستخدم)
    حساباتSynchronizator.fire!(المستخدم)
    EmailSender.fire.fire!(user)
  نهاية
  تعريف ip_validator
    @ip_validator ||= IpValidator.new
  نهاية
النهاية
صنف RegistrationController < ApplicationController
  تعريف إنشاء
    مستخدم = RegistrationService.new.new.fire!(registration_params)
  النهاية
النهاية

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

فئة الشهر من السنة
  تضمين قابل للمقارنة
  attr_reader :السنة، :الشهر
  تعريف تهيئة(شهر، سنة)
    رفع ArgumentError ما لم يكن الشهر بين؟(1, 12)
    @السنة، @الشهر = السنة، الشهر
  نهاية
  تعريف (أخرى)
    [سنة، شهر]  [سنة أخرى، شهر آخر]
  نهاية
النهاية

عرّفني بـ Rails

في عالم Rails، اعتدنا في عالم Rails على حقيقة أن كل فئة هي نموذج أو طريقة عرض أو وحدة تحكم. لديهم أيضًا موقعهم الدقيق في بنية الدليل، فأين يمكن أن نضع جيشنا الصغير من PORO؟ فكِّر في بعض الخيارات. الفكرة الأولى التي تتبادر إلى الذهن هي: إذا كانت الأصناف التي تم إنشاؤها ليست نماذج ولا طرق عرض ولا وحدات تحكم، فيجب أن نضعها جميعًا في الدليل "/lib". من الناحية النظرية، إنها فكرة جيدة، ولكن إذا كانت جميع ملفات PORO ستقع في دليل واحد، وسيكون التطبيق كبيرًا، فسيصبح هذا الدليل سريعًا مكانًا مظلمًا تخشى فتحه. لذلك، لا شك أنها ليست فكرة جيدة.

مشروع رائع
」التطبيق
أدوات التحكم
النماذج
【تعلم العروض
│
「تعرف-عليب
  الخدمات
      1TP63بورو طويل هنا

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

مشروع رائع
」التطبيق
│بأدوات التحكم
││││مفتاح_التسجيل_عناصر_التحكم
││علم │علم │خدمة_التسجيل.rb
│علم │متحكم_التسجيل.rb
النماذج
│││تسوية
│علم شهر_من_السنة.rb
││علم التسوية.rb
│تعريف المشاهدات
│
🌹تعليمات

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

انظر إليّ!

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

وصف الشهر من السنة القيام به
  الموضوع { MonthOfYear.new(11, 2015)}
  يجب أن يكون { يجب أن يكون_نوع_من قابل للمقارنة }
  وصف "إنشاء مثيل جديد" القيام به
    "تهيئته بالسنة والشهر الصحيحين" القيام به
      نتوقع { وصف_الفئة_الجديدة(10, 2015)}.to_لا_يرفع_خطأ
    إنهاء
    فإنه "يثير خطأً عندما يكون الشهر المعطى غير صحيح" القيام به
      نتوقع { { described_class.new(0, 2015)}.to رفع_خطأ (ArgumentError)
      توقع { { described_class.new(13, 2015)}.to raise_error(ArgumentError)
    النهاية
  النهاية
النهاية

آمل أن نلتقي مرة أخرى!

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