تطبيق نمط حالة الاستخدام مع القضبان

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

تابعني في هذا المقال لاكتشاف فوائد هذا النمط.

حالة الاستخدام

التعريف

حالة الاستخدام هي قائمة من الإجراءات أو خطوات الحدث التي تحدد عادةً التفاعلات بين الدور والنظام لتحقيق هدف ما.

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

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

القواعد

لدينا حالات الاستخدام يجب أن يكون

• لا يوجد إطار عمل لا يعتمد على الإطار
• لا تعتمد على قاعدة البيانات
• مسؤول عن شيء واحد فقط (تحديد خطوات تحقيق هدف المستخدم)

المزايا

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

في الممارسة

لنأخذ مثالاً لمستخدم يريد شراء شيء ما في نظامنا.

وحدة حالات الاستخدام
  وحدة المشتري
    صنف الشراء
      تعريف التهيئة(المشتري:, عربة التسوق:)
        @المشتري = المشتري
        @عربة التسوق = عربة التسوق
      نهاية
      تعريف الاستدعاء
        العودة ما لم يتم التحقق من المخزون
        إرجاع ما لم يكن إنشاء_شراء
إشعار نهاية
خاص
      attr_reader :المشتري، :عربة التسوق
      ديف شيك_مخزون
        الخدمات::CheckStock.call(سلة التسوق: عربة التسوق)
نهاية
      تعريف إنشاء_شراء
        الخدمات::CreatePurchase.call(المشتري: المشتري، عربة التسوق: عربة التسوق).call
      نهاية
      تعريف الإخطار

         الخدمات::إعلام المشتري.call(المشتري: المشتري).
       النهاية
     النهاية
   النهاية
 النهاية

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

نحن الآن جاهزون للاتصال بأول حالة الاستخدام من وحدة تحكم.

فئة المتحكم
  تعريف الشراء
    حالات الاستخدام::المشتري::شراء.جديد(
      المشتري: buy_params[:المشتري],
      عربة التسوق: buy_params[:عربة التسوق]
    ).call).call

    ...
  انتهى

  ...
النهاية

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

التحسينات

أول حالة الاستخدام يعمل ولكن يمكن أن يكون أفضل. كيف يمكننا تحسينه؟ دعنا نستفيد من جاف الجواهر. في هذه الحالة سنستخدم المعاملات الجافة.

أولًا دعنا نعرّف الصنف الأساسي لدينا.

فئة حالة الاستخدام
  تضمين المعاملات الجافة::معاملة

  صنف << ذاتي
    تعريف النداء(**args)
      جديد.call(**args)
    النهاية
  النهاية
النهاية

سيساعدنا هذا على تمرير السمات إلى معاملة حالة الاستخدام واستخدامها. ثم نحن مستعدون لإعادة تعريف حالة استخدام الشراء.

وحدة حالات الاستخدام
  وحدة المشتري
    صنف الشراء
      تعريف التهيئة(المشتري:, عربة التسوق:)
        @المشتري = المشتري
        @عربة التسوق = عربة التسوق
      نهاية

      تعريف الاستدعاء
        إرجاع ما لم يتم التحقق من المخزون
        العودة ما لم يكن إنشاء_شراء
        الإخطار
      إنهاء

      خاص

      attr_reader :المشتري، :عربة التسوق

      تعريف شيك_مخزون
        الخدمات::CheckStock.call(سلة التسوق: سلة التسوق)
      نهاية

      تعريف إنشاء_شراء
        الخدمات::CreatePurchase.call(المشتري: المشتري، عربة التسوق: عربة التسوق).call
      نهاية

      تعريف إعلام
        الخدمات::إعلام المشتري.call(المشتري: المشتري).
      النهاية
    النهاية
   النهاية
 النهاية

مع التغييرات الجديدة، يمكننا أن نرى بطريقة واضحة كيف يتم تعريف خطواتنا ويمكننا إدارة نتيجة كل خطوة مع النجاح() والفشل().

نحن جاهزون لاستدعاء حالة الاستخدام الجديدة في وحدة التحكم وإعداد استجابتنا بناءً على النتيجة النهائية.

فئة المتحكم
  تعريف الشراء
    حالات الاستخدام::Buyer::Buyer::Purchase.new.call(
      المشتري: buy_params[:المشتري],
      عربة التسوق: buy_params[:عربة التسوق]
    ) القيام ب |النتيجة |
      result.success do
        ...
      تنتهي
      النتيجة.فشل تفعل
        ...
      النهاية
    النهاية

    ...
  النهاية

  ...
النهاية

يمكن تحسين هذا المثال أكثر من خلال عمليات التحقق من الصحة ولكن هذا يكفي لإظهار قوة هذا النمط.

الاستنتاجات

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

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

خذ هذا في صندوق أدواتك وربما تستفيد منه في المستقبل.