تتشارك أغلب لغات البرمجة في العديد من المزايا. من أفضل الطرق لتعلم لغة برمجة جديدة هي كتابة برنامج مألوف. في هذا المقال، سنتعلم كيف ننشئ لعبة "احزر الرقم" باستخدام لغة البرمجة Awk لنشرح من خلالها مفاهيم مألوفة.

عند تعلم البرمجة بلغة برمجة جديدة، من المهم التركيز على أكثر المفاهيم التي تشترك بها لغات البرمجة:

• المتغيرات: مكان يُخزن فيه المعلومات.
• التعابير: طرق لحساب الأشياء.
• الصياغات: طرق التعبير عن تغير الحالة داخل البرنامج.

هذه المفاهيم هي أساس معظم لغات البرمجة.

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

بالرجوع إلى الأساسيات. لغات البرمجة تتشارك بعدة تشابهات. حالما تتعرف على لغة برمجة واحدة، ابدأ بتعلم أساسيات لغة برمجة أخرى وستجد نفسك تقدّر الاختلافات في تلك اللغة الجديدة.

طريقة جيدة للبدء تكون في إنشاء برنامج اختبار بسيط. أحد تلك البرامج قد يكون برنامج "احزر الرقم". يقوم الحاسب باختيار رقم بين واحد ومئة ويسألك أن تحزر ذلك الرقم. يعيد البرنامج الكرّة إلى أن تحزر الرقم.

برنامج "احزر الرقم" سيُدربك على عدة مفاهيم في لغات البرمجة:

• المتغيرات.
• الدخل.
• الخرج.
• التقييم الشرطي.
• الحلقات التكرارية.

هذا مثال عملي تجريبي رائع لتعلم لغة برمجة جديدة.

احزر الرقم باستخدام awk

لنبدأ بكتابة لعبة "احزر الرقم" كبرنامج في Awk.

Awk لغة برمجة نصية ديناميكية النوع موجهة لتحويل البيانات، ولديها دعم جيد من ناحية الاستخدام التفاعلي. Awk موجودة منذ عام 1970، بدأت كقسم من نظام يونكس. إذا كنت لا تعلم عن Awk ولكنك تحب جداول البيانات فهذه فأنت في المكان الصحيح للتعرف عليها.

يمكنك بدء الاستكشاف عبر كتابة نسخة من لعبة "احزر الرقم". التالي تضمين للعبة (مع ترقيم الأسطر حتى نتمكن من الإشارة إليها لاحقًا):

1    BEGIN {
2        srand(42)
3        randomNumber = int(rand() * 100) + 1
4        print "random number is",randomNumber
5        printf "guess a number between 1 and 100\n"
6    }
7    {
8        guess = int($0)
9        if (guess < randomNumber) {
10            printf "too low, try again:"
11        } else if (guess > randomNumber) {
12            printf "too high, try again:"
13        } else {
14            printf "that's right\n"
15            exit
16        }
17    }

يمكن الملاحظة مباشرة التشابه بين بنى التحكم في Awk ومثيلاتها في لغات أخرى مثل سي C وجافا JAVA، ولا تشبه تلك التي في بايثون. في التعابير مثل if-then-else أو while، يمكن أن تأخذ تعبيرًا واحدًا أو مجموعة من التعابير محاطة بقوسين معقوصين { و }. ومع ذلك يوجد فرق واحد كبير في Awk يجب فهمه منذ البداية:

اقتباس

لغة Awk بتصميمها مبنية حول قنوات أو أنابيب البيانات.

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

الجواب أنها مبنية في داخل اللغة نفسها. تحديدا في الأسطر 7 - 17 نخبر Awk ماذا يفعل بكل سطر من الدخل. سيصبح واضحا أن الأسطر 1 - 6 تنفذ قبل أن يتم قراءة أي شيء.

تحديدا الكلمة المفتاحية BEGIN في السطر الأول هي نمط مكرر، في حالتنا هذه فإنها تخبر Awk قبل قراءة أي شيء أن ينفذ ما بين القوسين {...}. ومثلها الكلمة المفتاحية END، لم نستخدمها هنا لكنها تدل Awk على التعليمات التي يجب أن ينفذها بعد أن يتم قراءة كل شيء.

بالعودة للأسطر 7 - 17، فهي تمثل كتلة واحدة ستنفذ معًا، لكن لا يوجد قبلها كلمة مفتاحية. لذا يقوم Awk بتنفيذ هذه الأسطر على كل سطر يتم تلقيه من الدخل وفي حالتنا هذه هي محاولات المستخدم لحزر الرقم.

لنلق الآن نظرة على الشيفرة التي تنفذ، بدايةً هناك المقدمة التي تنفذ قبل كل قراءة للدخل.

في السطر 2، نعرّف رقما عشوائيا من واحد إلى 42. السطر 3 يقوم بحساب رقم بين 1 و 100، السطر 4 يطبع هذه الرقم لنا فقط للتأكد من وجود أي خطأ. السطر 5 يسأل المستخدم أن يحزر رقمًا. لاحظ هنا استخدمنا التابع printf وليس print فهو مثل التابع الموجود في C، ويأخذ أول معامل ويكون قالب نصي يستخدم لتنسيق الخرج.

الآن بعد أن تم سؤال المستخدم البرنامج ينتظر الإدخال، بعد أن يدخل المستخدم تخمينه، يمرر Awk ذلك الادخال الى الاسطر 7 - 17، كما ذكرنا سابقًا. السطر 1 يحول الدخل الى نوع عدد صحيح؛ 0$ تعني سجل الدخل كاملًا، بينما 1$ تعني أول حقل من سجل الدخل 2$ تعني الحقل الثاني، وهكذا. يقوم Awk بتقسيم الدخل إلى حقول تلقائيا مستخدمًا الفاصل المحدد مسبقًا، والذي تكون قيمته الافتراضية المساحة الفارغة. الأسطر 9 - 15 تقارن جواب المستخدم مع العدد العشوائي المخزن سابقًا، ويطبع الجواب المناسب. إذا كان الجواب صحيحًا، السطر 15 سيخرج من البرنامج وينهي سلسلة معالجة الدخل، بهذه البساطة.

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

1    BEGIN {
2        srand(42)
3        randomNumber = int(rand() * 100) + 1
4        print "random number is",randomNumber
5        printf "guess a number between 1 and 100\n"
6    }
7    int($0) < randomNumber {
8        printf "too low, try again: "
9    }
10    int($0) > randomNumber {
11        printf "too high, try again: "
12    }
13    int($0) == randomNumber {
14        printf "that's right\n"
15        exit
16    }

الأسطر 1 - 6 لم تتغير عن البرنامج السابق لكن نلاحظ أن الشيفرة في الأسطر 7 - 9 ستنفذ في حال كان جواب المستخدم أقل من الرقم العشوائي الذي يحاول تخمينه، والأسطر 10 - 12 كذلك ستنفذ في حال كان جواب المستخدم أكبر من الرقم العشوائي الذي يحاول المستخدم تخمينه، والشيفرة في الأسطر 13 - 16 ستنفذ في حال كان جواب المستخدم مساويًا لذلك الرقم.

قد يبدو ذلك غريبًا، لماذا نقوم بتكرار حساب int($0)‎ عند كل تحقق؟ فهي طريقة غريبة لحل المشكلة. لكن هذه الأنماط هي طريقة رائعة لفصل معالجة التحقق من الإجابة حيث يمكن توظيف استخدام التعابير النظامية أو أي بنية مدعومة من قبل Awk عند كل كتلة من كتل التحقق تلك بشكل منفصل.

يمكننا أيضا استخراج الحسابات المتكررة وفصلها بمكان واحد، عن أماكن التحقق منها للحالات المختلفة، التالي نسخة ثالثة من البرنامج توضح ذلك:

1    BEGIN {
2        srand(42)
3        randomNumber = int(rand() * 100) + 1
4        print "random number is",randomNumber
5        printf "guess a number between 1 and 100\n"
6    }
7    {
8        guess = int($0)
9    }
10    guess < randomNumber {
11        printf "too low, try again: "
12    }
13    guess > randomNumber {
14        printf "too high, try again: "
15    }
16    guess == randomNumber {
17        printf "that's right\n"
18        exit
19    }

لاحظ أنه مهما كانت القيمة المدخلة من قبل المستخدم، يجب تحويلها إلى عدد صحيح، تم إضافة الأسطر 7 - 9 لفعل ذلك. الآن الثلاث مجموعات من الأسطر 10 - 12، 13 - 15 و 16 - 19، تشير إلى متغير معرّف مسبقًا باسم guess بدلًا من تحويل الدخل عندها في كل مرة.

لنقم بمراجعة لما كنا قد نوينا تعلمه سابقًا:

• المتغيرات: Awk يحتوي عليها؛ يمكننا الملاحظة أن بيانات الدخل تأتي إلى البرنامج على شكل نص ولكن يمكننا تحويلها إلى قيمة عددية عند الحاجة.
• الدخل: يقوم Awk بإرسال الدخل عبر طريقته "سلسلة معالجة البيانات" لقراءة الدخل.
• الخرج: قمنا باستخدام توابع Awk الإجرائية التالية print و printf لكتابة الأشياء إلى الخرج.
• التقييم الشرطي: تعلمنا عن كتلة if-then-else في Awk وتصفية الدخل التي تتجاوب مع إعدادات مختلفة لأسطر الدخل.
• الحلقات: لم نحتج إلى الحلقات في مثالنا هذا، لكن بفضل طريقة Awk في معالجة البيانات عبر "سلسلة معالجة البيانات" فإن الحلقات موجودة من طبيعة تصميم اللغة نفسها. لكن يمكن للمستخدم الخروج من تلك السلسلة في أي وقت عبر إرسال إشارة "نهاية الملف" إلى Awk (بالضغط على Ctrl+D عند استعمال طرفية لينكس).

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

لننفذ البرنامج:

$ awk -f guess.awk
random number is 25
guess a number between 1 and 100: 50
too high, try again: 30
too high, try again: 10
too low, try again: 25
that's right
$

من الأشياء التي لم نذكرها هي التعليقات. التعليق في Awk يبدأ بمحرف المربع (#) وينتهي عند نهاية سطر التعليق.

الختام

Awk لغة قوية ومثالنا السابق "لعبة احزر الرقم" هو بداية جيدة لبدء تعلم البرمجة بتلك اللغة. وهي البداية وليست نهاية طريق تعلمك لها، يمكنك أيضا القراءة عن تاريخ لغة Awk و Gawk (إصدار awk لجنو)، وهي إصدار موسع من Awk وعلى الأغلب هو الإصدار المتواجد على حاسبك إذا كنت تعمل على نظام لينكس، أو يمكنك.

ترجمة -وبتصرف- للمقال Learn awk by coding a "guess the number" game لصاحبه Chris Hermansen.

اقرأ أيضًا

• أفضل 5 لغات برمجة لـ DevOps
• تعرف على أشهر لغات برمجة الألعاب
• كيف تتعلم البرمجة
• ما هي البرمجة ومتطلبات تعلمها؟

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

سنشرح في هذا المقال ما يلي:

• تعريف التعاودية، وكيفية عملها.
• كيف تساعد التعاودية في تبسيط بعض المشاكل الصعبة.

تعريف التعاودية

رغم قولنا سابقًا إن الحلقات التكرارية loops هي إحدى ركائز البرمجة، إلا أنه يمكننا كتابة برامج كاملة دون استخدام صريح لهذه البنية، بل إن بعض اللغات مثل Scheme لا تحوي بنية حلقة تكرارية صريحةً مثل For وWhile وغيرهما، وإنما تستخدم تقنيةً تسمى التعاودية، وقد تبين أن هذه التقنية قوية للغاية في حل بعض أنواع المشاكل، وهي تعني تطبيق دالة كجزء من تعريف نفس الدالة، ولننظر مثالًا على ذلك أحد الاختصارات التعاودية المشهورة في الكلمات، وهو أحد أساليب التلاعب بالاختصارات يحتوي الاختصار نفسه على كلمة تطابق حروف الاختصار، مثل مشروع GNU مثلًا -وهو أحد أهم المشاريع في البرمجيات مفتوحة المصدر- والذي تشير حروف كلمته إلى "نظام GNU ليس يونكس" أو GNU's Not UNIX، فتكون اختصارًا تعاوديًا لأن كلمة GNU التي في الاختصار هي نفسها كلمة GNU المختصرة كلها، أما معنى الكلمة الحرفي فهو حيوان الثور الإفريقي.

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

لننظر هنا في مثال بسيط، تُعرَّف فيه دالة المضروب الرياضي factorial function المشار إليها بعلامة التعجب بعد العدد n!‎، على أنها ناتج ضرب جميع الأعداد من الواحد حتى العدد المطلوب -بما في ذلك العدد نفسه-، ومضروب الصفر هو الواحد، فإذا أردنا التعبير عن هذا المثال بطريقة أخرى فسنقول إن مضروب N يساوي (N(N-1، وعليه سيكون:

1! = 1
  2! = 1 x 2 = 2
  3! = 1 x 2 x 3 = 2! x 3 = 6
  N! = 1 x 2 x 3 x .... (N-2) x (N-1) x N = (N-1)! x N

ويمكن التعبير عن ذلك في بايثون كما يلي:

def factorial(n):
    if n == 0:
        return 1
    else:
        return n * factorial(n-1)

يجب أن تنتهي الدالة بما أننا نقلل قيمة N في كل مرة ونتحقق هل تساوي 1 أم لا، لكن ثمة مشكلة بسيطة في هذا التعريف، إذ سيدخل في حلقة لا نهائية إذا استدعيناه برقم سالب، ولحل هذا نضيف اختبارًا للتحقق من أن n أقل من صفر، ويعيد None إذا كان كذلك لأن مضروب العدد السالب غير معرَّف undefined.

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

لنرى الآن كيف يكون هذا عند تنفيذه، لاحظ أن تعليمة الإعادة تعيد * n (نتيجة استدعاء المضروب التالي)، فنحصل على ما يلي:

factorial(4) = 4 * factorial(3)
factorial(3) = 3 * factorial(2)
factorial(2) = 2 * factorial(1)
factorial(1) = 1

وتعود بايثون أدراجها لتستبدل القيم كما يلي:

factorial(2) = 2 * 1 = 2
factorial(3) = 3 * 2 = 6
factorial(4) = 4 * 6 = 24

ليس من الصعب كتابة دالة مضروب دون استخدام التعاودية، ويمكنك تجريب هذا، إذ يجب أن تمر على جميع الأعداد حتى N؛ وتنفذ عمليات ضرب أثناء ذلك المرور التكراري، لكن قد يصعب كتابة بعض الدوال دون التعاودية، كما سنرى أدناه.

التعاودية على القوائم

إحدى الحالات التي تكون التعاودية مفيدةً فيها هي معالجة القوائم Lists، بشرط أن نستطيع التحقق من فراغ القائمة، وتوليد قائمة دون عنصرها الأول، ونفعل هذا في بايثون باستخدام تقنية تسمى التشريح Slicing، لكن كل ما يجب معرفته في هذا الفصل هو أن استخدام فهرس [‎1:‎] يعيد جميع العناصر من العنصر ذي الفهرس 1 حتى نهاية القائمة، لذا نكتب ما يلي لنصل إلى العنصر الأول من قائمة اسمها L:

first = L[0] # استخدم الفهرسة العادية

وللوصول إلى بقية القائمة:

# استخدم التشريح للوصول إلى العناصر 1،2،3 وما بعدها
butfirst = L[1:] 

لنجرب ذلك في محث بايثون، لنتأكد أنه يعمل:

>>> L =[1,2,3,4,5]
>>> print( L[0] )
1
>>> print( L[1:] )
[2,3,4,5]

نعود الآن إلى استخدام التعاودية لطبع القوائم، ولنفرض حالةً نطبع فيها كل عنصر من قائمة سلاسل نصية باستخدام الدالة printList:

def printList(L):
    if L:
        print( L[0] )
        printList(L[1:])

إذا تحققت L -أي كانت true ولم تكن فارغةً- فسنطبع العنصر الأول، ثم نعالج بقية القائمة كما يلي:

# شيفرة وهمية ليست بايثون
PrintList([1,2,3])
   prints [1,2,3][0] => 1
   runs printList([1,2,3][1:]) => printList([2,3])
   => we're now in printList([2,3])
         prints [2,3][0] => 2
         runs printList([2,3][1:]) => printList([3])
         => we are now in printList([3])
               prints [3][0] => 3
               runs printList([3][1:]) => printList([])
               => we are now in printList([])
                     "if L" is false for an empty list, so we return None
         => we are back in printList([3])
               it reaches the end of the function and returns None
   => we are back in printList([2,3])
         it reaches the end of the function and returns None
=> we are back in printList([1,2,3])
   it reaches the end of the function and returns None

لاحظ أن الشرح أعلاه مأخوذ من شرح في نشرة تعليم بايثون البريدية بواسطة Zak Arnston بتاريخ يوليو 2003.

يسهل تنفيذ هذا الأمر لقائمة بسيطة باستخدام حلقة for، لكن ماذا لو كانت القائمة معقدةً وتحتوي قوائم أخرى فيها، فإذا استطعنا التحقق من كون عنصر ما قائمةً باستخدام دالة type()‎ المضمنة وكان قائمة حقًا؛ فسنستدعي printList()‎ تعاوديًا، أما إن لم يكن قائمةً فنطبعه:

def printList(L):
    # لا تفعل شيًا إن كانت فارغة
    if not L: return
    # على العنصر الأول printList إذا كانت قائمة فاستدع
    if type(L[0]) == list:
        printList(L[0])
    else: # لا توجد قوائم لذا نطبع هنا 
        print( L[0] ) # L نعالج بقية عناصر  
    printList( L[1:] )

سيصعب تنفيذ ذلك باستخدام الحلقة التكرارية العادية، ويظهر الفرق مع استخدام التعاودية في تسهيل ذلك التنفيذ، لكن ثمة مشكلة هنا، فالتعاودية على بنى البيانات الكبيرة يستهلك الذاكرة كثيرًا، لذا عند وجود ذاكرة صغيرة أو بنى بيانات كبيرة لمعالجتها، فيجب تفضيل الشيفرة المعتادة للأمان، وبسبب مشكلة الذاكرة تلك واحتمال أن يتعطل المفسر interpreter بسببها فقد وضعت بايثون حدًا لعدد مستويات التعاودية التي تسمح بها، فإذا تجاوزنا ذلك الحد فسيُنهى برنامجنا مع خطأ RecusrionError، والذي نلتقطه باستخدام try/except:

  >>> def f(n): return f(n+1)

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

جافاسكربت ولغة VBScript

تدعم كل من لغة جافاسكربت ولغة VBScript التعاودية، لكن بما أننا ذكرنا كل شيء تقريبًا فسنتركك مع نسخة تعاودية من دالة المضروب للغتين:

<script type="text/vbscript">
Function factorial(N)
   if N < 0 Then
      Factorial = -1   'a negative result is "impossible"
   if N = 0 Then
      Factorial = 1
   Else
      Factorial = N * Factorial(N-1)
   End If
End Function

Document.Write "7! = " & CStr(Factorial(7))
</script>

<script type="text/javascript">
function factorial(n){
   if (n < 0)
      return NaN  // NaN - Not a Number - يعني أنه غير صالح 
   if (n == 0)
      return 1;
   else
      return n * factorial(n-1);
};

document.write("6! = " + factorial(6));
</script>

لننظر الآن في البرمجة الدالية Functional Programming (أو البرمجة الوظيفية) في الفصل التالي.

خاتمة

نأمل بنهاية هذا الفصل أن تكون تعلمت ما يلي:

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

ترجمة -بتصرف- للفصل العشرين: Recursion, or doing it to yourself، من كتاب Learn To Program لصاحبه Alan Gauld.

اقرأ أيضًا

• المقال التالي: مقدمة إلى البرمجة الوظيفية Functional Programming
• المقال السابق: برمجة الواجهات الرسومية باستخدام Tkinter
• التعاود recursion والمكدس stack في جافاسكربت
• التعاود recursion في جافا
• مفهوم التعاود (Recursion) والكائنات القابلة للاستدعاء (Callable Objects) في Cpp

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

تُبين اللقطات التالية أن تطبيقات المنصات الخاصة تعرض شيئًا ما في وضع انقطاع الاتصال. مثلًا اللقطة التالية للمُساعد Google Assistant:

أما اللقطة التالية لتطبيق سلاك Slack:

واللقطة التالية لتطبيق زووم Zoom:

على النقيض من ذلك، لا نحصل على شيء على الويب عند انقطاع الاتصال. مثلًا، قد يُظهر المتصفح Chrome اللعبة البسيطة dino على أنظمة التشغيل iOS:

وعلى أنظمة التشغيل macOS:

سنتعلم في هذا المقال كيفية إنشاء صفحة احتياطية لوضع انقطاع الاتصال وإضافتها إلى تطبيقات الويب التقدمية PWA.

إنشاء صفحة احتياطية باستخدام عامل خدمة مخصص

من المناسب تخصيص سلوك صفحات الويب التقدميّة في حال انقطاع الاتصال لاسيما أنه أصبح بالإمكان توفير تجربة استخدام مخصصة باستخدام عامل خدمة service worker وواجهة برمجة التطبيقات ذات التخزين المؤقت Cache Storage API . يُمكن عادًة إنشاء صفحة احتياطية بسيطة تُبين للمستخدم أنه في وضع انقطاع الاتصال، إلا أنه يُمكن أيضًا إيجاد حلول إبداعية أجمل. لنلقي نظرة مثلًا على موقع الحجز trivago والذي يوفر في صفحته الاحتياطية لعبة متاهة مسلية للمستخدم خلال انقطاع الاتصال مع زر لتجريب إعادة الاتصال Reconnect وعدّاد تنازلي لإظهار الزمن المتبقي لإعادة محاولة الاتصال تلقائيًا كما يُبين الشكل التالي:

تسجيل عامل الخدمة

لإنشاء الصفحة الاحتياطية، يجب أولًا تسجيل عامل خدمة في الصفحة الأساسية كما تُبين الشيفرة التالية والتي تُنفّذ عند تحميل التطبيق:

window.addEventListener("load", () => {
  if ("serviceWorker" in navigator) {
    navigator.serviceWorker.register("service-worker.js");
  }
});

شيفرة عامل الخدمة

نعرض فيما يلي مثالًا عن شيفرة عامل الخدمة والتي قد تبدو للوهلة الأولى معقدة قليلًا ولذا أُضيفت بعض التعليقات المُساعدّة. تكمن الفكرة بالتخزين المؤقت المسبق لملف ندعوه offline.html والذي يعرضه المتصفح في حال فشل طلبات التنقل navigation فقط، وفي بقية الحالات يتابع المتصفح معالجاته الاعتيادية.

/* معلومات رخصة الاستخدام
Copyright 2015, 2019, 2020, 2021 Google LLC. All Rights Reserved.
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at
 http://www.apache.org/licenses/LICENSE-2.0
 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
*/

// (1)
// يُمكن إضافة أي تعليق مناسب لمنقح الصياغة
// eslint-disable-next-line no-unused-vars
const OFFLINE_VERSION = 1;
const CACHE_NAME = "offline";
يُمكن تخصيص مُحدّد موارد URL مختلف إذا دعت الحاجة //
const OFFLINE_URL = "offline.html";

self.addEventListener("install", (event) => {
  event.waitUntil(
    (async () => {
      const cache = await caches.open(CACHE_NAME);
      // (2) 
      await cache.add(new Request(OFFLINE_URL, { cache: "reload" }));
    })()
  );
 إرغام عامل الخدمة المنتظر ليصبح العامل النشط //
  self.skipWaiting();
});

self.addEventListener("activate", (event) => {
  event.waitUntil(
    (async () => {
      // السماح بالتنقل قبل التحميل إذا كان ذلك مدعومًا
      // See https://developers.google.com/web/updates/2017/02/navigation-preload
      if ("navigationPreload" in self.registration) {
        await self.registration.navigationPreload.enable();
      }
    })()
  );

  // الطلب من عامل الخدمة أن يتحكم بالصفحة فورًا
  self.clients.claim();
});

self.addEventListener("fetch", (event) => {
 إذا كان الطلب لصفحة HTML نستدعي event.respondWith//
  if (event.request.mode === "navigate") {
    event.respondWith(
      (async () => {
        try {
         نحاول أولًا استخدام جواب التنقل قبل التحميل إذا كان مدعومًا //        
          const preloadResponse = await event.preloadResponse;
          if (preloadResponse) {
            return preloadResponse;
          }

          تجريب الشبكة أولًا //        
          const networkResponse = await fetch(event.request);
          return networkResponse;
        } catch (error) {
          // (3)
          console.log("Fetch failed; returning offline page instead.", error);

          const cache = await caches.open(CACHE_NAME);
          const cachedResponse = await cache.match(OFFLINE_URL);
          return cachedResponse;
        }
      })()
    );

  }
  // (4)
});

• (1) تؤدي زيادة قيمة المتغير OFFLINE_VERSION إلى تنشيط حدث التثبيت وتحديث الموارد المخبئة سابقًا عبر الشبكة، المتغير مُعرّف عمدًا مع أنه غير مستخدم.
• (2) يؤدي ضبط {cache: 'reload'‎} في الطلب الجديد إلى استيفاء الطلب HTTP من الشبكة وليس من الذاكرة المؤقتة.
• (3) رُفع استثناء يُنشّط الالتقاط catch والذي يكون على الأغلب بسبب خطأ في الشبكة، ولن تُستدعى catch إذا أعادت fetch جواب HTTP صالح، مع كود الجواب محصور بين
• 4xx - 5xx. (4) إذا كان شرط التعليمة if خاطئًا فلن يقاطع معالج الجلب fetch الطلب، يُمكن أن يُستدعى التابع event.respondWith في حال وجود معالجات جلب أخرى مسجلة، إذا لم يستدع أي معالج جلب التابع event.respondWith فعندها يعالج المتصفح الطلب كما لو أنه لا يوجد عامل خدمة.

الصفحة الاحتياطية لوضع انقطاع الاتصال

يُعدّ ملف الصفحة الاحتياطية offline.html المكان المناسب لإظهار بعض الإبداع لجذب المستخدم وإبراز العلامة التجارية للمنتج مثلًا، حيث يُمكن تكييف هذا الملف مع الاحتياجات المطلوبة. يُبين المثال التالي الحد الأدنى الممكن القيام به كإظهار زر إعادة التحميل، إضافًة لمحاولات إعادة التحميل الآلية والتي تعتمد على حدث الاتصال online وعلى اقتراع خادم منتظم regular server polling.

يجب تخزين جميع الموارد التي تتطلبها الصفحة الاحتياطية لوضع انقطاع الاتصال. من الحلول المُمكنة لذلك تضمين كل شيء وبذا تُصبح الصفحة الاحتياطية حاوية لنفسها، وهو ما يُبينه المثال التالي:

<!DOCTYPE html>
<html lang="en">
 <head>
   <meta charset="utf-8" />
   <meta http-equiv="X-UA-Compatible" content="IE=edge" />
   <meta name="viewport" content="width=device-width, initial-scale=1" />

   <title>You are offline</title>

   <!-- Inline the page's stylesheet. -->
   <style>
     body {
       font-family: helvetica, arial, sans-serif;
       margin: 2em;
     }

     h1 {
       font-style: italic;
       color: #373fff;
     }

     p {
       margin-block: 1rem;
     }

     button {
       display: block;
     }
   </style>
 </head>
 <body>
   <h1>You are offline</h1>

   <p>Click the button below to try reloading.</p>
   <button type="button">⤾ Reload</button>

   <!-- Inline the page's JavaScript file. -->
   <script>
     //  ميزة إعادة التحميل اليدوي
     document.querySelector("button").addEventListener("click", () => {
       window.location.reload();
     });
     //(1)
     window.addEventListener('online', () => {
       window.location.reload();
     });
//(2)

     async function checkNetworkAndReload() {
       try {
         const response = await fetch('.');
          // التحقق من الحصول على جواب صالح من الخادم
         if (response.status >= 200 && response.status < 500) {
           window.location.reload();
           return;
         }
       } catch {
// تجاهل إذ لا يُمكن الاتصال مع الخادم
       }
       window.setTimeout(checkNetworkAndReload, 2500);
     }

     checkNetworkAndReload();
   </script>
 </body>
</html>

حيث أن:

• (1) متابعة تغييرات حالة الشبكة وإعادة التحميل عند انقطاع الاتصال حيث ينشط المعالج التالي في حالة انقطاع الاتصال كليًا.
• (2) إعادة تحميل الصفحة إذا كان الخادم متجاوبًا حيث ينشط المعالج التالي في حال انقطاع الاتصال عن الجهاز أو عدم تجاوب الخادم بشكل صحيح.

مثال توضيحي

يُمكن معاينة الصفحة الاحتياطية في المثال والموضح لقطة منه أدناه. كما يُمكن الحصول على الشيفرة المصدرية الموافقة من المستودع Glitch.

يُمكن، بعد الانتهاء من إنشاء الصفحة الاحتياطية لوضع عدم الاتصال، تحقيق إمكانية تثبيت التطبيق بإضافة بيان تطبيق الويب واختيار استراتيجية التثبيت. كما يُمكن، للسهولة، استخدام مكتبات Workbox.js والتي توفر الشيفرة اللازمة لإنشاء الصفحة الاحتياطية.

ترجمة -وبتصرف- للمقال Create an offline fallback page للمؤلفين: Thomas Steiner و Pete LePage.

اقرأ أيضًا

• ما هي تطبيقات الويب التقدمية ولماذا يجب على المصممين الاهتمام بها؟
• استئناف رفع الملفات بعد فقدان الاتصال في جافاسكربت
• 3 أخطاء شائعة عند رفع الملفات باستخدام بروتوكول FTP وكيفية إصلاحها
• أنظمة التشغيل للمبرمجين

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

• مفاهيم بناء الواجهات الرسومية البسيطة.
• الوِدجات البسيطة.
• هيكل برنامج Tkinter بسيط.
• الواجهات الرسومية والبرمجة الكائنية التوجه، تطابق مثالي.
• wxPython بديل Tkinter.

مبادئ الواجهات الرسومية

لن نتعرض لمفاهيم برمجية جديدة هنا، فبرمجة الواجهات الرسومية تشبه أي نوع آخر من البرمجة، إذ تحوي تسلسلات sequences، ووحدات modules، وفروعًا branches، وحلقات تكراريةً loops، أما الأمر الإضافي فيها فهو استخدام صندوق أدوات Toolkit، واتباعنا نمطًا معينًا في تصميم البرمجيات يحدده من كتب صندوق الأدوات ذاك، لذا يكون لكل صندوق أدوات مجموعته الخاصة من الوحدات والأصناف والدوال، والتي تعرف باسم واجهة برمجة التطبيقات Application Programming Interface، واختصارًا API، كما يحتوي صندوق الأدوات على مجموعة من قواعد التصميم، وعلينا -نحن المبرمجون- أن نتعلم واجهة برمجة التطبيقات وقواعد التصميم معًا، ولهذا يحاول أغلبنا اعتماد صناديق أدوات قليلةً تكون متاحةً في عدة لغات برمجة، لأن تعلم استخدام صندوق الأدوات أصعب من تعلم لغة البرمجة نفسها.

صناديق أدوات الواجهات الرسومية

تأتي أغلب لغات برمجة نظام التشغيل ويندوز مع صندوق أدوات مضمن فيها، ويكون طبقةً خفيفةً فوق صندوق الأدوات البدائي المضمن في نظام النوافذ نفسه، ويوجد في لغات مثل Visual Basic وDelphi وVisual C++/.NET، أما جافا فتختلف عن لغات ويندوز في أنها تحتوي على صندوق أدوات الرسوم الخاص بها، بل أكثر من صندوق واحد في الواقع، وتعمل هذه الصناديق على أي منصة تعمل عليها جافا، وهذا يعني جميع المنصات تقريبًا، وتوجد صناديق أدوات أخرى يمكن الحصول عليها بشكل مستقل وتُستخدم في أي نظام تشغيل سواء كان لينكس أو ويندوز أو ماك، وتحتوي محولات adapters لتسمح للغات المختلفة باستخدامها، وبعض تلك الصناديق تجاري مدفوع، وبعضها مجاني أو حر، والأمثلة على هذه الصناديق تشمل GTK وQt وTk وwxWidegets، ولها جميعًا مواقع وتدعم ويندوز وماك ولينكس:

• wxPython: النسخة الخاصة ببايثون من wxWidgets، وهو مكتوب بلغة C++‎، وتسمى رابطة بايثون إلى wxWidgets باسم WxPython.
• PyQt, the Qt toolkit: يحتوي على روابط لأغلب لغات البرمجة، وتُعرف روابط بايثون إلى Qt باسم PyQt.
• GTK+‎: مجموعة من العناصر والأدوات لإنشاء واجهات رسومية، ورابطة بايثون فيه اسمها PyGTk.

تُكتب أغلب برامج لينكس باستخدام Qt وGTk، وكلاهما مجاني للاستخدامات غير التجارية، ويوفر Qt رخصةً تجاريةً لمن شاء، في حين أن رخصة GTk هي رخصة Gnu GPL التي لها شروطها الخاصة بها.

صندوق الأدوات الرسومي الخاص ببايثون والذي يأتي افتراضيًا مع اللغة هو Tkinter، المبني على Tk، وهو صندوق أدوات قديم متعدد نظم التشغيل، وسندرسه هنا، حيث توجد منه إصدارات للغات Tcl وHaskell وRuby وPerl وبايثون، وتختلف المبادئ المستخدمة في Tk عن صناديق الأدوات الأخرى قليلًا، لذا سنذكر باختصار نظرةً على صندوق أدوات رسومي آخر لبايثون و C و C++‎، يكون تقليديًا في منظوره العام، لكن سنتعرف أولًا على بعض المفاهيم العامة.

عناصر الواجهات الرسومية الأساسية

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

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

النافذة window

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

المتحكم Control

كائن رسومي يُستخدم للتحكم في التطبيق، وتحتوي المتحكمات على خصائص properties، وتولّد أحداثًا events، وتستجيب عادةً لكائنات على مستوى التطبيق، حيث تُرفَق الأحداث بتوابع الكائن الموافق corresponding object، فإذا وقع الحدث نفّذ الكائن أحد توابعه، وتوفر الواجهة الرسومية آليات لربط الأحداث بالتوابع.

الودجِت Widget

متحكم مقيَّد عادةً بالمتحكمات المرئية، إذ يمكن ربط بعض المتحكمات -مثل المؤقتات timers- بنافذة ما، لكن دون أن تكون مرئيةً، أما الودجات فهي فئة مرئية فرعية من المتحكمات، ويمكن للمستخدم أو المبرمج أن يعدل فيها.

سنغطي في هذا المقال الودجات Frame وLabel وButton وText Entry وMessage box، كما سنتعرض لاحقًا للودجات Text box وRadio Button، أما الودجات التي لن نذكرها مطلقًا فهي Canvas الخاصة بالرسم، وCheck button الخاصة بالاختيار المتعدد، وImage الخاص بعرض صور BMP وGIF وJPEG وPNG، وListbox للقوائم، و Menu/MenuButton لبناء القوائم المنسدلة menus، وScale/Scrollbar التي توضح الموضع.

الإطار Frame

نوع من الودجات يُستخدم لدمج ودجات أخرى معًا، ويُستخدم عادةً لتمثيل النافذة ككل، ويمكن دمج إطارات أخرى فيه.

التخطيط Layout

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

الأب/الابن Parent/Child

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

شجرة الاحتواء Containment tree

من المفاهيم التي يجب استيعابها في برمجة الواجهات الرسومية هرمية الاحتواء containment hierarchy، حيث تُحتوى الودجات داخل هيكل شجري تتحكم فيه ودجت المستوى الأعلى بالواجهة كلها، ويكون لذلك الهيكل ودجات فرعية يمكن أن تحتوي بدورها على ودجات أخرى فرعية خاصة بها، وتصل الأحداث إلى ودجت فرعية تمرر الحدث -إذا لم تستطع معالجته- إلى الودجت الرئيسية (الأب) لها، وهكذا إلى أن نصل إلى ودجت المستوى الأعلى، وإذا أُعطي أمر لرسم ودجت ما فسيرسَل الأمر إلى الودجات الفرعية، وعليه فإن أمر الرسم إلى ودجت المستوى الأعلى قد يعيد رسم التطبيق كله، في حين أن أمر الرسم المرسَل إلى زر ما لن يعيد إلا رسم الزر فقط.

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

توضح الصورة أعلاه ودجت المستوى الأعلى التي تحتوي على إطار Frame واحد يمثل الحد border الخارجي للنافذة، والذي يحتوي بدوره على إطارين آخرين، في الأول منهما ودجت Text Entry، وفي الثاني زران Buttons يُستخدمان للتحكم في التطبيق، وسنشير إلى هذا المخطط لاحقًا حين نأتي لبناء الواجهة الرسومية.

نظرة على بعض الودجات الشائعة

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

>>> from tkinter import * 

هذا أول متطلبات أي برنامج Tkinter، وهو استيراد أسماء الودجات، يجب أن نستورد الوحدة، لكننا لا نريد كتابة tkinter قبل كل اسم مكون، لذا نستخدم الاسم البديل tk:

 >>> import tkinter as tk

وهذا يعني أننا نحتاج إلى سبق الأسماء بـ tk.‎ فقط، لكن بما أننا نجرب هنا فمن الأسهل استيراد كل شيء:

>>> top = Tk()

ينشئ هذا ودجت المستوى الأعلى في هرمية الودجات، ونلاحظ حالة الأحرف في Tk، حيث كان اسم الوحدة بالأحرف الصغيرة، لكن اسم الودجت بأحرف كبيرة، وتُنشأ جميع الودجات الأخرى فروعًا لودجت top.

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

سنضيف المكونات إلى هذه النافذة أثناء بنائنا للتطبيق، ولننظر الآن إلى ما لدينا:

>>> dir(top)
[....lots of stuff!...]

توضح دالة dir()‎ الأسماء المعروفة للوسيط، ونستطيع استخدامها على الوحدات لكننا ننظر هنا إلى المكونات الداخلية للكائن top، وهو نسخة من الصنف Tk، حيث نلاحظ وجود سمات كثيرة للكائن top، نخص بالذكر منها children وmaster اللتان تمثلان روابط إلى شجرة احتواء الودجت، كما نلاحظ سمة _tclCommands_، لأن Tkinter بُني على صندوق أدوات من Tcl اسمه Tk.

>>> F = Frame(top)

لننشئ ودجت إطار Frame هنا تحتوي المتحكمات/الودجات الفرعية التي نستخدمها، ويحدد Frame كائن top على أنه معامله الأول -والوحيد في هذه الحالة-، وعليه فإن F ستكون ودجت فرعيةً للكائن top، ,يمكن التحقق من هذا بسهولة كما يلي:

>>> top.children
{'!frame': <tkinter.Frame object .!frame>}
>>> F.master
<tkinter.Tk object .> 

نرى هنا أن top.children ما هو إلا قاموس يربط اسمًا غريبًا قليلًا هو ‎'!frame'‎ بمرجع كائن object reference، وهذه التسمية الغريبة خاصة بـ Tcl/Tk وانتقلت إلى Tkinter، كما أن F.master ما هو إلا مرجع إلى top، وننصحك هنا بالتدرب على السمتين master وchildren لودجاتنا، مما يسهل عليك فهم الصلة بين الودجات وشجرة الاحتواء التي ذكرناها من قبل.

>>> F.pack()

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

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

>>> lHello = Label(F, text="Hello world")

ننشئ هنا كائنًا جديدًا هو lHello، وهو نسخة من الصنف Label مع ودجت أب هي F، وسمة text قيمتها "Hello World"، نلاحظ أنه من المعتاد استخدام تقنية المعامِل المسمى بتمرير الوسائط إلى كائنات Tkinter بسبب ميل منشئات كائنات Tkinter لامتلاك عدة معامِلات لكل منها قيمته الافتراضية، كما نلاحظ أن الكائن ليس مرئيًا بعد لأننا لم نحزّمه.

كما نلاحظ استخدام اصطلاح تسمية هنا، وهو حرف l الذي يشير إلى كلمة Label قبل الاسم Hello الذي يذكرنا بالغرض منه، ومسألة اصطلاحات التسمية هذه هي في الحقيقة أمور شخصية، لكنها مفيدة لهذا الغرض الذي ذكرناه.

>>> lHello.pack()

نستطيع الآن أن نراها، وينبغي أن تكون النافذة التي أنشأتها لديك شبيهة بهذه:

تُحدَّد خصائص Label -مثل الخط واللون- باستخدام معامِلات منشئ الكائن أيضًا، ونستطيع الوصول إلى الخصائص الموافقة corresponding باستخدام التابع configure الخاص بودجات Tkinter كما يلي:

>>> lHello.configure(text="Goodbye")

لقد تغيرت الرسالة هنا، لذا نرى أن تقنية configure ممتازة عند تغيير عدة خصائص مرةً واحدةً لتمريرها جميعًا على أنها وسطاء، لكن إذا أردنا تغيير خاصية واحدة فقط في كل مرة كما فعلنا أعلاه فيمكن معاملة الكائن على أنه قاموس، وهذا أقصر وأسهل في الفهم:

>>> lHello['text'] = "Hello again"

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

>>> F.master.title("Hello")

كان بإمكاننا استخدام top مباشرةً، لكن الوصول من خلال الخاصية الرئيسية للإطار مفيد، كما سنرى لاحقًا:

>>> bQuit = Button(F, text="Quit", command=F.quit)

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

يجب ألا تأخذ الدالة أو التابع أي وسطاء، ويُعرَّف التابع quit في صنف أساسي -وكذلك التابع pack- وترثه جميع ودجات Tkinter، لكنه يُستعدى في الغالب في مستوى النافذة العليا للتطبيق.

>>> bQuit.pack()

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

>>> top.mainloop()

وأخيرًا نبدأ حلقة حدث Tkinter، لاحظ اختفاء محث بايثون ‎>>>‎، وهذا يخبرنا أن Tkinter هو المتحكم الآن، فإذا ضغطنا زر Quit فسيعود المحث ليثبت لنا أن خيار command يعمل، لا تتوقع أن تنغلق النافذة، فلا زال مفسر بايثون يعمل ولم نرد إلا الخروج من دالة mainloop، فإذا خرجنا من بايثون فستُدمَّر الودجات الموجودة، ويكون هذا -في البرامج الحقيقية- بعد انتهاء mainloop مباشرة.

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

import tkinter as tk

# إعداد النافذة ذاتها
top = tk.Tk()
F = tk.Frame(top)
F.pack()

# إضافة الودجات
lHello = tk.Label(F, text="Hello")
lHello.pack()
bQuit = tk.Button(F, text="Quit", command=F.quit)
bQuit.pack()

# تشغيل الحلقة التكرارية
top.mainloop()

يبدأ استدعاء التابع top.mainloop حلقة حدث Tkinter لتوليد الأحداث، والحدث الوحيد الذي نلتقطه في هذه الحالة سيكون حدث ضغط الزر المتصل بالتابع F.quit، وينهي الأخير التطبيق وستنغلق النافذة هذه المرة لأن بايثون قد خرجت هي الأخرى، جربها بنفسك الآن، ينبغي أن تبدو كما يلي:

لاحظ أننا نسينا السطر الذي يغير عنوان النافذة، جرب إضافة ذلك السطر بنفسك وتحقق من نجاح ذلك.

استكشاف التخطيط

سنبدأ من الآن بإعطاء الأمثلة في ملفات سكربتات بايثون بدلًا من أوامر في محث ‎>>>‎، وسنوفر مقتطفات من الشيفرات في الغالب لتكتب أنت الاستدعاءات إلى Tk()‎ وmainloop()‎ بنفسك، فاستخدم البرنامج السابق قالبًا، وسننظر في هذا القسم في توضع الودجات في النافذة في Tkinter، وقد رأينا ودجات Frame وLabel وButton من قبل، وهي كل ما نحتاج إليه في هذا القسم، وقد استخدمنا التابع pack الخاص بالودجت في المثال السابق لتحديد موقعها في الودجت الأب لها، والواقع أن ما نفعله هو استدعاء مدير تخطيط المحزِّم الخاص بـ Tk، ويطلق عليه أحيانًا اسم المدير الهندسي Geometry Manager، ووظيفته تحديد أفضل تخطيط للودجات بناءً على الإرشادات التي يوفرها المبرمج، إضافةً إلى القيود مثل حجم النافذة التي يتحكم بها المستخدم، ويستخدم بعض مدراء التخطيطات نفس المواقع داخل النافذة محددةً بالبكسل، وهذا أمر شائع في بيئات ويندوز مثل Visual Basic.

ويحتوي Tkinter على مدير تخطيط واضع placer layout manager يستطيع تنفيذ ذلك من خلال تابع place، ولن ننظر فيه لوجود خيارات أخرى أفضل وأكثر ذكاءً للمدراء، لأنها توفر علينا التفكير -نحن المبرمجين- في ما يحدث عند تغيير حجم نافذة ما، وأبسط مدير تخطيط في Tkinter هو برنامج التحزيم الذي كنا نستخدمه، وهو يكدس الودجات بعضها فوق بعض، ويمكن تغيير هذا السلوك لتكديس الودجات يسارًا ويمينًا لكن هذا محدود للغاية، ونادرًا ما نريد ذلك من الودجات العادية، لكن إذا أردنا بناء تطبيقاتنا من إطارات Frames فيجب أن نكدس الإطارات فوق بعضها، ثم نستطيع وضع الودجات الأخرى في الإطارات باستخدام المحزِّم أو مدير تخطيط آخر داخل كل إطار حسب الحاجة، ويمكن أن يكون لكل إطار مدير التخطيط الخاص به، لكننا لا نستطيع الجمع بين المدراء في إطار واحد.

يوفر المحزِّم -وإن كان بسيطًا- عدة خيارات، إذ نستطيع ترتيب ودجاتنا رأسيًا أو أفقيًا، ونستطيع تعديل أحجامها وتعديل الفواصل بينها والإطار التي تحاذيه، لننظر في المثال التالي على التحزيم الأفقي:

lHello = tk.Label(F, text="Hello")
lHello.pack(side="left")
bQuit = tk.Button(F, text="Quit", command=F.quit)
bQuit.pack(side="left")

سيؤدي هذا إلى إجبار الودجات على الانتقال إلى اليسار، لذا ستظهر الودجت الأولى -وهي العنوان- في أقصى اليسار، متبوعةً بالودجت التالية -الزر-، فإذا عدّلنا الأسطر في المثال أعلاه فسيبدو كما يلي:

وإذا غيرنا "left" إلى "right" فسيظهر العنوان على أقصى اليمين، وسيظهر الزر على يساره، كما يلي:

يجب أن نلاحظ أن الشكل غير لطيف، لأن الودجات مضغوطة إلى جانب بعضها البعض، ويزودنا المحزِّم ببعض المعامِلات للتعامل مع ذلك، لعل أسهلها الحشو padding الذي يُحدَّد بحشو أفقي padx ورأسي pady، وتُكتب تلك القيم بالبكسل، لنضف حشوًا أفقيًا إلى مثالنا:

lHello.pack(side="left", padx=10)
bQuit.pack(side='left', padx=10)

يجب أن يبدو كما يلي:

إذا حاولنا تغيير عرض النافذة فسنرى أن الودجات تحافظ على مواضعها النسبية، لكنها ستظل في مركز النافذة، لأننا -رغم إضافتنا الحشو إلى اليسار- حزمنا الودجات في إطار Frame؛ وحزّمنا الإطار نفسه دون جانب side، لذا فإن موضعه يكون إلى الأعلى والمنتصف، وهو الافتراضي للمحزِّمات، فإذا أردنا أن تبقى الودجات في الجانب الصحيح من النافذة فيجب أن نحزم الإطار إلى الجانب الصحيح كذلك:

F.pack(side='left')

نلاحظ هنا أن الودجات تظل في المنتصف إذا غيرنا حجم النافذة الرأسي، وهذا هو السلوك الافتراضي للمحزِّمات أيضًا، سنترك لك تجربة تغيير padx وpady لترى تأثير القيم المختلفة عليها. وتسمح side وpadx/pady بمرونة كبيرة في تحديد مواضع الودجات باستخدام المحزِّم، وتوجد خيارات أخرى يضيف كل منها شكلًا خفيفًا من أشكال التحكم، يُرجَع فيها إلى توثيق Tkinter.

يوجد عدة مدراء تخطيطات آخرين في Tkinter مثل الشبكة grid والواضع placer، إضافةً إلى وحدة Tix التي تعزز Tkinter وتوفر مدير التخطيط Form، لكننا لن نشرح هذه الوحدة هنا لأنها أُهملت في المكتبة القياسية رسميًا.

نستخدم grid()‎ إذا أردنا استخدام مدير الشبكة grid manager، بدلًا من pack()‎ التي استخدمناها أعلاه، أما في الواضع placer فنستدعي place()‎ بدلًا من pack()‎، ولكل منها مجموعة خيارات خاصة، وبما أننا سنشرح المحزِّم فقط هنا فيُرجَع إلى توثيق Tkinter لمزيد من التفاصيل عن هؤلاء المدراء، لكن النقاط الأساسية التي نريد الإشارة إليها هنا هي ما يلي:

• تنظم الشبكة المكونات في "شبكة" داخل النافذة، وهذا مفيد في الصناديق الحوارية التي تحوي صناديق إدخال نصيةً مرتبةً مثلًا، ويفضل العديد من مستخدمي Tkinter استخدام الشبكة على المحزِّم، لكن قد يحتاج المبتدئ وقتًا حتى يتعلمها، خاصةً عندما يريد أن يشغل مكون عدة خلايا من الشبكة.
• يستخدم الواضع إحداثيات ثابتةً بالبكسل أو إحداثيات نسبيةً داخل النافذة، وتسمح الأخيرة بتغيير حجم المكونات مع تغير حجم النافذة، كأن تظل المساحة التي تشغلها 75% من المساحة الرأسية للنافذة مثلًا، لكن قد يبدو مظهر الأزرار غريبًا إذا زاد عرضها كثيرًا، وتظهر فائدة هذا في التصاميم المعقدة للنوافذ، لكنها تحتاج إلى كثير من التخطيط المسبق، لذا يُنصح باستخدام الورق والقلم!

التحكم في المظهر باستخدام الإطارات والمحزم

تحتوي ودجت الإطار Frame على العديد من الخصائص المفيدة التي يمكن استخدامها، فمن الجميل أن يكون لدينا إطار منطقي غير مرئي حول المكونات، لكننا قد نرغب في رؤيته، خاصةً عند جمع عدة متحكمات مثل أزرار الانتقاء radio buttons أو صناديق الاختيار check boxes، ويحل الإطار هذه المشكلة بتوفير حد يُعرف بخاصية المساعدة relief property، على غرار العديد من ودجات Tkinter الأخرى، يمكن أن تأخذ Relief إحدى القيم التالية:

• sunken: غائر.
• raised: مرتفع.
• groove: محفور.
• ridge: مشطوف.
• flat: مسطح.

لنستخدم القيمة sunken على صندوق حوارنا البسيط، بتغيير سطر إنشاء الإطار Frame إلى ما يلي:

 F = Frame(top, relief="sunken", border=1) 

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

ومما يجب ملاحظته أيضًا أن الإطار لا يملأ النافذة، ونستطيع إصلاح ذلك بخيار محزِّم آخر هو fill، فنفعل ما يلي عند تحزيم الإطار:

F.pack(fill="x")

ستُملأ النافذة عرضيًا كما هو واضح من الإحداثي x، فإذا أردنا ملأها كلها فنستخدم fill='y'‎ أيضًا، ويوجد خيار ملء خاص هو both بسبب شيوع هذه العملية:

F.pack(fill="both")

ينبغي أن تكون النتيجة النهائية بعد تشغيل السكربت كما يلي:

إضافة ودجات أخرى

لننظر الآن في الودجت Entry، وهو السطر الواحد ذو الشكل المألوف لصندوق الإدخال النصي، والذي يتشارك الكثيرَ من التوابع مع ودجت النص متعدد الأسطر الذي استخدمناه في المقال السابق، كما سنستخدمه في مقال لاحق، وسنستخدم Entry لالتقاط النص الذي يكتبه المستخدم، ولمحو ذلك النص عند الحاجة.

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

import tkinter as tk

# أنشئ معالج الحدث لمسح النص
def evClear():
   eHello.delete(0,tk.END)

# أنشئ نافذة/إطار المستوى الأعلى
top = tk.Tk()
F = tk.Frame(top)
F.pack(fill="both")

# والآن الإطار الذي فيه الإدخال النصي
fEntry = tk.Frame(F, border=1)
eHello = tk.Entry(fEntry)
fEntry.pack(side="top")
eHello.pack(side="left")

# وأخيرًا الإطار الذي فيه الأزرار 
# سنجعل هذا غاطسًا لنبرزه
fButtons = tk.Frame(F, relief="sunken", border=1)
bClear = tk.Button(fButtons, text="Clear Text", command=evClear)
bClear.pack(side="left", padx=5, pady=2)
bQuit = tk.Button(fButtons, text="Quit", command=F.quit)
bQuit.pack(side="left", padx=5, pady=2)
fButtons.pack(side="top", fill="x")

# والآن شغل حلقة الحدث
F.mainloop()

نلاحظ هنا أننا عرّفنا معالج الحدث مثل أي دالة أخرى، وبما أننا نريد إسنادها إلى حدث الأمر command event لزر فنعرف أنها يجب ألا تحتوي على معامِلات، رغم أن بعض معالجات الأحداث -مثل أحداث الفأرة- قد تأخذ معامِلات، لكن يجب التحقق من التوثيق لمعرفة المطلوب للحدث.

لاحظ أيضًا أننا نمرر أسماء معالجات الأحداث evClear وF.quit -دون أقواس- قيمًا للمعامل command للأزرار، ولاحظ استخدام اصطلاح التسمية evXXX لربط معالج الحدث بالودجت XXX الموافقة له، لذا سيكون evClear هو معالج الحدث لودجت bClear.

يستدعي معالج الحدث التابع delete الخاص بالودجت Entry، ورغم أن نظام الفهرسة المستخدم للوسطاء معقد قليلًا إلا أننا نستطيع في هذا المستوى أن نقول بأنه يمسح النص من الموضع 0 -أي من البداية- إلى الموضع tk.END -آخر موضع-، ولاحظ أن tk.END ثابت معرَّف في tkinter، ويوجد غيره مما يمكن استخدامه بدلًا من السلاسل الاختيارية right وleft وtop وغيرها، وذلك راجع لما يفضله كل منا، وبتشغيل البرنامج نحصل على النتيجة التالية:

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

لاحظ أننا بنينا الواجهة الرسومية التي رسمها مخطط الاحتواء في بداية هذا المقال، فللودجت العليا إطار Frame تحتها، وفيه إطاران تحته، واحد فيه ودجت إدخال والآخر فيه زران، وهذا ما نراه في المخطط بالضبط.

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

import tkinter as tk

# أنشئ معالج الحدث لمسح النص
def evClear():
  lHistory['text'] = eHello.get()
  eHello.delete(0,tk.END)

# أنشئ نافذة/إطار المستوى الأعلى
top = tk.Tk()
F = tk.Frame(top)
F.pack(fill="both")

# والآن الإطار الذي فيه الإدخال النصي
fEntry = tk.Frame(F, border=1)
eHello = tk.Entry(fEntry)
eHello.pack(side="left")
lHistory = tk.Label(fEntry, foreground="steelblue")
lHistory.pack(side="bottom", fill="x")
fEntry.pack(side="top")

# وأخيرًا الإطار الذي فيه الأزرار 
# سنجعل هذا غائرًا لنبرزه
fButtons = tk.Frame(F, relief="sunken", border=1)
bClear = tk.Button(fButtons, text="Clear Text", command=evClear)
bClear.pack(side="left", padx=5, pady=2)
bQuit = tk.Button(fButtons, text="Quit", command=F.quit)
bQuit.pack(side="left", padx=5, pady=2)
fButtons.pack(side="top", fill="x")

# والآن شغل حلقة الحدث
F.mainloop()

نرى هنا أننا أضفنا السطر التالي عند إنشاء معالج الحدث الذي يمسح النص:

  lHistory['text'] = eHello.get()

كما أضفنا الأسطر التالية في الإطار الذي يحتوي على إدخال نصي:

lHistory = tk.Label(fEntry, foreground="steelblue")
lHistory.pack(side="bottom", fill="x")

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

أحداث الربط: من الودجات إلى الشيفرة

لقد استخدمنا الخاصية command للأزرار إلى الآن لربط دوال بايثون مع أحداث الواجهة الرسومية، لكننا قد نريد تحكمًا أكثر من هذا أحيانًا، لالتقاط تجميعة مفاتيح معينة مثلًا، ونفعل ذلك باستخدام دالة bind لربط حدث ما مع دالة بايثون صراحةً.

سنعرِّف الآن مفتاحًا ساخنًا مثل CTRL+C لحذف النص في المثال أعلاه، سنحتاج هنا أن نربط تجميعة المفاتيح CTRL+C بنفس معالج الحدث الخاص بزر Clear، لكننا سنواجه مشكلةً غير متوقعة هنا، إذ يجب ألا تأخذ الدالة المحددة أي وسطاء عند استخدامنا للخيار command، أما حين نستخدم دالة الربط bind لأداء نفس الوظيفة فيجب أن تأخذ الدالة المحددة وسيطًا واحدًا، لذا نحتاج إلى إنشاء دالة جديدة ذات معامِل وحيد تستدعي evClear، أضف الشيفرة التالية بعد تعريف evClear:

def evHotKey(event):
    evClear()

ثم أضف السطر التالي مباشرةً بعد تعريف ودجت الإدخال eHello:

eHello.bind("<Control-c>",evHotKey) # تعريف المفتاح حساس لحالة الأحرف

شغّل البرنامج الآن مرةً أخرى، ستستطيع مسح النص الآن بضغط الزر أو باستخدام تجميعة المفاتيح CTRL+C، ويمكن استخدام الربط لالتقاط نقرات الفأرة أو فقدان تركيز النافذة Focus -أي كونها نشطةً أو غير نشطة-، أو حتى كون النافذة مرئيةً أم لا، ويُرجَع في هذا إلى توثيق Tkinter لمزيد من المعلومات، وسيكون الجزء الأصعب هو معرفة صيغة وصف الحدث.

الرسالة القصيرة

من الممكن إبلاغ رسائل قصيرة للمستخدمين باستخدام MessageBox، وهذا سهل للغاية في Tk ويمكن تنفيذه باستخدام دوال وحدة messagebox كما يلي:

from tkinter import messagebox
messagebox.showinfo("Window Text", "A short message") 

هناك أيضًا صناديق الخطأ والتحذير وصناديق نعم ولا Yes/No وموافق وإلغاء Ok/Cancel التي يمكن استخدامها من خلال دوال showXXX المختلفة، ويمكن تمييزها بأيقوناتها وأزرارها المختلفة، ويستخدم الصندوقان الأخيران askxxx بدلًا من showxxx، ويعيد قيمةً لتوضيح على أي زر ضغط المستخدم، كما يلي:

res = messagebox.askokcancel("Which?", "Ready to stop?")
print res

فيما يلي بعض الأمثلة لصناديق الرسائل في Tkinter:

وهذا شبيه بصناديق alert وMsgBox التي استخدمناها في برامج الويب من جافاسكربت وVBScript في دروسنا الأولى.

كما توجد صناديق حوارية قياسية يمكن استخدامها للحصول على أسماء الملفات أو المجلدات من المستخدم، تشبه صناديق "Open File" أو "Save File"، ولن نشرحها هنا لكن يمكن الاطلاع على أمثلة عنها في صفحات Tkinter المرجعية، تحت قسم Standard Dialogs.

تغليف التطبيقات مثل الكائنات

من الشائع في برمجة الواجهات الرسومية أن نغلف التطبيق كله مثل صنف واحد، وهذا يطرح سؤال كيف نلائم ودجات تطبيق Tkinter في هيكل هذا الصنف؟

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

سنحول المثال أعلاه إلى هيكل كائني التوجه باستخدام حقل إدخال وزر Clear وزر Quit، لكننا سننشئ أولًا صنف تطبيق، ونجمّع الأجزاء المرئية للواجهة الرسومية داخل الباني Constructor، ثم نسند الإطار الناتج إلى self.mainWindow، سامحين بهذا للتوابع الأخرى للصنف بالوصول إلى إطار المستوى الأعلى، وتُسنَد الودجات الأخرى التي قد نحتاج إلى الوصول إليها -مثل حقل الإدخال- إلى متغيرات أعضاء member variables للتطبيق.

تصبح معالجات الأحداث توابعًا لصنف التطبيق باستخدام هذه التقنية، ويكون لها وصول إلى أي أعضاء بيانات data members لتطبيق -رغم عدم وجود أي منها في حالتنا هنا- من خلال مرجع self، مما يوفر تكاملًا سلسًا للواجهة الرسومية مع كائنات التطبيق الأساسية:

import tkinter as tk

# أنشئ معالج الحدث لمسح النص
class ClearApp:
    def __init__(self, parent):
        # create the top level window/frame
        self.mainWindow = tk.Frame(parent)
        self.eHello = tk.Entry(self.mainWindow)
        self.eHello.insert(0,"Hello world")
        self.eHello.pack(fill="x", padx=5, pady=5)
        self.eHello.bind("<Control-c>", self.evHotKey)

        # والآن أنشئ الإطار ذا الأزرار. 
        fButtons = tk.Frame(self.mainWindow, height=2)
        self.bClear = tk.Button(fButtons, text="Clear",
                             width=10, height=1,command=self.evClear)
        self.bQuit  = tk.Button(fButtons, text="Quit",
                             width=10, height=1, command=self.mainWindow.quit)
        self.bClear.pack(side="left", padx=15, pady=1)
        self.bQuit.pack(side="right", padx=15, pady=1)
        fButtons.pack(side="top", pady=2, fill="x")
        self.mainWindow.pack()
        self.mainWindow.master.title("Clear")

    def evClear(self):
        self.eHello.delete(0,tk.END)

    def evHotKey(self, event):
        self.evClear()

# والآن أنشئ التطبيق وشغل حلقة الحدث
top = tk.k()
app = ClearApp(top)
top.mainloop()

ستكون النتيجة كما يلي:

تبدو النتيجة مشابهةً للصورة السابقة، رغم أننا عدلنا بعض الإعدادات وخيارات التحزيم لتبدو أشبه بمثال wxPython أدناه.

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

يحتوي Tkinter بدءًا من الإصدار 3.1 على بعض المزايا الجديدة التي تُعرف باسم الودجات ذات السمات themed widgets، وتوجد في وحدة tkinter.ttk، وهي تحسن كثيرًا من مظهر Tkinter إلى حد يصعب التفريق بين نوافذه وبين ودجات النظام المضمّنة، لكننا لن نشرحها هنا، ويُرجَع فيها إلى موقع Tcl/Tk.

صندوق الأدوات البديل wxPython

توجد عدة صناديق أدوات أخرى للواجهات الرسومية، لعل أشهرها صندوق WxPython الذي يغلف ودجات صندوق أدوات C++‎، وهذا الصندوق -أي WxPython- أكثر شيوعًا من صندوق أدوات Tkinter عمومًا بين صناديق الواجهات المرئية، حيث يوفر وظائف قياسيةً افتراضيًا أكثر من Tk، مثل التلميحات tooltips، وشرائط الحالة status bars وغيرها، أما في Tk فيجب إنشاؤها يدويًا، وسنستخدم wxPython لإعادة إنشاء مثال Hello World أعلاه.

لكن المشكلة هنا هي أن wxPython ليس متاحًا بعد للإصدار الثالث من بايثون حتى الوقت الذي كتبنا فيه هذه الكلمات، مما يعني أننا سنعامل شيفرة الإصدار الثاني أدناه على أنها مجرد تدريب للقراءة لا غير، أو يمكن تثبيت الإصدار 2.7 من بايثون إذا أردنا التطبيق العملي، وتنزيل الحزمة من موقع wxPython، إذ لن ندخل كثيرًا في التفاصيل هنا، وعمومًا يعرِّف صندوق الأدوات إطار عمل يسمح لنا بإنشاء نوافذ وملئها بعناصر التحكم، وربط توابع بهذه المتحكمات، وبما أن هذا كائني التوجه فيجب استخدام التوابع وليس الدوال، ويبدو المثال كما يلي:

import wx

# --- عرّف إطارًا مخصصًا. سيكون هو النافذة الأساسية ---
class HelloFrame(wx.Frame):
   def __init__(self, parent, id, title, pos, size):
        super().__init__(parent, id, title, pos, size)
       # we need a panel to get the right background
        panel = wx.Panel(self)

        # أنشئ ودجتي النص والزر
        self.tHello = wx.TextCtrl(panel, -1, "Hello world", pos=(3,3), size=(185,22))
        bClear = wx.Button(panel, -1, "Clear", pos=(15, 32))
        self.Bind(wx.EVT_BUTTON, self.OnClear, bClear)
        bQuit = wx.Button(panel, -1, "Quit", pos=(100, 32))
        self.Bind(wx.EVT_BUTTON, self.OnQuit, bQuit)

   # هذه معالجات الأحداث الخاصة بنا
   def OnClear(self, event):
       self.tHello.Clear()

   def OnQuit(self, event):
       self.Destroy()

# --- عرّف كائن التطبيق ---
# يجب أن تعرّف صنف تطبيق wxPython لاحظ أن كل برامج  
# wx.App مشتق من 
class HelloApp(wx.App):
   def OnInit(self):
       frame = HelloFrame(None, -1, "Hello", (200,50), (200,90) )
       frame.Show(True)
       self.SetTopWindow(frame)
       return True

# أنشئ نسخة وابدأ حلقة الحدث
HelloApp().MainLoop()

نلاحظ استخدام اصطلاح التسمية onXXXX للتوابع التي يستدعيها إطار العمل، واستخدام ثوابت EVT_XXX لربط الأحداث بالودجات، وتوجد مجموعة كبيرة منها.

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

وقد يكون من المهم ملاحظة أن هذا المثال ومثال Tkinter الشبيه به أعلاه يحتويان على نفس عدد الأسطر البرمجية تقريبًا، إذ يحتوي مثال Tk على 23 سطرًا، ومثال wxPython على 21، فإذا رغبنا في واجهة رسومية سريعة لأداة نصية فسيكون Tk كافيًا، أما إذا أردنا بناء تطبيقات كاملة تعمل على عدة منصات تشغيل فينبغي استخدام wxPython.

ومن صناديق الأدوات الأخرى MFC و‎.NET، ولا ننسى Curses التي هي واجهة رسومية مبنية على نصوص، ويمكن تطبيق كثير من الدروس التي تعلمناها مع Tkinter على كل صناديق الأدوات هذه، لكن لكل منها مزاياه وعيوبه، فاختر واحدًا وتعرف عليه واستمتع ببرمجة الواجهات الرسومية.

أخيرًا نشير إلى أن العديد من صناديق الأدوات لها أدوات بناء رسومية، مثل Blackadder لـ Qt ، وGlade لــ GTK ، وكذلك يحتوي wxPython على بانٍ رسومي هو Boa Constructor رغم أنه لا زال في مرحلة الإصدار Alpha مما يعني أنه غير مستقر، كما يوجد بانٍ رسومي لصندوق Tk يسمى GUI Builder كان مخصصًا ابتداءً لبناء واجهات Tcl/Tk، لكنه يستطيع توليد شيفرات في عدة لغات بما فيها بايثون.

توجد عدة كتب أخرى لاستخدام Tcl/Tk وعدة كتب أخرى من بايثون لديها فصول عن Tk، وسنعود إليه في مقال قادم، حين نشرح طريقة تغليف برنامج وضع باتش batch mode في واجهة رسومية لتحسين الاستخدام.

خاتمة

نرجو في نهاية هذا المقال أن تكون تعلمت ما يلي:

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

ترجمة -بتصرف- للفصل التاسع عشر: GUI Programming with Tkinter من كتاب Learn To Program لصاحبه Alan Gauld.

اقرأ أيضًا

• المقال التالي: مفهوم التعاودية Recursion
• المقال السابق: البرمجة الحدثية Event Driven Programming المساقة بالأحداث
• البرمجة كائنية التوجه (Object Oriented Programming) في PHP
• البرمجة كائنية التوجه (Object Oriented Programming) في لغة سي شارب #C
• تطبيق البرمجة كائنية التوجه في لغة سي شارب #C - الجزء الثالث
• التعابير النمطية في البرمجة

يُحدّد ملف بيان تطبيق الويب web app manifest مظهر وسلوك صفحات الويب التقدميّة PWA كما يجب أن يعرضها المتصفح بعد تثبيت التطبيق على سطح مكتب أو جوّال المستخدم، وهو عبارة عن ملف مكتوب بصيغة جيسون JSON.

تدّعم معظم المتصفحات ملف بيان تطبيق الويب مثل Chrome و Edge و Firefox و UC Browser و Opera و Samsung أما المتصفح Safari فيوفر دعمًا جزئيًا فقط.

إنشاء ملف بيان تطبيق الويب

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

نٌبين فيما يلي مثالًا عن محتوى بيان الويب:

{
  "short_name": "Weather",
  "name": "Weather: Do I need an umbrella?",
  "icons": [
    {
      "src": "/images/icons-192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "/images/icons-512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "start_url": "/?source=pwa",
  "background_color": "#3367D6",
  "display": "standalone",
  "scope": "/",
  "theme_color": "#3367D6",
  "shortcuts": [
    {
      "name": "How's weather today?",
      "short_name": "Today",
      "description": "View weather information for today",
      "url": "/today?source=pwa",
      "icons": [{ "src": "/images/today.png", "sizes": "192x192" }]
    },
    {
      "name": "How's weather tomorrow?",
      "short_name": "Tomorrow",
      "description": "View weather information for tomorrow",
      "url": "/tomorrow?source=pwa",
      "icons": [{ "src": "/images/tomorrow.png", "sizes": "192x192" }]
    }
  ],
  "description": "Weather forecast information",
  "screenshots": [
    {
      "src": "/images/screenshot1.png",
      "type": "image/png",
      "sizes": "540x720"
    },
    {
      "src": "/images/screenshot2.jpg",
      "type": "image/jpg",
      "sizes": "540x720"
    }
  ]
}

أهم خصائص ملف بيان الويب

سنشرح أهم الخصائص التي يحويها ملف بيان الويب والتي عليك ضبطها لتطبيقك.

الاسم القصير short_name و/أو الاسم name

يجب تضمين، على الأقل، إحدى الخاصيتين: الاسم القصير short_name أو الاسم name. وفي حال توفر كلتيهما يُستخدم الاسم القصير في شاشة المستخدم الرئيسية home screen وفي مُشغّل التطبيق launcher وفي أي مكان لا تتوفر فيه المساحة الكافية لعرض الاسم كاملًا؛ أما الاسم فيُستخدم عند تثبيت التطبيق.

الأيقونات icons

يُمكن تحديد مجموعة من الأيقونات ليعرضها المتصفح على الشاشة الرئيسية home screen وعلى مُشغّل التطبيق launcher وعلى مُبدّل المهام task switcher وعلى شاشة البداية splash screen وغيرها، بعد أن يقوم المستخدم بتثبيت صفحات الويب التقدميّة.

تكون قيمة خاصية الأيقونات icons مصفوفة من العناصر، يحوي كل عنصر منها خاصية المصدر src وخاصية القياسات sizes وخاصية نوع الصورة type. يجب إضافة "purpose": "any maskable" إلى خاصية الأيقونة icon في حال الحاجة لاستخدام الأيقونات المقنّعة maskable icons والتي تُدعى أيضًا بالأيقونات المتكيفة في أندرويد.

يتطلب استخدام المتصفح توفير أيقونات بقياس 192x192 بكسل وبقياس 512×512 بكسل على الأقل. إذا توفر هذان القياسان فقط سيقوم المتصفح Chrome بتحجيم الأيقونات لتتناسب مع الجهاز المستخدم. في حال أردت الوصول لكمال الإظهار pixel-perfection فعليك توفير أيقونات بقياسات من مضاعفات 48dp.

عنوان بدء التطبيق start_url

توجه الخاصية المطلوبة start_url المتصفح إلى عنوان أو رابط الصفحة التي يجب أن يبدأ منها التطبيق عند تشغيله، وتمنع التطبيق من البدء من الصفحة التي يتصفحها المستخدم عند إضافة التطبيق لشاشته الرئيسية.

توجه الخاصية start_url المستخدم مباشرًة إلى التطبيق عوضًا عن صفحة الهبوط landing page لمنتج ما. يجب دومًا التفكير بما يريد المستخدم أن يقوم به حال فتح التطبيق ومن ثم وضعه في المكان المناسب.

لون الخلفية backgroud_color

تُستخدم خاصية لون الخلفية لشاشة البداية splash screen عند تشغيل التطبيق لأول مرة على الجوّال.

العرض display

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

ملء الشاشة fullscreen

فتح تطبيق الويب دون أي واجهة متصفح متاحة للمستخدم وشغل مساحة العرض المتاحة بالكامل.

مستقل standalone

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

الحد الأدنى من الواجهة minimal-ui

يشبه هذا الوضع الوضع المستقل السابق إلا أنه يوفر للمستخدم مجموعة صغيرة من عناصر التنقل (مثل الرجوع back وإعادة التحميل reload).

متصفح browser

يتيح هذا الوضع تجربة استخدام متصفح تمامًا.

تجاوز العرض display_override

تُحدّد خاصية العرض display في ملف بيان تطبيق الويب وضع العرض كما هو موضح أعلاه. ليس مطلوبًا من جميع المتصفحات أن توفر كل أوضاع العرض السابقة إلا أن عليها أن تدعم السلسلة الاحتياطية وفق المواصفات المحدّدة spec-defined fallback chain أي التسلسل: ("ملء الشاشة" fullscreen← "مستقل" standalone← "الحد الأدنى من الواجهة" minimal-ui← "المتصفح "browser) والتي تُحتّم على المتصفح في حال عدم إمكانية دعمه لوضع معين أن يوفر الوضع التالي له في السلسلة. يُمكن أن يؤدي هذا السلوك غير المرن لبعض المشاكل في حالات نادرة جدًا كعدم استطاعة المطور أن يطلب وضع الحد الأدنى minimal-ui دون العودة بشكل قسري إلى وضع المتصفح browser وذلك إذا كان وضع الحد الأدنى غير مدعوم أصلًا. يُمكن أن يؤدي هذا السلوك أيضًا إلى مشكلة عدم القدرة على تضمين أوضاع عرض جديدة متوافقة مع الإصدارات السابقة، مثلًا: لا يُمكن التوافق مع وضع التبويب tabbed application mode غير الموجود في السلسلة الاحتياطية.

تحل خاصية "تجاوز العرض" display_override جميع هذه المشاكل حيث يعتمد المتصفح هذه الخاصية قبل خاصية العرض display. توضع قيمة هذه الخاصية على شكل تسلسل مرتب من السلاسل النصية وبحيث يُطبّق أول عرض منها مدعوم من قبل المتصفح، وفي حال عدم وجود أي عرض مدعوم يعود المتصفح إلى خاصية العرض display.

تكون السلسلة الاحتياطية في المثال التالي كما يلي (مع ملاحظة أن تفاصيل الوضع window-control-overlay خارج إطار هذه المقالة):

1. وضع تراكب عناصر النافذة window-control-overlay (أولًا ننظر إلى الخاصية display_override).
2. وضع الحد الأدنى من الواجهة minimal-ui.
3. الوضع المستقل standalone (إذا استُنفذت كل الأوضاع في display_override نعود إلى الخاصية display).
4. وضع الحد الأدنى من الواجهة minimal-ui (نعود في النهاية للسلسلة الاحتياطية للخاصية display).
5. وضع المتصفح browser.

{
  "display_override": ["window-control-overlay", "minimal-ui"],
  "display": "standalone",
}

لا يقوم المتصفح باستخدام الخاصية display_override ما لم تكن الخاصية display موجودة.

النطاق scope

يُحدّد النطاق scope عناوين URLs الصفحات التي يعتبرها المتصفح واقعة ضمن التطبيق وتُستخدم لمعرفة وقت مغادرة المستخدم لهذا التطبيق. يتحكم النطاق ببنية هذه المحدِّدات والتي تتضمن جميع نقاط الدخول والخروج للتطبيق. بالطبع، يجب أن يكون رابط URL للبداية start_url ضمن محدِّدات النطاق هذه.

تحذير: في حال نقر المستخدم لأحد روابط التطبيق الذي يُخرجه من النطاق، فسيُفتح الرابط للعرض ضمن نافذة صفحات الويب التقدميّة الحالية. إذا كان المطلوب فتح الرابط ضمن تبويب جديد للمتصفح فيجب إضافة "target="_blank لوسم الرابط <a>. تُفتح مثل هذه الروابط في أندرويد بتبويب مخصص للمتصفح Chrome Custom Tab.

يجب أخذ الملاحظات التالية حول النطاق scope بعين الاعتبار:

• في حال عدم تحديد النطاق scope في ملف بيان الويب، فسيكون النطاق الافتراضي هو المجلد الذي يحوي ملف بيان الويب.
• يُمكن أن تُحدّد قيمة النطاق مسارًا نسبيًا (/..) أو أي مسار لمستوى أعلى (/) مما يسمح بتغطية أكبر للتنقلات في التطبيق.
• يجب أن يكون رابط URL للبداية start_url ضمن محدِّدات النطاق scope.
• يكون رابط URL للبداية start_url نسبي للمسار المُعرّف في النطاق scope.
• إذا ابتدأ start_url بالمحرف / فسيكون دومًا الجذر للبداية.

لون النمط theme_color

يُحدّد لون النمط theme_color لون شريط الأدوات، وقد يُستخدم في عرض التطبيق ضمن محوّل المهام task switchers. يجب أن يُطابق لون النمط اللون المحدّد في السمة meta في ترويسة الصفحة.

بدءًا من نسخ المتصفحات Chromium 93 و Safari 15، يُمكن ضبط لون النمط باستخدام استعلام وسائط media query للخاصية media في السمة meta وباعتماد أول لون مطابق. يُمكن مثلًا تحديد لون ما للوضع الساطع وآخر للوضع الداكن. لايُمكن، حتى وقت كتابة هذه المقالة، تحديد هذا السلوك في ملف بيان الويب (يُمكنك العودة لمناقشة هذه المشكلة في w3c/manifest#975 GitHub issue)

<meta name="theme-color" media="(prefers-color-scheme: light)" content="white">
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="black">

الاختصارات shortcuts

تسمح هذه الخاصية بتعريف مجموعة من الاختصارات للمهام الأساسية للتطبيق وهي عبارة عن مصفوفة يكون كل عنصر فيها من النوع "كائن اختصار" app shortcut. يُعرّف الكائن باستخدام قاموس من الأزواج مفتاح/قيمة ويجب أن يحوي على الأقل المفتاح name والمفتاح url.

الوصف description

تشرح هذه الخاصية الهدف من التطبيق.

اللقطات screenshots

تكون قيمة هذه الخاصية مصفوفة من كائنات الصور لبعض لقطات سيناريوهات الاستخدام الشائعة للتطبيق. يجب أن يتضمن كل كائن خاصية المصدر src والقياسات sizes و النوع type.

يجب أن تحترم الصورة المعايير التالية في المتصفح Chrome:

• لا يقل قياس كل من العرض والارتفاع عن 320 بكسل ولا يزيد عن 3840 بكسل.
• لا يزيد البعد الأكبر عن 2.3 ضعف البعد الأقل.
• لجميع اللقطات نفس نسبة الطول إلى العرض aspect ratio.
• تنسيقات الصور JPEG أو PNG فقط.

اقتباس

ملاحظة: تُستخدم الخاصيتان description و screenshots حاليًا في المتصفح Chrome لتطبيقات أندرويد عندما يطلب المستخدم تثبيت التطبيق. سيتم تفعيل الراية about://flags/#mobile-pwa-install-use-bottom-sheet في النسخة 90 من Chrome.

إضافة ملف بيان الويب إلى صفحات التطبيق

يُمكن، بعد الانتهاء من إنشاء ملف بيان الويب، إضافة الوسم <link> لجميع صفحات الويب التقدميّة للتطبيق. مثلًا:

<link rel="manifest" href="/manifest.json">

اقتباس

ملاحظة: لا يحتاج طلب بيان الويب إلى اعتماديات credentials، وفي حال الحاجة إليها يُمكن تضمين "crossorigin="use-credentials في سمات ملف البيان.

اختبار ملف البيان

يُمكن استخدام جزء البيان Manifest في لوحة التطبيق Application من أدوات التطوير DevTools في المتصفح Chrome للتحقق من إعداد ملف البيان بشكل صحيح.

يسمح جزء البيان Manifest بمعاينة معظم خصائص ملف البيان بشكل مرئي، ويُسهّل التحقق من تحميل جميع الصور بشكل صحيح.

شاشة البدء على الجوال

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

يقوم المتصفح بإنشاء شاشة البداية آليًا معتمدًا على خصائص ملف البيان ولا سيما:

• الاسم name.
• لون الخلفية background_color.
• الأيقونات icons.

يجب أن يكون لون الخلفية background_color نفس لون صفحة التحميل لتوفير انتقال سلس من شاشة البداية إلى واجهة التطبيق الأولى.

يختار المتصفح Chrome الأيقونة الأنسب لدقة الجهاز. يُمكن أن يكون توفير أيقونات بقياس 193 بكسل و512 بكسل كافيًا في معظم الحالات، إلا أن توفير أيقونات إضافية بقياسات مختلفة يوصل لكمال الإظهار بشكل عام.

ترجمة -وبتصرف- للمقال Add a web app manifest للمؤلفين: Pete LePage و François Beaufort و Thomas Steiner.

اقرأ أيضًا

• مدخل إلى تطبيقات الويب التقدمية PWA
• ما هي تطبيقات الويب التقدمية ولماذا يجب على المصممين الاهتمام بها؟
• صيغة JSON وتوابعها في جافاسكربت
• صيغة JSON وXML في PHP

درسنا حتى الآن البرامج جزئية التوجه batch oriented programs، والتي تستدعى بإحدى طريقتين: جزئية التوجه batch oriented، حيث تبدأ البرامج بالعمل ثم تنفذ شيئًا ما ثم تتوقف، أو مدفوعة بالأحداث أو حدثية التوجه event driven، أي تبدأ البرامج وتنتظر وقوع أحداث بعينها؛ ولا تتوقف إلا حين يأمرها حدث آخر بالتوقف.

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

وسنغطي في هذا المقال النقاط التالية:

• أوجه اختلاف البرامج المدفوعة بالأحداث عن البرامج جزئية التوجه.
• كيفية كتابة حلقة حدث تكرارية.
• كيفية استخدام إطار عمل أحداث مثل Tkinter.

محاكاة حلقة أحداث تكرارية

يحتوي البرنامج المدفوع بالأحداث أو البرنامج الحدثي event driven program على حلقة تلتقط الأحداث المستَلمة وتعالجها، وقد تولد بيئة التشغيل الأحداث -كما يحدث في جميع البرامج الرسومية تقريبًا-، أو يبحث البرنامج عن الأحداث -كما يحدث في أنظمة التحكم المدمجة التي في الكاميرات وغيرها-، وسنكتب برنامجًا يبحث عن نوع واحد من الأحداث، وهو مدخلات لوحة المفاتيح، ويعالج النتائج إلى أن يستلم حدث خروج quit، والذي سيكون حالتنا مفتاح المسافة space على لوحة المفاتيح، وسنعالج الأحداث المدخلة بطريقة سهلة، إذ سنطبع ترميز آسكي ASCII الخاص بالمفتاح الذي ضغطه المستخدم، وسنستخدم بايثون لأنها تحوي دالة getch()‎ سهلة الاستخدام، وسنقرأ المفاتيح مفتاحًا تلو الآخر، وتأتي هذه الدالة في صورتين وفقًا لنظام التشغيل الذي نستخدمه، فنجدها في لينكس في وحدة curses، أما في ويندوز فستكون في وحدة msvcrt، وسنستخدم نسخة ويندوز أولًا ثم نناقش خيار لينكس بالتفصيل، ويجب أن نشغل هذه البرامج من سطر أوامر النظام، لأن بيئات التطوير -مثل IDLE- ستلتقط ضربات لوحة المفاتيح التقاطًا مختلفًا.

وسنطبق دوال معالجة الأحداث أولًا، والتي تُستدعى عند التقاط ضغطة أحد المفاتيح، ثم متن البرنامج الرئيسي الذي يبدأ حلقة جمع الأحداث؛ ويستدعي دالة معالجة الحدث المناسبة عند التقاط حدث صالح.

تطبيق المثال في ويندوز

إليك التطبيق التالي:

import msvcrt
import sys

# معالجات الأحداث أولًا
def doKeyEvent(key):
    if key == '\x00' or key == '\xe0':
       key = msvcrt.getch()
    print ( ord(key), ' ', end='')
    sys.stdout.flush() # make sure it appears on screen

def doQuit(key):
    print() # أدخل سطرًا جديدًا
    raise SystemExit

# أخل مساحة على الشاشة أولًا
lines = 25 
for n in range(lines): print()

# والآن حلقة الحدث الأساسية
while True:
    ky = msvcrt.getch()
    if len(str(ky)) != 0:
        # we have a real event
        if " " in str(ky):
            doQuit(ky)
        else: 
            doKeyEvent(ky)

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

كما نلاحظ أن getch()‎ تعيد بايتات، لذا نحتاج إلى تحويلها إلى سلسلة نصية، وإلى استخدام اختبار in للتحقق متى يمكن الخروج بما أن السلسلة الناتجة لن تكون حرفًا.

وفي الحالة التي لا يكون فيها المفتاح محرف آسكي، كأن يكون مفتاحًا وظيفيًا مثلًا، وهي المفاتيح التي تحمل حرف F في أولها أعلى لوحة المفاتيح، فسنحتاج إلى جلب محرف ثانٍ من لوحة المفاتيح، لأن هذه المفاتيح الخاصة تولد أزواجًا من البايتات، أما getch()‎ فلا تجلب إلى بايتًا واحدًا في كل مرة، وتكون القيمة المهمة التي نريدها هي البايت الثاني فعليًا.

تطبيق المثال في لينكس وماك

لا يستطيع المبرمجون الذين يستخدمون أنظمة تشغيل لينكس وماك استخدام مكتبة msvcrt، لذا يستخدمون وحدةً أخرى تسمى curses، وتكون الشيفرة الناتجة شبيهةً بشيفرة ويندوز، مع بعض التعديلات التي يجب إجراؤها، كما يلي:

import curses as c

def doKeyEvent(key):
    if key == '\x00' or key == '\xe0': # non ASCII key
       key = screen.getch()     # fetch second character
    screen.addstr(str(key)+' ') # uses global screen variable

def doQuitEvent(key):
    c.resetty() # set terminal settings
    c.endwin()  # end curses session
    raise SystemExit


# امسح الشاشة واحفظ الإعدادات الحالية
# وأوقف الطباعة الآلية للمحارف على الشاشة
# ثم أخبر المستخدم ما يفعله للخروج

screen = c.initscr()
c.savetty()
c.noecho()
screen.addstr("Hit space to end...\n")

# والآن تعمل الحلقة الأساسية بلا نهاية
while True:
     ky = screen.getch()
     if ky != -1:
       # send events to event handling functions
       if ky == ord(" "): # check for quit event
         doQuitEvent(ky)
       else: 
         doKeyEvent(ky)

c.endwin()

لا تعمل أوامر الطباعة العادية في وحدة curses، بل يجب أن نستخدم دوال معالجة الشاشة الخاصة بوحدة curses، كما تعيد getch هنا ‎-1 إذا لم يُضغط على أي مفتاح -بدلًا من سلسلة فارغة-، ويطابق منطق البرنامج نسخة ويندوز السابقة فيما عدا ذلك.

ويجب أن تستعيد curses.endwin()‎ شاشتنا إلى الحالة العادية، لكنها قد لا تعمل أحيانًا، فإذا اختفى المؤشر أو لم نحصل على محرف إرجاع لبداية السطر أو غير ذلك، فسنصلح المشكلة بالخروج من بايثون باستخدام Ctrl+D واستخدام الأمر التالي:

$ stty echo -nl

تشير nl إلى "سطر جديد"، وينبغي أن يصلح هذا السطر المشكلة أعلاه حال حدوثها.

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

برنامج رسومي

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

وفي مثالنا هنا ننشئ صنف تطبيق application class اسمه KeysApp ينشئ الواجهة الرسومية في التابع __init__، ويربط مفتاح المسافة بالتابع doQuitEvent، كما يعرّف الصنف تابع doQuitEvent المطلوب، أما الواجهة الرسومية نفسها فتتكون ببساطة من ودجِت widget (تطبيق مُصغَّر) لإدخال النصوص؛ سلوكها الافتراضي هو طباعة المحارف المدخَلة على الشاشة.

إن إنشاء صنف تطبيق في البيئات الحدثية كائنية التوجه أمر شائع، بسبب الارتباط بين مفاهيم الأحداث المرسَلة إلى برنامج ما والرسائل المرسَلة إلى كائن، إذ يرتبطان ببعضهما بسهولة كبيرة، وبذلك تصبح دالة معالجة الحدث تابعًا لصنف التطبيق، وبعد أن عرّفنا الصنف سننشئ نسخةً منه ونرسل إليها رسالة mainloop، وستبدو الشيفرة كما يلي: ً

# للحفظ، بما أن علينا تقديم كل شيءfrom X import * استخدم
# tkinter.xxx كـ
from tkinter import *
import sys


# أنشئ صنف التطبيق الذي يعرف الواجهة الرسومية وتوابع
# معالجة الأحداث
class KeysApp(Frame):
    def __init__(self): # use constructor to build GUI
        super().__init__()
        self.txtBox = Text(self)
        self.txtBox.bind("<space>", self.doQuitEvent)
        self.txtBox.pack()
        self.pack()

    def doQuitEvent(self,event):
        sys.exit()


# والآن أنشئ نسخة وابدأ تشغيل حلقة الحدث
myApp = KeysApp()
myApp.mainloop()

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

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

self.txtBox.bind("<Key>", self.doKeyEvent)

كما سنضيف التابع التالي لمعالجة الحدث:

def doKeyEvent(self,event):
    str = "%d\n" % event.keycode
    self.txtBox.insert(END, str)
    return "break"

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

كما نلاحظ أن return "break"‎ هي إشارة سحرية تخبر Tkinter بأن لا يستدعي معالجة الأحداث الافتراضية لهذه الودجِت، وبدون هذا السطر سيعرض الصندوق النصي رمز آسكي متبوعًا بالمحرف الحقيقي الذي ضُغط، وليس هذا ما نريده.

إلى هنا يكفي الحديث عن Tkinter، فلم نكن ننو شرحه هنا وإنما في مقال تالٍ.

البرمجة الحدثية في VBScript وجافاسكربت

نستطيع تطبيق البرمجة الحدثية في كل من جافاسكربت وVBScript عند برمجة متصفح، فعادةً إذا حُمِّلَت صفحة ويب تحتوي على سكربت فإن السكربت ينفَّذ جزءًا جزءًا مع تحميل الصفحة، لكن إذا لم يحوِ السكربت إلا تعريفات الدوال فلن يفعل التنفيذ شيئًا إلا تعريف الدوال على أنها جاهزة للاستخدام، أما الدوال نفسها فلن تُستدعى هنا ابتداءً، بل ستكون مقيدةً إلى عناصر HTML في الجزء الخاص بشيفرة HTML في الصفحة -داخل عنصر Form غالبًا-، بحيث تُستدعى هذه الدوال عند وقوع الأحداث، وقد رأينا هذا في مثال جافاسكربت الخاص بالحصول على مدخلات المستخدم عندما نقرأ المدخلات من استمارة HTML، لننظر في هذا المثال مرةً أخرى؛ ونر كيف أنه تطبيق عملي على برمجة حدَثية في صفحة ويب:

<form name='entry'>
<p>Type value then click outside the field with your mouse</p>
<input Type='text' 
          Name='data' 
          onChange='alert("We got a value of " + document.entry.data.value);'/>
</form>

نلاحظ عدم وجود تعريف لدالة جافاسكربت، بل مجرد استدعاء لـ alert المرتبطة بسمة onChange لعنصر input، وهذه السمة هي إحدى الأحداث التي تستطيع عناصر HTML توليدها، ونستطيع ربط أي شيفرة جافاسكربت عشوائية لتنفيذها في كل مرة تقع فيها هذه الأحداث، كما يمكن إنشاء دالة واستدعاؤها بدلًا من استدعاء alert كما يلي:

<script type="text/javascript">
function echoValue(){
   alert("We got a value of " + document.entry.data.value);
}
</script>

<form name='entry'>
<p>Type value then click outside the field with your mouse</p>
<input Type='text' Name='data' onChange='echoValue()'/>
</form>

يعرّف الجزء الخاص بالسكربت دالة جافاسكربت هي echoValue تحاكي استدعاء alert الذي كان معنا من قبل، ويحتوي عنصر input الآن على دالة مسندة على أنها معالج الأحداث للسمة onChange، ثم تنفَّذ الدالة عند تغير قيمة الدخل، وتكون حلقة الحدث التي تلتقط الأحداث مضمنةً داخل المتصفح.

ورغم أن دالتنا هذه استدعت alert إلا أنها تستطيع أكثر من ذلك، بل من الممكن جعلها برنامجًا معقدًا بذاتها، وذلك وفقًا لما نضعه في متنها.

يمكن استخدام VBScript بنفس الطريقة، عدا أن تعريفات الدوال ستكون بـ VBscript بدلًا من جافاسكربت، كما يلي:

<script type="text/vbscript">
Sub EchoInput()
   MsgBox "We got a value of " & Document.entry2.data.value
End Sub
</script>

<form name='entry2'>
<p>Type value then click outside the field with your mouse</p>
<input Type='text' Name='data' onChange='EchoInput()'/>
</form>

وبهذا نرى أن الشيفرة الموجهة للمتصفحات يمكن كتابتها في صورة أجزاء batches أو في صورة حدَثية event driven، أو بهما معًا، وفق متطلبات كل حالة.

خاتمة

نأمل في هذا المقال أن تكون تعلمت ما يلي:

• لا تبالي حلقات الأحداث بالأحداث التي تلتقطها.
• تعالج معالجات الأحداث حدثًا واحدًا في كل مرة.
• توفر أطر العمل -مثل Tkinter- حلقة أحداث، وبعض معالجات الأحداث الافتراضية أحيانًا.
• يمكن كتابة الشيفرة لمتصفحات الويب بأسلوب مدفوع بالأحداث، أو بالأجزاء، أو بهما معًا.

ترجمة -بتصرف- للفصل الثامن عشر: Event Driven Programming، من كتاب Learn To Program لصاحبه Alan Gauld.

اقرأ أيضًا

• المقال التالي: برمجة الواجهات الرسومية باستخدام Tkinter
• المقال السابق: البرمجة كائنية التوجه
• تعلم البرمجة
• ما هي البرمجة ومتطلبات تعلمها؟

رغم أن الأفكار التي كانت وراء البرمجة الكائنية التوجه طُورت في ستينيات القرن الماضي إلا أنها لم تشتهر في الوسط البرمجي إلا بعد ذلك بعقدين، أي في الثمانينيات، بعد إطلاق Smalltalk-80 ومجموعة متنوعة من تطبيقات لغة Lisp، ولم تكن وقتها اتجاهًا سائدًا في البرمجة وإنما كانت تثير الفضول فقط، ثم تغير ذلك عندما انتشرت الواجهات الرسومية في الحواسيب الشخصية على حواسيب أبل أولًا، ثم على الحواسيب العاملة بنظام ويندوز ونظام نوافذ X في يونكس، إلى أن اقتربنا من نهاية الألفية السابقة، حيث صارت البرمجة الكائنية التوجه Object Oriented Programming -والتي تعرف اختصارًا OOP- التقنية الأبرز لتطوير البرمجيات.

وتتجسد مفاهيم البرمجة الكائنية التوجه في لغات مثل جافا وC++‎ وبايثون بحيث لا تكاد تفعل شيئًا فيها إلا وتقابل كائنًا في مكان ما، ونريد في هذا المقال أن نتعرف على هذه التقنية وننظر في المفاهيم الأساسية لها، مثل تعريف الكائن والصنف وتعددية الأشكال polymorphism والوراثة inheritance، وكيفية إنشاء الكائنات وتخزينها واستخدامها، والبرمجة الكائنية التوجه موضوع كبير قد كُتبت فيه كتب، فإذا أردت التعمق فيه أكثر مما هو مذكور في هذا المقال فانظر هذه الكتب باللغة الإنجليزية:

• كتاب Object Oriented Analysis لبيتر كود Peter Coad وإد يوردون Ed Yourdon.
• كتاب Object Oriented Analysis and Design with Applications لجريدي بوش Grady Booch (الطبعة الأولى أو الثالثة).
• كتاب Object Oriented Software Construction لبرتراند ماير Berterand Meyer (الطبعة الثانية).

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

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

جمع البيانات والدوال

الكائنات هي تجميعات من البيانات والدوال التي تنفذ مهامًا على تلك البيانات، وتوضعان معًا بحيث يمكن تمرير كائن من جزء ما في البرنامج كي نحصل تلقائيًا على وصول إلى العمليات المتاحة وسمات البيانات، وهذا الجمع بين البيانات والدوال هو أصل البرمجة الكائنية التوجه، ويُعرف باسم التغليف encapsulation، لأن بعض لغات البرمجة تخفي البيانات عن مستخدمي الكائن، وبناءً عليه تتطلب توابع الكائن للوصول إليها، وتسمى هذه التقنية باسم إخفاء البيانات، ويطلق عليها التغليف أحيانًا، وكمثال على التغليف، قد يخزن كائن سلسلة نصية سلسلة محارف، لكنه يوفر كذلك توابع للعمل على هذه السلسلة؛ لتنفيذ أمور مثل البحث وتغيير حالة الأحرف وحساب الطول وغير ذلك، وتستخدم الكائنات مجازًا تمرير الرسالة message passing، حيث يمرر كائنٌ رسالةً إلى كائن آخر، ويرد الكائن المستقبل بتنفيذ تابع -وهو إحدى عملياته-، وهكذا يُستدعى التابع عند استقبال الرسالة الموافقة له بواسطة الكائن المالك، ويمكن تمثيل ذلك بصيغ مختلفة، وأكثرها شيوعًا الصيغة النقطية . التي تحاكي الوصول إلى العناصر التي في الوحدات، فبالنسبة إلى صنف widget وهمي:

w = Widget() # widget جديدة من w أنشئ نسخة 
w.paint()  # paint أرسل إليها الرسالة 

ستستدعي هذه التعليمات التابع paint الخاص بكائن widget.

تعريف الأصناف

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

class Message:
    def __init__(self, aString):
        self.text = aString
    def printIt(self):
        print( self.text )

• الملاحظة الأولى: يسمى أحد توابع هذا الصنف باسم __init__، وهو تابع خاص يسمى الباني constructor، وسبب هذا الاسم أنه يُستدعى عند إنشاء أو بناء نسخة جديدة من كائن ما، وستكون المتغيرات المسندة داخل هذا التابع -والتي أنشئت داخل بايثون- متغيرات فريدة للنسخة الجديدة، وتوجد عدة توابع خاصة مثل هذا التابع في بايثون، وجميعها مميزة بصيغة التسمية التي فيها شرطتان سفليتان عن يمينها وشمالها __xxx__، ويطلق عليها مستخدمو بايثون أحيانًا اسم التوابع السحرية magic methods أو التوابع المحاطة بشرطين سفليتين dunder methods (إذ dunder اختصار إلى double under)؛ أما وقت استدعاء الباني الدقيق فيختلف بين اللغات، حيث يُستدعى التابع init في بايثون بعد إنشاء النسخة في الذاكرة، لكنه في لغات أخرى يعيد النسخة نفسها، والفرق في هذا بين اللغات طفيف ولا يستحق الانتباه له.
• الملاحظة الثانية: يحتوي كلا التابعين المعرفين على معامل أول هو self، والاسم مجرد اصطلاح يشير إلى نسخة الكائن، وسنرى قريبًا أن هذا المعامِل لا يملؤه المبرمج، بل يُملأ بواسطة المفسر في وقت التشغيل، وعلى هذا يُستدعى printIt على نسخة للصنف -انظر أدناه-، بدون وسطاء بالشكل m.printIt()‎.
• الملاحظة الثالثة: لقد استدعينا الصنف Message بحرف M كبير كما نرى، وهذا للسهولة فقط، لكن هذا الاصطلاح يُستخدم بكثرة في لغات البرمجة الكائنية التوجه، وليس في بايثون وحدها، ويوجد اصطلاح قريب من هذا يقتضي أن تبدأ أسماء التوابع بحرف صغير ثم تبدأ الكلمات التالية في الاسم بحرف كبير، فإذا كان لدينا تابع اسمه calculate current balance، فسيُكتب بالشكل calculateCurrentBalance.

ننصحك عند هذه النقطة بالعودة إلى مقال البيانات وأنواعها، لقراءة قسم الأنواع المعرَّفة من قِبل المستخدم، حيث ستفهم مثال دليل جهات الاتصال في بايثون فهمًا أفضل بعد هذا الشرح هنا، فالنوع الوحيد الذي يعرّفه المستخدم في بايثون هو الصنف، والصنف الذي له سمات attributes وليس له توابع -ما عدا __init__- يكافئ الباني المسمى record أو struct في بعض لغات البرمجة.

الصيغة الرسومية

تبنّى مجتمع هندسة البرمجيات صيغةً مرئيةً لوصف الأصناف والكائنات وعلاقاتها بعضها ببعض، وتسمى هذه الصيغة باسم لغة النمذجة الموحدة Unified Modelling Language أو UML اختصارًا، وهي أداة تصميم قوية وتحتوي على العديد من المخططات والأيقونات، وسننظر في بعضها هنا بما يعيننا على فهم المبادئ التي نريد شرحها فقط، وأول أيقونة سنقابلها في UML هي وصف الصنف، وهي أهم الأيقونات، وتتكون من صندوق من ثلاثة أجزاء، يحتوي الجزء العلوي على اسم الصنف، والأوسط على سماته أو البيانات فيه، أما الجزء السفلي فيحتوي على توابع الصنف أو دواله، وبناءً عليه سيبدو صنف Message المعرَّف أعلاه كما يلي:

سنرى في هذا المقال أيقونات UML أخرى، ونتعرض لمفاهيم جديدة تدعمها هذه الصيغة.

استخدام الأصناف

بما أننا عرّفنا الصنف Message فنستطيع إنشاء نسخ منه الآن والعمل عليها:

m1 = Message("Hello world")
m2 = Message("So long, it was short but sweet")

notes = [m1, m2] # ضع الكائنات في قائمة
for msg in notes:
    msg.printIt() # اطبع الرسائل متتابعة

وبهذا نعامل الصنف كما لو كان نوع بيانات قياسيًا في بايثون، وهو الغرض من التدريب ابتداءً.

كما توجد أيقونة للكائن أو النسخة في UML، وهي مثل أيقونة الصنف إلا أننا نترك الجزئين السفليين في الصندوق فارغين، ويتكون الاسم من اسم الكائن أو النسخة متبوعًا بنقطتين رأسيتين ثم اسم الصنف، وعليه فإن m1:Message تخبرنا أن m1 ما هي إلا نسخة من الصنف Message، ويمكن رسم مثال الرسالة الخاص بنا الآن كما يلي:

نلاحظ أن الصنف List يمثل نوع القائمة القياسي في بايثون، كما هو موضح من وضع كلمة builtin بين أقواس حادة، وهي بنية معروفة في UML باسم القالب النمطي stereotype، وتشير الخطوط ذوات الرؤوس الماسية في الصورة إلى القائمة التي تحتوي على كائنات Message، وبالمثل فإن كائن MyProg يُنمَّط stereotyped على أنه صنف مساعد utility class، مما يعني في هذه الحالة أنه غير موجود مثل صنف داخل البرنامج، لكنه منتج من منتجات البيئة نفسها، وتُظهَر أدوات نظام التشغيل عادةً بهذه الطريقة، مثل مكتبات لدوال.

أما الخطوط المستقيمة التي تخرج من myProg إلى Message فتوضح أن الكائن myProg يرتبط بـكائنات Message أو يشير إليها، وتشير الأسهم المرافقة لتلك الخطوط أن كائن myProg يرسل رسالة printIt إلى كل كائن من كائنات Message، وتُنقل رسائل الكائنات من خلال ارتباطات associations.

المعامل self

يطرح من يبدأ حديثًا في البرمجة الكائنية التوجه ببايثون سؤالًا هو: ما هو المعامل self؟ لأن تعريف أي تابع في صنف ما في بايثون يبدأ به، ويجب أن نبين أن الاسم نفسه مجرد اصطلاح، ولم يتغير إلى الآن لأن الثبات أمر محمود في الاصطلاحات البرمجية، فلغة جافاسكربت مثلًا لديها مفهوم مشابه لكنها تستخدم اسم this بدلًا من self.

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

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

وعند إرسال رسالة إلى كائن يحدث ما يلي:

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

يمكن رؤية تلك النقاط عمليًا في تسلسل الشيفرة التالي، ونلاحظ أننا نستطيع استدعاء تابع الصنف صراحةً كما فعلنا في السطر الأخير:

>>> class C:
...   def __init__(self, val): self.val = val
...   def f(self): print ("hello, my value is:", self.val)
...
>>> # create two instances
>>> a = C(27)
>>> b = C(42)
>>> # first try sending messages to the instances
>>> a.f()
hello, my value is 27
>>> b.f()
hello, my value is 42
>>> # now call the method explicitly via the class
>>> C.f(a)
hello, my value is 27

نستطيع استدعاء التوابع كما نرى في المثال أعلاه من خلال النسخة، وتملأ بايثون معامِل self في تلك الحالة لنا، أو من خلال الصنف صراحةً، وفي تلك الحالة نحتاج إلى تمرير قيمة self صراحةً.

لدينا سؤال يطرح نفسه الآن، فإذا كانت بايثون تستطيع توفير مرجع بين النسخة وصنفها، ألا تستطيع أن تملًا self بنفسها أيضًا؟ ربما يكون هذا سؤالًا منطقيًا لكن الإجابة عليه هي أن Guido Van Rossum -منشئ اللغة- صممها هكذا. لكن مع هذا فإن العديد من لغات البرمجة الكائنية التوجه تخفي معامِل self، لكن بايثون تعتمد الصراحة explicity وتفضلها على الضمنية implicity، ويتعود المبرمج على هذا المبدأ مع كثرة العمل.

تعددية الأشكال polymorphism

لدينا الآن القدرة على تعريف أصنافنا الخاصة وإنشاء نسخ منها وإسنادها إلى متغيرات، ثم تمرير رسائل إلى تلك الكائنات تؤدي إلى تشغيل التوابع التي عرفناها، لكن هناك عنصر أخير يتعلق بالبرمجة الكائنية التوجه هنا، وهو الأهم فيها من نواحٍ عدة، فإذا كان لدينا كائنان من صنفين مختلفين لكنهما يدعمان نفس مجموعة الرسائل، لكن مع التوابع الموافقة لها، فنستطيع عندئذ أن نجمع تلك الكائنات معًا ونعاملها معاملةً واحدةً في برنامجنا، لكنها ستتصرف تصرفًا مختلفًا، وتُعرف تلك القدرة على التصرف المختلف لنفس رسائل الدخل باسم تعددية الأشكال، تُستخدم هذه الخاصية عادةً لجعل عدد من الكائنات الرسومية المختلفة ترسم نفسها عند استلام رسالة paint، فترسم الدائرة شكلًا مختلفًا تمامًا عن المثلث، لكن بما أن لهما نفس تابع paint فنستطيع -نحن المبرمجين- أن نتجاهل الاختلافات ونراهما على أنهما مجرد أشكال، لننظر الآن في مثال نحسب فيه مساحة الأشكال بدلًا من رسمها:

ننشئ أولًا الصنفين Square وCircle:

class Square:
    def __init__(self, side):
        self.side = side
    def calculateArea(self):
        return self.side**2

class Circle:
    def __init__(self, radius):
        self.radius = radius
    def calculateArea(self):
        import math
        return math.pi*(self.radius**2)

نستطيع الآن أن ننشئ قائمةً من الأشكال -دوائر أو مربعات- ثم نطبع مساحاتها:

shapes = [Circle(5),Circle(7),Square(9),Circle(3),Square(12)]

for item in shapes:
    print "The area is: ", item.calculateArea()

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

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

الوراثة inheritence

تُستخدم الوراثة (أو الاكتساب) عادةً لتنفيذ تعددية الأشكال واستخدامها، وقد تكون هي الآلية الوحيدة لذلك في العديد من لغات البرمجة الكائنية، ويمكن للصنف أن يرث السمات والعمليات من صنف أب parent class أو صنف رئيسي super class، وهذا يعني أن الصنف الجديد المطابق لصنف آخر في أغلب جوانبه لا يجب أن يعيد تنفيذ جميع التوابع التي في الصنف الأول، بل يمكن أن يرث تلك الإمكانيات ثم يغيرها لتنفيذ أمور مختلفة، كما في تابع calculateArea أعلاه، وسنستخدم للتوضيح مثالًا فيه هرمية أصناف حسابات بنكية، حيث نستطيع إيداع المال والحصول على الرصيد والقيام بعمليات سحب، ولبعض الحسابات نسبة ربوية (فائدة) سنفترض أنها تُحسب عند كل إيداع، إضافةً إلى بعض الرسوم الأخرى لعمليات السحب.

الصنف BankAccount

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

• إيداع المال.
• سحب المال.
• التحقق من الرصيد الحالي.
• تحويل الأموال إلى حساب آخر.

وسنحتاج إلى معرِّف الحساب المصرفي ID للحساب الآخر والرصيد الحالي، بالنسبة للمعرِّف فسنستخدم المتغير الذي نسند الكائن إليه، لكن إذا كنا في مشروع حقيقي فيجب إنشاء سمة خاصة بالمعرِّف تخزن مرجعًا فريدًا، كما سنحتاج إلى تخزين الرصيد، وعند تمثيل ذلك بلغة النمذجة الموحدة UML فسيبدو كما يلي:

نستطيع الآن أن ننشئ صنفًا يدعم ذلك:

# ‫ننشئ صنف اعتراض Exception مخصص
class BalanceError(Exception): 
      value = "Sorry you only have $%6.2f in your account"

class BankAccount:
    def __init__(self, initialAmount):
       self.balance = initialAmount
       print( "Account created with balance %5.2f" % self.balance )

    def deposit(self, amount):
       self.balance = self.balance + amount

    def withdraw(self, amount):
       if self.balance >= amount:
          self.balance = self.balance - amount
       else:
          raise BalanceError()

    def checkBalance(self):
       return self.balance

    def transfer(self, amount, account):
       try: 
          self.withdraw(amount)
          account.deposit(amount)
       except BalanceError:
          print( BalanceError.value % self.balance )

• الملاحظة الأولى: نتحقق من الرصيد قبل السحب، ونستخدم اعتراضًا لمعالجة الأخطاء، وبما أنه لا يوجد خطأ من النوع BalanceError في بايثون فسنحتاج إلى إنشاء واحد، وهو صنف فرعي من الصنف Exception مع قيمة نصية، وتُعرَّف قيمة السلسلة value سمةً لصنف الاعتراض لمجرد الاصطلاح فقط، وهي تضمن أننا نولد رسائل خطأ في كل مرة نرفع فيها اعتراضًا، ونلاحظ هنا أننا لم نستخدم self عند تعريف القيمة في BalanceError لأن value سمة مشتركة بين كل النسخ، وهي معرَّفة على مستوى الصنف وتُعرف بمتغير الصنف، ونصل إليها باستخدام اسم الصنف متبوعًا بنقطة BalanceError.value كما رأينا أعلاه، فعندما يولّد خطأ التعقب العكسي traceback -أي مسار مكان وقوع الخطأ ورجوعًا ضمن سلسلة الاستدعاءات- فسينتهي بطباعة سلسلة الخطأ المصاغة مع عرض الرصيد الحالي.
• الملاحظة الثانية: يستخدم التابع transfer الدالة التابعة withdraw/deposit الخاصة بالصنف BankAccount أو توابعه لتنفيذ عملية التحويل، وهذا أمر شائع في البرمجة الكائنية التوجه ويُعرف بالمراسلة الذاتية self messaging، ويعني أن الأصناف المشتقة تستطيع تنفيذ نسخها الخاصة من deposit/withdraw لكن يظل التابع transfer كما هو لجميع أنواع الحسابات.

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

الصنف InterestAccount

نستخدم الوراثة الآن لتوفير حساب يضيف نسبة ربوية -سنفترض أنها ‎3%- عند كل عملية إيداع، وستكون مطابقةً لصنف BankAccount القياسي عدا تابع الإيداع وبدء معدل النسبة، لذا نعيد كتابة تنفيذ هذه التوابع كما يلي:

class InterestAccount(BankAccount):
   def __init__(self, initialAmount, interest=0.03):
       super().__init__(initialAmount)
       self.interest = interest
   def deposit(self, amount):
       super().deposit(amount)
       self.balance = self.balance * (1 + self.interest)

• الملاحظة الأولى: نمرر الصنف الرئيسي (أو الأب) معامِلًا في تعريف الصنف، ويكون هذا الصنف الأب في حالتنا هو BankAccount.
• الملاحظة الثانية: نستدعي super().__init__()‎ في بداية التابع ‎__init__()‎، والدالة super()‎ هي دالة خاصة وظيفتها معرفة الصنف الرئيسي، ويفيدنا ذلك عند وراثة أكثر من صنف رئيسي واحد فيما يسمى بالوراثة المتعددة، حيث نتجنب بعض المشاكل الغريبة التي قد تظهر إذا حاولنا استدعاء الصنف الرئيسي باسمه، لذلك يُفضل استخدام super()‎.

ونبدأ الصنف الموروث باستدعاء التابع __init__ الخاص بالصنف الرئيسي، ولا نحتاج هنا إلا إلى بدء السمة interest التي قدمناها هنا، وبالمثل في استخدام super()‎ في تابع الإيداع، إذ يستدعي التابع deposit الخاص بالصنف الأب فلا نحتاج إلا إلى إضافة المزايا الجديدة للصنف InterestAccount.

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

الصنف ChargingAccount

هذا الصنف مطابق للصنف BankAccount عدا أنه يطلب رسومًا افتراضية مقدارها ‎3$ لكل عملية سحب، وبالنسبة لـ InterestAccount فيمكن إنشاء صنف يرث من BankAccount ويعدّل التابعين init و withdraw:

class ChargingAccount(BankAccount):
    def __init__(self, initialAmount, fee=3):
        super().__init__(initialAmount)
        self.fee = fee

    def withdraw(self, amount):
        super().withdraw(amount+self.fee)

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

ونمثل هذه الوراثة في UML بسهم مصمت من الصنف الفرعي إلى الصنف الرئيسي، فتُمثَّل هرمية الحساب البنكي الآن كما يلي:

نلاحظ أننا سردنا التوابع والسمات التي تغيرت فقط أو أضيفت إلى الأصناف الفرعية.

اختبار النظام

للتحقق من عمل الهرمية السابقة بكفاءة، جرب تنفيذ الشيفرة التالية في محث بايثون أو بإنشاء ملف اختبار منفصل:

from bankaccount import *
# الحساب البنكي العادي
a = BankAccount(500)
b = BankAccount(200)
a.withdraw(100)
# a.withdraw(1000)
a.transfer(100,b)
print( "A = ", a.checkBalance() )
print( "B = ", b.checkBalance() )

# حساب للنسبة الربوية
c = InterestAccount(1000)
c.deposit(100)
print( "C = ", c.checkBalance() )

# حساب للرسوم المفروضة
d = ChargingAccount(300)
d.deposit(200)
print( "D = ", d.checkBalance() )
d.withdraw(50)
print( "D = ", d.checkBalance() )
d.transfer(100,a)
print( "A = ", a.checkBalance() )
print( "D = ", d.checkBalance() )

# حوّل من حساب الرسوم إلى حساب النسبة الربوية
# حساب الرسوم سيطلب رسومًا، وحساب النسبة الربوية
# يضيف نسبة ربوية
print( "C = ", c.checkBalance() )
print( "D = ", d.checkBalance() )
d.transfer(20,c)
print( "C = ", c.checkBalance() )
print( "D = ", d.checkBalance() )

أزل علامة التعليق الآن من السطر (a.withdraw(1000 لترى الاعتراض عمليًا.

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

اقتباس

التطوير الموجه بالاختبارات

يستخدم العديد من المبرمجين العاملين تقنيةً تسمى التطوير الموجَّه بالاختبار test driven development، حيث يكتبون اختباراتهم قبل كتابة الشيفرة البرمجية نفسها، مما يسمح لهم باختبار شيفرتهم مرةً بعد مرة أثناء تطويرها، وينتقلون تدريجيًا من فشل الاختبارات المتكرر إلى نجاحها، وإذا نجحت جميع الاختبارات فإن هذا يعني أن البرنامج يعمل بكفاءة. وهذا النهج شائع جدًا في البرمجة لدرجة تطوير أدوات خاصة لتساعد فيه، ولدى بايثون أدوات مثل هذه موجودة في وحدة unittest في المكتبة القياسية، وهذا النهج -وإن كان مفيدًا في كتابة شيفرة حقيقية- لن يفيدنا في شرحنا كثيرًا لأنه يخفي الشيفرة الأساسية وحالات اختبار كثيرة نحاول دراستها، لذا لن نستخدمه هنا، لكن قد ننظر فيه في مقال لاحق.

تجميعات الكائنات

إحدى المشاكل التي قد تواجهها هي كيفية التعامل مع كائنات كثيرة، أو كيفية التعامل مع كائنات تنشئها في وقت التشغيل، فمن السهل إنشاء حسابات بنكية ثابتة كما فعلنا أعلاه:

acc1 = BankAccount(...)
acc2 = BankAccount(...)
acc3 = BankAccount(...)
etc...

لكن في العالم الحقيقي لا تكون لدينا بيانات عن عدد الحسابات التي يجب إنشاؤها، فكيف نحل هذه المشكلة؟ لننظر فيها بتفصيل أكبر:

نريد شكلًا ما من قواعد البيانات التي تسمح لنا بإيجاد أي حساب بنكي باسم مالكه أو رقم حسابه -بما أنه قد يكون للشخص الواحد عدة حسابات-، والعكس صحيح، ولكن ألا يشبه البحث عن شيء له معرّف خاص به القاموس؟ لنجرب استخدام قاموس في بايثون للاحتفاظ بكائنات منشأة ديناميكيًا:

from bankaccount import BankAccount
import time

# أنشئ دالة جديدة لتوليد أرقام معرّفات فريدة
def getNextID():
    ok = input("Create account[y/n]? ")
    if ok[0] in 'yY':  # check valid input
       id = time.time() # use current time as basis of ID
       id = int(id) % 10000 # حول إلى عدد صحيح وقلله إلى 4 أرقام
    else: id = -1  # وذلك سيوقف الحلقة التكرارية
    return id

# أنشئ بعض الحسابات وخزنها في القاموس
accountData = {}  # قاموس جديد
while True:          # كرر حلقيًا بلا نهاية
   id = getNextID()
   if id == -1: 
      break       # تخرج إجباريًا من الحلقة التكرارية
   bal = float(input("Opening Balance? "))  # حول السلسلة إلى عدد ذي فاصلة عائمة  
   accountData[id] = BankAccount(bal) # استخدم المعرِّف لإنشاء إدخال جديد في القاموس
   print( "New account created, Number: %04d, Balance %0.2f" % (id, bal) )

# دعنا نصل الآن إلى بعض الحسابات
for id in accountData.keys():
    print( "%04d\t%0.2f" % (id, accountData[id].checkBalance()) )

# ونبحث عن واحد فيها
# أدخل محرفًا غير رقمي لرفع اعتراض وإنهاء البرنامج
while True:
   id = int(input("Which account number? "))
   if id in accountData:
      print( "Balance = %0.2d" % accountData[id].checkBalance() )
   else: print( "Invalid ID" )

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

يمثَّل هذا مرئيًا في UML باستخدام مخطط الصنف، ويُعرض القاموس مثل صنف له علاقة مع العديد من الحسابات البنكية، ونرى ذلك موضحًا بمحرف النجمة على الخط الموصل بين الأصناف، ونستخدم محرف النجمة هنا لأنه الرمز المستخدم في التعابير النمطية للإشارة إلى عدد من العناصر مقداره صفر أو أكثر، وهذا يُعرف بعدد عناصر العلاقة cardinality of the relationship، ويمكن رؤيته بعد طرق، لكن المجالات العددية للتعابير النمطية هي المستخدمة بكثرة لثرائها ومرونتها.

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

حفظ الكائنات

إن فقد البيانات عند انتهاء المخطط هو أحد مشاكل السلوك السابق، لذا نريد طريقةً لحفظ الكائنات، ويمكن فعل ذلك باستخدام قواعد البيانات لكنه أسلوب متقدم، أما الآن فسنستخدم ملفًا نصيًا بسيطًا لحفظ الكائنات واسترجاعها، ورغم أن بايثون تحتوي على وحدتين لتنفيذ ذلك بكفاءة، وهما pickle وshelve، إلا أننا سنشرح الطريقة العامة التي تصلح لأي لغة، والطريقة العامة التي نقصدها هي إنشاء التابعين save وrestore في الكائن ذي المستوى الأعلى، ثم إعادة كتابتهما في كل صنف ليستدعيا النسخة الموروثة ثم يضيفا السمات المعرفة محليًا، وبالمناسبة يُستخدم مصطلح الثبات Persistence للإشارة إلى القدرة على حفظ الأشياء واستعادتها.

class A:
   def __init__(self,x,y):
     self.x = x
     self.y = y
     self.f = None

   def save(self,fn):
     f = open(fn,"w")
     f.write(str(self.x)+ '\n') # convert to a string and add newline
     f.write(str(self.y)+'\n')
     return f             # for child objects to use

   def restore(self, fn):
     f = open(fn)
     self.x = int(f.readline()) # convert back to original type
     self.y = int(f.readline())
     return f

class B(A):
   def __init__(self,x,y,z):
     super().__init__(x,y)
     self.z = z

   def save(self,fn):
     f = super().save(fn)  # call parent save
     f.write(str(self.z)+'\n')
     return f         # in case further children exist

   def restore(self, fn):
     f = super().restore(fn)
     self.z = int(f.readline())
     return f

# أنشئ النُسخ
a = A(1,2)
b = B(3,4,5)

# احفظ النُسخ
a.save('a.txt').close() # تذكر أن تغلق الملف
b.save('b.txt').close()

# اجلب النسخ
newA = A(5,6)
newA.restore('a.txt').close() # تذكر أن تغلق الملف
newB = B(7,8,9)
newB.restore('b.txt').close()
print( "A: ",newA.x,newA.y )
print( "B: ",newB.x,newB.y,newB.z )

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

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

دمج الأصناف والوحدات

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

يمكن تمثيل ذلك مرئيًا بواسطة UML بطريقتين، حيث يمكن تمثيل الجمع المنطقي للأصناف باستخدام حزمة، أو نستطيع تمثيل الملف الحقيقي مثل مكوّن:

والهدف هنا أن تبدو أيقونة الحزمة مثل مجلد في أي برنامج مدير ملفات، أما الأيقونة الصغيرة التي في أعلى اليمين في أيقونة المكون فهي رمز المكون القديم في UML، وبما أن رسمها صعب في المخططات عند رسم الخطوط التي تظهر العلاقات بين المكونات فقد صغِّر شكلها في UML 2.0.

هذا ما سنغطيه حول UML في هذه السللسلة، ويمكن الرجوع لمحركات البحث والويب للاستزادة من المراجع والتدريبات وأدوات رسم UML، رغم أن الأشكال سهلة الرسم في أي برنامج رسم متجهي.

إذا أردنا تمثيلًا بسيطًا لذلك التصميم فسيكون كما يلي:

# File: bankaccount.py
#
# Implements a set of bank account classes
###################

class BankAccount: ....

class InterestAccount: ...

class ChargingAccount: ...

ثم إذا أردنا استخدامه:

import bankaccount

newAccount = bankaccount.BankAccount(50)
newChrgAcct = bankaccount.ChargingAccount(200)


# هنا يمكن تنفيذ المهام التي تريدها

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

لننظر في مثال واقعي لتوضيح ذلك، حيث ننشئ وحدةً قصيرةً نسميها logger تحتوي صنفين، هما Logger الذي يسجل النشاط داخل ملف، ويحتوي هذا الصنف على تابع واحد هو log()‎ الذي يأخذ معاملًا كائنًا قابلًا للتسجيل، أما الصنف الآخر فهو Loggable الذي تستطيع الأصناف الأخرى أن ترثه لتعمل مع logger:

# File: logger.py
#
# Create Loggable and Logger classes for logging activities 
# of objects
############

class Loggable:
   def activity(self):
       return "This needs to be overridden locally"

class Logger:
   def __init__(self, logfilename = "logger.dat"):
       self._log = open(logfilename,"a")

   def log(self, loggedObj):
       self._log.write(loggedObj.activity() + '\n')

   def __del__(self):
       self._log.close()

نلاحظ أننا وفرنا تابع تدمير destructor هو __del__ لإغلاق الملف عند حذف كائن التسجيل أو كنسه garbage collected، وهو أحد التوابع السحرية الموجودة في بايثون كما نرى من الشرطتين السفليتين حوله، واللتين تشبهان ‎__init__()‎، مع فرق أن init يُستدعى عند إنشاء نسخة ما، أما del فيستدعى عندما يحذف كانس المخلفات النسخة، وقد لا يُستدعى إذا خرجت بايثون خروجًا غير متوقع، حيث سيكون لدينا في هذه الحالة مشاكل أكبر من استدعاء del أو عدم استدعائه.

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

سننشئ الآن وحدةً جديدةً تعرِّف النسخ القابلة للتسجيل لأصناف حساباتنا المصرفية السابقة، لنستطيع استخدام وحدتنا:

# File: loggablebankaccount.py
#
# Extend Bank account classes to work with logger module.
###############################

import bankaccount, logger

class LoggableBankAccount(bankaccount.BankAccount, logger.Loggable):
    def activity(self):
       return "Account balance = %d" % self.checkBalance()

class LoggableInterestAccount(bankaccount.InterestAccount,
                              logger.Loggable):
    def activity(self):
       return "Account balance = %d" % self.checkBalance()

class LoggableChargingAccount(bankaccount.ChargingAccount,
                              logger.Loggable):
    def activity(self):
       return "Account balance = %d" % self.checkBalance()

استخدمنا الوراثة المتعددة في المثال أعلاه، حيث ورثنا صنفين رئيسيين وليس صنفًا واحدًا، وهذا غير ضروري في بايثون بما أننا نستطيع إضافة التابع activity()‎ إلى أصنافنا الأصلية ونحقق نفس الأثر، أما في لغات برمجة كائنية التوجه ثابتة مثل جافا أو C++‎ فسيكون هذا ضروريًا، لذا سنشرح التقنية هنا، قد تلاحظ أن التابع activity()‎ متطابق في الأصناف الثلاثة، وهذا يعني أننا نستطيع توفير بعض الكتابة على أنفسنا بإنشاء نوع وسيط من صنف حساب قابل للتسجيل يرث Loggable وله تابع activity فقط، ثم ننشئ ثلاثة أنواع حسابات قابلة للتسجيل بوراثتها من ذلك الصنف الجديد ومن صنف Loggable، كما يلي:

class LoggableAccount(logger.Loggable):
     def activity(self):
         return "Account balance = %d" % self.checkBalance()

class LoggableBankAccount(bankaccount.BankAccount, LoggableAccount):
     pass

class LoggableInterestAccount(bankaccount.InterestAccount, LoggableAccount):
     pass

class LoggableChargingAccount(bankaccount.ChargingAccount, LoggableAccount):
     pass

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

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

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

# Test logging and loggable bank accounts.
#############

import logger
import loggablebankaccount as lba

log = logger.Logger()

ba = lba.LoggableBankAccount(100)
ba.deposit(700)
log.log(ba)

intacc = lba.LoggableInterestAccount(200)
intacc.deposit(500)
log.log(intacc)

نلاحظ هنا كلمة as المفتاحية التي تُستخدم لإنشاء اسم مختصر عند استدعاء loggablebankaccount.

لا نحتاج إلى استخدام سابقة الوحدة module prefix بعد إنشاء النسخ المحلية، وبما أنه لا يوجد وصول مباشر من كائن إلى آخر بل من خلال الرسائل، فلا حاجة أن تشير وحدتا تعريف الصنف إلى بعضهما البعض مباشرةً، كما يعمل المسجل مع نسخ كل من LoggableBankAccount وLoggableInterestAccount لأنهما يدعمان واجهة Loggable، فالتوافق بين واجهات الكائنات من خلال تعددية الأشكال هو الأساس الذي تبنى عليه جميع البرامج الكائنية التوجه.

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

نأمل أن يكون هذا الشرح كافيًا لفهم البرمجة كائنية التوجه، مع الاستزادة من المصادر الموجودة في الويب أو قراءة أحد الكتب المذكورة في بداية المقال، أما الآن فسننظر في كيفية تنفيذ البرمجة كائنية التوجه في جافاسكربت وVBScript.

البرمجة الكائنية في VBScript

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

تعريف الأصناف

يُعرَّف الصنف في VBScript باستخدام تعليمة Class كما يلي:

<script type=text/VBScript>
Class MyClass
   Private anAttribute
   Public Sub aMethodWithNoReturnValue()
       MsgBox "MyClass.aMethodWithNoReturnValue"
   End Sub
   Public Function aMethodWithReturnValue()
       MsgBox "MyClass.aMethodWithReturnValue"
       aMethodWithReturnValue = 42
   End Function
End Class
</script>

وهذا يعرِّف صنفًا جديدًا اسمه MyClass مع سمة تسمى anAttribute تكون مرئيةً فقط للتوابع التي في الصنف، كما نرى من كلمة Private المفتاحية، ومن المتعارف عليه أن نصرح عن سمات البيانات بأنها Private، وعن أغلب التوابع بأنها Public، ويُعرف هذا باسم إخفاء البيانات، وميزته أنه يسمح لنا بالتحكم في الوصول إلى البيانات بإجبار استخدام التوابع التي تتحقق من جودة البيانات على القيم التي تمرَّر إلى داخل وخارج الكائن، وتوفر بايثون آليةً خاصةً بها لتنفيذ هذا لكنها خارج نطاق شرحنا.

إنشاء النسخ

ننشئ النسخ في VBScript بدمج الكلمتين المفتاحيتين Set وNew، ويجب أن يكون المتغير الذي أُسندت إليه النسخة الجديدة قد صرِّح عنه باستخدام كلمة Dim كما هو متبع في VBScript:

<script type=text/VBScript>
Dim anInstance
Set anInstance = New MyClass
</script>

يؤدي هذا إلى إنشاء نسخة من الصنف مصرح عنها في القسم السابق وإسنادها إلى متغير anInstance، لاحظ أننا يجب أن نسبق اسم المتغير بـ Set، وأننا نستخدم كلمة New لإنشاء الكائن.

إرسال الرسائل

تُرسَل الرسائل إلى النسخ باستخدام نفس الصيغة النقطية . التي تستخدمها بايثون:

<script type=text/VBScript>
Dim aValue
anInstance.aMethodWithNoReturnValue()
aValue = anInstance.aMethodWithReturnValue()
MsgBox "aValue = " & aValue
</script>

يُستدعى التابعان المصرح عنهما في تعريف الصنف، ولا توجد في الحالة الأولى قيمة معادة، أما في الحالة الثانية فسنسند القيمة المعادة إلى المتغير aValue، ولا يوجد شيء غير اعتيادي هنا باستثناء أن البرنامج الفرعي subroutine والدالة مسبوقان باسم النسخة.

الوراثة وتعددية الأشكال

لا تدعم VBScript أي آلية للوراثة أو تعددية الأشكال، لكن نستطيع محاكاة ذلك إلى حد ما باستخدام تقنية تسمى التفويض، وهذا يعني أننا نعرف سمةً للصنف الفرعي ليكون نسخةً من الصنف الرئيسي المفترض، ثم نعرف تابعًا لجميع التوابع الموروثة التي تستدعي تابع النسخة الرئيسية أو تفوض إليه، لننشئ صنفًا فرعيًا من MyClass كما هو معرَّف أعلاه:

<script type=text/VBScript>
Class SubClass
   Private parent
   Private Sub Class_Initialize()
      Set parent = New MyClass
   End Sub
   Public Sub aMethodWithNoReturnValue()
      parent.aMethodWithNoREturnVAlue
   End Sub
   Public Function aMethodWithReturnValue()
      aMethodWithReturnValue = parent.aMethodWithReturnValue
   End Function
   Public Sub aNewMethod
      MsgBox "This is unique to the sub class"
   End Sub
End Class

Dim inst,aValue
Set inst = New SubClass
inst.aMethodWithNoReturnVAlue
aValue = inst.aMethodWithReturnValue
inst.aNewMethod
MsgBox "aValue = " & CStr(aValue)
</script>

نلاحظ هنا استخدام السمة الخاصة parent والتابع الخاص المميز Class_Initialise، فالأولى هي سمة تفويض الصنف الأب، والثاني هو المكافئ للتابع __init__ في بايثون لبدء النسخ عند إنشائها، أي أنه الباني في لغة VBScript.

البرمجة الكائنية في جافاسكربت

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

تعريف الأصناف

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

<script type=text/JavaScript>
function MyClass(theAttribute)
{
   this.anAttribute = theAttribute;
};
</script>

ربما تلاحظ كلمة this التي تُستخدم بنفس طريقة استخدام self في بايثون مثل مرجع نائب placeholder reference إلى النسخة الحالية، رغم أننا لا نحتاج في الغالب إلى إدراج this صراحةً في قائمة المعامِلات لتوابع الصنف، ونستطيع إضافة سمات جديدة إلى الصنف لاحقًا باستخدام السمة prototype المضمَّنة كما يلي:

<script type=text/JavaScript>
MyClass.prototype.newAttribute = null;
</script>

ويعرِّف هذا سمةً جديدةً لـ MyClass اسمها newAttribute، وتضاف التوابع من خلال تعريف دالة عادية؛ ثم إسناد اسم الدالة إلى سمة جديدة مع اسم التابع، ويكون للتابع والدالة نفس الاسم عادةً، لكن لا مانع من تغيير اسم التابع إلى شيء مختلف، كما يلي:

<script type=text/JavaScript>
function oneMethod(){
    return this.anAttribute;
}
MyClass.prototype.getAttribute = oneMethod;
function printIt(){
    document.write(this.anAttribute + "<BR>");
};
MyClass.prototype.printIt = printIt;
</script>

ولا شك أن الأسهل تعريف الدوال ثم الباني، ثم إسناد التوابع داخل الباني، وهذا هو الأسلوب الافتراضي، لذا سيبدو تعريف الصنف كاملًا كما يلي:

<script type=text/JavaScript>
function oneMethod(){
    return this.anAttribute;
};

function printIt(){
    document.write(this.anAttribute + "<BR>");
};

function MyClass(theAttribute)
{
   this.anAttribute = theAttribute;
   this.getAttribute = oneMethod;
   this.printIt = printIt;
};
</script>

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

square = function(x){ return x*x;}

ثم نستدعي ذلك كما يلي:

document.write("The square of 5 is: " + square(5))

فإذا طبقناه على تعريف الصنف الخاص بنا نحصل على:

<script type=text/JavaScript>
function MyClass(theAttribute)
{
   this.anAttribute = theAttribute;
   this.getAttribute = function(){
                       return this.anAttribute;
                       };
   this.printIt = function printIt(){
                  document.write(this.anAttribute + "<BR>");
                  };
};
</script>

يفضل بعض المبرمجين هذا الأسلوب لأنه يبقي تعريفات التابع داخل الصنف دون تلويث فضاء الاسم الخارجي، بينما يرى آخرون أن هذا أسلوب فوضوي وأصعب في القراءة، وأنت حر في اختيار أي الأسلوبين تفضل.

إنشاء النسخ

تُنشأ نسخ الأصناف باستخدام كلمة new المفتاحية كما يلي:

<script type=text/JavaScript>
var anInstance = new MyClass(42);
</script>

مما ينشئ نسخةً جديدةً اسمها anInstance.

إرسال الرسائل

لا يختلف إرسال الرسائل في جافاسكربت عن اللغات الأخرى، إذ نستخدم الصيغة النقطية:

<script type=text/JavaScript>
document.write("The attribute of anInstance is: <BR>");
anInstance.printIt();
</script>

الوراثة وتعددية الأشكال

يمكن استخدام آلية النمذجة الأولية في جافاسكربت للوراثة من صنف آخر -على عكس VBScript-، مع أنها أعقد من تقنية بايثون لكن يمكن التعامل معها وضبطها، لكنها ليست منتشرةً بين مبرمجي جافاسكربت، إن أساس الوراثة في جافاسكربت هو الكلمة المفتاحية prototype التي استخدمناها في التمرير في الشيفرة أعلاه، حيث يمكن إضافة مزايا إلى كائن ما بعد تعريفه، كما يلي:

<script type="text/javascript">
function Message(text){
   this.text = text;
   this.say = function(){
        document.write(this.text + '<br>');
        };
};

msg1 = new Message('This is the first');
msg1.say();

Message.prototype.shout = function(){
    alert(this.text);
    };

msg2 = new Message('This gets the new feature');
msg2.shout();

/* msg1 وبالمثل بالنسبة لـ ...*/
msg1.shout();

</script>

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

<script type="text/javascript">
function Parent(){
   this.name = 'Parent';
   this.basemethod = function(){
       alert('This is the parent');
       };
};

function Child(){
   this.parent = Parent;
   this.parent();
   this.submethod = function(){
       alert('This from the child');
       };
};

var aParent = new Parent();
var aChild = new Child();

aParent.basemethod();
aChild.submethod();
aChild.basemethod();

</script>

يجب أن نلاحظ أن كائن child هنا له وصول إلى basemethod، دون أن يُعطى ذلك الوصول صراحةً، وإنما يرثه من الصنف الرئيسي بحكم أسطر الإسناد/الاستدعاء داخل تعريف الصنف Child:

   this.parent = Parent;
   this.parent();

وبهذا نكون ورثنا basemethod من الصنف الرئيسي Parent.

اقتباس

الخلاف حول جافاسكربت

لجافاسكربت سمعة سيئة وسط المبرمجين لأسباب كثيرة، أحدها إمكانية إنشاء كائنات دون استخدام الكلمة المفتاحية new، ودون إرسال أي خطأ، لذا ستكون النتيجة غير التي نريدها، وسنواجه زلات برمجيةً يصعب إيجادها، أحد أسبابها أن جافاسكربت ليس لديها مفهوم الصنف نفسه، وإنما تحاكيه محاكاةً فقط من خلال آلية النموذج الأولي، وليتغلب مبرمجو جافاسكربت على هذه المشكلة طوروا بعض المصطلحات التي تنتج شيفرات أكثر موثوقيةً، لكن تفسيرها يتطلب بعض المفاهيم المتقدمة من علوم الحاسوب التي يقصر عنها شرحنا، فإذا أردت استخدام جافاسكربت للبرمجة الكائنية التوجه ننصحك بقراءة الكتاب القصير Javascript the Good Parts الذي كتبه Douglas Crockford، والذي يشرح السبب الذي يجعل التقنيات المشروحة أعلاه غير مثالية، وكيفية تنفيذها بشكل أفضل.

يمكن استخدام نفس حيلة التفويض التي استخدمناها في VBScript، كما يلي:

<script type=text/JavaScript>
function noReturn(){
   this.parent.printIt();
};

function returnValue(){
      return this.parent.getAttribute();
};

function newMethod(){
      document.write("This is unique to the sub class<BR>");
};

function SubClass(){
   this.parent = new MyClass(27);
   this.aMethodWithNoReturnValue = noReturn; 
   this.aMethodWithReturnValue = returnValue;
   this.aNewMethod = newMethod;
};

var inst, aValue;
inst = new SubClass(); // عرِّف الصنف الرئيسي 
document.write("The sub class value is:<BR>");
inst.aMethodWithNoReturnValue();
aValue = inst.aMethodWithReturnValue();
inst.aNewMethod();
document.write("aValue = " + aValue);
</script>

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

خاتمة

نأمل في نهاية هذا المقال أن تكون تعلمت ما يلي:

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

ترجمة -بتصرف- للفصل السابع عشر: Object Oriented Programming من كتاب Learning To Program لصاحبه Alan Gauld.

اقرأ أيضًا

• المقال التالي: البرمجة الحدثية Event Driven Programming المساقة بالأحداث
• المقال السابق: التعابير النمطية في البرمجة
• التوابع السحرية (Magic Methods) في PHP
• البرمجة كائنية التوجه (Object Oriented Programming) في PHP
• البرمجة كائنية التوجه (Object Oriented Programming) في لغة سي شارب #C
• تطبيق البرمجة كائنية التوجه في لغة سي شارب #C - الجزء الثالث

تعرَّف التعابير النمطية بأنها مجموعات من المحارف التي تصف مجموعةً أخرى من المحارف أكبر منها، وهي تصف نمط المحارف الذي نستطيع البحث عنه في متن نص ما، وهي تشبه مفهوم المحارف البديلة wildcards المستخدمة في تسمية الملفات على أغلب نظم التشغيل، حيث يمكن استخدام محرف النجمة * لتمثيل أي تسلسل من المحارف في اسم ملف، ولهذا فإن ‎*.py تعني أي ملف ينتهي بالامتداد ‎.py، بل إن المحارف البديلة ما هي إلا مجموعة فرعية صغيرة من التعابير النمطية.

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

ولعل إحدى الخصائص المميزة للتعابير النمطية هي أنها تُظهر أوجه التشابه مع البرامج في البنية، فهي أنماط مبنية من وحدات أصغر منها، وتلك الوحدات هي:

• محارف منفردة.
• محارف بديلة.
• نطاقات أو مجموعات من المحارف، أو مجموعات محاطة بأقواس.

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

التسلسلات

تسلسلات المحارف

لا شك أن أبسط بنية برمجية يمكن تصورها هي تسلسل من المحارف، كما أن أبسط تعبير نمطي ما هو إلا تسلسل من المحارف كذلك:

red

وهذا سيطابق أو يبحث في سلسلة نصية عن أي حدوث لهذه الأحرف الثلاثة التي تتكون منها كلمة red على الترتيب، وبناءً على ذلك سيجد كلمات مثل red وlettered وcredible، لأنها تحتوي على كلمة red ضمنها. ولنتحكم أكثر في خرج المطابقات، فإننا نوفر بعض المحارف الخاصة التي تُعرف باسم المحارف الوصفية metacharacters للحد من نطاق البحث:

يُطلق على هذه المحارف اسم المرابط anchors لأنها تثبت موضع التعبير النمطي في جملة أو كلمة ما، وهناك عدة مرابط أخرى معرَّفة في توثيق وحدة re يمكنك الاطلاع عليها.

المحارف البديلة

قد تحتوي التسلسلات على محارف بديلة Wildcard Characters تحل محل أي محرف، والمحرف البديل هو نقطة .

 جرِّب الشيفرة التالية مثلًا:

>>> import re
>>> re.match('be.t', 'best')
<_sre.SRE_Match object at 0x01365AA0>
>>> re.match('be.t', 'bess')

تخبرنا الرسالة التي في الأقواس السهمية أن التعبير النمطي 'be.t' -الممرَّر وسيطًا أول- يطابق السلسلة 'best' الممرَّرة وسيطًا ثانيًا، كما يطابق 'beat' و'bent' و'belt' وغيرها، لكن المثال الثاني لا يطابق لأن 'bess' لا تنتهي بحرف t، لذا لا يُنشئ MatchObject. يمكنك تجريب عدة مطابقات أخرى لتفهم كيفية عملها، ولاحظ أن match()‎ لا تطابق إلا في بداية السلسلة النصية، أما لمنتصفها فنستخدم search()‎ كما سنرى لاحقًا.

المجالات أو الفئات

يتكون المجال range (أو الفئة set) من تجميعة من المحارف المغلَّفة في أقواس مربعة، ويبحث التعبير النمطي عن أي محرف يكون داخل هذه الأقواس:

>>> re.match('s[pwl]am', 'spam')
<_sre.SRE_Match object at 0x01365AD8>

فهذا سيطابق swam أو slam، لكن لن يطابق sham لأن h غير موجودة في فئة التعبير النمطي.

أما إذا وضعنا محرف الإقحام ^ أول عنصر في المجموعة، فكأننا نقول أننا نريد البحث عن أي محرف عدا المحارف الموجودة في المجموعة:

>>> re.match('[^f]ool', 'cool')
<_sre.SRE_Match object at 0x01365AA0>
>>> re.match('[^f]ool','fool')

وبناءً على ذلك نستطيع مطابقة cool وpool، لكننا لن نطابق fool لأننا نبحث عن أي محرف عدا f في بداية النمط.

المجموعات

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

التكرار

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

يمكن تطبيق جميع محارف التكرار هذه على مجموعات أخرى من المحارف، وبناءً عليه:

>>> re.match('(.an){1,2}s', 'cans')
<_sre.SRE_Match object at 0x013667E0>

يكون النمط هنا ‎(.an){1,2}s الذي يقول إن لدينا مجموعةً تتكون من أي محرف متبوع بالحرفين an، ونريد أن نجد مجموعةً أو اثنتين متبوعتين بالحرف s، وسيطابق هذا النمط: cancans وpans وcanpans، لكن لن يطابق bananas لانعدام وجود حرف قبل مجموعة an الثانية فيها. جرب تعديل البحث ليطابق bananas.

اقتباس

إرشاد: انظر في محددات التكرار الأخرى، ولا تنس a الإضافية التي في آخر bananas.

هناك مشكلة واحدة مع نمط التكرار {m,n}، وهو أنه لا يحد المطابقة لعدد n من الوحدات، وعلى ذلك سيطابق مثال {fo{1,2 الذي في الجدول السابق fooo لأنه يطابق foo في بداية fooo، وعليه فإذا أردنا الحد من عدد المحارف المطابَقة، فسنحتاج إلى أن نُتبع تعبير الضرب بمرساة أو نطاق نفي negated range.

وفي حالتنا، فإن [fo{1,2}[^o سيمنع fooo من المطابقة بما أنه يقول طابق حرف o واحد أو حرفين متبوعين بأي شيء غير o، لكن يجب أن يكون متبوعًا بشيء ما، لذا فإن foo لم تَعُد مطابقةً الآن. يوضح هذا الطبيعة المتقلبة للتعابير النمطية، فقد يصعب ضبطها للحصول على الخرج الذي نريده، ويجب أن نضعها تحت اختبارات فاحصة لتجنب الأخطاء.

أما النمط الفعلي المطلوب للسماح بمطابقة foo وfoobar مع استثناء fooo، فهو ‎'fo{1,2}[^o]*$'‎، وهذا يعني fo أو foo المتبوعين بعدد صفر أو أكثر من حروف o ونهاية السطر، وفي الواقع حتى هذا النمط ليس تامًا وخاليًا من الأخطاء -جرب fooboo مثلًا-، لكن نحتاج أن نشرح بعض العناصر الأخرى قبل أن نحسّنه ونعدل فيه.

التعابير الجشعة

يقال إن التعابير النمطية جشعة، أي أن دوال البحث والمطابقة ستطابق كل ما تستطيعه من السلسلة النصية، بدلًا من التوقف عند أول مطابقة تامة، وهذا لا يهم غالبًا، لكننا سنحصل على مطابقات أكثر من المطلوب عند جمع المحارف البديلة مع عوامل التكرار. لننظر في المثال التالي: إذا كان لدينا تعبير نمطي مثل a.*b الذي يقول إننا نريد إيجاد a متبوعًا بأي عدد من المحارف إلى أن نصل إلى حرف b، فستبحث دالة المطابقة من أول a إلى آخر b، مما يعني أنه إذا احتوت سلسلة البحث على أكثر من b فستُضمَّن جميعًا في الجزء‏ ‎*. من التعبير عدا آخر واحدة، وعليه:

re.match('a.*b','abracadabra')

فقد طابق MatchObject في هذا المثال كل abracadab وليس أول ab فقط، وسلوك المطابقة الجشع هذا هو أكثر الأخطاء التي يرتكبها المبرمج في بداية استخدامه للتعابير النمطية، ولمنع هذا السلوك الجشع نضيف '?' بعد محرف التكرار، كما يلي:

re.match('a.*?b','abracadabra')

مما سيطابق ab فقط.

الشرطيات

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

العناصر الاختيارية

يمكن تحديد محرف ما ليكون اختياريًا باستخدام عدد صفر أو أكثر من محارف التكرار الوصفية:

>>> re.match('computer?d?', 'computer')
<re.MatchObject instance at 864890>

هذا سيطابق compute وcomputer وcomputed، كما سيطابق computerd، لكننا لا نريد هذه الأخيرة، لذا سنضيق النطاق الذي نريده كما يلي:

>>> re.match('compute[rd]$','computer')
<re.MatchObject instance at 874390>

وهذا سيختار computer وcomputed فقط، ويرفض computerd، وإذا أضفنا ? بعد هذا النطاق فسنسمح باختيار compute مع تجنب computerd أيضًا.

التعابير الاختيارية

بالإضافة إلى خيارات المطابقة من قائمة محارف السابقة الذكر، يمكن المطابقة بناءً على اختيار من تعابير فرعية، فقد ذكرنا سابقًا أننا نستطيع جمع تسلسلات من المحارف في أقواس، لكن الواقع أننا نستطيع جمع أي تعبير نمطي عشوائي بين أقواس ومعاملته مثل وحدة، وسنستخدم الصيغة (RE) أثناء شرح التركيب اللغوي هنا للإشارة إلى أي تجميع لتعابير نمطية، والحالة التي نريد دراستها هنا هي مطابقة تعبير نمطي يحتوي على ‎(RE)xxxx أو ‎(RE)yyyy حيث تكون xxxx وyyyy أنماطًا مختلفةً، وبناءً عليه فإذا أردنا مطابقة premature وpreventative فسنفعل هذا بواسطة محرف الاختيار الوصفي |:

>>> regexp = 'pre(mature|ventative)'
>>> re.match(regexp,'premature')
<re.MatchObject instance at 864890>
>>> re.match(regexp,'preventative')
<re.MatchObject instance at 864890>
>>> re.match(regexp,'prelude')

نلاحظ أنه عند تعريف التعبير النمطي تعين علينا أن ندرج النص الكامل لكلا الخيارين داخل أقواس بدلًا من (e|v)، ولو لم نفعل لاقتصر الخيار على prematureentative وprematurventative فقط، أي كان الحرفان فقط هما اللذان سيمثلان الخيارات المتاحة، وليس المجموعات كلها.

نستطيع الآن باستخدام هذه التقنية أن نعود إلى المثال أعلاه الذي أردنا فيه التقاط fo أو foo وتجنب التقاط fooo إضافةً إلى أي شيء يأتي بعدها، وقد تركناها مع تعبير نمطي يتكون من fo{1,2}[^o]*$‎، والمشكلة هنا أن التطابق سيفشل إذا احتوت السلسلة النصية التالية لـ fo أو foo على o، لكن يمكن الالتفاف على ذلك باستخدام عدة خيارات من التعبيرات، ونريد أن ينجح التطابق سواء كان النمط في نهاية السطر أو متبوعًا بأي حرف سوى o، وسيبدو ذلك كما يلي:

fo{1,2}($|[^o])

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

المزيد من الملاحظات حول التعابير النمطية

تحتوي وحدة re على مزايا كثيرة لم نذكرها هنا، يجدر النظر فيها ودراستها من توثيق الوحدة نفسها، لكننا نريد تسليط الضوء على مجموعة من الرايات flags التي يمكن استخدامها عند تصريف التعبيرات مع دالة re.compile()‎، والتي تتحكم في أمور مثل مطابقة النمط في الأسطر المختلفة، أو تجاهله لحالة الأحرف، أو غير ذلك.

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

استخدام التعابير النمطية في بايثون

رأينا في السطور السابقة شيئًا يسيرًا من التعابير النمطية، ونريد أن نطبق ذلك في بايثون، حيث نستطيع استخدامها أداة بحث قويةً جدًا في النصوص، إذ يمكن البحث عن صور كثيرة مختلفة لسلاسل نصية في عملية واحدة، بل يمكن البحث عن المحارف التي لا تُطبع مثل الأسطر الفارغة باستخدام بعض المحارف الوصفية المتاحة، كما يمكن استبدال هذه الأنماط باستخدام التوابع والدوال الخاصة بوحدة re، كما رأينا في دالة match()‎ أعلاه، وفيما يلي بعض الدوال الأخرى المتاحة:

لا شك أن هذه القائمة لا تحتوي جميع توابع re ودوالها، كما أن التوابع التي ذكرناها في الجدول لها معامِلات اختيارية لتوسيع استخدامها، واخترناها لأنها أكثر العمليات استخدامًا، ومناسبةً لاحتياجاتنا.

مثال عملي على التعابير النمطية

لننشئ برنامجًا يبحث في ملف HTML عن وسم IMG ليس له قسم ALT، فإذا وجدنا واحدًا فسنضيف رسالةً إلى المالك ليكتب ملفات HTML أفضل في المستقبل.

import re

# لنسمح بصفر مسافة أو أكثر بين img أو IMG التقط 
# < و I
img = '< *[iI][mM][gG] '     

# alt أو ALT السماح بأي عدد من المحارف حتى 
before >
alt = img + '.*[aA][lL][tT].*>'

# افتح الملف واقرأه في قائمة
filename = input('Enter a filename to search ')
inf = open(filename,'r')
lines = inf.readlines()

# ALT بدون IMG إذا احتوى السطر على وسم
# HTML فأضف رسالتنا كتعليق
for index,line in enumerate(lines):
  if ( re.search(img,line) and not
       re.search(alt,line) ):
        lines[index] += '<!-- PROVIDE ALT TAGS ON IMAGES! -->\n'

# والآن اكتب الملف المعدَّل.
inf.close()
outf = open(filename,'w')
outf.writelines(lines)
outf.close()

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

وهذه الشيفرة ليست مثاليةً لأنها لا تأخذ في الحسبان الحالة التي يكون وسم img فيها مقسمًا على عدة أسطر، لكنها تكفي لشرح التقنية عمومًا، على أنه يُفضل تجنب هذا "التخريب" الذي قمنا به في ملف HTML، لكن الذي ينسى وسوم alt يستحق جزاءه.

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

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

التعابير النمطية في جافاسكربت

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

<script type="text/javascript">
var str = "A lovely bunch of bananas";
document.write(str + "<BR>");
if (str.match(/^A/)) {
   document.write("Found string beginning with A<BR>");
}
if (str.match(/b[au]/)) {
   document.write("Found substring with either ba or bu<BR>");
}
if (!str.match(/zzz/)) {
   document.write("Didn't find substring zzz!<BR>");
}
</script>