رضوى العربي

يُمكِننا أن نُضمِّن نمط المصفوفة الديناميكية (dynamic array) داخل صَنْف كما رأينا بالقسم الفرعي 7.2.4، ولكن بدا الأمر كما لو أننا سنحتاج إلى تعريف صَنْف مختلف لكل نوع من البيانات (data type). في الحقيقة، تُوفِّر جافا خاصية تُعرَف باسم "الأنواع ذات المعاملات غَيْر مُحدَّدة النوع (parameterized types)"، والتي يُمكِنها أن تُجنِّبنا مشكلة تعدد الأصناف كما تُوفِّر جافا الصَنْف ArrayList الذي يُنفِّذ (implement) نمط المصفوفة الديناميكية لجميع أنواع البيانات. الصنف ArrayList والأنواع ذات المعاملات غير محددة النوع (Parameterized Types) تُوفِّر جافا النوع القياسي ArrayList<String>‎ لتمثيل مصفوفة ديناميكية (dynamic arrays) من النوع String. وبالمثل، يُمثِل النوع ArrayList<Button>‎ مصفوفة ديناميكية من النوع Button. بنفس الكيفية، إذا كان Player صنفًا (class) يُمثِل اللاعبين ضِمْن لعبة، فإن النوع ArrayList<Player>‎ يُمثِل مصفوفة ديناميكية من النوع Player. قد يبدو الأمر كما لو أننا نَستخدِم أصنافًا كثيرة، ولكن، في الواقع، هنالك صَنْف (class) واحد فقط هو الصَنْف ArrayList المُعرَّف بحزمة java.util. يُعدّ ذلك الصَنْف صَنْفًا ذي مُعامِلات غَيْر مُحدَّدة النوع (parameterized type) -نوع يُمكِنه أن يَأخُذ معامل نوع (type parameter)-. يُمكِننا ذلك من اِستخدَام صَنْف واحد فقط للحصول على عدة أنواع مثل ArrayList<String>‎ و ArrayList<Button>‎ وحتى ArrayList<T>‎. لابُدّ أن يَكُون معامل النوع T نوعًا كائنيًا (object type) أي اسم صَنْف (class) أو اسم واجهة (interface)، ولا يُمكِنه أن يَكُون نوعًا أساسيًا (primitive type). يعني ذلك أنك لا تستطيع الحصول على ArrayList من النوع int أو ArrayList من النوع char. يُمكِننا مثلًا أن نَستخدِم النوع ArrayList<String>‎ للتّصرِيح (declare) عن مُتْغيِّر كالتالي: ArrayList<String> namelist; أو قد نَستخدِمه كنوع لمعامل صوري (formal parameter) ضِمْن تعريف برنامج فرعي (subroutine) أو كنوع مُعاد (return type) من برنامج فرعي. علاوة على ذلك، قد نَستخدِمه مع العامل new لإنشاء كائنات (objects): namelist = new ArrayList<String>(); يَكُون الكائن المُنشَئ في هذه الحالة من النوع ArrayList<String>‎، ويُمثِل قائمة ديناميكية من السَلاسِل النصية (strings). يُوفِّر الصَنْف مجموعة من توابع النُسخ (instance methods) مثل التابع namelist.add(str)‎ لإضافة سِلسِلة نصية من النوع String إلى القائمة، والتابع namelist.get(i)‎ لجَلْب السِلسِلة النصية الموجود برقم الفهرس i، والتابع namelist.size()‎ لحِسَاب عدد العناصر الموجودة بالقائمة حاليًا. إلى جانب ما سبق، يُستخدَم الصَنْف ArrayList مع أنواع آخرى أيضًا. فمثلًا، إذا كان الصَنْف Player يُمثِل اللاعبين ضِمْن لعبة، يُمكِننا أن نُنشِئ قائمة من اللاعبين كالتالي: ArrayList<Player> playerList = new ArrayList<Player>(); والآن، يُمكِنك أن تَستخدِم playerList.add(plr)‎ لإضافة لاعب plr إلى اللعبة أو قد تَستخدِم playerList.remove(k)‎ لحَذْف اللاعب الموجود برقم الفهرس k. علاوة على ذلك، إذا كان playerList مُتْغيِّرًا محليًا (local variable)، يُمكِنك أن تَستخدِم صيغة التّصرِيح (declaration) المختصرة -اُنظر القسم الفرعي 4.8.2- كما يلي: var playlerList = new ArrayList<Player>(); يَعتمِد مُصرِّف (compiler) الجافا على القيمة المبدئية المُسنَدة إلى playerList لاستنتاج أن نوعه هو ArrayList<Player>‎. عندما تَستخدِم نوعًا (type) مثل ArrayList<T>‎، فإن المُصرِّف يتأكد من أن جميع الكائنات (objects) المضافة إليه من النوع T، وستُعدّ أي محاولة لإضافة كائن (object) من نوع آخر خطأً في بناء الجملة (syntax error)، ولا يُصرَّف عندها البرنامج. لمّا كانت الكائنات المنتمية لصَنْف فرعي من T هي بالنهاية من النوع T، فإنه من المُمكن إضافتها أيضًا إلى القائمة. فمثلًا، يُمكِن لمُتْغيِّر من النوع ArrayList<Pane>‎ أن يَحمِل كائنات من النوع BorderPane أو TilePane أو GridPane أو أي صنف فرعي (subclass) آخر من الصَنْف Pane (في الواقع، يُشبِه ذلك طريقة عمل المصفوفات حيث يستطيع كائن من النوع T[]‎ أن يَحمِل أي كائنات تنتمي لصَنْف فرعي من T). بالمثل، إذا كان T عبارة عن واجهة (interface)، فمن الممكن إضافة أي كائن (objects) إلى القائمة طالما كان يُنفِّذ (implement) تلك الواجهة T. تَملُك الكائنات من النوع ArrayList<T>‎ جميع توابع النسخ (instance methods) التي قد تَتَوقَّعها من مصفوفة ديناميكية (dynamic array). بِفَرْض أن list عبارة عن مُتْغيِّر من النوع ArrayList<T>‎، اُنظر التوابع التالية: list.size()‎: يُعيد حجم القائمة أي عدد العناصر الموجودة بها حاليًا. قد يَكون حجم القائمة مُساويًا للصفر. فمثلًا، يُنشِئ باني الكائن الافتراضي new ArrayList<T>()‎ قائمة حجمها يُساوي صفر، وفي العموم، تتراوح أرقام المواضع الصالحة من 0 وحتى list.size()-1. list.add(obj)‎: يُضيِف كائنًا (object) إلى نهاية القائمة مع زيادة حجمها بمقدار الواحد. لاحِظ أن المُعامل obj لابُد أن يَكُون كائنًا من النوع T أو قد يَكُون فارغًا. list.get(N)‎: يَستقبِل المُعامل N الذي لابُدّ أن يكون عددًا صحيحًا (integer) يتراوح من 0 إلى list.size()-1 ثُمَّ يُعيد القيمة المُخزَّنة بالمَوْضِع N، والتي بطبيعة الحال تَكُون من النوع T. إذا كان N خارج النطاق المسموح به، يَقَع اعتراض من النوع IndexOutOfBoundsException. في الواقع، تُشبه تلك الدالة الأمر A[N]‎ -بِفَرْض أن A عبارة عن مصفوفة- بفارق أنه لا يُمكِن اِستخدَام list.get(N)‎ بالجانب الأيسر من أي تَعْليمَة إِسْناد (assignment statement). list.set(N, obj)‎: يُسنِد الكائن obj إلى عنصر المصفوفة بالمَوْضِع N أي يَحلّ ذلك الكائن محلّ الكائن المُخزَّن مُسْبَقًا بذلك الموضع. لابُدّ أن يَكُون المُعامل obj من النوع T كما ينبغي أن يَكُون N عددًا صحيحًا (integer) يتراوح بين 0 و list.size()-1. في الواقع، تُشبِه تلك الدالة الأمر A[N] = obj بِفَرْض أن A عبارة عن مصفوفة. list.clear()‎: يحذِف جميع العناصر الموجودة بالقائمة، ويَضبُط حجمها إلى الصفر. list.remove(N)‎: يَحذِف العنصر الموجود بالمَوْضِع N من القائمة، ويُنقِص حجمها بمقدار الواحد كما يَنقِل العناصر الموجودة بَعْد العنصر المحذوف مَوْضِعًا للأعلى. لاحِظ أن المُعامل N لابُدّ أن يَكُون عددًا صحيحًا (integer) يتراوح بين 0 و list.size()-1. list.remove(obj)‎: يَحذِف الكائن المُمرَّر من القائمة إذا كان موجودًا بها، ويُنقِص حجمها بمقدار الواحد كما يَنقِل العناصر الموجودة بَعْد العنصر المحذوف مَوضِعًا للأعلى. لاحِظ أنه في حالة وجود الكائن obj أكثر من مرة ضِمْن القائمة، فإنه يَحذِف أول حدوث له فقط أما إذا لم يَكُن موجودًا، فإنه لا يَفعَل أي شيء أي لا يُعدّ ذلك بمثابة خطأ. list.indexOf(obj)‎: يَبحَث عن الكائن obj داخل القائمة، ويُعيد أول مَوْضِع لحدوثه إذا كان موجودًا أما إذا لم يَكُن موجودًا، فإنه يُعيِد العدد -1. ملحوظة: يَستخدِم آخر تابعين الاستدعاء obj.equals(item)‎ لموازنة obj -لو لم يَكُن obj فارغًا- مع عناصر القائمة أي أنهما يَفْحَصا تَساوِي السَلاسِل النصية بِفْحَص محتوياتها وليس مَواضِعها بالذاكرة. تُوفِّر جافا أصنافًا كثيرة ذات مُعاملات غَيْر مُحدَّدة النوع (parameterized classes) لتمثيل هياكل البيانات المختلفة (data structure)، وتُشكِّل تلك الأصناف إطار جافا للتجميعات (Java Collection Framework). لقد ناقشنا هنا الصَنْف ArrayList فقط، ولكننا سنُعود لمناقشة هذا الموضوع على نحو أكثر تفصيلًا بالفصل 10. ملحوظة: يُستخدَم الصَنْف ArrayList أيضًا بشكل عادي بدون مُعاملات غَيْر مُحدَّدة النوع (non-parametrized) أي يُمكنِنا أن نُصرِّح (declare) عن مُتْغيرِّات، ونُنشِئ كائنات من النوع ArrayList كالتالي: ArrayList list = new ArrayList(); يُكافِئ ذلك التّصرِيح عن مُتْغيٍّر list من النوع ArrayList<Object>‎. يَعنِي ذلك أن list يُمكِنه أن يَحمِل أي كائن ينتمي إلى صَنْف فرعي من Object. ولأن أي صَنْف هو بالنهاية صَنْف فرعي (subclass) من Object، فإنه من الممكن إضافة أي كائن (object) إلى list. الأصناف المُغلِّفة (Wrapper Classes) كما أوضحنا مُسْبَقًا، لا تتوافق الأنواع ذات المعاملات غير محدَّدة النوع (parameterized types) مع الأنواع الأساسية (primitive types) أي لا يُمكِنك مثلًا أن تَستخدِم شيئًا مثل ArrayList<int>‎. مع ذلك، نظرًا لتوفُّر أصناف مُغلِّفة (wrapper classes) مثل Integer و Character، فلربما الأمر ليس مُقيَدًا تمامًا. لقد تَعرضنا بالقسم 2.5 للأصناف Double و Integer. تُعرِّف تلك الأصناف التوابع الساكنة Double.parseDouble()‎ و Integer.parseInteger()‎ المُستخدَمة لتَحْوِيل سِلسِلة نصية (string) إلى قيمة عددية. تَتَضمَّن تلك الأصناف أيضًا ثوابتًا (constants) مثل Integer.MAX_VALUE و Double.NaN. لقد تَعرضنا أيضًا للصَنْف Character ببعض الأمثلة. يُعرِّف ذلك الصَنْف التابع الساكن Character.isLetter()‎ المُستخدَم لفْحَص ما إذا كانت قيمة معينة من النوع char عبارة عن حرف أبجدي (letter) أم لا. تَتوفَّر في الواقع أصناف مشابهة لكل نوع أساسي (primitive type) مثل Long و Short و Byte و Float و Boolean. تُعدّ جميع تلك الأصناف أصنافًا مُغلِّفة (wrapper classes)، وعلى الرغم من أنها تَحوِي بعض الأعضاء الساكنة (static members) المفيدة عمومًا، فإنها تُستخدَم أيضًا لغرض آخر: تَمثيِل الأنواع الأساسية ككائنات (objects). تذكَّر دومًا أن الأنواع الأساسية ليست أصنافًا (classes)، وأن قيم تلك الأنواع ليست كائنات (objects). مع ذلك، قد يَكُون من المفيد أحيانًا التَعامُل مع قيمة من نوع أساسي كما لو كانت كائنًا (object)، فمثلًا قد نرغب بتَخْزِين قيمة من نوع أساسي (primitive type) داخل قائمة من النوع ArrayList. لا نستطيع في الواقع فِعِل ذلك حرفيًا، ولكن يُمكِننا التَحايُل على ذلك قليلًا بتَغْليف (wrap) تلك القيمة داخل كائن ينتمي إلى صَنْف مُغلِّف (wrapper classes). على سبيل المثال، يحتوي أي كائن من النوع Double على مُتْغيِّر نُسخة (instance variable) وحيد من النوع double. يَعمَل ذلك الكائن بمثابة مُغلِّف (wrapper) للقيمة العددية. يُمكِنك إذًا أن تُنشِئ كائنًا (object) لتَغليف قيمة من النوع double مثل 6.0221415e23 كالتالي: Double d = new Double(6.0221415e23); في الواقع، يَحتوِي d على نفس المعلومات التي تَحتوِيها قيمة من النوع double، ولكنه كائن (object). يُمكِنك أن تَستدِعي d.doubleValue()‎ لاسترجاع القيمة العددية المُغلَّفة داخل الكائن. بالمثل، يُمكِنك أن تُغلِّف قيمة من النوع int ضِمْن كائن من النوع Integer أو قيمة من النوع boolean ضِمْن كائن من النوع Boolean، وهكذا. إذا كنت تريد أن تُنشِئ كائنًًا من النوع Double لتَغْلِيف قيمة عددية x، يُفضَّل أن تَستخدِم التابع الساكن Double.valueOf(x)‎ بدلًا من أن تَستدعِي الباني new Double(x)‎؛ لأن استدعاء التابع Double.valueOf()‎ بنفس قيمة المُعامل (parameter) أكثر من مرة دائمًا ما يُعيِد نفس ذات الكائن. تحديدًا، بَعْد أول استدعاء لذلك التابع بقيمة مُعامِل معينة، فإنه سيُعيد نفس ذلك الكائن بالاستدعاءات المتتالية لنفس قيمة المُعامل. لا يُعدّ ذلك مشكلة كما قد تَظّن؛ لأن الكائنات من النوع Double غَيْر قابلة للتَعْدِيل (immutable) أي أن الكائنات التي لها نفس القيمة المبدئية ستَظِلّ دائمًا متطابقة. يُعدّ التابع Double.valueOf تابعًا مُصنِّعًا (factory method) مثل تلك التوابع التي تَعرَّضنا لها بالقسم 6.2 أثناء تَعامُلنا مع الصَنْفين Color و Font، وتحتوي جميع الأصناف المُغلِّفة عمومًا على تابع مُصنِّع مشابه مثل Character.valueOf(ch)‎ و Integer.valueOf(n)‎. يَتَوفَّر أيضًا تحويل أتوماتيكي بين كل نوع أساسي (primitive type) وصَنْفه المُغلِّف (wrapper class) لتسهيل الاِستخدَام. على سبيل المثال، إذا كنت تَستخدِم قيمة من النوع int ضِمْن سياق يَتَطلَّب كائنًا (object) من النوع Integer، يُمكِنك أن تُغلِّف تلك القيمة ضِمْن كائن من النوع Integer أتوماتيكيًا كالتالي: Integer answer = 42; سيقرأ الحاسوب التَعْليمَة بالأعلى كما لو كانت مَكْتُوبة كالتالي: Integer answer = Integer.valueOf(42); يُطلَق على ذلك اسم "التغليف الأوتوماتيكي (autoboxing)"، ويَعمَل من الجهة الآخرى أيضًا. فمثلًا، إذا كان d يُشير إلى كائن من النوع Double، يُمكِنك أن تَستخدِم d بتعبير عددي (numerical expression) مثل 2*d. تُفَك (unboxing) القيمة العددية داخل d أتوماتيكيًا، ويُحسَب حاصل ضربها مع العدد 2. كثيرًا ما يَسمَح لك التَغْلِيف الأتوماتيكي (autoboxing) وفكه بتَجاهُل الفارق بين الأنواع الأساسية (primitive types) والكائنات (objects). يُعدّ ما سبق صحيحًا فيما يَتَعلَّق بالأنواع ذات المعاملات غَيْر مُحدَّدة النوع (parameterized types). على الرغم من عدم توفُّر النوع ArrayList<int>‎، يَتَوفَّر ArrayList<Integer>‎ حيث تَحمِل مصفوفة من ذلك النوع كائنات من النوع Integer التي تُمثِل مُجرّد قيمة من النوع int ضِمْن مُغلِّف صغير. لنَفْترِض أن لدينا كائن (object) من النوع ArrayList<Integer>‎، اُنظر التالي: ArrayList<Integer> integerList; integerList = new ArrayList<Integer>(); يُمكِننا الآن أن نُضيف كائنًا مُمثلًا للعدد 42 مثلًا إلى integerList كالتالي: integerList.add( Integer.valueOf(42) ); أو قد نعتمد على التَغْلِيف الأتوماتيكي (autoboxing) كالتالي: integerList.add( 42 ); سيُغلِّف المُصرِّف (compiler) العدد 42 أتوماتيكيًا داخل كائن (object) من النوع Integer قبل إضافته إلى القائمة. بالمثل، يُمكِننا كتابة التالي: int num = integerList.get(3); يُعيد التابع integerList.get(3)‎ قيمة من النوع Integer، ولكن بِفَضل خاصية فك التَغْلِيف (unboxing)، سيُحوِّل المُصرِّف (compiler) القيمة المُعادة (return value) أتوماتيكيًا إلى قيمة من النوع int كما لو كنا قد كتبنا ما يلي: int num = integerList.get(3).intValue(); نستطيع إذًا أن نَستخدِم المصفوفة integerList كما لو كانت مصفوفة ديناميكية (dynamic array) من النوع int لا من النوع Integer. وفي العموم، يَنطبِق نفس الأمر على القوائم (lists) من الأصناف المُغلِّفة الآخرى مثل ArrayList<Double>‎ و ArrayList<Character>‎. يَتَبقَّى لنا مشكلة أخيرة: يُمكِن لأي قائمة أن تَحمِل القيمة null، ولكن لا تَتَوفَّر قيمة من النوع الأساسي (primitive type) مناظرة للقيمة null. وبالتالي، إذا أعاد استدعاء مثل integerList.get(3)‎ ضِمْن التَعْليمَة int num = integerList.get(3);‎ القيمة null، سيَحدُث اِعتراض مُتعلِّق بوجود مُؤشر فارغ (null pointer). ينبغي إذًا أن تَأخُذ ذلك بالحسبان إذا لم تَكُن متأكدًا بشأن وجود قيم فارغة ضِمْن القائمة. البرمجة باستخدام ArrayList كمثال بسيط، سنُعيِد كتابة البرنامج ReverseWithDynamicArray.java من القسم السابق باِستخدَام النوع ArrayList بدلًا من الصَنْف المُخصَّص (custom) الذي كنا قد كتبناه. نظرًا لأننا سنُخزِّن أعدادً صحيحة (integers) ضِمْن القائمة، سنَستخدِم إذًا النوع ArrayList<Integer>‎. اُنظر شيفرة البرنامج بالكامل: import textio.TextIO; import java.util.ArrayList; public class ReverseWithArrayList { public static void main(String[] args) { ArrayList<Integer> list; list = new ArrayList<Integer>(); System.out.println("Enter some non-zero integers. Enter 0 to end."); while (true) { System.out.print("? "); int number = TextIO.getlnInt(); if (number == 0) break; list.add(number); } System.out.println(); System.out.println("Your numbers in reverse are:"); for (int i = list.size() - 1; i >= 0; i--) { System.out.printf("%10d%n", list.get(i)); } } } كما أوضحنا مُسْبَقًا، عادةً ما تُستخدَم حَلْقة التَكْرار for لمعالجة المصفوفات الديناميكية من النوع ArrayList بنفس طريقة مُعالجة المصفوفات العادية. على سبيل المثال، تَطبَع حَلْقة التَكْرار (loop) التالية جميع العناصر بالمصفوفة namelist من النوع ArrayList<String>‎: for ( int i = 0; i < namelist.size(); i++ ) { String item = namelist.get(i); System.out.println(item); } يُمكِنك أيضًا أن تَستخدِم حَلْقة التَكْرار for-each مع المصفوفات من النوع ArrayList كالتالي: for ( String item : namelist ) { System.out.println(item); } عند التَعامُل مع الأصناف المُغلِّفة (wrapper classes)، يُمكن للمُتْغيِّر المُتحكِّم بحَلْقة التَكْرار for-each أن يَكُون من النوع الأساسي (primitive type) بفضل خاصية فك التغليف (unboxing). على سبيل المثال، إذا كان numbers مُتْغيِّر من النوع ArrayList<Double>‎، يُمكِنك أن تَستخدِم حَلْقة التَكْرار التالية لحِسَاب حاصل مجموع القيم بالقائمة: double sum = 0; for ( double num : numbers ) { sum = sum + num; } ستَعمَل الشيفرة بالأعلى طالما لم يَكُن هناك أي عنصر ضِمْن القائمة مُساوِي للقيمة null. إذا كان هنالك احتمالية لحُدوث ذلك، فينبغي أن تَستخدِم مُتْغيِّرًا مُتحكِّمًا بالحَلْقة (loop control variable) من النوع Double ثُمَّ تَفْحَص ما إذا كانت قيمته فارغة أم لا. على سبيل المثال، تَحسِب الشيفرة التالية حاصل مجموع القيم غَيْر الفارغة بالقائمة: double sum; for ( Double num : numbers ) { if ( num != null ) { // يتم فك التغليف للحصول على قيمة‫ double sum = sum + num; } } سنَفْحَص الآن البرنامج SimplePaint2.java الذي يُعدّ نسخة مُحسَّنة من البرنامج SimplePaint.java الذي كتبناه بالقسم الفرعي 6.3.3. بالبرنامج الجديد، يستطيع المُستخدِم أن يَرسِم منحنيات داخل مساحة رسم (drawing area) بالنَقْر على زر الفأرة والسَحب كما يستطيع أن يختار كُلًا من اللون المُستخدَم للرسم ولون خلفية مساحة الرسم من قائمة. تحتوي أيضًا قائمة "Control" على عدة أوامر منها: الأمر "Undo" المُستخدَم لحَذْف آخر منحنى رسمه المُستخدِم على الشاشة، والأمر "Clear" المُستخدَم لحَذْف جميع المنحنيات. يَتَوفَّر أيضًا مربع الاختيار "Use Symmetry" المسئول عن تَفْعِيل خاصية التماثلية أو تَعْطِيلها. تَنعكِس المنحنيات التي يَرسِمها المُستخدِم أثناء تَفْعِيل تلك الخاصية أفقيًا ورأسيًا لتُنتِج نمطًا متماثلًا. بخلاف البرنامج الأصلي SimplePaint، تَستخدِم النسخة الجديدة هيكلًا بيانيًا (data structure) لتَخْزِين عدة معلومات عما رَسمه المُستخدِم. عندما يختار المُستخدِم لون خلفية جديد، تُملَئ الحاوية (canvas) بذلك اللون ثم يُعاد رَسْم جميع المنحنيات مجددًا على الخلفية الجديدة، ولذلك لابُدّ أن نُخزِّن كل المعلومات اللازمة لإعادة رَسْم تلك المنحنيات. بالمثل، عندما يختار المُستخدِم الأمر "Undo"، تُحَذَف بيانات آخر منحنى رسمه المُستخدِم ثُمَّ يُعاد رَسْم الصورة بالكامل مُجددًا بالاعتماد على البيانات المُتبقية. سنعتمد في العموم على الهيكل البياني ArrayList لتَخْزِين تلك البيانات. تَتَكوَّن البيانات الأساسية لأي منحنى من قائمة من النقط الواقعة على المنحنى، والتي سنُخزِّنها بكائن من النوع ArrayList<Point2D>‎. لاحِظ أن الصَنْف Point2D هو صَنْف قياسي (standard) مُعرَّف بحزمة javafx.geometry، ويُمكِننا أن نُنشِئ كائنًا منه باِستخدَام قيمتين من النوع double يُمثِلان الإحداثي x والإحداثي y. يَمتلك أي كائن من النوع Point2D تابعي جَلْب pt.getX()‎ و pt.getY()‎ لاسترجاع قيمة x و y. إلى جانب ذلك، سنحتاج إلى مَعرِفة لون المنحنى، وما إذا كان ينبغي تطبيق خاصية التماثلية عليه أم لا. سنُخزِّن جميع البيانات المطلوبة لرَسْم منحنى ضِمْن كائن من النوع CurveData، والذي سنُعرِّفه كصَنْف مُتْدِاخل (nested class) بالبرنامج: private static class CurveData { Color color; // لون المنحنى boolean symmetric; // خاصية التماثلية ArrayList<Point2D> points; // نقاط المنحنى } نظرًا لأن الصورة قد تَحتوِي على عدة منحنيات وليس فقط منحنى وحيد، ولأننا نحتاج إلى تَخْزِين كل البيانات الضرورية لإعادة رَسْم الصورة بالكامل، سنحتاج إذًا إلى قائمة من الكائنات من النوع CurveData. سيَستخدِم البرنامج المُتْغيِّر curves من النوع ArrayList لذلك الغرض، وسنُصرِّح عنه كالتالي: ArrayList<CurveData> curves = new ArrayList<CurveData>(); لدينا هنا قائمة من الكائنات (objects)، ويَحتوِي كل كائن منها على قائمة من النقط كجزء من البيانات المُعرَّفة بداخله. سنَفْحَص الآن عدة أمثلة على معالجة ذلك الهيكل البياني (data structure). أولًا، عندما يَنقُر المُستخدِم بزر الفأرة على مساحة الرسم (drawing surface)، يَعنِي ذلك أنه يَرسِم منحنى جديدًا، ولذلك ينبغي أن نُنشِئ كائنًا جديدًا من النوع CurveData، ونُهيئ جميع مُتْغيِّرات النُسخ (instance variables) المُعرَّفة بداخله. بَفْرَض أن currentCurve هو مُتْغيِّر عام (global) من النوع CurveData، يُمكِننا تعريف البرنامج mousePressed()‎ كالتالي: currentCurve = new CurveData(); // ‫أنشئ كائن من النوع CurveData // ‫يُنسخ اللون المستخدم لرسم المنحنى من متغير النسخة الممثل للون // المستخدم للرسم currentCurve.color = currentColor; // ‫تنسخ خاصية التماثلية أيضًا من القيمة الحالية للمتغير useSymmetry currentCurve.symmetric = useSymmetry; currentCurve.points = new ArrayList<Point2D>(); // A new point list object. عندما يَسحَب المُستخدِم الفأرة، ينبغي أن نُضيف نقطًا جديدة إلى المُتْغيِّر currentCurve، وأن نَرسِم قطعًا مستقيمة بين تلك النقط أثناء إضافتها. في المقابل، عندما يُحرِّر المُستخدِم الفأرة، يَكُون المنحنى قد اكتمل، وينبغي إذًا أن نُضيِفه إلى قائمة المنحنيات باستدعاء ما يلي: curves.add( currentCurve ); عندما يُغيِّر المُستخدِم لون الخلفية أو يختار الأمر "Undo"، ينبغي أن نُعيِد رَسْم الصورة. يَحتوِي البرنامج على التابع redraw()‎ المسئول عن إعادة رَسْم الصورة بالكامل. يَعتمِد التابع على البيانات الموجودة بالمُتْغيِّر curves لإعادة رَسْم جميع المنحنيات، ويَستخدِم حَلْقة تَكْرار for-each لمعالجة بيانات كل منحنى على حدى كالتالي: for ( CurveData curve : curves ) { . // ‫ارسم المنحنى الذي يمثله الكائن curve من النوع CurveData . } لاحِظ أن curve.points عبارة عن مُتْغيِّر من النوع ArrayList<Point2D>‎ أي عبارة عن قائمة من النقط الواقعة على المنحنى. يُمكِننا على سبيل المثال أن نَسترجِع النقطة i على المنحنى باستدعاء التابع get()‎ المُعرَّف بالقائمة curve.points.get(i)‎. يُعيِد ذلك الاستدعاء قيمة من النوع Point2D التي تُعرِّف بدورها توابع الجَلْب getX()‎ و getY()‎. يُمكِننا إذًا أن نُشير إلى الإحداثي x للنقطة i على المنحنى مباشرةً كالتالي: curve.points.get(i).getX() قد يبدو الاستدعاء السابق مُعقدًا، ولكنه مثال جيد على الأسماء المركبة (complex names). يُخصِّص ذلك الاسم مسارًا إلى جزء من البيانات: اذهب إلى الكائن curve. بداخل ذلك الكائن، إذهب إلى points. بداخل points، إذهب إلى العنصر برقم المَوْضِع i. من هذا العنصر، اِسترجِع الإحداثي x من خلال استدعاء تابعه getX()‎. اُنظر تعريف التابع redraw()‎ بالكامل: private void redraw() { g.setFill(backgroundColor); g.fillRect(0,0,canvas.getWidth(),canvas.getHeight()); for ( CurveData curve : curves ) { g.setStroke(curve.color); for (int i = 1; i < curve.points.size(); i++) { // ‫ارسم قطعة مستقيمة من رقم الموضع i-1 إلى رقم الموضع i double x1 = curve.points.get(i-1).getX(); double y1 = curve.points.get(i-1).getY(); double x2 = curve.points.get(i).getX(); double y2 = curve.points.get(i).getY(); drawSegment(curve.symmetric,x1,y1,x2,y2); } } } يَرسِم التابع drawSegment()‎ قطعة مستقيمة من (x1,y1) إلى (x2,y2). بالإضافة إلى ذلك، إذا كان المُعامل (parameter) الأول يُساوِي true، فإنه أيضًا يَرسِم انعكاسًا أفقيًا ورأسيًا لتلك القطعة. لقد رَكَّزنا هنا على اِستخدَام الصَنْف ArrayList ضِمْن البرنامج، ولكن يُفضَّل بالطبع أن تَتَطلِع على الشيفرة الكاملة للبرنامج SimplePaint2.java. بالإضافة إلى كَوْنه مثال على اِستخدَام الأنواع ذات المُعاملات غَيْر محدَّدة النوع (parameterized types)، فإنه يُعدّ أيضًا مثالًا جيدًا على إنشاء القوائم (menus) واِستخدَامها. ينبغي عمومًا أن تَكُون قادرًا على فهم البرنامج بالكامل. ترجمة -بتصرّف- للقسم Section 3: ArrayList من فصل Chapter 7: Arrays and ArrayLists من كتاب Introduction to Programming Using Java.

تَعرَّضنا حتى الآن إلى بعض الأمثلة على معالجة المصفوفات في المقال السابق، ولكن غالبيتها كان مُجرد أمثلة بسيطة على معالجة عناصر مصفوفة من البداية إلى النهاية أو جَلْب عشوائي لقيمة عنصر ضِمْن مصفوفة. سنَفْحَص بهذا القسم وما يليه من أقسام بعضًا من الأمور الآخرى الأكثر تشويقًا. أمثلة على المعالجة لابُدّ أن تكون حريصًا فيما يتعلَّق بالفهارس من خارج نطاق المصفوفة. لنَفْترِض مثلًا أن lines عبارة عن مصفوفة من النوع String[]‎، وأننا نريد مَعرِفة ما إذا كانت تلك المصفوفة تحتوي على أية عناصر مكررة بموضعين متتاليين. ينبغي إذًا أن نَفْحَص الاختبار lines.equals(lines[i+1])‎ لأي فهرس i. اُنظر المحاولة الخاطئة التالية: boolean dupp = false; // Assume there are no duplicates for ( int i = 0; i < list.length; i++ ) { if ( lines[i].equals(lines[i+1]) ) { // THERE IS AN ERROR HERE! dupp = true; // we have found a duplicate! break; } } تبدو حلقة التكرار for بالأعلى مثل الكثير من الحلقات التي تعرضنا لها من قبل، لذلك ما هي المشكلة إذًا؟ يحدث الخطأ عندما تسند القيمة النهائية إلى i بالحلقة أي عندما i تساوي lines.length-1. في هذه الحالة، i+1 تساوي lines.length. لكن فهرس العنصر الأخير بالمصفوفة هو lines.length-1، لذلك lines.length ليست فهرس صالح. يعني ذلك أن lines[i+1]‎ يتسبب بحدوث اعتراض من النوع ArrayIndexOutOfBoundsException. يمكنك إصلاح ذلك بسهولة عن طريق إيقاف حلقة التكرار قبل i+1 من النطاق المسموح به، كالتالي: boolean dupp = false; // Assume there are no duplicates for ( int i = 0; i < list.length - 1 ; i++ ) { if ( lines[i].equals(lines[i+1]) ) { dupp = true; // we have found a duplicate! break; } } يظهر أحيانًا نوع شبيه من الأخطاء عند العمل مع المصفوفات المملوءة جزئيًا (partially full arrays) -اُنظر القسم الفرعي 3.8.4-، ولكنه قد لا يَكُون بهذا الوضوح. إذا كان جزء معين فقط من المصفوفة مملوءًا بحيث يُستخدَم عداد (counter) لمعرفة عدد الخانات المُستخدَمة فعليًا ضِمْن تلك المصفوفة. لا تتعلَّق المشكلة في تلك الحالة بمحاولة الوصول لعنصر بموضع خارج المصفوفة ولكنها تتعلق بفحص جزء من المصفوفة قيد الاستخدام بالفعل. عندما يُحاوِل البرنامج الوصول إلى مَوْضِع خارج المصفوفة، ينهار (crash) البرنامج على الأقل مما يَسمَح لك برصد المشكلة لكن في حالة المصفوفات المملوءة جزئيًا، لن تتمكن من رصد الخطأ بسهولة. لقد رأينا الكيفية التي يُمكِننا بها أن نُضيف عناصر إلى مصفوفة مملوءة جزئيًا، ولكننا لم نَتعرَّض لطريقة حَذْف تلك العناصر؟ لنَفْترِض مثلًا أننا نَكْتُب برنامجًا عبارة عن لعبة يستطيع اللاعبون الانضمام إليها ومغادرتها بأي وقت. يُمكِننا إذًا أن نُنشِئ الصَنْف Player لتمثيل كل لاعب موجود باللعبة. سنُخزِّن بطبيعة الحال قائمة اللاعبين الموجودين باللعبة داخل مصفوفة من النوع Player[]‎، وليَكُن اسمها هو playerList. نظرًا لأن عدد اللاعبين قد يَتَغيَّر بأي وقت، سنُطبِق نمط المصفوفة المملوءة جزئيًا، لذا سنُعرِّف مُتغيِّر playerCt لتَخْزِين عدد اللاعبين الموجودين باللعبة. بفَرْض عدم احتمالية وجود أكثر من 10 لاعبين بأي لحظة، يُمكِننا إذًا أن نُصرِّح عن المُتْغيِّرات كالتالي: Player[] playerList = new Player[10]; // Up to 10 players. int playerCt = 0; // At the start, there are no players. بَعْد انضمام بعض اللاعبين إلى اللعبة، سيُصبِح المُتْغيِّر playerCt أكبر من الصفر كما ستُخزَّن الكائنات (objects) المُمثِلة للاعبين داخل عناصر المصفوفة playerList[0]‎ و playerList[1]‎ .. وحتى playerList[playerCt-1]‎. لاحِظ أننا لم نُشِر إلى العنصر playerList[playerCt]‎. يُمثِل المُتْغيِّر playerCt كُلًا من عدد العناصر الفعلية الموجودة داخل المصفوفة، وكذلك فهرس (index) الخانة التالية المتاحة بالمصفوفة. تُضيِف الشيفرة التالية كائنًا جديدًا newPlayer إلى اللعبة: playerList[playerCt] = newPlayer; // Put new player in next // available spot. playerCt++; // And increment playerCt to count the new player. في المقابل، قد يَكُون حَذْف لاعب من اللعبة أصعب قليلًا، لأننا لا نُريد بالطبع أن نَترُك مَوْضِع اللاعب المطلوب حَذْفه فارغًا. لنَفْترِض مثلًا أننا نُريد حَذْف اللاعب الموجود بالفهرس k داخل المصفوفة playerList. يَعنِي ذلك أن عدد الخانات المُستخدَمة فعليًا بالمصفوفة سيُصبِح أقل بمقدار الواحد. إذا لم يَكُن ترتيب اللاعبين داخل المصفوفة مُهِمًا، يُمكنِنا إذًا أن نَنقِل اللاعب الأخير الموجود فعليًا داخل المصفوفة إلى المَوْضِع k ثُمَّ نُنقِص قيمة playerCt بمقدار الواحد كالتالي: playerList[k] = playerList[playerCt - 1]; playerCt--; لم يَعُد اللاعب الذي كان موجودًا مُسْبَقًا بالمَوْضِع k موجودًا بالمصفوفة، فقد حَذْفناه ببساطة من القائمة. في المقابل، أصبح اللاعب الذي كان موجودًا مُسْبَقًا بالموضع playerCt - 1 موجودًا بالمصفوفة مرتين، ولكن نظرًا لأننا انقصنا المُتْغيِّر playerCt بمقدار الواحد، فإن واحدة منهما فقط تَقَع ضِمْن الجزء المُستخدَم فعليًا بالمصفوفة. يَحمِل أي عنصر بالمصفوفة في العموم قيمة ما، ولكن القيم من الموضع 0 وحتى playerCt - 1 هي فقط الصالحة أي يُمكِننا معالجتها. حاول أن تُفكِر بما سيَحدُث إذا كان اللاعب المطلوب حَذْفه هو اللاعب الأخير بالمصفوفة، وهل ترى أن الشيفرة بالأعلى ستَظِل صالحة؟ إذا كان ترتيب اللاعبين بالمصفوفة مُهِمًّا (ربما لأنه يُسمَح لهم باللعب وفقًا لترتيب تَخْزِينهم بالمصفوفة)، ينبغي عندها تحريك كل لاعب موجود من المَوْضِع k+1 وحتى آخر مَوْضِع مملوء فعليًا بالمصفوفة إلى المَوْضِع الذي يَسبِقُه أي سيَحلّ مثلًا اللاعب بالمَوْضِع k+1 محلّ اللاعب بالمَوْضِع k الذي أصبح خارج اللعبة للتو، وبدوره سيَملئ اللاعب بالمَوْضِع k+2 البقعة التي تركها اللاعب k+1 للتو، وهكذا. اُنظر الشيفرة التالية: for (int i = k+1; i < playerCt; i++) { playerList[i-1] = playerList[i]; } playerCt--; تُوضِح الصورة التالية طريقتي حَذْف عنصر -اللاعب "C" تحديدًا- من مصفوفة مملوءة جزئيًا (partially full array): يترك ذلك السؤال مفتوحًا عما سيَحدُث إذا كانت المصفوفة المملوءة جزئيًا (partially full) مملوءة بالكامل بينما تَرغَب بإضافة عناصر جديدة إليها؟ بالطبع، لا يُمكِننا أن نُغيِّر حجم المصفوفة (array size)، ولكن يُمكِننا أن نُنشِئ مصفوفة جديدة أكبر ثُمَّ نَنَسَخ البيانات الموجودة بالمصفوفة القديمة إلى المصفوفة الجديدة. ينقلنا ذلك إلى السؤال التالي: ما الذي يعنيه نَسخ مصفوفة بالأساس؟ لنَفْترِض أن A و B عبارة عن مُتْغيِّري مصفوفة (array variables) لهما نفس النوع الأساسي (base type). تُشير A بالفعل إلى مصفوفة، ونريد الآن جَعْل B تُشيِر إلى نُسخة من A. أول ما ينبغي أن تُدركه هو أن تَعْليمَة الإِسْناد (assignment statement) التالية: B = A; لا تُنشِئ نسخة من A. نظرًا لأن المصفوفات عبارة عن كائنات (objects)، يَحمِل أي مُتْغيِّر مصفوفة (array variable) -إن لم يَكُن فارغًا- مؤشِرًا (pointer) إلى مصفوفة. تَنَسَخ تَعْليمَة الإِسْناد (assignment) بالأعلى ذلك المُؤشر من A إلى B، وبالتالي سيُشيِر كُلًا من A و B إلى نفس ذات المصفوفة، فيُعدّ مثلًا كُلًا من A[0]‎ و B[0]‎ أسماءً مختلفة لنفس عناصر المصفوفة (array element). في المقابل، إذا كنا نريد جَعْل B يُشيِر إلى نسخة من A، ينبغي إذًا أن نُنشِئ مصفوفة جديدة كليًا ثُمَّ نَنَسخ العناصر من A إلى B. بِفَرض أن A و B من النوع double[]‎، يُمكِننا إذًا كتابة ما يَلي لإنشاء نسخة من A: double[] B; B = new double[A.length]; // Make a new array with the same length as A. for ( int i = 0; i < A.length; i++ ) { B[i] = A[i]; } لكي نَتَمكَّن من إضافة عناصر جديدة إلى مصفوفة مملوءة جزئيًا (partially full array) ممتلئة، ينبغي أن نُنشِئ مصفوفة جديدة أكبر، وعادةً ما تَكُون بحجم يُساوِي ضعف المصفوفة الحالية. لما كان مُتْغيِّر المصفوفة هو ما يَسمَح لنا بالوصول إلى البيانات التي أصبحت موجودة بالمصفوفة الجديدة، ينبغي إذًا أن نُعدِّل ذلك المُتْغيِّر لكي يُشير إلى المصفوفة الجديدة. يُمكِننا أن نُجرِي ذلك لحسن الحظ بتَعْليمَة إِسْناد (assignment statement) بسيطة. بِفَرْض اِستخدَام playerList و playerCt لتَخْزِين اللاعبين باللعبة -كالمثال بالأعلى-، تُوضِح الشيفرة التالية طريقة إضافة لاعب جديد newPlayer إلى اللعبة حتى لو كانت المصفوفة playerList ممتلئة: if ( playerCt == playerList.length ) { // The number of players is already equal to the size of the array. // The array is full. Make a new array that has more space. Player[] temp; // A variable to point to the new array. temp = new Player[ 2*playerList.length ]; // Twice as big as the old array. for ( int i = 0; i < playerList.length; i++ ) { temp[i] = playerList[i]; // Copy item from old array into new array. } playerList = temp; // playerList now points to the new, bigger array. } // At this point, we know that there is room in the array for newPlayer. playerList[playerCt] = newPlayer; playerCt++; الآن، لم يَعُد هناك أي مُتْغيِّر يُشير إلى المصفوفة القديمة، ولذلك يَتَولَّى كانس المُهملات (garbage collector) مُهِمَة تَحرِيرها. بعض التوابع القياسية للمصفوفات تحتاج الكثير من البرامج إلى عمليات مثل نَسْخ مصفوفة، ولهذا تُوفِّر الجافا العديد من التوابع (methods) القياسية لمعالجة المصفوفات. هذه التوابع مُعرَّفة كتوابع ساكنة (static methods) بصَنْف اسمه Arrays ضِمْن حزمة java.util. اُنظر المثال التالي: Arrays.copyOf( list, lengthOfCopy ) تُعيد الدالة copyOf مصفوفة جديدة طولها يُساوِي قيمة المعامل lengthOfCopy، وبحيث تحتوي على عناصر منسوخة من المُعامل list. إذا كان lengthOfCopy أكبر من list.length، ستَحمِل الخانات الإضافية بالمصفوفة الجديدة قيمها الافتراضية (أي صفر في حالة المصفوفات العددية، وnull في حالة مصفوفات الكائنات [array objects]، ..إلخ). في المقابل، إذا كان lengthOfCopy أقل من list.length، تُنسَخ العناصر بمقدار ما يَتَناسَب مع حجم المصفوفة الجديدة. على سبيل المثال، إذا كانت A مصفوفة، فإن الشيفرة التالية: B = Arrays.copyOf( A, A.length ); تَضبُط B لكي تُشيِر إلى نُسخة مُتطابِقة مع A، أما الشيفرة التالية: playerList = Arrays.copyOf( playerList, 2*playerList.length ); يُمكِنها أن تُستخدَم لمضاعفة حجم المساحة المتاحة بمصفوفة مملوءة جزئيًا (partially full array). علاوة على ذلك، قد نَستخدِم نفس ذلك التابع Arrays.copyOf لإنقاص حجم مصفوفة مملوءة جزئيًا، وهو ما يُساعِدنا على تَجنُّب وجود خانات إضافية كثيرة غَيْر مُستخدَمة. يُمكِننا أن نُطبِق ذلك أثناء حَذْف لاعب k من قائمة اللاعبين كالتالي: playerList[k] = playerList[playerCt-1]; playerCt--; if ( playerCt < playerList.length/4 ) { // More than 3/4 of the spaces are empty. Cut the array size in half. playerList = Arrays.copyOf( playerList, playerList.length/2 ); } يحتوي الصَنْف Arrays في الواقع على نُسخ مختلفة من التابع copyOf: نُسخة لكل نوع أساسي (primitive type)، بالإضافة إلى نُسخة آخرى للكائنات (objects). ملحوظة: عند نَسْخ مصفوفة كائنات (objects)، تُنسَخ فقط مؤشرات (pointers) الكائنات لا محتوياتها إلى المصفوفة الجديدة، ويُمثِل ذلك عمومًا القاعدة العامة لإِسْناد مؤشر (pointer) إلى آخر. إذا كان كل ما تُريده هو مُجرد نسخة بسيطة من مصفوفة بنفس حجمها الأصلي، فهناك طريقة سهلة للقيام بذلك. في الواقع، تَملُك أي مصفوفة تابع نُسخة (instance method) اسمه هو clone()‎. يُنشِئ ذلك التابع نُسخة من المصفوفة. يُمكِنك مثلًا أن تَستخدِم الشيفرة التالية لإنشاء نسخة من مصفوفة من النوع int: int[] B = A.clone(); يَحتوِي الصَنْف Array على توابع (methods) مفيدة آخرى سنَعرِض بعضًا منها هنا. بالمثل من التابع Arrays.copyOf، تَتَوفَّر نُسخ متعددة من كل تلك التوابع للأنواع المختلفة من المصفوفات: Arrays.fill( array, value )‎: تَملَئ مصفوفة كاملة بقيمة محددة. لابُدّ أن يَكُون value من نوع مُتوافق مع النوع الأساسي للمصفوفة array. إذا كان numlist عبارة عن مصفوفة من النوع double[]‎ مثلًا، ستَملَئ التَعْليمَة Arrays.fill(numlist,17)‎ جميع عناصر تلك المصفوفة بالقيمة 17. Arrays.fill( array, fromIndex, toIndex, value )‎: تَملَئ جزءًا من المصفوفة array من الفهرس fromIndex حتى الفهرس toIndex-1 بالقيمة value. لاحِظ أن الفهرس toIndex غَيْر مُضمَّن. Arrays.toString( array )‎: عبارة عن دالة (function) تُعيِد سِلسِلة نصية من النوع String مُكوَّنة من قيم المصفوفة array مفصولة بفاصلة (comma) ومُحاطَة بأقواس مربعة. تُحوَّل القيم إلى سَلاسِل نصية (strings) بنفس الطريقة التي تُحوَّل بها تلك القيم أثناء طباعتها. Arrays.sort( array )‎: تُعيد ترتيب جميع القيم الموجودة بمصفوفة ترتيبًا تصاعديًا. لاحِظ أنها لا تَعمَل مع جميع المصفوفات، فلابُدّ أن تكون قيم المصفوفة قابلة للموازنة لمعرفة أيهما أصغر. افتراضيًا، تَعمَل مع المصفوفات من النوع String والأنواع البسيطة (primitive types) باستثناء النوع boolean. سنناقش خوارزميات ترتيب المصفوفات (array sorting) بالقسم 7.4. Arrays.sort( array, fromIndex, toIndex )‎: تُرتِّب العناصر من array[fromIndex]‎ إلى array[toIndex-1]‎. Arrays.binarySearch( array, value )‎: تبحث تلك الدالة عن value داخل array، وتُعيد قيمة من النوع int عبارة عن فهرس (index) عنصر المصفوفة المُتضمِّن للقيمة المُمرَّرة إذا كانت موجودة. إذا لم تَكُن تلك القيمة موجودة بالمصفوفة، تُعيد تلك الدالة القيمة -1. ملحوظة: لابُدّ أن تَكُون المصفوفة مُرتَّبة ترتيبًا تصاعديًا. سنُناقِش خوارزمية البحث الثنائي (binary search) بالقسم 7.4. 7.2.3 برنامج RandomStrings صَمَّمنا -بالقسم الفرعي 6.2.4- برنامج واجهة مُستخدِم رسومية (GUI) يَعرِض نُسخًا مُتعددة من سِلسِلة نصية بمواضع عشوائية وبألوان وخطوط عشوائية، وعندما يَنقُر المُستخدِم على نافذة البرنامج، تَتَغيَّر كُلًا من مَواضِع وألوان وخطوط تلك السَلاسِل النصية (strings) إلى قيم عشوائية. لنَفْترِض الآن أننا نُريد أن نُنشِئ تحريكة (animation) تتحرك خلالها تلك السَلاسِل عبر النافذة. سنحتاج في تلك الحالة إلى تَخْزِين خاصيات كل سِلسِلة نصية منها لكي نَتَمكَّن من إعادة رسمها بكل إطار ضِمْن التحريكة. يُمكِنك الإطلاع على نسخة البرنامج الجديدة بالملف RandomStringsWithArray.java. سنَرسِم 25 سِلسِلة نصية. لكل سِلسِلة نصية منها، ينبغي أن نُخزِّن إحداثيات مَوْضِعها (x,y) ولون ونوع الخط المُستخدَم للرَسْم. لكي نَتَمكَّن من تَحرِيك السَلاسِل النصية، سنُخزِّن سرعة الحركة الخاصة بكل سِلسِلة نصية بهيئة عددين dx و dy. بكل إطار (frame)، ينبغي أن تزداد قيمة الإحداثي x لكل سِلسِلة نصية بمقدار dx الخاص بتلك السِلسِلة بينما ستزداد قيمة الإحداثي y بمقدار dy المناظر. سنحتاج إذًا إلى الست مصفوفات التالية لتَخْزِين بيانات البرنامج: double[] x = new double[25]; double[] y = new double[25]; double[] dx = new double[25]; double[] dy = new double[25]; Color[] color = new Color[25]; Font[] font = new Font[25]; ستُملَئ هذه المصفوفات بقيم عشوائية. يَرسَم التابع draw()‎ -المسئول عن رَسْم الحاوية (canvas)- السَلاسِل النصية. تُرسَم كل سِلسِلة نصية i بإحداثيات نقطة تُساوِي (x,y)‎ وبلون يُساوِي color‎ وبنوع خط يُساوِي font‎. لم نَستخدِم كُلًا من dx و dy بالتابع draw()‎، وإنما سنَستخدِمهما أثناء تَحدِيث البيانات أثناء رَسْم الإطار التالي. يُمكِننا إذًا كتابة تعريف التابع draw()‎ كالتالي: public void draw() { GraphicsContext g = canvas.getGraphicsContext2D(); g.setFill(Color.WHITE); // (Fill with white, erasing previous picture.) g.fillRect(0,0,canvas.getWidth(),canvas.getHeight()); for (int i = 0; i < 25; i++) { g.setFill( color[i] ); g.setFont( font[i] ); g.fillText( MESSAGE, x[i], y[i] ); g.setStroke(Color.BLACK); g.strokeText( MESSAGE, x[i], y[i] ); } } يَستخدِم هذا الأسلوب المصفوفات المتوازية (parallel arrays) حيث قُسِّمت بيانات رسالة واحدة بين عدة مصفوفات، ولكي تَرَى جميع البيانات المُتعلِّقة برسالة واحدة، ستحتاج إلى وَضْع المصفوفات إلى جانب بعضها كخطوط مُتوازية، وبحيث تَقَع العناصر برقم المَوضِع i ضِمْن تلك المصفوفات إلى جوار بعضها البعض. قد لا يُعدّ اِستخدَام المصفوفات المتوازية (parallel arrays) بهذا المثال البسيط خطأً فادحًا، ولكنها في العموم لا تَتَبِع الفلسفة كائنية التوجه (object-oriented) فيما يَتَعلَّق بتَخْزِين البيانات المُرتبطة معًا ضِمْن كائن واحد. إذا اتبعنا تلك القاعدة، فإننا لن نحتاج إلى تَخيُل العلاقة بين تلك البيانات؛ لأنها ستَكُون موجودة بمكان واحد بالفعل. سنُعرِّف الصَنْف StringData لهذا الغرض تحديدًا: private static class StringData { // Info needed to draw one string. double x,y; // location of the string; double dx,dy; // velocity of the string; Color color; // color of the string; Font font; // the font that is used to draw the string } سنَستخدِم مصفوفة من النوع StringData[]‎ لتَخْزِين بيانات النُسخ المختلفة من الرسالة النصية. تُصرِّح التَعْليمَة التالية عن مصفوفة stringData بهيئة مُتْغيِّر نسخة (instance variable): StringData[] stringData; ستَكُون قيمة المُتْغيِّر stringData فارغة بالبداية. ينبغي إذًا أن نُنِشئ مصفوفة ونملأها بالبيانات ثم نُسنِدها (assign) إليه. لاحِظ أن كل عنصر بتلك المصفوفة عبارة عن كائن (object) من النوع StringData، والذي ينبغي أن نُنشِئه قبل اِستخدَامه. يُنشِئ البرنامج الفرعي (subroutine) التالي المصفوفة ويملؤها ببيانات عشوائية: private void createStringData() { stringData = new StringData[25]; for (int i = 0; i < 25; i++) { stringData[i] = new StringData(); stringData[i].x = canvas.getWidth() * Math.random(); stringData[i].y = canvas.getHeight() * Math.random(); stringData[i].dx = 1 + 3*Math.random(); if (Math.random() < 0.5) // 50% chance that dx is negative stringData[i].dx = -stringData[i].dx; stringData[i].dy = 1 + 3*Math.random(); if (Math.random() < 0.5) // 50% chance that dy is negative stringData[i].dy = -stringData[i].dy; stringData[i].color = Color.hsb( 360*Math.random(), 1.0, 1.0 ); stringData[i].font = fonts[ (int)(5*Math.random()) ]; } } يُستدعَى التابع (method) السابق داخل start()‎ وكذلك عندما يَنقُر المستخدم على الزر لإنشاء بيانات عشوائية جديدة. يُمكِننا الآن أن نَستخدِم حَلْقة تَكْرار for لرَسْم السلاسل النصية كالتالي: for (int i = 0; i < 25; i++) { g.setFill( stringData[i].color ); g.setFont( stringData[i].font ); g.fillText( MESSAGE, stringData[i].x, stringData[i].y ); g.setStroke(Color.BLACK); g.strokeText( MESSAGE, stringData[i].x, stringData[i].y ); } أو قد نَستخدِم حَلْقة التَكْرار for-each لكي نَتَجنَّب التَعامُل مع فهارس المصفوفة (array indices) كالتالي: for ( StringData data : stringData ) { g.setFill( data.color ); g.setFont( data.font); g.fillText( MESSAGE, data.x, data.y ); g.setStroke( Color.BLACK ); g.strokeText( MESSAGE, data.x, data.y ); } أثناء كل تَكْرار (iteration)، سيَحمِل المُتْغيِّر المُتحكِّم بالحلقة data نسخة من إحدى قيم المصفوفة. تلك القيمة عبارة عن مَرجِع (reference) إلى كائن (object) من النوع StringData المُتْضمِّن لمُتْغيِّرات النُسخة color و font و x و y. ناقشنا التحريكات (animations) بالقسم الفرعي 6.3.5. يُمكِنك أيضًا الإطلاع على شيفرة البرنامج بالكامل بالملف RandomStringsWithArray.java لمعرفة طريقة تّنْفيِذ التحريكة (animation). ينبغي أن يختار البرنامج RandomStringsWithArray نوع الخط المُستخدَم لرَسْم الرسالة عشوائيًا من خمسة خطوط محتملة. بالنسخة الأصلية من البرنامج، صَرَّحنا عن خمسة مُتْغيِّرات أسمائها هي font1 و font2 و font3 و font4 و font5 من النوع Font لتمثيل تلك الخطوط ثُمَّ اِستخدَمنا تَعْليمَة switch لاختيار إحدى تلك الخطوط عشوائيًا كالتالي: Font randomFont; // One of the 5 fonts, chosen at random. int rand; // A random integer in the range 0 to 4. fontNum = (int)(Math.random() * 5); switch (fontNum) { case 0: randomFont = font1; break; case 1: randomFont = font2; break; case 2: randomFont = font3; break; case 3: randomFont = font4; break; case 4: randomFont = font5; break; } سنُخزِّن الخطوط الخمسة داخل مصفوفة fonts بالنسخة الجديدة من البرنامج. صَرَّحنا عنها بهيئة مُتْغيِّر نسخة (instance variable) من النوع Font[]‎ كالتالي: Font[] fonts; اِستخدمنا الباني (constructor) للإنشاء الفعليّ للمصفوفة بصيغة مُصنَّفة النوع (array literal) -اُنظر القسم الفرعي 7.1.3- كالتالي: fonts= new Font[] { Font.font("Times New Roman", FontWeight.BOLD, 20), Font.font("Arial", FontWeight.BOLD, FontPosture .ITALIC, 28), Font.font("Verdana", 32), Font.font(40), Font.font("Times New Roman", FontWeight.BOLD, FontPosture .ITALIC, 60) }; يُسهِل ذلك من عملية الاختيار العشوائي لنوع الخط المُستخدَم كالتالي: Font randomFont; // One of the 5 fonts, chosen at random. int fontIndex; // A random number in the range 0 to 4. fontIndex = (int)(Math.random() * 5); randomFont = fonts[ fontIndex ]; وبذلك نَكُون قد اِستخدَمنا أسطر قليلة من الشيفرة بدلًا من تَعْليمَة switch. يُمكِننا حتى أن نَضُم تلك الأسطر إلى سطر واحد كالتالي: Font randomFont = fonts[ (int)(Math.random() * 5) ]; يُعدّ ذلك تطبيقًا نمطيًا على المصفوفات (arrays). لاحِظ أن التَعْليمَة السابقة تَستخدِم خاصية الجَلْب العشوائي (random access) بمعنى اختيار فهرس مصفوفة (array index) بشكل عشوائي لجَلْب قيمة العنصر بذلك الفهرس مباشرةً. لنَفْحَص مثالًا آخر: عادةً ما تُخزَّن الأشهر بهيئة أعداد صحيحة: 1 و 2 و 3 .. وحتى 12. ستحتاج أحيانًا إلى تَحْوِيل تلك الأعداد إلى أسماء الأشهر المناظرة: يناير و فبراير و .. وحتى ديسمبر. يُمكِننا ببساطة أن نَستخدِم مصفوفة لإجراء ذلك التَحْوِيل. تُصرِّح (declare) التَعْليمَة التالية عن المصفوفة وتُهيِئها (initialize) كالتالي: static String[] monthName = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }; إذا كان mnth عبارة عن مُتْغيِّر يَحمِل عددًا صحيحًا يتراوح بين 1 و 12، فإن monthName[mnth-1]‎ يُمثِل اسم الشهر المناظر. ينبغي أن نُضيِف "-1" لأن الأشهر مُرقَّمة بدءًا من 1 بينما عناصر المصفوفة (array elements) مُرقَّمة بدءًا من صفر. المصفوفات الديناميكية (Dynamic Arrays) لقد ناقشنا الكيفية التي يُمكِننا بها اِستخدَام المصفوفات المملوءة جزئيًا (partially full array) لتَخْزِين قائمة من اللاعبين داخل لعبة، بحيث تَكبُر تلك القائمة أو تَتقلَّص أثناء تَشْغِيل اللعبة. يُطلَق الاسم "ديناميكي (dynamic)" على أي قائمة (list) يُمكِن أن يَتَغيَّر حجمها أثناء تّنْفِيذ البرنامج. تُعدّ القوائم الديناميكية شائعة الاستخدام، لذلك ربما من الأفضل كتابة صَنْف (class) يُمثِل ذلك المفهوم، وهو ما سيُمكِّننا من تَجنُّب إعادة كتابة نفس ذات الشيفرة بكل مرة نُريد فيها اِستخدَام هيكل بياني (data structure) مُشابِه. سنُصمِّم إذًا شيئًا مشابهًا للمصفوفة باستثناء أن يَكُون حجمها (size) قابلًا للتَغيِير. فَكِر بالعمليات التي نحتاج إلى إِجرائها على مصفوفة ديناميكية (dynamic array)، مثلًا: إضافة عنصر إلى نهاية المصفوفة حَذْف عنصر بمَوِضْع معين ضِمْن المصفوفة جَلْب قيمة إحدى عناصر المصفوفة ضَبْط قيمة إحدى عناصر المصفوفة جَلْب عدد العناصر الموجودة حاليًا بالمصفوفة عندما نُصمِّم ذلك الصَنْف، ستُصبِح تلك العمليات توابع نسخة (instance methods) داخل الصَنْف. سنُطبِق أيضًا نمط المصفوفة المملوءة جزئيًا (partially full array) لتَخْزِين العناصر بالمصفوفة الديناميكية (dynamic) أي ستُخزَّن العناصر بالنهاية داخل مصفوفة عادية. علاوة على ذلك، لابُدّ أن نُقرِّر ما ينبغي أن يَحدُث عند محاولة جَلْب عنصر مصفوفة غَيْر موجود، فقد نُبلِّغ مثلًا عن اِعتراض من النوع ArrayIndexOutOfBoundsException. بِفْرَض كَوْن عناصر المصفوفة من النوع int، يُمكِننا كتابة الشيفرة التالية: import java.util.Arrays; /** * Represents a list of int values that can grow and shrink. */ public class DynamicArrayOfInt { private int[] items = new int[8]; // partially full array holding the ints private int itemCt; /** * Return the item at a given index in the array. * Throws ArrayIndexOutOfBoundsException if the index is not valid. */ public int get( int index ) { if ( index < 0 || index >= itemCt ) throw new ArrayIndexOutOfBoundsException("Illegal index, " + index); return items[index]; } /** * Set the value of the array element at a given index. * Throws ArrayIndexOutOfBoundsException if the index is not valid. */ public void set( int index, int item ) { if ( index < 0 || index >= itemCt ) throw new ArrayIndexOutOfBoundsException("Illegal index, " + index); items[index] = item; } /** * Returns the number of items currently in the array. */ public int size() { return itemCt; } /** * Adds a new item to the end of the array. The size increases by one. */ public void add(int item) { if (itemCt == items.length) items = Arrays.copyOf( items, 2*items.length ); items[itemCt] = item; itemCt++; } /** * Removes the item at a given index in the array. The size of the array * decreases by one. Items following the removed item are moved up one * space in the array. * Throws ArrayIndexOutOfBoundsException if the index is not valid. */ public void remove(int index) { if ( index < 0 || index >= itemCt ) throw new ArrayIndexOutOfBoundsException("Illegal index, " + index); for (int j = index+1; j < itemCt; j++) items[j-1] = items[j]; itemCt--; } } // end class DynamicArrayOfInt ينبغي أن تَكُون الشيفرة بالأعلى واضحة. ربما قد تَتَساءل مع ذلك عن سبب اختيار العدد 8 كحجم مبدئي للمصفوفة. في الحقيقة، أنه مجرد رقم عشوائي أي يُمكِنك أن تختار أي عدد صحيح آخر، ولن يُؤثِر ذلك على الصَنْف (class). في العموم، لا تبدأ بمصفوفة ضخمة جدًا، فهي بالفعل مُصمَّمة لتُكيف حجمها مع عدد العناصر المطلوب. بالمثال ReverseInputNumbers.java، اِستخدَمنا مصفوفة مملوءة جزئيًا (partially full array) من النوع int لطباعة قائمة من الأعداد المُدْخَلة من قِبَل المُستخدِم بترتيب معاكس. اِستخدَمنا تحديدًا مصفوفة عادية طولها يُساوِي 100 لحَمْل الأعداد. في الواقع، قد يَكُون حجم المصفوفة كبيرًا جدًا أو صغيرًا جدًا مما قد يَتَسبَّب بحُدوث اِعترَاض (exception). نستطيع الآن إعادة كتابة البرنامج باستخدام الصَنْف DynamicArrayOfInt، والذي سيَتَكيَف مع أي عدد معقول من المُدْخَلات. يُمكِنك الإطلاع على شيفرته بالملف ReverseWithDynamicArray.java. على الرغم من أنه برنامج بسيط جدًا، لكن بإمكانك تطبيق نفس المبدأ بأي تطبيق آخر لا يُمكِنك تَوقُّع مقدار البيانات التي قد يحتاجها مقدمًا. تستطيع هياكل البيانات الديناميكية (dynamic data structure) عمومًا أن تَتَكيَف مع أي مقدار من البيانات، ولكن بالطبع بما يتناسب مع مساحة الذاكرة (memory) المُتاحة للبرنامج. يُعدّ الصَنف بالأعلى مثالًا جيدًا نوعًا ما على المصفوفات الديناميكية، ولكنه يُعانِي من مشكلة صغيرة. لنَفْترِض مثلًا أننا نريد أن نُنشِئ مصفوفة ديناميكية من النوع String. نظرًا لأن الصَنْف DynamicArrayOfInt مُصمَّم للتَعامُل مع النوع int فقط، لا يُمكِننا بطبيعة الحال أن نَستخدِم كائنًا (object) منه لحَمْل سلاسل نصية (strings). يبدو أننا سنضطّر إذًا إلى كتابة صَنْف جديد DynamicArrayOfString. بالمثل، إذا أردنا أن نُنشِئ مصفوفة ديناميكية لتَخْزِين لاعبين من النوع Player، سنضطّر إلى كتابة صَنْف جديد DynamicArrayOfPlayer، وهكذا. يَعنِي ذلك ضرورة كتابة صَنْف جديد لكل نوع من البيانات، وهو ما لا يُمكِن أن يَكُون أمرًا منطقيًا. في الواقع، توفِّر الجافا الصَنْف القياسي ArrayList كحلّ لتلك المشكلة حيث يُمثِل مصفوفة ديناميكية (dynamic arrays) يُمكِنها التَعامُل مع أي نوع من البيانات. ترجمة -بتصرّف- للقسم Section 2: Array Processing من فصل Chapter 7: Arrays and ArrayLists من كتاب Introduction to Programming Using Java.

ناقشنا أساسيات المصفوفات (arrays) بالفصول السابقة، ولكن ما يزال هنالك بعض التفاصيل الأخرى الخاصة بقواعد الصيغة (syntax) التي نحتاج إلى تناولها كما أن هنالك الكثير لذِكره بشأن اِستخدَامات المصفوفات في العموم. سنَفْحَص خلال هذا القسم بعضًا من تلك التفاصيل. المصفوفة عبارة عن متتالية من العناصر المُرقَّمة بحيث يُمثِل كل عنصر مُتْغيِّرًا منفصلًا. لابُدّ أن تَكُون جميع العناصر ضِمْن مصفوفة معينة من نفس النوع. يُطلق على هذا النوع اسم نوع المصفوفة الأساسي (base type) كما أن المصفوفة ككل لها نوع أيضًا. فمثلًا، إذا كان النوع الأساسي لمصفوفة هو btype، فإن المصفوفة ككل تَكُون من النوع btype[]‎. يَملُك كل عنصر فهرسًا (index) يُمثِل مَوضِعه العددي بمتتالية العناصر. إذا كان لدينا مثلًا مصفوفة A، فإننا نَستخدِم A‎ للإشارة إلى عنصر المصفوفة الموجود برقم المَوضِع i. يُطلَق على عدد العناصر الموجودة ضِمْن مصفوفة اسم طول المصفوفة (length)، ويُستخدَم A.length لمَعرِفة طول مصفوفة A. لاحِظ أنه من غَيْر الممكن تَغيِير طول مصفوفة معينة بَعْد انشائها. يُشار إلى عناصر مصفوفة A باستخدام A[0]‎ و A[1]‎ و .. حتى A[A.length-1]‎، وتُؤدِي أي محاولة للإشارة إلى عنصر مصفوفة برقم فهرس خارج النطاق المسموح به أي خارج نطاق يتراوح بين 0 و A.length-1 إلى حُدوث اِعتراض من النوع ArrayIndexOutOfBoundsException. المصفوفات بلغة الجافا عبارة عن كائنات (objects) أي يستطيع أي مُتْغيِّر مصفوفة (array variable) أن يُشير إلى مصفوفة معينة لا أن يَحتوِي قيمة المصفوفة نفسها. قد تَكُون قيمة المُتْغيِّر فارغة (null)، وفي تلك الحالة، لا يُشير المُتْغيِّر إلى أي مصفوفة، وستَتَسبَّب إذًا أي محاولة للإشارة إلى عنصر ضِمْن تلك المصفوفة مثل A‎ بحدوث اعتراض من النوع NullPointerException. تُنشَئ المصفوفات باِستخدَام صيغة خاصة من العامل new كالتالي: int[] A = new int[10]; تُنشِئ التَعْليمَة بالأعلى مصفوفة جديدة نوعها الأساسي (base type) هو int وطولها يُساوِي 10 ثم تَضبُط المُتْغيِّر A لكي يشير إلى تلك المصفوفة الجديدة المُنشئة للتو. حلقات تكرار For-each تعالج المصفوفات عادةً باستخدام حلقات التكرار (loop). تسهل حلقات التكرار من معالجة كل عنصر بالمصفوفة. على سبيل المثال، إذا كان namelist مصفوفة من النوع String، يمكننا طباعة قيم جميع عناصر تلك المصفوفة كالتالي: for (int i = 0; i < namelist.length; i++) { System.out.println( namelist[i] ); } هذا النوع من المعالجة شائع جدًا لدرجة وجود صياغة مختلفة من حلقات التكرار تسهل أكثر من ذلك. يطلق على تلك الصياغة اسم for-each. يستخدم المثال التالي حلقة التكرار for-each لطباعة جميع قيم عناصر مصفوفة من النوع String: for ( String name : namelist ) { System.out.println( name ); } يُقصَد من التَعْليمَة for (String name : namelist)‎ "نَفِّذ ما يلي لكل عنصر name من النوع String ضِمْن المصفوفة namelist". يُسنَد إلى المُتْغيِّر name خلال كل تَكْرار (iteration) إحدى قيم عناصر المصفوفة namelist ثُم يُنفَّذ مَتْن الحلقة. يُمثِل مُتْغيِّر التَحكُّم بالحلقة name قيمة عنصر المصفوفة وليس فهرسه (index) أي أننا لا نَملُك فهرس (index) العنصر داخل الحلقة. تجنبك حَلْقة التَكْرار for-each التعقيد المُرتبط بفهارس عناصر المصفوفة. إلى جانب ذلك، يُمكِنك في العموم اِستخدَامها لمعالجة مجموعة من القيم ضِمْن شتى هياكل البيانات (data structure) كما سنرى بالفصل 10 حيث تَسمَح بمعالجة تلك القيم بغض النظر عن هيكل البيانات المُستخدَم. تُنفِّذ حلقة التكرار for-each نفس العملية على كل قيمة مُخزَّنة بالمصفوفة. على سبيل المثال، إذا كان itemArray مصفوفة من النوع BaseType[]‎، يُمكنك كتابة حَلْقة التَكْرار for-each بالصياغة التالية: for ( BaseType item : itemArray ) { . . // عالج العنصر . } الأقواس بالأعلى اختيارية في حالة وجود تَعْليمَة واحدة فقط ضِمْن المَتْن. نظرًا لأن النوع الأساسي للمصفوفة (base type) هو BaseType، صَرَّحنا (declare) عن المُتْغيَّر المُتحكِّم بالحلقة (loop control variable)‏ item ليَكُون من النوع BaseType. لاِحظ أن التَّصريح (declare) عن المُتْغيِّر المُتحكِّم بحَلْقات التَكْرار for-each لابُدّ أن يَقَع داخل حَلْقة التَكْرار، فلا يُمكِنك اِستخدَام مُتْغيِّر مُصرَّح عنه مُسبَقًا خارج الحلقة (loop). عند تّنفيذ الحلقة، تُسنَد كل قيمة بالمصفوفة إلى المُتْغيِّر item ثم يُنْفَّذ مَتْن الحلقة (loop body) لتلك القيمة. يُمكِنك في الواقع استخدام for لكتابة نفس حَلْقة التَكْرار بالأعلى كما يلي: for ( int index = 0; index < itemArray.length; index++ ) { BaseType item; item = itemArray[index]; // اجلب قيمة أحد عناصر المصفوفة . . // process the item . } على سبيل المثال، إذا كان المُتْغيِّر A عبارة عن مصفوفة من النوع int[]‎، يُمكِننا طباعة جميع قيم A باستخدام for-each كالتالي: for ( int item : A ) System.out.println( item ); ويُمكِننا حساب مجموع قيم الأعداد الصحيحة الموجبة داخل المصفوفة A كالتالي: int sum = 0; // حاصل مجموع الأعداد الموجبة ضمن المصفوفة for ( int item : A ) { if (item > 0) sum = sum + item; } قد لا يَكون اِستخدَام حَلْقة التَكْرار for-each ملائمًا ببعض الأحيان. على سبيل المثال، لا توجد طريقة بسيطة لاستخدامها لمعالجة العناصر الموجودة بجزء معين من مصفوفة أو لمعالجة عناصر مصفوفة بترتيب معكوس. في المقابل، هي في العموم أكثر ملائمة في حالة أردت معالجة جميع قيم عناصر مصفوفة معينة بنفس ترتيب وجودها داخل تلك المصفوفة؛ لأنها تُجنِّبك اِستخدَام الفهارس (indices). تُعالِج حَلْقة التَكْرار for-each "القيم (values)" الموجودة بالمصفوفة وليس "العناصر (elements)" أي أنها لا تُعالِج مواضع الذاكرة الفعلية لتلك القيم. على سبيل المثال، تُحاوِل الشيفرة التالية مَلْئ مصفوفة من الأعداد الصحيحة بالقيمة 17 بطريقة خاطئة: int[] intList = new int[10]; for ( int item : intList ) { // غير صحيح item = 17; } تُسنِد التَعْليمَة item = 17 القيمة 17 إلى المُتْغيِّر المُتحكِّم بالحَلْقة item، ولكن هذا ليس له أي علاقة بالمصفوفة. عند تّنفِيد مَتْن الحَلْقة (body loop)، تُنسَخ إحدى قيم عناصر المصفوفة إلى المُتْغيِّر item أي أن ما تحاول التَعْليمَة item = 17 تَعْدِيله هو تلك القيمة المَنسُوخَة، وبالتالي ليس لها أي تأثير على عنصر المصفوفة المَنسُوخ ذاته ولا تَتَغيَّر قيمته. تُكافِيء حَلْقة التَكْرار السابقة ما يلي: int[] intList = new int[10]; for ( int i = 0; i < intList.length; i++ ) { int item = intList[i]; item = 17; } والتي بوضوح لا تُغيِّر قيمة أي عنصر داخل المصفوفة. التوابع متغيرة الرتبية (Variable Arity Methods) قبل الإصدار الخامس من الجافا، كانت جميع التوابع (method) ثابتة الرتبية (fixed arity) -الرتبية عمومًا هي عدد المُعاملات المُمرَّرة لتابع ضِمْن تَعْليمَة الاستدعاء-. في حالة التوابع ثابتة الرتبية (fixed arity methods)، لابُدّ من تمرير نفس عدد المعاملات (parameters) بكل تعليمة استدعاء (call) لتابع ثابت الرتبية، كما لابُدّ أن يَكُون ذلك العدد هو نفسه عدد المُعاملات الصُوريَّة (formal parameters) ضِمْن تعريف ذلك التابع (method definition). منذ الإصدار الخامس من الجافا، تَتَوفَّر توابع مُتْغيِّرة الرتبية (variable arity methods)، والتي يُمكِن أن يُمرَّر إليها عدد مختلف من المعاملات (parameters). على سبيل المثال، يُعدّ التابع System.out.printf -ناقشناه بالقسم الفرعي 2.4.1- مُتْغيِّر الرتبية (variable arity). بالإضافة إلى مُعامله الأول الذي لابُدّ أن يَكُون عبارة عن سِلسِلة نصية من النوع String، فإنه يَستقبِل أي عدد ممكن من المعاملات الإضافية ومن أي نوع. لا تختلف طريقة استدعاء تابع مُتْغيِّر الرتبية (variable arity method) عن طريقة استدعاء أي تابع آخر، ولكن تَتَطلَّب كتابته بعض قواعد الصيغة الجديدة (syntax). على سبيل المثال، إذا أردنا كتابة تابع (method) يَحسِب قيمة متوسط أي عدد من القيم من النوع double، يُمكِننا أن نُعرِّفه كالتالي: public static double average( double... numbers ) { لاحظ اِستخدَام الترميز ... بَعْد اسم النوع double ضِمْن التعريف بالأعلى، وهو في الواقع ما يَجعَل ذلك التابع مُتْغيِّر الرتبية (variable arity) حيث يُشير ذلك الترميز إلى إمكانية تمرير أي عدد من القيم من النوع double بتعليمة استدعاء البرنامج الفرعي (subroutine) أي يُمكِنك اِستدعائه باِستخدَام average(1,4,9,16)‎ أو average(3.14,2.17)‎ أو average(0.375)‎ أو average()‎. يُمكِنك أيضًا أن تُمرِّر قيم من النوع int كمُعاملات فعليّة (actual parameters) للتابع حيث تُحوَّل كالعادة تلقائيًا إلى أعداد حقيقية (real). عند استدعاء تابع مُتْغيِّر الرتبية (variable arity method)، تُوضَع قيم المُعاملات الفعليّة المناظرة لمعامل مُتْغيِّر الرتبية (variable arity) بمصفوفة ثم تُمرَّر تلك المصفوفة إلى التابع أي يبدو مُعامل مُتْغيِّر الرتبية من النوع T مثلًا بهيئة مصفوفة من النوع T[]‎ داخل مَتْن التابع، ويُحدِّد عدد المُعاملات الفعليّة (actual parameters) المُمرَّرة أثناء الاستدعاء طول تلك المصفوفة. بالنسبة للتابع average()‎، فإن مَتْنه (body) سيَرى مصفوفة اسمها numbers من النوع double[]‎، ويُحدِّد numbers.length عدد المعاملات الفعليّة بتَعْليمَة الاستدعاء، وتُمثِل numbers[0]‎ و numbers[1]‎ ..إلخ قيم تلك المعاملات المُمرَّرة. يُمكِننا تعريف (define) ذلك التابع كالتالي: public static double average( double... numbers ) { // ‫داخل التابع، المتغير numbers من النوع double[] double sum; // مجموع قيم المعاملات الفعلية double average; // متوسط قيم المعاملات الفعلية sum = 0; for (int i = 0; i < numbers.length; i++) { // أزد أجد المعاملات الفعلية إلى حاصل المجموع sum = sum + numbers[i]; } average = sum / numbers.length; return average; } بالمناسبة، من الممكن تمرير مصفوفة واحدة إلى تابع متغير الرتبية (variable arity mehtod) بدلًا من قائمة من القيم المفردة. على سبيل المثال، لنفترض أن salesData عبارة عن متغير من النوع double[]‎، فإنه من الممكن استخدام الاستدعاء average(salesData)‎ لحساب قيمة متوسط جميع الأعداد بالمصفوفة. قد تتضمن قائمة المعاملات الصورية (formal parameter list) بتعريف تابع متغير الرتبية (variable-arity method) أكثر من معامل واحد، ولكن الترميز ... يمكن أن يطبق على المعامل الصوري الأخير فقط. كمثال، إذا أردنا كتابة تابع (method) لرسم مضلع يُحدَّد موضعه عبر أي عدد من النقاط. تكون تلك النقاط من النوع Point، وبحيث يحتوي أي كائن (object) من ذلك النوع على مُتْغيِّري نُسخة (instance variables) هما x و y من النوع double يُحدِّدان موضع النقطة. سيَستقبِل التابع أولًا مُعاملًا عاديًا هو كائن السياق الرسومي (graphics context) المُستخدَم لرَسْم المضلع بالإضافة إلى مُعامل مُتْغيِّر الرتبية (variable arity parameter). يبدو ذلك المُعامل بهيئة مصفوفة من النوع Point ضِمن مَتْن التابع. يُمكننا كتابة تعريف التابع كالتالي: public static void drawPolygon(GraphicsContext g, Point... points) { // نحتاج إلى نقطتين على الأقل لرسم أي شيء if (points.length > 1) { for (int i = 0; i < points.length - 1; i++) { // ‫ارسم خطا من النقطة i إلى النقطة i+1 g.strokeLine( points[i].x, points[i].y, points[i+1].x, points[i+1].y ); } // ارسم خطًا عائدًا إلى نقطة البداية g.strokeLine( points[points.length-1].x, points[points.length-1].y, points[0].x, points[0].y ); } } لابُدّ أن تحتوي تَعْليمَة استدعاء ذلك البرنامج الفرعي (subroutine call) على مُعامل فعلي واحد من النوع GraphicsContext متبوعًا بأي عدد من المعاملات الفعلية من النوع Point. كمثال أخير، يَضُمّ التابع (method) التالي قائمة من السَلاسِل النصية (strings) معًا ليُكوِّن سِلسِلة نصية واحدة طويلة. تَستخدِم الشيفرة التالية حَلْقة تَكْرار for-each لمعالجة المصفوفة: public static String concat( String... values ) { // ‫استخدم الصنف StringBuilder لضم أكثر كفاءة StringBuilder buffer; buffer = new StringBuilder(); // ابدأ بكائن فارغ for ( String str : values ) { // استخدم حلقة تكرار لمعالجة القيم buffer.append(str); // أضف سلسلة نصية إلى المخزن المؤقت } return buffer.toString(); // أعد محتويات المخزن المؤقت } يُعيد الاستدعاء concat("Hello", "World")‎ مثلًا السِلسِلة النصية "HelloWorld" بينما يُعيد الاستدعاء concat()‎ سِلسِلة نصية فارغة. لمّا كان مُمكِنًا تمرير مصفوفة كمعامل فعلي (actual parameter) لتابع مُتْغيِّر الرتبية (variable arity method)، فبإمكاننا أيضًا استدعاء concat(lines)‎ حيث lines عبارة عن مصفوفة من النوع String[]‎. سيَضُمّ (concatenate) التابع جميع العناصر الموجودة داخل المصفوفة إلى سِلسِلة نصية (string) واحدة. مصفوفات مجردة مصنفة النوع (Array Literals) لقد رأينا أنه بإمكاننا أن نُهيِئ (initialize) مُتْغيِّر مصفوفة (array variable) بقائمة من القيم أثناء التّصرِيح (declare) عنه كالتالي: int[] squares = { 1, 4, 9, 16, 25, 36, 49 }; تُهيِئ التَعليمَة بالأعلى المُتْغيِّر squares لكي يُشيِر إلى مصفوفة جديدة تحتوي على قائمة من 7 قيم. يُمكِنك اِستخدَام مُهيِئ القائمة (list initializer) بالصياغة السابقة مع تَعْليمَات التّصرِيح (declaration statement) فقط لكي تُسنِد قيمة مبدئية لمُتْغيِّر المصفوفة (array variable) المُصرَّح عنه للتو. في المقابل، لا يُمكنِك اِستخدَامه مع تَعْليمَة إِسْناد (assignment statement) بغرض إِسْناد قيمة جديدة إلى مُتْغيِّر مَوجود مُسْبَقًا. تَتَوفَّر طريقة آخرى لإنشاء مصفوفات جديدة، ويُمكِنك حتى اِستخدَامها بمواضع آخرى غير التّصرِيح. تَستخدِم تلك الطريقة صياغة مختلفة من العامل new لإنشاء كائن مصفوفة جديد ومن ثَمَّ مَلْئه. يُمكِننا مثلًا أن نُسنِد قيمة جديدة إلى مُتْغيِّر مصفوفة cubes من النوع int[]‎ كالتالي: cubes = new int[] { 1, 8, 27, 64, 125, 216, 343 }; لاحِظ أن التَعْليمَة بالأعلى هي تَعْليمَة إِسْناد (assignment) وليست تصريح (declaration) أي أنه من غَيْر المُمكن اِستخدَام مُهيِئ المصفوفة -بدون new int[]‎- هنا. تُكتَب تلك الصياغة في العموم على النحو التالي: new base-type [ ] { list-of-values } في الواقع، يُعدّ ما سبق تعبيرًا (expression) قيمته عبارة عن مَرجِع (reference) إلى كائن مصفوفة (array object) جديد، ويُمكِنك اِستخدَامه لتمثيل قيمة من ذلك النوع، لهذا يُمكِن عدّه ضِمْن هذا السياق مُصفوفة مُصنَّفة النوع (array literal). يَعنِي ذلك أنه من المُمكن اِستخدَامه أينما أمكن اِستخدَام كائن (object) من النوع base-type[]‎، فيُمكِنك مثلًا أن تُمرِّر المصفوفة الجديدة المنشئة للتو كمُعامل فعلي (actual parameter) لبرنامج فرعي (subroutine). تَستخدِم الشيفرة التالية مصفوفة من السَلاسِل النصية (strings) لإنشاء قائمة (menu): /** * @param menuName the name for the Menu that is to be created. * @param itemNames an array holding the text that appears in each * MenuItem. If a null value appears in the array, the corresponding * item in the menu will be a separator rather than a MenuItem. * @return the menu that has been created and filled with items. */ public static Menu createMenu( String menuName, String[] itemNames ) { Menu menu = new Menu(menuName); for ( String itemName : itemNames ) { if ( itemName == null ) { menu.getItems().add( new SeparatorMenuItem() ); } else { MenuItem item = new MenuItem(itemName); menu.getItems().add(item); } } return menu; } يَستقبِل التابع createMenu معاملًا ثانيًا عبارة عن مصفوفة من السَلاسِل النصية. يُمكننا أن نُنشِئ المصفوفة المُمرَّرة كمعامل فعلي (actual parameter) إلى ذلك التابع بمحلها باِستخدَام العامل new. على سبيل المثال، تُنشِئ التَعْليمَة التالية قائمة File كاملة: Menu fileMenu = createMenu( "File", new String[] { "New", "Open", "Close", null, "Quit" } ); ينبغي أن يُقنعِك المثال السابق بأهمية القدرة على إنشاء مصفوفة واِستخدَامها بنفس المكان، فلربما هي بنفس أهمية القدرة على اِستخدَام الأصناف الداخلية (inner classes) مجهولة الاسم (anonymous). ربما كان من الافضل أيضًا كتابة التابع createMenu()‎ بهيئة تابع مُتْغيِّر الرتبية (variable arity method). تستطيع أيضًا أن تَستخدِم new BaseType[] { ... }‎ بدلًا من مُهيِئ المصفوفة (array initializer) أثناء التّصرِيح عن مُتْغيِّر مصفوفة (array variable). فمثلًا، بدلًا من كتابة: int[] primes = { 2, 3, 5, 7, 11, 13, 17, 19 }; يُمكِنك أن تَستخدِم ما يلي: int[] primes = new int[] { 2, 3, 5, 7, 11, 17, 19 }; يُفضِّل الكاتب في الواقع اِستخدَام الصياغة الثانية بدلًا من اِستخدَام صياغة خاصة تَعمَل فقط مع تَعْليمَات التّصرِيح (declaration statement). ملحوظة أخيرة: يُمكِنك كتابة التصريح عن مصفوفة مثل: int[] list; على النحو التالي أيضًا: int list[]; وهي صياغة مُستخدَمة بلغتي البرمجة C و C++‎، ولكنها مع ذلك غَيْر مُتِّسقَة مع لغة Java، ومن الأفضل تَجنُبها. فالغرض بالنهاية هو التّصرِيح عن مُتْغيِّر من نوع معين، وهذا النوع هو int[]‎، لذلك من الأفضل اتباع لمثل تلك التصريحات. ترجمة -بتصرّف- للقسم Section 1: Array Details من فصل Chapter 7: Arrays and ArrayLists من كتاب Introduction to Programming Using Java.

لقد ناقشنا حتى الآن الكثير من الجوانب الأساسية المُستخدَمة ببرمجة واجهات المُستخدِم الرسومية (GUI)، وتَعلَّمنا ما يَكفِي لكتابة بعض البرامج الشيقة، ولهذا سنَفْحَص مثالين كاملين يُطبقان ما درسناه حتى الآن عن برمجة الواجهات الرُسومية (GUI) إلى جانب ما درسناه عن البرمجة في العموم بالفصول السابقة. ما يزال هنالك الكثير من الأمور الآخر لتَعْلُّمها، ولهذا سنعود للحديث عن نفس الموضوع بالفصل ١٣. لعبة ورق بسيطة برنامجنا الأول عبارة عن نُسخة من برنامج سطر الأوامر HighLow.java من القسم الفرعي ٥.٤.٣، ولكنها ستَكُون مُدعَّمة بواجهة مُستخدِم رُسومية (GUI). بنُسخة البرنامج الجديدة HighLowGUI.java، ينبغي أن تَنظُر إلى ورقة لعب ثم تَتَوقَّع ما إذا كانت قيمة ورقة اللعب التالية ستَكُون أكبر أو أقل من قيمة ورقة اللعب الحالية. إذا كان تَوقُّعك خاطئًا، فستَخسَر المباراة أما إذا كان صحيحًا لثلاث مرات متتالية، فستَفوز بالمباراة. بَعْد انتهاء أية مباراة، يُمِكنك النَقْر على "New Game" لبدء مباراة جديدة. تُوضِح الصورة التالية ما سيَبدُو عليه البرنامج خلال المباراة: شيفرة البرنامج بالكامل مُتاحَة بالملف HighLowGUI.java. حاول تَصْرِيفها وتَشْغِيلها. ملحوظة: يَتَطلَّب البرنامج كُلًا من الملفات Card.java و Deck.java و Hand.java من القسم ٥.٤ حيث تُعرِّف أصنافًا (classes) مُستخدَمة ضِمْن البرنامج كما أنه يَتَطلَّب ملف صورة ورق اللعب cards.png الذي اِستخدَمناه بالبرنامج RandomCards.java بالقسم الفرعي ٦.٢.٤. ربما من السهل تَخْمِين التخطيط (layout) المُستخدَم بالبرنامج: يَستخدِم HighLowGUI حاوية من النوع BorderPane كمُكوِّن جذري (root) لمبيان المشهد (scene graph). تَتَضمَّن تلك الحاوية حاوية آخرى من النوع Canvas مرسُوم عليها ورق لعب ورسالة وتَقَع بمنتصف الحاوية الخارجية. يَتَضمَّن المَوْضِع السفلي من الحاوية الخارجية حاوية آخرى من النوع HBox تَحتوِي بدورها على ثلاثة أزرار ضُبِطَت بحيث يَكُون لها جميعًا نفس قيمة العَرْض بغَرْض مَلْئ الحاوية بالكامل كما أَوضَحنا بالقسم الفرعي ٦.٥.٣. يُنفِّذ التابع start()‎ التالي ما سبق: public void start(Stage stage) { cardImages = new Image("cards.png"); // حمل صورة ورق اللعب board = new Canvas(4*99 + 20, 123 + 80); // مسافة أربعة أوراق Button higher = new Button("Higher"); // أنشئ المفاتيح higher.setOnAction( e -> doHigher() ); // وجهز معالجات الأحداث Button lower = new Button("Lower"); lower.setOnAction( e -> doLower() ); Button newGame = new Button("New Game"); newGame.setOnAction( e -> doNewGame() ); HBox buttonBar = new HBox( higher, lower, newGame ); // اضبط كل زر لكي يحصل على ثلث العرض المتاح higher.setPrefWidth(board.getWidth()/3.0); lower.setPrefWidth(board.getWidth()/3.0); newGame.setPrefWidth(board.getWidth()/3.0); BorderPane root = new BorderPane(); // أنشئ المكون الجذري لمبيان المشهد root.setCenter(board); root.setBottom(buttonBar); doNewGame(); // جهز المباراة الأولى Scene scene = new Scene(root); // Finish setting up the scene and stage. stage.setScene(scene); stage.setTitle("High/Low Game"); stage.setResizable(false); stage.show(); } // end start() تَستدعِي مُعالِجات الأحداث (event handlers) بالأعلى توابعًا مُعرَّفة بمكان آخر من البرنامج مثل التابع doNewGame()‎. تُعدّ برمجة تلك التوابع (methods) تمرينًا جيدًا على التفكير وفقًا لما يُعرَف باسم "آلة الحالة (state machine)": ينبغي أن تُفكِر بالحالات (states) التي يُمكِن للمباراة أن تَقَع ضِمْنها، وبالكيفية التي قد تَتَغيَّر بها من حالة لآخرى، وكذلك بالكيفية التي ستَعتمِد بها مُعالجات الأحداث (events) على تلك الحالات. لاحِظ أن الأسلوب الذي اتِبعَناه بالنسخة الأصلية النصية من البرنامج بالقسم الفرعي ٥.٤.٣ غَيْر مُناسِب هنا حيث ستُربكَك محاولة التفكير بالمباراة تفصيليًا خطوة بخطوة من البداية وحتى النهاية أكثر مما ستُساعِدك. تَتَضمَّن حالة المباراة ورق لعب (cards) مُمثَل بكائن (object) من النوع Hand بالإضافة إلى رسالة مُمثَلة بكائن من النوع String. تُخزَّن تلك القيم ضِمْن مُتْغيِّرات نُسخ (instance variables). هنالك جانب آخر أقل وضوحًا سنُضْمّنه بحالة (state) المباراة: في بعض الأحيان، يَكُون هنالك مباراة قَيْد التّنْفِيذ ونَكُون بانتظار اختيار المُستخدِم لتَوقُّعه عن ورقة اللعب التالية. في بعض الأحيان الآخرى، نَكُون للتو قد انتهينا من مباراة وبانتظار نَقْر المُستخدِم على الزر "New Game". لذلك، ربما من الجيد أن نُضيِف عنصرًا جديدًا إلى حالة المباراة يُميِّز ذلك الاختلاف البسيط. يَستخدِم البرنامج مُتْغيِّر نُسخة (instance variable) من النوع boolean اسمه gameInProgress لذلك الغرض. عندما يَنقُر المُستخدِم على أحد الأزرار، فقد تَتَغيَّر حالة المباراة. يُعرِّف البرنامج ثلاثة توابع (methods) للاستجابة على أحداث الضَغْط على زر هي: doHigher()‎ و doLower()‎ و newGame()‎، والتي يُوكَل إليها مُهِمّة مُعالِجة الأحداث (event-handling). لأننا لا نُريد أن نَسمَح للمُستخدِم ببدء مباراة جديدة طالما كان هنالك مباراة آخرى قَيْد التّنْفِيذ بالفعل، فإن استجابة التابع newGame()‎ ستَختلِف بناءً على قيمة مُتْغيِّر الحالة gameInProgress. إذا كانت قيمته تُساوِي true أي أن هنالك مباراة قَيْد التّنْفِيذ، فينبغي أن يُضبَط مُتْغيِّر النُسخة message إلى رسالة خطأ معينة. في المقابل، إذا كانت قيمة المُتْغيِّر تُساوِي false أي ليس هنالك أي مباراة، فينبغي ضَبْط جميع مُْتْغيِّرات الحالة (state variables) إلى القيم المناسبة لبدء مباراة جديدة. بجميع الأحوال، لابُدّ من إعادة رَسْم الرقعة (board) حتى يَرَى المُستخدِم أن الحالة قد تَغيَّرت. يُمكِننا تَعرِيف التابع newGame()‎ على النحو التالي: private void doNewGame() { if (gameInProgress) { // إذا لم تنته المباراة الحالية بعد، اعرض رسالة خطأ message = "You still have to finish this game!"; drawBoard(); return; } deck = new Deck(); // أنشئ مجموعة ورق اللعب واليد hand = new Hand(); deck.shuffle(); hand.addCard( deck.dealCard() ); // اسحب ورقة اللعب الأولى message = "Is the next card higher or lower?"; gameInProgress = true; drawBoard(); } // end doNewGame() التابعان doHigher()‎ و doLower()‎ مُتطابقان تقريبًا، وربما كان بإِمكَاننا دَمْجهُما ضِمْن تابع واحد يَستقبِل مُعاملًا (parameter) واحدًا. عندما يَنقُر المُستخدِم على الزر "Higher"، يُستدعَى البرنامج doHigher()‎، ولأن ذلك الاستدعاء ليس له أي معنى إلا في حالة وجود مباراة قَيْد التّنْفِيذ، يَفْحَص التابع قيمة مُتْغيِّر الحالة gameInProgress أولًا. إذا كانت قيمته تُساوِي false، فإنه يَعرِض رسالة خطأ أما إذا كانت قيمته تساوي true أي توجد مباراة قَيْد التّنْفِيذ، فإنه يُضيِف ورقة لعب جديدة إلى اليد (hand) ثم يَفْحَص تَوقُّع المُستخدِم. قد تنتهي المباراة في تلك اللحظة بفوز المُستخدِم أو بخسارته، وعندها يََضبُط التابع قيمة مُتْغيِّر الحالة gameInProgress إلى القيمة false لأن المباراة قد انتهت ببساطة. بجميع الأحوال، يُعاد رَسْم الرُقعة (board) لضمان عَرْض الحالة (state) الجديدة. اُنظر التابع doHigher()‎: private void doHigher() { if (gameInProgress == false) { // إذا كانت المباراة قد انتهت، فمن الخطأ النقر // ‫على زر "Higher" لذلك اعرض رسالة خطأ وانهي المعالجة message = "Click \"New Game\" to start a new game!"; drawBoard(); return; } hand.addCard( deck.dealCard() ); // اسحب ورقة لعب إلى اليد int cardCt = hand.getCardCount(); Card thisCard = hand.getCard( cardCt - 1 ); // تم سحب ورقة لعب Card prevCard = hand.getCard( cardCt - 2 ); if ( thisCard.getValue() < prevCard.getValue() ) { gameInProgress = false; message = "Too bad! You lose."; } else if ( thisCard.getValue() == prevCard.getValue() ) { gameInProgress = false; message = "Too bad! You lose on ties."; } else if ( cardCt == 4) { gameInProgress = false; message = "You win! You made three correct guesses."; } else { message = "Got it right! Try for " + cardCt + "."; } drawBoard(); } // end doHigher() يَعتمِد التابع drawBoard()‎ على قيم مُتْغيِّرات الحالة (state variables) لتَقْرِير ما ينبغي له أن يَرسِمه ضِمْن الحاوية (canvas)، فيَعرِض السِلسِلة النصية المُخزَّنة بالمُتْغيِّر message ويَرسِم ورق اللعب ضِمْن اليد hand. وأخيرًا، إذا كانت المباراة قَيْد التّنْفِيذ، فإنه يَرسِم ورقة لعب إضافية مقلوبة تُمثِل ورقة اللعب التالية بمجموعة ورق اللعب (deck). ملحوظة: لقد ناقشنا التقنية المُستخدَمة لرَسْم ورقة لعب (card) مُفرّدة بالقسم ٦.٢. القوائم Menu وشريط القوائم MenuBar سنَعرِض الآن برنامج رَسْم اسمه "MosaicDraw". تَتَوفَّر شيفرة البرنامج بالملف MosaicDraw.java كما يَتَطلَّب الصَنْف MosaicCanvas.java. تُظهِر الصورة التالية رسمة مَصنُوعة باِستخدام البرنامج: عندما يَنقُر المُستخدِم على الفأرة ويَسحَبها داخل مساحة الرسم (drawing area)، فإن الفأرة تَترُك أثرًا مُكوَّنًا من مربعات صغيرة مُلوَّنة عشوائيًا. بالإضافة إلى ذلك، يُوفِّر البرنامج شريط قوائم (menu bar) أعلى مساحة الرسم. أولًا، تحتوي قائمة "Control" على أوامر لمَلْئ مساحة الرسم وتنظيفها مع خيارات آخرى تُؤثِر على مَظهَر الصورة. ثانيًا، تَسمَح قائمة "Color" بتَخْصِيص اللون المُستخدَم أثناء الرسم. ثالثًا، تُؤثِر قائمة "Tools" على سلوك الفأرة، فعندما نَستخدِم أداة "Draw" الافتراضية، تَترُك الفأرة أثرًا مُكوَّنًا من مُربعات مُفردّة، ولكن عندما نَستخدِم أداة "Draw 3x3"، فإنها تترُك أثرًا يَبلُغ عَرْضه ثلاثة مربعات. تَتَوفَّر أيضًا أداة "Erase" لإعادة ضَبْط المربعات إلى اللون الأسود الافتراضي. سنُمثِل مساحة الرسم (drawing area) داخل البرنامج باستخدام الصَنْف الفرعي MosaicCanvas المُشتَق من الصَنْف Canvas المُعرَّف بالملف MosaicCanvas.java. لا يُدعِّم ذلك الصَنْف "رسوم الفسيفساء" مباشرةً، ولكن بإمكاننا اِستخدَامه لمحاكاتها عن طريق ضَبْط لون كل مربع على حدى. أَعدّ البرنامج MosaicDraw معالجين لحدثيّ الفأرة MousePressed و MouseDragged الواقعين ضِمْن الحاوية (canvas) بحيث تَستجِيب تلك المُعالجات بتطبيق الأداة (tool) المُختارة حاليًا على مَوضِع مُؤشر الفأرة عند النَقْر. يُعدّ هذا البرنامج في العموم مثالًا جيدًا على تَطبيق مُستمع حَدَث (event listeners) على كائن (object) مما يَسمَح له بالقيام بأمور لم يَكُن هو ذاته مُبرمَجًا للقيام بها. ستَجِد شيفرة البرنامج بالكامل بالملف MosaicDraw.java. لن نُناقش جميع تفاصيلها هنا، ولكن يُفْترَض أن تَكُون قادرًا على فهمها بالكامل بَعْد قراءة هذا القسم. في المقابل، تَعتمِد شيفرة الملف MosaicCanvas.java على بعض التقنيات التي لن تَتَمكَّن من استيعابها في الوقت الحالي، ومع ذلك، يُمكِنك قراءة التعليقات الموجودة بالملف لكي تَتَعلَّم المزيد عن واجهة برمجة التطبيقات (API) الخاصة بالصَنْف MosaicCanvas. سنَستخدِم مُكوِّن شريط القوائم (menu bar) للمرة الأولى ضِمْن البرنامج MosaicDraw. تَسمَح لك مكتبة جافا إف إكس (JavaFX) بإضافة قائمة إلى البرنامج بسهولة عن طريق استخدام كائنات (objects) تَنتمِي للصَنْف MenuItem أو إلى أي من أصنافها الفرعية (subclasses) الُمعرَّفة بحزمة javafx.scene.control لتَمثيِل عناصر القائمة. تَعمَل عناصر القائمة تقريبًا بنفس الكيفية التي تعمل بها الأزرار (buttons). يُوفِّر الصَنْف MenuItem باني كائن (constructor) بمُعامل واحد عبارة عن نص عنصر القائمة. بإمكانك استخدامه لإنشاء كائن من ذلك الصَنْف كالتالي: MenuItem fillCommand = new MenuItem("Fill"); نظرًا لأن عناصر القائمة قد تَتَكوَّن من صورة ونص مثل الأزرار، يُوفِّر الصَنْف باني كائن (constructor) آخر بمُعاملين لتَخْصِيصهما. عندما يختار المُستخدِم عنصر قائمة من النوع MenuItem من قائمة، يَقَع حَدَث من النوع ActionEvent. يُمكِنك إضافة مُستمِع حَدَث (event listener) إليه باِستخدَام تابعه setOnAction(handler)‎. بالإضافة إلى ذلك، قد تَستخدِم التابع setDisable(disabled)‎ لتَفْعيل عنصر قائمة أو تَعْطِيله، وكذلك التابع setText()‎ لتَغْيِير النص المعروض. يختلف عنصر القائمة (menu item) عن الزر (button) بكَوْنه يَظهَر ضِمْن قائمة (menu). في الواقع، أي عنصر قائمة هو عبارة عن عقدة من النوع Node تَظهَر عادةً ضِمْن قائمة، ولكنها قد تَظهَر أيضًا بأي مكان آخر ضِمْن مبيان المشهد (scene graph). تُمثَل القوائم (menus) بمكتبة جافا إف إكس (JavaFX) باِستخدَام الصَنْف Menu. لمّا كان ذلك الصَنْف صنفًا فرعيًا مُشْتقًا من الصَنْف MenuItem، فإنه من المُمكن إضافة قائمة ضِمْن قائمة آخرى كعنصر، وتَكُون عندها قائمة فرعية (submenu) من القائمة الأصلية المُضافة إليها. أي قائمة من الصَنْف Menu لها اسم يُمكِنك تَخْصِيصه من خلال باني الكائن (constructor). يُعيد تابع النسخة getItems()‎ المُعرَّف بالصَنْف Menu قائمة (list) بعناصر القائمة (menu items)، ويُمكِنك أن تُضيِف عنصر قائمة جديد بإضافته إلى تلك القائمة. تُوضِح الشيفرة التالية طريقة إضافة عناصر (items) إلى قائمة: Menu sampleMenu = new Menu("Sample"); sampleMenu.getItems().add( menuItem ); // اضف عنصر قائمة إلى القائمة sampleMenu.getItems().addAll( item1, item2, item3 ); // أضف عدة عناصر ينبغي أن تضيف القائمة (menu) بَعْد إنشائها إلى شريط قوائم (menu bar) يُمثَل باِستخدَام الصنف MenuBar. لا يملك شريط القوائم اسمًا، فهو يعمل فقط بمثابة حاوي (container) لعدة قوائم. يمكنك استدعاء باني الكائن (constructor) الخاص به بدون أي معاملات أو بقائمة مُعاملات (parameter list) تحتوي على القوائم (menus) المطلوب إضافتها إليه. يعيد تابع النسخة getMenus()‎ قائمة من القوائم (menus). يُعيد تابع النسخة getMenus()‎ المُعرَّف بالصَنْف MenuBar قائمة (list) بالقوائم (menus) ضمن الشريط، ويستخدم كُلًا من التابعين add()‎ و addAll()‎ لإضافة قوائم (menus) جديدة إلى الشريط. يَستخدَم برنامج MosaicDraw ثلاثة قوائم هي controlMenu و colorMenu و toolMenu. تُنشِئ التَعْليمَات التالية شريط قوائم (menu bar) وتُضيِف إليه عدة قوائم (menus): MenuBar menuBar = new MenuBar(); menuBar.getMenus().addAll(controlMenu, colorMenu, toolMenu); أو قد نُمرِّر القوائم (menu) مباشرةً إلى الباني (constructor) كالتالي: MenuBar menuBar = new MenuBar(controlMenu, colorMenu, toolMenu); تَبقَّى لنا إضافة شريط القوائم (menu bar) إلى مبيان المشهد (scene) الخاص بالبرنامج. عادةً ما يَكُون شريط القوائم أعلى النافذة، ولكن من الممكن وَضْعُه بأي مكان آخر. عادةً ما تَستخدِم البرامج -المُحتويّة على شريط قوائم- كائن حاوية من النوع BorderPane يَعمَل كمُكوِّن جذري (root) لمبيان المشهد (scene graph). يَظهَر شريط القوائم (menu bar) بالمُكوِّن الموجود أعلى الحاوية أما المُكوِّنات الرسومية (GUI components) الآخرى فتَظهَر بالمواضع الأربعة الآخرى. يُمكِنك إذًا إنشاء أي قائمة على النحو التالي: أولًا، اِنشِئ شريط قوائم (menu bar). ثانيًا، اِنشِئ قوائم (menus) وأَضِفها إلى ذلك الشريط. ثالثًا، اِنشِئ عناصر قائمة (menu items) وأَضِفها إلى تلك القوائم. أَضِف مُستمعِي أحداث للأحداث (events) الصادرة عن تلك العناصر لمُعالجتها. أخيرًا، ضَعْ شريط القوائم (menu bar) بأعلى مُكوِّن الحاوية من النوع BorderPane. تُوفِّر مكتبة جافا إف إكس (JavaFX) أنواعًا آخرى من عناصر القوائم (menu items)، والتي يُمكِن بطبيعة الحال إضافتها إلى أي قائمة. تلك العناصر مُعرَّفة كأصناف فرعية (subclasses) من الصَنْف MenuItem. على سبيل المثال، يَستخدِم المثال التالي عنصر قائمة من النوع SeparatorMenuItem لإضافة خط بين عناصر القائمة الأخرى: menu.getItems().add( new SeparatorMenuItem() ); يتوفَّر أيضًا الصنفين الفرعيين CheckMenuItem و RadioMenuItem. يُمثِل الصَنْف CheckMenuItem عنصر قائمة يُمكِنه أن يَكُون بواحدة من حالتين: مُختار (selected) أو غير مُختار (not selected). تَتَبدَّل حالة العنصر عندما يختاره المُستخدِم من القائمة الحاوية له. يَعمَل ذلك العنصر بنفس الطريقة التي تَعمَل بها مُربعات الاختيار من الصَنْف CheckBox (اُنظر القسم الفرعي ٦.٤.٣). يَستخدِم البرنامج MosaicDraw ثلاثة عناصر من النوع CheckMenuItems بقائمة "Control": يُستخدَم إحداها لتَفْعِيل ميزة الألوان العشوائية للمربعات وإلغاؤها. يُستخدَم آخر لغَلْق خاصية التَماثُل (symmetry) وفَتْحها. عند تَفْعِيل تلك الخاصية، تَنعكِس الرسمة أفقيًا ورأسيًا لإنتاج نمط مُتماثِل. أخيرًا، يَعرِض عنصر القائمة الثالث ما يُعرَف بـ"الحشو (grouting)" ويُخفِيه. يَتَكوَّن ذلك الحشو من خطوط رمادية مرسومة حول كل مربع داخل الرسمة. اُنظر التَعْليمَات التالية المُستخدَمة لإضافة عنصر القائمة المُمثِل للخيار "Use Randomness" إلى قائمة "Control": useRandomness = new CheckMenuItem("Use Randomness"); useRandomness.setSelected(true); // شغل العشوائية افتراضيًا controlMenu.getMenus().add(useRandomness); // أضف عنصر قائمة إلى القائمة لم نُضِف مُعالجًا للحدث ActionEvent الصادر عن عنصر القائمة useRandomness حيث يَفْحَص البرنامج حالته باستدعاء useRandomness.isSelected()‎ عند حاجته إلى تلوين أي مربع لكي يُقرِّر ما إذا كان سيُضيف بعض العشوائية للون أم لا. في المقابل، عندما يختار المُستخدِم مربع الاختيار "Use Grouting"من القائمة، فلابُدّ أن يُعِيد البرنامج رَسْم الحاوية (canvas) مباشرةً حتى تَعكِس حالتها الجديدة. تُضيِف الشيفرة التالية معالجًا (handler) إلى عنصر القائمة useGrouting المُمثِل لذلك الخيار لكي يَستدعِي التابع المناسب: useGrouting.setOnAction( e -> doUseGrouting(useGrouting.isSelected()) ); تحتوي قائمة "Tools" وقائمة "Color" بالبرنامج على عناصر قائمة من النوع RadioMenuItem تَعمَل بنفس الطريقة التي تَعمَل بها أزرار الانتقاء من الصَنْف RadioButton (اُنظر القسم الفرعي ٦.٤.٣). يُمكِن لأي عنصر قائمة من ذلك النوع أن يَكُون مختارً (selected) أو غير مختار، ولكن إذا أضفت عدة عناصر منها إلى كائن من الصَْنْف ToggleGroup، فلن تَتَمكَّن من اختيار أكثر من عنصر واحد فقط ضِمْن تلك المجموعة. يستطيع المُستخدِم أن يختار الأداة التي يَرغَب باِستخدَامها من قائمة "Tools"، ولأنه سيختار بطبيعة الحال أداة واحدة بكل مرة، كان من البديهي تَمثيِل تلك الأدوات بهيئة عناصر قائمة من الصَنْف RadioMenuItem، ومن ثَمَّ إضافتها جميعًا إلى كائن من الصَنْف ToggleGroup. يُؤشَر بعلامة على عنصر القائمة المُمثِل للأداة المُختارة حاليًا بالقائمة، وعندما يختار المُستخدِم أداة جديدة، يَتبدَّل مكان ذلك التأشير كاِستجابة مرئية تُوضِح الأداة المُختارَة حاليًا. بالإضافة إلى ذلك، تَملُك الكائنات من الصَنْف ToggleGroup خاصية "قابلة للمراقبة (observable)" تُمثِل الخيار المُحدَّد حاليًا (اُنظر القسم ٦.٣.٧). يُضيِف البرنامج مُستمِعًا (listener) إلى تلك الخاصية ويُخصِّص لها مُعالِج حَدَث (event handler) يُستدعَى تلقائيًا بكل مرة يختار فيها المُستخدِم أداة جديدة. اُنظر الشيفرة المسئولة عن إنشاء قائمة "Tools": Menu toolMenu = new Menu("Tools"); ToggleGroup toolGroup = new ToggleGroup(); toolGroup.selectedToggleProperty().addListener( e -> doToolChoice(toolGroup.getSelectedToggle()) ); addRadioMenuItem(toolMenu,"Draw",toolGroup, true); addRadioMenuItem(toolMenu,"Erase",toolGroup, false); addRadioMenuItem(toolMenu,"Draw 3x3",toolGroup, false); addRadioMenuItem(toolMenu,"Erase 3x3",toolGroup, false); وبحيث يُعرَّف التابع addRadioMenuItem على النحو التالي: private void addRadioMenuItem(Menu menu, String command, ToggleGroup group, boolean selected) { RadioMenuItem menuItem = new RadioMenuItem(command); menuItem.setToggleGroup(group); menu.getItems().add(menuItem); if (selected) { menuItem.setSelected(true); } } الشيفرة المسئولة عن إنشاء شريط القوائم (menua bar) مُعرَّفة بالكامل ضِمْن تابع (method) اسمه هو createMenuBar()‎. Scene و Stage قبل أن ننتهي من هذه المقدمة المُختصَرة عن برمجة واجهات المُستخدِم الرسومية (GUI)، سنَفْحَص صَنْفين أساسيين على نحو أكثر تفصيلي: Scene من حزمة package javafx.scene و Stage من حزمة package javafx.stage. يُمثِل أي مشهد من الصَنْف Scene مساحة المحتويات ضِمْن نافذة، ويَحمِل المُكوِّن الجذري لمبيان المشهد (scene graph) الخاص بها. يُعرِّف الصَنْف Scene بواني كائن (constructors) كثيرة تَستقبِل جميعها المُكوِّن الجذري لمبيان المشهد كمُعامل (parameters) إلى جانب عدة معاملات آخرى. على سبيل المثال، يَستقبِل الباني new Scene(root)‎ مُعاملًا واحدًا فقط يُمثِل المُكوِّن الجذري، ويُعدّ أكثر بواني الصنف شيوعًا. يُمكِنك أيضًا أن تُمرِّر عَرْض المشهد وارتفاعه كمُعاملات للباني باِستخدَام Scene(root,width,height)‎. إذا كان المُكوِّن الجذري عبارة عن حاوية من النوع Pane، يُضبَط حجم الحاوية بحيث يُساوِي حجم المشهد وتُعرَض محتوياتها بناءً على ذلك الحجم أما إذا لم يُخصَّص حجم المشهد، فإنه يُضْبَط إلى القيمة المفضلة لحجم المشهد. في المقابل، إذا كان المُكوِّن الجذري من الصَنْف Group المُعرَّف بحزمة package javafx.scene، فإنه لا يُضْبَط إلى نفس حجم المشهد وإنما يُقْصّ أي لا يَظهَر أي جزء يَقَع خارج المشهد (scene). لا تستطيع البرامج ضَبْط عَرْض أو ارتفاع مشهد من الصَنْف (Scene)، ولكن إذا تَغيَّر حجم المرحلة (stage) -من الصَنْف Stage- الحاوية لمشهد (scene)، فإن حجم المشهد يَتَغيَّر أتوماتيكيًا ليُطابِق الحجم الجديد لمساحة المُحتويات بالمرحلة (stage) كما يَتَغيَّر حجم المُكوِّن الجذري (root) للمشهد (scene) إذا كان من النوع Pane. يُمكِنك أن تُخصِّص لون مَلْئ (fill) -من النوع Paint- لخلفية مشهد (scene) عن طريق باني الكائن (constructor). مع ذلك، لا تَكُون خلفية المشهد مرئية في العموم لكَوْنها مغطاة بخلفية المُكوِّن الجذري (root). يُضْبَط لون خلفية المُكوِّن الجذري إلى الرمادي الفاتح افتراضيًا، ولكن قد تَضبُطه ليُصبِح شفافًا (transpatent) إذا أردت رؤية خلفية المشهد. تُمثِل أي مرحلة من الصَنْف Scene -المُعرَّف بحزمة javafx.stage- نافذة على شاشة الحاسوب. يَملُك أي تطبيق جافا إف إكس (JavaFX) مرحلة (stage) واحدة على الأقل يُطلَق عليها اسم "المرحلة الرئيسية (primary stage)". يُنشِئ النظام تلك المرحلة ويُمرِّرها كمُعامل (parameter) إلى التابع start()‎ الخاص بالتطبيق. تَستخدِم البرامج في العادة أكثر من مجرد نافذة واحدة كما يُمكِنها أن تُنشِئ كائنات مرحلة جديدة من النوع Stage. سنعُود للحديث عن ذلك بالفصل ١٣. تحتوي أي مرحلة (stage) على مشهد (scene) يَملَئ مساحة المحتويات (content area) الخاصة بها. يستخدم تابع النسخة stage.setScene(scene)‎ لضَبْط المشهد (scene) الخاص بمرحلة (stage). يُمكِنك عَرْض مرحلة لا تحتوي على أي مشهد، وستَظهَر عندها مساحة محتوياتها على هيئة مستطيل فارغ. علاوة على ذلك، تَحتوِي أي مرحلة (stage) على شريط عنوان (title bar) يَظهَر فوق مساحة محتوياتها (content area). يَتَكوَّن ذلك الشريط من عنوان نافذة إلى جانب مجموعة من أزرار التَحكُّم التي يستطيع المُستخدِم أن يَنقُر عليها للقيام بأشياء مثل غَلْق النافذة أو تكبيرها. يُضيِف نظام التشغيل (operating system) -لا الجافا- ذلك الشريط تلقائيًا، ويَتَحكَّم بتصميمه الخارجي. يُستخدَم تابع النسخة stage.setTitle(string)‎ لضَبْط النص المَعرُوض بشريط العنوان، وتستطيع استدعائه بأي وقت. افتراضيًا، يستطيع المُستخدِم أن يَضبُط حجم أي مرحلة (stage) بسَحْب حوافها أو أركانها. مع ذلك، يُمكِنك استدعاء stage.setResizable(false)‎ لكي تَمنَعه من ذلك. لاحِظ أنه حتى بَعْد استدعاء ذلك التابع على مرحلة، فما تزال شيفرة البرنامج ذاتها قادرة على تَغْيِير حجم تلك المرحلة باستدعاء توابع النسخة stage.setWidth(w)‎ و stage.setHeight(h)‎. عادةً ما يُحدَّد الحجم المبدئي لأي مرحلة بحجم المشهد (scene) الموجود داخلها، ولكن بإمكانك استدعاء setWidth()‎ و setHeight()‎ لضَبْط قيمة الحجم المبدئي قَبْل عَرْض النافذة. عندما يَكُون حجم مرحلة (stage) قابلًا للضَبْط من قِبَل المُستخدِم، فإن بإِمكانه تَصغِير النافذة أو تَكْبيرها إلى أي قيمة عشوائية افتراضيًا. يُمكِنك مع ذلك اِستخدَام توابع النسخ stage.setMinWidth(w)‎ و stage.setMaxWidth(w)‎ و stage.setMinHeight(h)‎ و stage.setMaxHeight(h)‎ لوَضْع بعض القيود على القيم المسموح بها. تُطبَق تلك القيود على ما يستطيع المُستخدِم القيام به أثناء سَحْبه لحواف النافذة أو أركانها. يُمكِنك تَغْيِير موضع مرحلة (stage) على الشاشة -عادةً قبل عَرْضها- باستدعاء توابع النُسخ stage.setX(x)‎ و stage.setY(y)‎. تُخصِّص الإحداثيات x و y مَوضِع الركن الأيسر العلوي من النافذة وفقًا لنظام إحداثيات الشاشة. أخيرًا، تَذكَّر أن أي مرحلة (stage) تَظلّ غَيْر مرئية إلى أن تَعرِضها على الشاشة صراحةً باستدعاء تابع النسخة stage.show()‎. عادةً ما يَكُون إظهار "المرحلة الرئيسية (primary stage)" هو آخر ما يُنفِّذه التابع start()‎ الخاص بالتطبيق. إنشاء ملفات Jar الملف المُنتهِي بالامتداد ‎.jar هو عبارة عن ملف جافا أرشيفي (java archive) يَتَضمَّن عددًا من ملفات الأصناف (class files) والموارد (resource files) المُستخدَمة ضِمْن البرنامج. عندما تُنشِئ برنامجًا يَعتمِد على أكثر من ملف واحد، يُنصَح عمومًا بوَضْع جميع الملفات التي يَتَطلَّبها ذلك البرنامج ضِمْن ملف جافا أرشيفي، وعندها لن يحتاج المُستخدِم لأكثر من ذلك الملف حتى يَتَمكَّن من تَشْغِيل البرنامج. يُمكِنك أيضًا أن تُنشِئ ما يُعرَف باسم "ملف جافا أرشيفي تّنْفِيذي (executable jar file)"، والذي يستطيع المُستخدِم أن يُشغِّله بنفس الكيفية التي يُشغِّل بها أي تطبيق آخر أي بالنَقْر المُزدوج على أيقونة الملف، ولكن لابُدّ من وجود نُسخة مُثبتَّة وصحيحة من الجافا على حاسوبه كما ينبغي أن تَكُون إعدادات حاسوبه مَضْبُوطَة بطريقة معينة. عادةً ما تُضبَط تلك الإعدادات تلقائيًا عند تثبيت الجافا بنظامي ويندوز وماك على الأقل. تَعتمِد طريقة إنشاء ملفات الجافا الأرشيفية (jar file) على بيئة البرمجة (programming environment) المُستخدَمة. لقد ناقشنا بالفعل نوعين أساسين منها هما: بيئة سطر الأوامر (command line) وبيئة التطوير المُتكاملة (IDE) بالقسم ٢.٦. تُوفِّر أي بيئة تطوير مُتكاملة للجافا (Java IDE) أمرًا لإنشاء ملفات الجافا الأرشيفية (jar files). اِتبِع مثلًا الخطوات التالية ببيئة تَطوِير إكلبس (Eclipse): اُنقُر بزر الفأرة الأيمن على المشروع داخل نافذة مُتصفِح الحزم (Package Explorer) ثُمَّ اِختَر "Export" من القائمة. ستَظهَر نافذة، اِختَر منها "JAR file" ثُمَّ اُنقُر على "Next". ستَظهَر نافذة أخرى، أَدْخِل اسمًا للملف الأرشيفي بصندوق الإدخال "JAR file" (يُمكنِك أيضًا النَقْر على زر "Browse" المجاور لذلك الصندوق لاختيار اسم الملف من خلال نافذة). لابُدّ أن يَنتهِي اسم الملف بالامتداد ‎.jar. إذا كنت تُنشِئ ملفًا أرشيفيًا (jar file) عاديًا لا ملفًا تنفيذيًا، تستطيع أن تَنقُر على "Finish" لإنشاء الملف. أما إذا كنت تريد أن تُنشِئ ملفًا أرشيفيًا تنفيذيًا (executable)، اُنقُر على زر "Next" مرتين إلى أن تَصِل إلى شاشة "Jar Manifest Specification". ستَجِد صندوق الإدخال "Main class" بنهاية الشاشة. ينبغي أن تُدْخِل به اسم الصَنْف المُتْضمِّن للبرنامج main()‎ المُراد تَشْغِيله عند تّنْفِيذ الملف الأرشيفي. إذا ضَغطَت على زر "Browse" المجاور للصندوق "Main class"، ستَظهَر قائمة بالأصناف المُحتويّة على برنامج main()‎ والتي يُمكِنك الاختيار من بينها. بَعدّ اختيار الصَنْف، اُنقُر على زر "Finish" لإنشاء الملف التّنْفِيذي. بالنسبة لبيئة سطر الأوامر، تَتَضمَّن عُدّة تطوير جافا (Java Development Kit - JDK) برنامج سطر الأوامر jar المُستخدَم لإنشاء ملفات جافا أرشيفية (jar files). إذا كانت جميع الأصناف (classes) واقعة ضِمْن الحزمة الافتراضية (default package) كغالبية الأمثلة التي تَعرَّضنا لها، يَكُون اِستخدَام الأمر jar سهلًا نوعًا ما. فمثلًا، لكي تُنشِئ ملفًا أرشيفيًا غَيْر تّنفِيذي بسطر الأوامر، اِنتقِل إلى المجلد الذي يَحتوِي على ملفات الأصناف المطلوب إضافتها إلى الملف الأرشيفي، ثُمَّ اِستخدِم الأمر التالي: jar cf JarFileName.jar *.class حيث JarFileName هو اسم ملف الجافا الأرشيفي الذي تَرغَب بإنشائه. لاحِظ أن المحرف * بـ ‎*.class هو عبارة عن محرف بدل (wildcard) يَجعَل ‎*.class تُطابِق جميع أسماء ملفات الأصناف (class files) الموجودة بالمجلد الحالي أي سيَحتوِي الملف الأرشيفي (jar file) على كل ملفات الأصناف ضِمْن المجلد. إذا كان البرنامج يَستخدِم ملفات موارد (resource files) مثل الصور، فلابُد من أن تُضيفها إلى الأمر jar أيضًا. أما إذا كنت تريد أن تُضيِف ملفات أصناف مُحدَّدة فقط، فينبغي أن تَذكُر أسمائها صراحةً بحيث تَفصِل مسافة فارغة بين كل اسم والذي يليه. إذا كانت ملفات الأصناف والموارد مُعرَّفة بحزم غَيْر الحزمة الافتراضية (default package)، تُصبِح الأمور أكثر تعقيدًا، ففي تلك الحالة، لابُدّ أن تَقَع ملفات الأصناف بمجلدات فرعية داخل المجلد الذي تُنفِّذ به الأمر jar. اُنظُر القسم الفرعي ٢.٦.٧. في المقابل، إذا كنت تريد أن تُنشِئ ملفًا أرشيفيًا تنفيذيًا من خلال سطر الأوامر، فالأمر ربما أعقد قليلًا. فلابُدّ من وجود طريقة لتَخْصِيص الصَنْف المُتضمِّن للبرنامج main()‎ مثلًا بإنشاء ملف نصي يحتوي على سطر وحيد كالتالي: Main-Class: ClassName يُشير ClassName -بالأعلى- إلى اسم الملف المُحتوِي على البرنامج main()‎. على سبيل المثال، إذا كان البرنامج main()‎ مُعرَّف ضِمْن الصنف MosaicDraw، فينبغي أن يَحتوِي الملف على العبارة "Main-Class: MosaicDraw". يُمكِنك أن تُسمِي الملف بأي اسم تريده، ولكن لابُدّ من أن تَضعُه داخل نفس المجلد الذي تُنفِّذ به الأمر jar كما ينبغي أن تَكتُب الأمر jar بالصياغة التالية: jar cmf ManifestFileName JarFileName.jar *.class يستطيع الأمر jar تّنْفِيذ الكثير من العمليات المختلفة. يخصص مُعامله (parameter) الأول cf أو cmf العملية المطلوب تّنْفِيذها. بالمناسبة، إذا استطعت إنشاء ملف أرشيفي تّنْفِيذي (executable jar file)، يُمكِنك اِستخدَام الأمر java -jar لتَشْغِيله عبر سطر الأوامر كالتالي: java -jar JarFileName.jar ترجمة -بتصرّف- للقسم Section 6: Complete Programs من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

تُعدّ المُكوِّنات (components) اللبنة الأساسية بأي واجهة مُستخدِم رُسومية (graphical user interface). لا يَقْتصِر الأمر على إنشاء مُكوِّنات الواجهة بل تحتاج أيضًا إلى تَخْطِيط الكيفية التي ستَتَموْضَع بها تلك المُكوِّنات على الشاشة وكذلك تَخْصِيص أحجامها. في العموم، تُعدّ عملية حِسَاب إحداثيات المَواضِع معقدة نوعًا ما خاصةً إذا لم تَفْترِض ثبات حجم مساحة الرسم. تُوفِّر الجافا لحسن الحظ حلًا مُبسِّطًا لذلك. تُشير المُكوِّنات (components) إلى الأشياء المرئية التي تُشكِّل واجهة المُستخدِم الرُسومية (GUI). بعضًا منها عبارة عن مُكوِّنات حاوية (containers) يُمكِنها أن تَتَضمَّن مُكوِّنات آخرى. بمصطلحات جافا إف إكس (JavaFX)، المُكوِّنات الحاوية (container) هي عُقَد مبيان مشهد (scene graph node) يُمكِنها أن تَتَضمَّن عقد مبيان مشهد آخرى كأبناء (children). لابد من ضَبْط مواضع وأحجام أبناء أي مُكوِّن حاوي فيما يُعرَف باسم "التخطيط (layout)"، وهو ما قد تُبرمجه بنفسك، ولكن تُستخدَم عادةً حلول أتوماتيكية بواسطة المُكوِّن الحاوي (container) نفسه. تُنفِّذ أنواع مختلفة من المُكوِّنات الحاوية سياسات تخطيط (layout policies) مختلفة لتَحْديد مواضع العقد الأبناء (child nodes). سنُغطِي في هذا القسم بعض أنواع المُكوِّنات الحاوية (containers) بمنصة جافا إف إكس (JavaFX) مع توضيح سياسات التخطيط الخاصة بكُلًا منها كما سنَفْحَص أمثلة برمجية متعددة. لأن أي مُكوِّن حاوي (container) هو بالنهاية عُقدَة مبيان مشهد (scene graph node)، فيُمكِنك أن تُضيف مُكوِّن حاوي كابن لمُكوِّن حاوي آخر مما يَسمَح بتداخل مُعقد للمُكوِّنات كما هو مُبيَّن بالصورة التالية: تُوضِح الصورة السابقة مُكوِّن حاوي (container) كبير يَتَكوَّن من مُكوِّنين حاويين أصغر كلًا منهما يَحمِل بدوره ثلاثة مُكوِّنات آخرى. تُخصِّص كل عقدة مبيان مشهد (scene graph node) قيم صغرى وكبرى ومُفضّلة لكُلًا من عرضها وارتفاعها. يَستعِين أي مُكوِّن حاوي بتلك القيم عند تقريره لطريقة وَضْع أبنائه. من الجهة الآخرى، يُعدّ حجم بعض مُكوِّنات العُقَد ثابتًا -مثل الصنفين Canvas و ImageView-، وتَتَساوَى عندها كُلًا من القيم الصغرى والعظمى والمُفضّلة للعرض والارتفاع مع الحجم الفعليّ للمُكوِّن، ولا يُمكِن لأي مُكوِّن حاوي عندها تَغْيير ذلك الحجم أثناء التخطيط (layout). في العموم، سيَحسِب المُكوِّن الحاوي حجمه المُفضّل اعتمادًا على ما يَتَضمَّّنه من مُكوِّنات وبحيث يَسمَح ذلك الحجم بأن يَحصُل كل مُكوِّن داخله على حجمه المُفضّل على الأقل. سيَحسِب المُكوِّن الحاوي القيم الصغرى والعظمى لحجمه بنفس الطريقة أي وفقًا للأحجام الصغرى والعظمى لأبنائه. أثناء التخطيط (layout)، تلتزم أغلب المُكوِّنات الحاوية (container) بضَبْط قيمة عَرْض (width) أي مُكوِّن ابن بحيث تتراوح بين القيمة الصغرى والعظمى لعَرْض المُكوِّن الابن ذاته حتى لو أدى ذلك إلى تَداخُله مع مُكوِّنات آخرى أو إلى تَمدُّده إلى خارج المُكوِّن الحاوي (قد يُصبِح ذلك الجزء المُتمدِّد مرئيًا أو لا بالاعتماد على المُكوِّن الحاوي) أو حتى إلى ترك مساحات فارغة بالمُكوِّن الحاوي. يَنطبِق نفس الأمر على ارتفاع المُكوِّنات الأبناء. تُعرِّف العُقَد مُتغيِّرة الحجم (resizable nodes) -مثل مُكوِّنات التحكُّم (controls) وغالبية المُكوِّنات الحاوية- توابع نسخ (instance methods) لضَبْط قيم العَرْض الصغرى والعظمى والمُفضّلة، هي كالتالي: setMinWidth(w)‎ و setPrefWidth(w)‎ و setMaxWidth(w)‎ حيث المُعامِل w من النوع double بالإضافة إلى توابع نسخ مشابهة لضَبْط قيم الارتفاع. تَتَوفَّر أيضًا توابع مثل setMaxSize(w,h)‎ و setPrefSize(w,h)‎ لضَبْط قيمتي العرض والارتفاع بنفس الوقت. بالنسبة لمُكوِّن حاوي (container)، ستُبطِل القيم المضبوطة باِستخدَام هذه التوابع تلك القيم التي كانت ستُحسَب بالاعتماد على المُكوِّنات الأبناء. بمنصة جافا إف إكس (JavaFX)، تُعرَّف المُكوِّنات الحاوية المسئولة عن التخطيط بواسطة الصنف Pane وأصنافه الفرعية (subclasses) الواقعة بحزمة javafx.scene.layout. سنَفْحَص الآن عددًا قليلًا من أصناف التخطيط (layout classes) بدءًا بالصَنْف Pane. إعداد تخطيط مخصص أحيانًا قد ترغب بتصميم التخطيط (layout) الخاص بك بدلًا من اِستخدَام إحدى الأصناف الفرعية القياسية المُشتقَّة من الصَنْف Pane. سنَستخدِم الصَنْف الأعلى Pane ذاته بالمثال الأول، وهو ما يَعنِي أننا سنتتوَلّي مُهِمّة ضَبْط مواضع العُقد الأبناء (child nodes). بالنسبة لأحجام تلك العُقد، سيتولَّى الصَنْف Pane ضَبْطها إلى أحجامها المُفضّلة افتراضيًا، ومع ذلك يُمكِنك أن تُنجِز تلك المُهِمّة أيضًا إذا أردت. بفَرْض أن node عُقدة مبيان مشهد، تَضَع التَعْليمَة التالية الركن الأيسر العُلوي للعُقدة بإحداثيات النقطة (x,y) وفقًا لنظام إحداثيات المُكوِّن الحاوي (container) لتلك العُقدة: node.relocate( x, y ); كما تَضبُط التَعْليمَة التالية حجم العُقدة بشَّرْط أن تَكُون مُتْغيِّرة الحجم (resizable): node.resize( width, height ) لن يَكُون لتلك التَعْليمَة أي تأثير إذا كانت العُقدة ثابتة الحجم (non-resizable). ومع ذلك تَملُك بعض العُقد ثابتة الحجم -مثل Canvas- توابعًا مثل setWidth(w)‎ و setHeight(h)‎ لضَبْط أحجامها. إذا كانت العُقدة ضِمْن مُكوِّن حاوي (container) مسئول عن التخطيط (layout) كليًا، فلن يَكُون لأي من التابعين relocate()‎ و resize()‎ أي تأثير. أما إذا كانت ضِمْن مُكوِّن حاوي مثل Pane، فسيُؤثِر التابع resize()‎ بالعُقد مُتْغيِّرة الحجم أما التابع relocate()‎ فلن يَكُون له أي تأثير. يُعدّ ما سَبَق صحيحًا فقط إذا كانت العُقدة مُدارة (managed). يُمكِن ضَبْط عُقدة معينة لتُصبِح غَيْر مُدارة (unmanaged) باستدعاء التالي: node.setManaged(false); سنَفْحَص مثالًا يَحتوِي على ٤ مُكوِّنات: زرين (buttons) وعنوان (label) وحاوي (canvas) يَعرِض رقعة شطرنج: عندما يَنقُر المُستخدِم على الأزرار، سيَتبدَّل النص المعروض بمُكوِّن العنوان (label). إلى جانب ذلك، لن يُنفِّذ البرنامج أي شيء فعليّ آخر، فهو فقط مُجرّد مثال بسيط على التخطيط (layout). سنَستخدِم هذا المثال بالقسم ٧.٥ كنقطة انطلاق لبرنامج لعبة داما (checkers). لأن هذا المثال يَستخدِم كائنًا من الصَنْف Pane كعُقدَة جذرية (root node) للمشهد وكمُكوِّن حاوي (container) للمُكوِّنات الأربعة الآخرى، فإن البرنامج سيَكُون مسئولًا عن ضَبْط مَواضِع المُكوِّنات باستدعاء تابعها relocate()‎ وإلا سيَقَع الركن الأيسر العُلوي لجميع المُكوِّنات بالمَوضِع الافتراضي (٠،٠). سنَضبُط أيضًا حجم الزرين (buttons) لكي يُصبِحا بنفس الحجم الذي سيَكُون أكبر قليلًا من حجمهما المُفضّل، ولكن لمّا كان الزران مدارين (managed)، فإن استدعاء تابعهما resize()‎ لن يَكُون له أي تأثير حيث سيُعيد المُكوِّن الحاوي ضَبْطهما لحجمهما المُفضّل، لذا سنحتاج أولًا لجعلهما غَيْر مُدارين (unmanaged). اُنظر الشيفرة التالية من تابع التطبيق start()‎ الذي يُنشِئ المُكوِّنات الأربعة ويَضبُط مَواضِعها وأحجامها: /* أنشئ العقد الأبناء */ board = new Checkerboard(); // صنف فرعي من الصنف‫ Canvas board.draw(); // ارسم محتويات رقعة الشطرنج newGameButton = new Button("New Game"); newGameButton.setOnAction( e -> doNewGame() ); resignButton = new Button("Resign"); resignButton.setOnAction( e -> doResign() ); message = new Label("Click \"New Game\" to begin."); message.setTextFill( Color.rgb(100,255,100) ); // Light green. message.setFont( Font.font(null, FontWeight.BOLD, 18) ); // ‫اضبط موضع كل ابن باستدعاء تابعه relocate() board.relocate(20,20); newGameButton.relocate(370, 120); resignButton.relocate(370, 200); message.relocate(20, 370); /* اضبط حجم الأزرار. لابد أن تجعلها غير مدارة أولًا */ resignButton.setManaged(false); resignButton.resize(100,30); newGameButton.setManaged(false); newGameButton.resize(100,30); يُمثِل المُكوِّن الحاوي من الصَنْف Pane العُقدَة الجذرية (root node) للمشهد، لذا سيُضبَط حجم نافذة البرنامج بما يتناسب مع الحجم المُفضَّل لذلك المُكوِّن. افتراضيًا، يُحسَب الحجم المُفضَّل للمُكوِّن الحاوي بحيث يَكُون كبيرًا كفاية لعَرْض عُقده الأبناء المُدارة، ولأننا ضَبطَنا الأزرار لتُصبِح غَيْر مُدارة (unmanaged)، فإنها لن تُؤثِر على حجمه المُفضَّل. سنَضبُط عَرْض المُكوِّن الحاوي وارتفاعه بالقيم التالية: Pane root = new Pane(); root.setPrefWidth(500); root.setPrefHeight(420); سنضيف الآن كُلًا من الأزرار (buttons) والعنوان (label) والرقعة (board) كأبناء بالمكون الحاوي بخطوة واحدة كالتالي: root.getChildren().addAll(board, newGameButton, resignButton, message); أو على عدة خطوات بحيث يُضَاف كل مُكوِّن على حدى باِستخدَام التَعْليمَة التالية: root.getChildren().add(board); أو يُمكِنك أن تُمرِّر العُقد الأبناء (child nodes) كمُعامِلات (parameters) لبَانِي الكائن (constructor) كالتالي: Pane root = new Pane(board, newGameButton, resignButton, message); لابُدّ من ضَبْط المُكوِّن الحاوي من الصَنْف Pane ليَكُون المُكوِّن الجذري (root) للمشهد (scene). ينبغي أيضًا أن نَضَع ذلك المشهد بالمرحلة (stage) التي لابُدّ من ضَبْطها وعَرْضها على الشاشة. اُنظر كامل الشيفرة المصدرية بالملف OwnLayoutDemo.java. قد يَكُون تَخْصِيص التخطيط (layout) بالمثال السابق أمرًا سهلًا على نحوٍ معقول، ولكنه سيُصبِح أصعب كثيرًا إذا كان حجم النافذة عامًلا مُتْغيِّرًا. في تلك الحالة، يُفضَّل عمومًا الاعتماد على أحد المُكوِّنات الحاوية القياسية لتُنفِّذ التخطيط (layout) بدلًا منك، ولكن إذا أردت تّنْفيذه، فلابُدّ من أن تُعرِّف صنفًا فرعيًا من الصَنْف Pane أو من صَنْفها الأعلى Region ثم ينبغي أن تُعيد تَعرِيف (override) التابع layoutChildren()‎ الذي يَستدعِيه النظام لحَث المُكوِّن الحاوي (container) على تطبيق التخطيط (layout) بما في ذلك تَغْيِير حجم المُكوِّن الحاوي. BorderPane يُعدّ مُكوِّن الحاوية BorderPane صنفًا فرعيًا (subclass) من الصَنْف Pane. قد يَشتمِل ذلك المُكوِّن على ما يَصِل إلى ٥ مُكوِّنات (components) يَقَع أكبرها بالمنتصف بينما يُرتَّب البقية حوله بالأعلى وبالأسفل وعلى اليسار وعلى اليمين كما هو مُبيَّن بالصورة التالية: قد يَشتمِل مُكوِّن الحاوية BorderPane على عدد أقل من خمسة مُكوِّنات لذا أنت لست مُضطّرًا لأن تُخصِّص مُكوِّن بكل مَوْضِع ولكن عادةً ما يُخصَّص مُكوِّن بمنتصف الحاوية. يُوفِّر الصَنْف BorderPane بانيين (constructors): لا يَستقبِل أحدهما أية مُعامِلات (parameters) بينما يَستقبِل الآخر مُعامِلًا واحدًا يُخصِّص مُكوِّن ابن (child) يُفْترَض وَضعُه بمنتصف الحاوية. بالإضافة إلى ذلك، يُمكِنك أن تُخصِّص العُقد الأبناء (child nodes) الآخرى لحاوية pane من الصَنْف BorderPane باِستخدَام التوابع (methods) التالية: pane.setCenter(node); pane.setTop(node); pane.setRight(node); pane.setBottom(node); pane.setLeft(node); ملحوظة: إذا مَرَّرت مُعامِلًا (parameter) قيمته تُساوِي null لأي من تلك التوابع، فسيُحذَف المُكوِّن الموجود بذلك المَوْضِع ضِمْن الحاوية تَضبُط مُكوِّنات الحاوية من الصَنْف BorderPane حجم عُقدها الأبناء (child nodes) على النحو التالي (لابُدّ أن يتراوح كُلًا من عرض أي مُكوّن وارتفاعه بين قيمته العظمى والصغرى المُخصَّصة): تَحتَل المُكوِّنات بالمَوْضِع العلوي والسفلي -إن وجدت- مساحة ارتفاعها يُساوِي القيمة المُفضَّلة لارتفاع المُكوِّن أما عَرْضها فيُساوِي عَرْض الحاوية الكلي. في المقابل، تَحتَل المُكوِّنات على اليمين واليسار مساحة عَرْضها يُساوِي القيمة المُفضَّلة لعَرْض المُكوِّن أما ارتفاعها فيُساوِي قيمة ارتفاع الحاوية مطروحًا منها المسافة التي احتلتها المُكوِّنات بكُلًا من المَوْضِع العلوي والسفلي. أخيرًا، يَمتدّ المُكوِّن بمنتصف الحاوية عَبْر المساحة المُتْبقيّة. تُضبَط القيمة المُفضَّلة لحجم الحاوية على نحو يتناسب مع الحجم المُفضَّل لأبنائها من العُقد المُدارة (managed). تُحسَب القيمة الصغرى بنفس الطريقة أما القيمة العظمى الافتراضية فهي لا نهائية. تُتيِح بعض الأصناف الفرعية (subclasses) المُشْتقَّة من الصَنْف Pane تطبيق ما يُعرَف باسم "قيود التَخْطِيط (layout constraint)" لتَعْدِيل تَخْطِيط (layout) العُقد الأبناء. على سبيل المثال، ماذا سيَحدُث بحاوية من النوع BorderPane إذا لم يَكُن مَسمُوحًا بإعادة ضَبْط حجم مُكوِّن ابن لكي يتناسب تمامًا مع المساحة المُتوفرة؟ في تلك الحالة، يَحتَل ذلك المُكوِّن مَوْضعًا افتراضيًا ضِمْن تلك المساحة. يَقَع مكون بمنتصف مساحة الحاوية (pane) بينما يقع آخر بالركن الأيسر السفلي منها وهكذا. يُمكِنك أن تُعدِّل الطريقة الافتراضية باِستخدَام التابع الساكن (static method) التالي المُعرَّف بالصَنْف BorderPane: BorderPane.setAlignment( child, position ); يُشير child إلى العُقدة التي تَرغَب بتَعْدِيل مَوْضِعها أما position فيَحتوِي على إحدى ثوابت نوع التعداد Pos من حزمة package javafx.geometry مثل Pos.CENTER أو POS.TOP_LEFT أو Pos.BOTTOM_RIGHT أو غيرها. يَسمَح الصَنْف BorderPane بإضافة هامش (margin) لأي مُكوِّن ابن يَقَع ضِمْن الحاوية. الهامش عبارة عن مسافة فارغة تُحيِط بالمُكوِّن الابن وتُلوَّن بنفس لون خلفية الحاوية، ويُسنَد إليها قيمة من النوع Insets المُعرَّف بحزمة package javafx.geometry. يَملُك أي كائن من النوع Insets أربع خاصيات (properties) من النوع double هي top و right و bottom و left والتي يُمكِنك ضَبْطها باِستخدَام بَانِي الكائن (constructor): new Insets(top,right,bottom,left) يَتَوفَّر باني كائن (constructor) آخر يَستقبِل مُعاملًا (parameter) واحدًا يُمثِل قيمة الخاصيات (properties) الأربعة. عند اِستخدَامه لتَخْصِيص هامش (margin) حول مُكوِّن ابن معين، تُحدِّد تلك الخاصيات الأربعة عَرْض الهامش (margin) حول جوانبه الأربعة: أعلاه ويمينه وأسفله ويساره. تستطيع تَخْصِيص الهامش (margin) باِستخدَام التابع الساكن (static method) التالي: BorderPane.setMargin( child, insets ); على سبيل المثال: BorderPane.setMargin( topchild, new Insets(2,5,2,5) ); يُمكِنك أيضًا اِستخدَام لغة أوراق الأنماط المتعاقبة (CSS) لتَعْدِيل مَظهَر حاوية (container)، وهي في الواقع واحدة من أسهل الطرائق لضَبْط خاصيات مثل لون الخلفية. HBox و VBox إذا أردت ترتيب مجموعة من المُكوِّنات ضِمْن صف أفقي أو عمود رأسي، يُمكِنك اِستخدَام الصنفين HBox و VBox. يُرتِّب الصَنْف الفرعي HBox المُشْتق من الصَنْف Pane أبنائه إلى جوار بعضها البعض ضِمْن صف أفقي بينما يُرتِّب الصَنْف الفرعي VBox المُشتق من الصَنْف Pane أبنائه ضِمْن عمود أفقي. يُمكِنك مثلًا أن تَستخدِم حاوية من الصَنْف HBox بالمَوْضِع السفلي لحاوية من الصَنْف BorderPame مما سيَسمَح باصطفاف عدة مُكوِّنات على طول الحافة السفلية للحاوية. بالمثل، قد تَستخدِم حاوية من الصَنْف VBox بالمَوْضِع الأيسر أو الأيمن لحاوية من الصَنْف BorderPane. سنُناقش الصَنْف HBox فقط ولكن تستطيع اِستخدَام الصَنْف VBox بنفس الكيفية. بإِمكَانك ضَبْط الصَنْف HBox لكي يَترُك فراغًا بين كل ابن والابن الذي يليه. بفَرْض وجود حاوية hbox، يُمكِنك تَخْصِيص مقدار الفراغ بتمرير قيمة من النوع double للتابع التالي: hbox.setSpacing( gapAmount ); القيمة الافتراضية تُساوِي صفر. تُضَاف الأبناء إلى حاوية hbox من الصَنْف HBox بنفس الكيفية التي تُضَاف بها إلى حاوية من الصَنْف Pane أي باستدعاء hbox.getChildren().add(child)‎ أو hbox.getChildren().addAll(child1,child2,...)‎. يُوفِّر الصَنْف HBox بانيين (constructor). لا يَستقبِل الأول أية مُعاملات (parameters) بينما يَستقبِل الثاني مُعاملين هما حجم الفراغ المتروك وأي عُقد أبناء (child nodes) قد ترغب بإضافتها إلى تلك الحاوية. تَضْبُط أي حاوية من النوع HBox حجم كل ابن وفقًا لقيمة العَرْض المُفضَّلة لذلك الابن مع إِمكانية تَرك مسافة فارغة إضافية إلى اليمين. إِذا كان مجموع قيم العَرْض المُفضَّلة للأبناء ضِمْن حاوية معينة أكبر من القيمة الفعلية لعَرْض تلك الحاوية، يُقلَّص عَرْض كل ابن منها في حدود قيمة العَرْض الصغرى الخاصة به. في المقابل، يُضبَط ارتفاع الأبناء إلى الارتفاع المتاح بالحاوية بما يَتَوافَق مع كُلًا من القيم الصغرى والعظمى المُخصَّصة لارتفاع تلك الأبناء. إذا أردت تَوْسِيع عَرْض عدة أبناء ضِمْن حاوية من النوع HBox إلى ما هو أبعد من قيمها المُفضَّلة بغَرْض مَلْئ مساحة مُتاحَة ضِمْن تلك الحاوية، فينبغي أن تُطبِق "قيد تخطيطي (layout constraint)" على كل ابن تَرغَب بتوسيعه باستدعاء التابع الساكن (static method) التالي: HBox.setHgrow( child, priority ); يَستقبِل التابع بالأعلى مُعاملًا ثانيًا عبارة عن ثابت (constant) من نوع التعداد Priority المُعرَّف بحزمة package javafx.scene.layout. إذا اِستخدَمت القيمة Priority.ALWAYS، فدائمًا ما سيَتَقاسَم ذلك الابن أي مساحة إضافية مُتْبقيّة، ولكنه مع ذلك سيَظَلّ مقيدًا بقيمة العَرْض العظمى الخاصة به لذا قد تَضطّر إلى زيادتها لتَسمَح له بالتَوسُع كما ينبغي. لنَفْترِض مثلًا وجود حاوية من الصَنْف HBox تَحتوِي على ثلاثة أزرار هي but1 و but2 و but3 والتي تُريِدها أن تَتَوسَّع بما يَكفِي لمَلْئ الحاوية بالكامل. ستحتاج إذًا إلى ضَبْط القيد التخطيطي HGrow لكل زر منها. بالإضافة إلى ذلك، لمّا كانت كُلًا من القيمة العظمى والمُفضَّلة لعَرْض زر مُتساوية، كان من الضروري زيادة القيمة القصوى. بالمثال التالي، ضُبِطَت قيمة العَرْض العُظمى لكل زر إلى قيمة الثابت Double.POSITIVE_INFINITY مما سيُمكِّنها من التَوسُّع بدون أي قيود نهائيًا: HBox.setHgrow(but1, Priority.ALWAYS); HBox.setHgrow(but2, Priority.ALWAYS); HBox.setHgrow(but3, Priority.ALWAYS); but1.setMaxWidth(Double.POSITIVE_INFINITY); but2.setMaxWidth(Double.POSITIVE_INFINITY); but3.setMaxWidth(Double.POSITIVE_INFINITY); ستُوزَّع الآن أي مساحة إضافية بالتَساوِي على الأزرار الثلاثة وتُضاف إلى قيمة عَرْضها المُفضَّلة. لا يَعنِي ذلك أن عَرْضها سيُصبِح متساويًا بالضرورة؛ فقد لا تَكُون قيمها المُفضَّلة الأصلية مُتساوية أساسًا. إذا أردت ضَبْط الأزرار الثلاثة لتُصبِح بنفس الحجم، فلابُدّ من ضَبْط قيمة العَرْض المُفضَّلة لكُلًا منها لتَحمِل نفس القيمة كما يَلي: but1.setPrefWidth(1000); but2.setPrefWidth(1000); but3.setPrefWidth(1000); سيَحتَلّ الآن كل زر ضِمْن تلك الحاوية مساحة عَرْضها مُتساوي. تَتَوفَّر طرائق آخرى لتَعْدِيل التخطيط (layout) ضِمْن حاوية من النوع HBox. يُمكِنك مثلًا إضافة هامش (margin) حول أي مُكوِّن ابن باِستخدَام تابع ساكن (static method) مُشابه لذلك المُستخدَم لنفس الغرض بالحاويات من النوع BorderPane. تستطيع أيضًا استدعاء hbox.setFillHeight(false)‎ لضَبْط ارتفاع حاوية معينة إلى القيمة المُفضَّلة لارتفاع أبنائها بدلًا من توسيعهم ليتلائموا مع ارتفاع تلك الحاوية. قد تَستدعِي hbox.setAlignment(position);‎ لضَبْط مَوْضِع ابن ضِمْن حاوية عندما لا يَملَؤها بالكامل. لاحِظ أن مُعاملها (parameter) من النوع Pos بقيمة افتراضية تساوي Pos.TOP_LEFT. يُمكِنك أيضًا أن تُطبِّق عليها خاصيات لغة أوراق الأنماط المتعاقبة (CSS). سنَفْحَص الآن مثالًا لواجهة مُستخدِم رُسومية (GUI) مبنية بالكامل على الصَنْفين HBox و VBox. يُمكِنك الإطلاع على شيفرة البرنامج بالملف SimpleCalc.java. تَتَضمَّن نافذة البرنامج ما يلي: حَقْلين نصيين من الصَنْف TextField تَسمَح للمُستخدِم بكتابة عدد، بالإضافة إلى أربعة أزرار يُمكِن للمُستخدِم النَقْر عليها لإجراء عملية جمع أو طرح أو ضرب أو قسمة على العددين المُدْخَلين، وأخيرًا عنوان نصي من الصَنْف Label يَعرِض نتيجة العملية المُجراة. تُبيِّن الصورة التالية ما تبدو عليه نافذة البرنامج: تُستخدَم حاوية من الصَنْف VBox كعُقدة جذرية لنافذة البرنامج، وتَحتوِي على أربعة عناصر: الثلاثة الأولى منها عبارة عن حاويات من الصَنْف HBox. يَحتوِي أول حاوي منها على عنوان من النوع Label يَعرِض النص "‎x =‎" بالإضافة إلى حقل نصي من الصَنْف TextField. يُنشَئ ذلك باستخدام الشيفرة التالية: xInput = new TextField("0"); // Text input box initially containing "0" HBox xPane = new HBox( new Label(" x = "), xInput ); يُنشَئ العنوان (label) باستخدام باني (constructor) ثم يُضاف مباشرةً إلى الحاوية لعدم حاجتنا إلى مَرجِع (reference) يُشير إليه فيما بَعْد. ستُضاف هذه الحاوية لاحقًا كابن للحاوية الخارجية من الصنف VBox. سيَعرِض ثالث حاوي الأزرار الأربعة. ولأن القيمة الافتراضية لعَرْض الزر صغيرة نسبيًا، فسنُطبِّق القيد hgrow عليها كما سنُزيد قيمة العرض العظمى لكُلًا منها لكي نَتَأكَّد من كَوْنها تملئ عَرْض الحاوية بالكامل. يُمكِنك القيام بما سبق باِستخدَام الشيفرة التالية: // ‫انشئ الأزرار الأربعة وحاوية HBox لحملها Button plus = new Button("+"); plus.setOnAction( e -> doOperation('+') ); Button minus = new Button("-"); minus.setOnAction( e -> doOperation('-') ); Button times = new Button("*"); times.setOnAction( e -> doOperation('*') ); Button divide = new Button("/"); divide.setOnAction( e -> doOperation('/') ); HBox buttonPane = new HBox( plus, minus, times, divide ); /* ‫ينبغي أن تضبط الأزرار الأربعة قليلًا لكي تملئ الحاوية buttonPane * بإمكانك القيام بذلك بضبط القيمة العظمى لعرض كل زر إلى قيمة أكبر */ HBox.setHgrow(plus, Priority.ALWAYS); plus.setMaxWidth(Double.POSITIVE_INFINITY); HBox.setHgrow(minus, Priority.ALWAYS); minus.setMaxWidth(Double.POSITIVE_INFINITY); HBox.setHgrow(times, Priority.ALWAYS); times.setMaxWidth(Double.POSITIVE_INFINITY); HBox.setHgrow(divide, Priority.ALWAYS); divide.setMaxWidth(Double.POSITIVE_INFINITY); يَعرِض القسم الأخير بالحاوية الخارجية من النوع VBox مُكوِّنًا واحدًا عبارة عن عنوان من النوع Label. نظرًا لكَوْنه مُكوِّنًا وحيدًا، يُمكِننا إضافته إلى الحاوية الخارجية مباشرةً دون الحاجة لوَضْعه أولًا ضِمْن حاوية من النوع HBox. لكي نَضْمَن ظهور النص بمنتصف النافذة بدلًا من جانبها الأيسر، سنحتاج إلى زيادة قيمة العَرْض العظمى لمُكوِّن العنوان (label) وكذلك إلى ضَبْط خاصية محاذاة النص (alignment) بمُكوِّن العنوان (label) إلى المنتصف بدلًا من اليسار. اُنظر الشيفرة التالية: answer.setMaxWidth(Double.POSITIVE_INFINITY); answer.setAlignment(Pos.CENTER); عندما يَنقُر المُستخدِم على أي من الأزرار الأربعة، يُستدعَى التابع doOperation()‎ ليُنفِّذ ما يَلي: يقرأ العَدَدين الذين أَدْخَلهما المُستخدِم بالحقول النصية (text fields) ثم يُجرِي العملية الحسابية المطلوبة ويَعرِض الناتج بنص العنوان (label). نظرًا لأن محتويات الحقول النصية (text fields) تُعاد كسَلاسِل نصية من النوع String، لابُدّ من تَحْوِيلها إلى قيم عددية أولًا. إذا فشلت عملية التَحْوِيل، يَعرِض العنوان (label) رسالة خطأ: private void doOperation( char op ) { double x, y; // الأعداد المدخلة try { // اقرأ x من أول صندوق إدخال String xStr = xInput.getText(); x = Double.parseDouble(xStr); } catch (NumberFormatException e) { // ‫لم يكن xStr عدد صالح // ‫اعرض رسالة خطأ وانقل موضع التركيز إلى xInput // وحدد محتوياته بالكامل answer.setText("Illegal data for x."); xInput.requestFocus(); xInput.selectAll(); return; // توقف عن المعالجة عند حدوث خطأ } try { // ‫اقرأ y من ثاني صندوق إدخال String yStr = yInput.getText(); y = Double.parseDouble(yStr); } catch (NumberFormatException e) { answer.setText("Illegal data for y."); yInput.requestFocus(); yInput.selectAll(); return; } /* نفذ العملية الحسابية بالاعتماد على قيمة المعامل الممررة */ if (op == '+') answer.setText( "x + y = " + (x+y) ); else if (op == '-') answer.setText( "x - y = " + (x-y) ); else if (op == '*') answer.setText( "x * y = " + (x*y) ); else if (op == '/') { if (y == 0) { // Can't divide by zero! Show an error message. answer.setText("Can't divide by zero!"); yInput.requestFocus(); yInput.selectAll(); } else { answer.setText( "x / y = " + (x/y) ); } } } // end doOperation() يُمكِنك الإطلاع على شيفرة البرنامج بالكامل بالملف SimpleCalc.java. GridPane و TilePane سنَطلِّع الآن على الصَنْف الفرعي GridPane المُشتَّق من الصَنْف Pane. يُرتِّب ذلك الصَنْف أبنائه ضِمْن شبكة (grid) من الصفوف والأعمدة مُرقَّمة بدءًا من الصفر. تُبيِّن الصورة التالية شبكة مُكوَّنة من ٤ صفوف و ٥ أعمدة: قد لا تَكُون الصفوف بنفس الارتفاع كما قد لا تَكُون الأعمدة بنفس العرض. يُمكِنك أن تَتَرُك فراغات بين الصفوف أو بين الأعمدة وستَظهَر خلفية الحاوية بتلك الفراغات. إذا كان grid عبارة عن حاوية من النوع GridPane، يُمكِنك استدعاء التالي لضَبْط حجم تلك الفراغات: grid.setHGap( gapSize ); // مسافة بين الأعمدة gris.setVGap( gapSize ); // مسافة بين االصفوف إذا أردت أن تُضيِف ابنًا (child) إلى حاوية من النوع GridPane، يُمكِنك استدعاء التابع التالي، والذي تستطيع من خلاله تَخْصِيص كُلًا من رقمي الصف والعمود لمَوْضِع ذلك الابن ضِمْن الشبكة: grid.add( child, column, row ); ملحوظة: يُخصَّص رقم العمود أولًا. قد يَحتَل ابن (child) أكثر من مجرد صف أو عمود واحد ضِمْن الحاوية. يَستقبِل التابع add عدد الأعمدة والصفوف التي ينبغي لابن أن يَحتَلّها كما يلي: grid.add( child, column, row, columnCount, rowCount ); يُحدَّد عدد الصفوف والأعمدة ضِمْن شبكة معينة بناءً على قيم المواضع التي أُضيفت إليها الأبناء. تَضبُط أي حاوية من الصَنْف GridPane حجم كل ابن داخلها بحيث يَملئ المَوضِع أو مجموعة المَواضِع المُخصَّصة له ضِمْن شبكة الحاوية. تُضبَط القيمة المُفضَّلة لعَرْض عمود ضِمْن الشبكة لتَكُون كبيرة كفاية بما يَتَناسَب مع عَرْض جميع الأبناء ضِمْن ذلك العمود، ويَنطبِق الأمر نفسه على القيمة المُفضَّلة للارتفاع. يتَوفَّر أيضًا عدد من الطرائق لتَعْدِيل ذلك، ولكننا سنَكتفِي بذِكر إمكانية التَحكُّم بالقيمة الفعلية لكُلًا من عَرْض العمود وارتفاع الصف. يُمكِنك أن تُطبِّق بعض القيود (constraints) على أعمدة وصفوف حاوية من الصَنْف GridPane لكي تُخصِّص الكيفية التي يُحسَب على أساسها كُلًا من عَرْض العمود وارتفاع الصف. بصورة افتراضية، يُحسَب عَرْض أي عمود وفقًا لعَرْض الأبناء المُضمَّنة داخله، ولكن قد تَعيد ضَبْطُه إلى قيمة ثابتة (constant) أو قد تَحسِب قيمته كنسبة من المساحة المُتاحة. يَنطبِق الأمر نفسه على ارتفاع الصفوف. تُسنِد الشيفرة التالية قيم ثابتة (constant) لارتفاع أربعة صفوف ضِمْن حاوية من النوع GridPane: gridpane.getRowConstraints().addAll( new RowConstraints(100), // ارتفاع الصف رقم 0 يساوي 100 new RowConstraints(150), // ارتفاع الصف رقم 1 يساوي 150 new RowConstraints(100), // ارتفاع الصف رقم 2 يساوي 100 new RowConstraints(200), // ارتفاع الصف رقم 3 يساوي 200 ); بالمثال الأعلى، الارتفاع الكلي للحاوية عبارة عن قيمة ثابتة بغَضْ النظر عن مقدار المساحة المُتوفِّرة. أما إذا اِستخدَمنا النسب (percentages)، فستتوسَّع الحاوية لتَملئ أي مساحة إضافية مُتوفِّرة، وسيُحسَب ارتفاع الصف وعَرْض العمود وفقًا لقيمة تلك النسب. بفَرْض أن gridpane هي كائن حاوية من الصَنْف GridPane مُكوَّنة من خمسة أعمدة، يُمكِننا اِستخدَام الشيفرة التالية للتأكُّد من أن الحاوية تُغطِي العَرْض المُتاح بالكامل، وكذلك للتأكُّد من أن عَرْض جميع أعمدتها متساوي: for (int i = 0; i < 5; i++) { ColumnConstraints constraints = new ColumnConstraints(); constraints.setPercentWidth(20); // لا يوجد باني يقوم بذلكّ gridpane.getColumnConstraints().add(constraints); } إذا تجاوز مجموع النسب المُخصَّصة ١٠٠، فإنها تُقلَّص بشكل مُتناسب أي أن ضَبْط قيم النسب الخمسة إلى ٥٠ له نفس تأثير ضَبْطها جميعًا إلى ٢٠. قد تُصبِح الأمور أكثر تعقيدًا من ذلك ولكن هذه هي الحالات الأكثر شيوعًا في العموم. يَستخدِم البرنامج SimpleColorChooser.java من القسم الفرعي ٦.٢.١ حاوية من الصَنْف GridPane. ينبغي الآن أن تَكُون قادرًا على قرائته بالكامل وفهمه. إذا كنت تحتاج إلى شبكة (grid) مُكوَّنة من مستطيلات مُتساوية الحجم، قد تَستخدِم حاوية من الصَنْف TilePane حيث يُقسَّم سطحها إلى "بلاطات (tiles)" متساوية الحجم ضِمْن صفوف وأعمدة. تُناظِر كل بلاطة (tile) عُقدة واحدة والعكس أي لا يُمكِن تَوزِيع عُقدة على أكثر من بلاطة واحدة. تَملُك أي حاوية tpane من الصَنْف TilePane عددًا مُفضَّلًا من الصفوف والأعمدة يُمكِنك ضَبْطُه باستدعاء ما يلي: tpane.setPrefColumns(cols); عادةً ما تُعرَض الحاوية بحجمها المُفضَّل، ويعتمد عدد أعمدتها في تلك الحالة على عدد الأعمدة المفضَّل، ولكنها قد تُعرَض أحيانًا بحجم مختلف، ويَعتمِد عندها عدد الأعمدة على المساحة المتاحة. أما عدد الصفوف فيُحدَّد بناءً على عدد العقد الأبناء بالحاوية حيث تَملَئ تلك العُقد الحاوية بدايةً من صفها الأول من اليسار إلى اليمين ثُمَّ تَملَئ الصف الثاني وهكذا حتى تَنتهِي العقد. لاحظ أنه ليس من الضروري للصف الأخير أن يَكُون مملوءًا بالكامل. يُعدّ ما سبق صحيحًا إذا كان "اتجاه (orientation)" الحاوية أفقيًا أما إذا كان عموديًا، فيُفْترَض بك تَخْصِيص عدد الصفوف المُفضَّل وليس عدد الأعمدة. من الشائع جدًا اِستخدَام حاويات من الصَنْف TilePane عدد أعمدتها المُفضَّل يُساوِي واحد، وتُشبِه عندها الحاويات من الصَنْف VBox كما يَشيِع اِستخدَام حاويات عدد أعمدتها مُساوِي لعدد العُقد الأبناء (child nodes) داخلها، وتُشبِه في تلك الحالة الحاويات من الصَنْف HBox. عند عَرْض حاوية بحجمها المُفضَّل، يَكُون عَرْض جميع البلاطات (tiles) مُساوِيًا لأكبر عَرْض مُفضَّل لأي من أبنائها وبالمثل لارتفاع البلاطة. بالإضافة إلى ذلك، تُعيد الحاوية ضَبْط حجم كل ابن لكي يَملَئ البلاطة الخاصة به بالكامل بما هو مُتوافِق بالطبع مع القيمة العُظمى لعَرْض ذلك الابن وارتفاعه. يُوفِّر الصَنْف TilePane باني كائن (constructor) بدون أية مُعاملات (parameters) وباني آخر يَستقبِل قائمة مُكوَّنة من أي عدد من الأبناء المطلوب إضافتها للحاوية. تستطيع أيضًا إضافة أي أبناء آخرى لاحقًا باِستخدَام أي مما يلي: tpane.getChildren().add(child); tpane.getChildren().addAll(child1, child2, ...); قد تَستخدِم باني الكائن (constructor) التالي لتَخْصِيص حجم الفراغ الأفقي بين الأعمدة أو حجم الفراغ الرأسي بين الصفوف، وستَظهَر خلفية الحاوية بتلك المسافات الفارغة: TilePane tpane = new TilePane( hgapAmount, vgapAmount ); أو قد تُخصِّصها لاحقًا باستدعاء التوابع tpane.setHgap(h)‎ و tpane.setVgap(v)‎. ترجمة -بتصرّف- للقسم Section 5: Basic Layout من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

تَعلَّمنا خلال الأقسام السابقة كيف نَستخدِم سياقًا رُسوميًا (graphics context) للرَسْم على الشاشة كما تَعلَّمنا كيف نُعالِج كُلًا من أحداث الفأرة (mouse events) وأحداث لوحة المفاتيح (keyboard events). من ناحية، يُمثِل ذلك كل ما هو مُتعلِّق ببرمجة واجهات المُستخدِم الرسومية (GUI) في العموم، فإذا كنت تريد الآن برمجة الرسوم ومعالجة أحداث لوحة المفاتيح والفأرة، فليس هناك أي شيء آخر تحتاج لتَعلُّمه. من ناحية آخرى، فإنك وبهذه المرحلة ستَضطرّ إما للقيام بعَمَل أكبر بكثير مما ينبغي أو ستضطرّ لبرمجة واجهات مُستخدِم (user interfaces) بسيطة. في الواقع، عادةً ما تَتَكوَّن واجهات المُستخدِم التقليدية من مُكوِّنات واجهة قياسية كالأزرار وشرائط التمرير (scroll bars) وصناديق الإِدْخَال النصية والقوائم، ولقد كُتبَت بالفعل تلك المُكوِّنات بطريقة تُمكِّنها من رَسْم نفسها ومُعالجة أحداث لوحة المفاتيح والفأرة الخاصة بها لكي لا تَضطرّ لتَكْرار ذلك. على سبيل المثال، أحد أبسط مُكوِّنات واجهة المُستخدِم هو "زر الضَغْط (push button)". الزر مُحاط بإطار (border) ويَعرِض نصًا معينًا يُمكِن تَغْييره. في بعض الأحيان، يَكُون الزر مُعطَّلًا (disabled) أي غَيْر مُفعَّل وعندها لا يُصبِح للنقر عليه أي تأثير كما يختلف مظهره نوعًا ما. عندما يَنقُر المُستخدِم على الزر، فإن مظهره يَتَغيَّر لحظة الضَغْط عليه ثم يَعود لمظهره العادي لحظة تَحْرِيره. لاحِظ أنه في حالة تحريك مُؤشِر الفأرة إلى خارج الزر قبل تَحْريره، سيَعُود عندها إلى مظهره العادي بذات اللحظة، كما أن تَحْريره لن يُمثِل نقرة على الزر. لتَتَمكَّن من تّنْفيذ ما سبَق، فلابُدّ أن تستجيب إما لحَدَث سَحْب الفأرة أو لحَدَث خُروج الفأرة. علاوة على ذلك، قد يُصبِح الزر مَوضِع التركيز (focus) ببعض المنصات، وعندها يَتَغيَّر مظهره، ولو ضَغَطَ المُستخدِم على مسطرة المسافات (space bar) في تلك اللحظة، فستُعدّ تلك الضغطة بمثابة نقرة على الزر. لذا لابُدّ أن يستجيب الزر لكُلًا من أحداث لوحة المفاتيح (keyboard events) والتركيز (focus events). في الواقع، أنت لست مُضطرًا لبرمجة أي من ذلك بِفَرْض اِستخدَامك لكائن ينتمي إلى الصَنْف القياسي javafx.scene.control.Button. يَتولَّى كائن الزر من الصَنْف Button مسئولية رَسْم نفسه وكذلك مُعالجة كُلًا من أحداث التركيز والفأرة ولوحة المفاتيح. ستحتاج للتَعامُل مع ذاك الزر فقط عندما يَنقُر المُستخدِم عليه أو عندما يَضغَط على مسطرة المسافات (space bar) بينما هو موضع التركيز (focus). عندما يَحدُث ذلك، سيُنشَئ كائن حَدَث (event object) ينتمي إلى الصنف javafx.event.ActionEvent ثم سيُرسَل إلى أي مُستمِع (listener) مُسجَّل لتبلّيغه بأن هنالك من ضَغَطَ على الزر، وعليه، سيَحصُل برنامجك فقط على المعلومة التي يحتاجها وهي أن الزر قد ضُغِطَ عليه. تُعرِّف واجهة برمجة تطبيقات منصة جافا إف إكس لواجهات المُستخدِم الرسومية (JavaFX GUI API) العديد من مُكوِّنات التَحكُّم (controls) القياسية باستخدام أصناف فرعية (subclasses) من الصنف Control المُعرَّف بحزمة package javafx.scene.control. يستطيع مُستخدِم البرنامج أن يَتعامَل مع تلك المُكوِّنات مما يؤدي إلى إنتاج مُدْخَلات أو وقوع أحداث (events). تُعرِّف مُكوِّنات التَحكُّم (controls) العديد من التوابع المفيدة سنَستعرِض منها ثلاثة يُمكِن اِستخدَامها مع أي مُكوِّن تَحكُّم control من الصنف Control: control.setDisable(true)‎: يُعطِّل (disable) مُكوِّن التحكُّم ويُمكِنك استدعاء control.setDisable(false)‎ لتَفْعيله مرة آخرى. عندما يَكُون مُكوِّن التَحكُّم مُعطَّلًا (disabled)، يَتَغيَّر مظهره ولا يُمكِن له عندها أن يَكُون مقصدًا (event target) لأحداث المفاتيح أو الفأرة. في الواقع، لا يَقْتصِر استدعاء تلك الدالة (function) على مُكوِّنات التَحكُّم (controls) وإنما يُمكِن استدعائها لأي عقدة (node) بمبيان المشهد (scene graph). لاحِظ أنه عند تعطيل عُقدة (node) معينة، فإن جميع العُقد (nodes) المُضمَّنة داخل تلك العُقدة تُصبِح مُعطَّلة أيضًا. تَتَوفَّر الدالة control.isDisabled()‎ والتي تُعيد قيمة منطقية تُحدِّد ما إذا كان مُكوِّن تَحكُّم (control) معين مُعطَّلًا سواء كان ذلك نتيجة لطلب تعطيله صراحةً أو لكَوْنه مُضمَّن بعُقدَة (مُكوِّن حاوي [container]) كانت قد عُطِّلَت. control.setToolTipText(string)‎: يَستقبِل سِلسِلة نصية ويَضبُطها لتُصبِح تلميحًا (tooltip) لمُكوِّن التَحكُّم. عادةً ما يُعطِي ذلك التلميح (tooltip) بعضًا من المعلومات عن مُكوِّن التَحكُّم وطريقة اِستخدَامه ويَظهَر عندما يَقَع مؤشر الفأرة بالمُكوِّن ولا يتحرك لعدة ثواني. control.setStyle(cssString)‎: يَضبُط قواعد الأنماط لمُكوِّن التَحكُّم. تُكْتَب تلك القواعد بلغة أوراق الأنماط المتعاقبة (CSS) التي ناقشناها بالقسم الفرعي ٦.٢.٥. لكي تَستخدِم مُكوِّن تحكُّم (control) أو أي عقدة آخرى بمبيان المشهد (graph node)، تحتاج عمومًا للقيام بعدة خطوات: لابُدّ أولًا أن تُنشِئ الكائن المُمثِل للمُكوِّن باستخدام باني الكائن (constructor) ثم تُضيفه إلى مُكوِّن حَاوِي (container). غالبًا ما ستحتاج إلى تسجيل مُستمِع (listener) يستجيب إلى الأحداث (events) الصادرة من ذلك المُكوِّن. قد تُخزِّن مَرجِعًا (reference) إلى المُكوِّن بمُتْغيِّر نُسخة (instance variable) في بعض الحالات لكي تَتَمكَّن من إعادة اِستخدَام المُكوِّن بَعْد إنشائه. سنَفْحَص خلال هذا القسم عددًا قليلًا من مُكوِّنات التَحكُّم (controls) القياسية البسيطة المُتاحة بمنصة جافا إف إكس (JavaFX)، والمُعرَّفة باستخدام أصناف بحزمة javafx.scene.control. سنَتَعلَّم بالقسم التالي كيفية وَضْع مُكوِّنات التحكُّم تلك بمُكوِّنات حاوية (containers). ImageView قبل مناقشة مُكوِّنات التحكُّم (controls)، سنتناول سريعًا نوع عُقدَة (node) آخر هو ImageView مُعرَّف بحزمة javafx.scene.image. كما ذَكَرَنا سابقًا بالقسم الفرعي ٦.٢.٣، تُمثِل الكائنات من الصنف Image صورًا يُمكِن تحميلها من ملفات موارد (resource files)، ولأن كائنات الصَنْف Image لا تُعدّ عُقدًا من النوع Node، لا يُمكِن لها إذًا أن تَكُون جزءًا من مبيان المشهد (scene graph)، ولهذا سنَضطرّ لرسَمها على كائن حاوية من النوع Canvas. في الواقع، يَسمَح الصنف ImageView بإضافة صورة إلى مبيان مشهد دون الحاجة إلى رَسْمها على حاوية (canvas)، فكائناتها عبارة عن عُقدَ مبيان مشهد (scene graph node) يَعمَل كُلًا منها كمُغلِّف (wrapper) للصورة تمهيدًا لعَرْضها. تُخصَّص الصورة كمُعامِل (parameter) إلى باني الصَنْف ImageView. لنَفْترِض أن مسار ملف صورة معينة هو "icons/tux.png"، يُمكِننا إذًا أن نُنشِئ كائنًا من النوع ImageView لعَرْض الصورة كالتالي: Image tux = new Image("icons/tux.png"); ImageView tuxIcon = new ImageView( tux ); نحن هنا نفكر بالصورة كما لو كانت "أيقونة" أي كما لو كانت صورة صغيرة معروضة فوق زر أو ضمن عنوان نصي (label) أو بعنصر قائمة لإضافة لمسة رسومية إلى جانب النص البسيط المعروض، وهو في الواقع ما سنرى كيفية القيام به بمنصة جافا إف إكس (JavaFX). العناوين Label والأزرار Button سنَفْحَص الآن أربعة من مُكوِّنات التَحكُّم (controls) تتشارك جميعها في أنها تَعرِض سِلسِلة نصية للمُستخدِم يُمكِنه أن يراها لكن دون أن يُجرِي عليها أي تَعْدِيل كما يُمكِنها أيضًا أن تَعرِض عنصرًا رسوميًا (graphical element) إلى جوار تلك السِلسِلة النصية أو كبديل عنها. يُمكِن لأي كائن من النوع Node أن يُمثِل ذلك العنصر الرسومي، ولكن عادةً ما تُعرَض أيقونة صغيرة مُنفَّذة (implement) باستخدام كائن من النوع ImageView. تَرِث مُكوِّنات التحكُّم (controls) الأربعة سُلوكها (behavior) من صَنْف أعلى (superclass) مشترك هو الصنف Labeled. بالقسم الفرعي ٦.٦.٢، سنَفْحَص عناصر القوائم والتي تَرِث سلوكها من نفس الصَنْف. يُعرِّف الصنف Labeled عددًا من توابع النُسخ (instance methods) التي يُمكِننا أن نَستخدِمها مع العناوين النصية (labels) والأزرار وغيرها من مُكوِّنات التحكُّم المُعنونة، نَستعرِض بعضا منها فيما يلي: setText(string)‎: يَضبُط السِلسِلة النصية المعروضة بمُكوِّن التحكُّم، والتي قد تَتكوَّن من عدة أسطر. يدل محرف سطر جديد ‎\n بسِلسِلة نصية على نهاية السطر. setGraphic(node)‎: يَضبُط العنصر الرسومي (graphical element) لمُكوِّن التحكُّم. setFont(font)‎: يَضبُط الخط المُستخدَم لرسم السِلسِلة النصية. setTextFill(color)‎: يَضبُط لون الملء المُستخدَم لرسم السِلسِلة النصية. setGraphicTextGap(size)‎: يَضبُط عَرْض المسافة الفارغة بين كُلًا من السِلسِلة النصية والعنصر الرسومي. لاحظ أن المُعامِل size من النوع double. setContentDisplay(displayCode)‎: يَضبُط موقع العنصر الرسومي بالنسبة للسِلسِلة النصية. لاحظ أن قيمة المُعامِل ستَكُون واحدة من ثوابت التعداد ContentDisplay أي ContentDisplay.LEFT أو ContentDisplay.RIGHT أو ContentDisplay.TOP أو ContentDisplay.BOTTOM. يَتَوفَّر تابع جَلْب (getter methods) لكل تابع من توابع الضَبْط (setter methods) السابقة مثل getText()‎ و getFont()‎. يَتَوفَّر أيضًا تابع آخر لضَبْط خاصية لون الخلفية. بفَرْض أن c هو مُكوِّن تحكُّم (control)، يُمكِننا اِستخدَام الشيفرة التالية لضَبْط لون خلفيته إلى الأبيض: c.setBackground(new Background(new BackgroundFill(Color.WHITE,null,null))); حيث الأصناف Background و BackgroundFill مُعرَّفة بحزمة javafx.scene.layout. في الواقع، يُمكِنك القيام بنفس الشيء بطريقة أسهل باِستخدَام التابع setStyle()‎ لضَبْط قواعد أنماط CSS الخاصة بمُكوِّن التحكُّم (control)، ويُمكِنك أيضًا اِستخدَامها لضَبْط كُلًا من الإطار (border) والحشوة (padding). تُمثِل العناوين من الصَنْف Label أحد أبسط أنواع مُكوِّنات التحكُّم، فهو لا يُضيف أي شيء تقريبًا إلى الصنف Labeled، ويُستخدَم لعَرْض نص غَيْر قابل للتَعْدِيل مع رسمة أو بدون. يُعرِّف الصنف Label بانيين (constructors)، يَستقبِل الأول مُعامِلًا من النوع String يُحدِّد نصًا للعنوان (label) أما الثاني فيَستقبِل مُعامِلًا إضافيًا من النوع Node يُحدِّد رسمة (graphic) للعنوان. بفَرْض أن tuxIcon هو كائن من النوع ImageView من القسم الفرعي السابق، اُنظر المثال التالي: Label message = new Label("Hello World"); Label linuxAd = new Label("Choose Linux First!", tuxIcon); لاحِظ أن خلفية العناوين (labels) من النوع Label تَكُون شفافة وبدون إطار (border) أو حشوة (padding) افتراضيًا. غالبًا يُفضَّل إضافة قليل من الحشوة على الأقل. اُنظر المثال التالي لضَبْط الخاصيات الثلاثة باِستخدَام لغة CSS: message.setStyle("-fx-border-color: blue; -fx-border-width: 2px; " + "-fx-background-color: white; -fx-padding: 6px"); لقد تَعرَّضنا للأزرار بالقسم ٦.١. تَعرِض الأزرار من الصنف Button نصًا مع رسمة أو بدون. يُعرِّف الصَنْف Button بانيين (constructors) تمامًا مثل الصَنْف Label: Button stopButton = new Button("Stop"); Button linuxButton = new Button("Get Linux", tuxIcon); عندما يَضغَط المُستخدِم على زر، يَقَع حَدَث (event) من النوع ActionEvent، ويُستخدَم التابع setOnAction لتسجيل مُعالِج حدث (event handler) كالتالي: stopButton.setOnAction( e -> animator.stop() ); بالإضافة إلى التوابع (methods) الموروثة من الصَنْف Labeled، يُعرِّف الصنف Button توابع نُسخ (instance methods) آخرى مثل setDisable(boolean)‎ و setToolTip(string)‎ والتي ذَكَرناها ببداية هذا القسم. يُمكِننا أيضًا اِستخدَام التابعين setDisable()‎ و setText()‎ لإعطاء المُستخدِم بعض المعلومات عما يَحدُث بالبرنامج. اِستخدَامك لزر مُعطَّل (disabled) هو أفضل عمومًا من اِستخدَامك لزر يُعطِي رسالة خطأ مثل "عذرًا، لا يُمكِنك الضَغْط على الزر الآن" بَعْد الضَغْط عليه. لنَفْترِض مثلًا أن لدينا زرين لتَشْغِيل تحريكة (animation) مُمثَلة بالكائن animator من الصَنْف AnimationTimer وإيقافها، فينبغي تَعْطيل زر بدء التَشْغِيل عندما تَكُون التحريكة مُشغَّلة أما زر الإيقاف فينبغي أن يُعطَّل عندما تَكُون التحريكة مُتوقِّفة مؤقتًا. اُنظر الشيفرة التالية: Button startButton = new Button("Run Animation"); Button stopButton = new Button("Stop Animation"); stopButton.setDisable(true); // Stop button is initially disabled. startButton.setOnAction( e -> { animator.start(); startButton.setDisable(true); stopButton.setDisable(false); } ); stopButton.setOnAction( e -> { animator.stop(); startButton.setDisable(false); stopButton.setDisable(true); } ); تتأكَّد الشيفرة بالأعلى من أن المُستخدِم لا يُمكِنه أن يحاول بدء تَشْغِيل تحريكة (animation) بينما هي مُشغَّلة بالفعل أو إيقافها عندما تَكُون مُتوقِّفة. غالبًا ما يُوفِّر البرنامج زرًا يؤدي لحُدوث فِعل (action) افتراضي معين. فمثلًا، قد يُدخِل المُستخدِم مجموعة بيانات بصناديق إِدْخَال نصية ثم يَنقُر على زر "Compute" لمعالجة تلك البيانات. سيَكُون من الرائع لو تَمكَّن المُستخدِم من مُجرّد الضغط على المفتاح "Return" عند انتهاءه من الكتابة بدلًا من النقر على الزر. في الحقيقة، يُمكِنك ضَبْط الكائن button من الصَنْف Button ليُصبِح زر النافذة الافتراضي (default button) باستدعاء التالي: button.setDefaultButton(true); في حالة وجود زر افتراضي (default button) بنافذة (window) معينة، فإن الضَغْط على المفتاح "Return" أو "Enter" بلوحة المفاتيح يَكُون مكافئًا للنقر على ذلك الزر الافتراضي إلا لو اُستُهلِك حَدَث (event) الضَغْط عليه من قِبَل مُكوِّن آخر. مربعات الاختيار CheckBox وأزرار الانتقاء RadioButton مربعات الاختيار (check box) من الصَنْف CheckBox هي نوع آخر من مُكوِّنات التَحكُّم. أي مربع اختيار له "حالة (state)"، فإما أن يَكُون مختارًا (selected) أو غَيْر مُختار (unselected)، ويستطيع المُستخدِم عمومًا أن يُغيِّر حالة مربع اختيار (check box) معين بالنقر عليه. تُستخدَم قيمة من النوع boolean لتمثيل حالة مربع الاختيار بحيث تَكُون مُساوية للقيمة المنطقية true إذا كان مختارًا (selected) وللقيمة المنطقية false إذا كان غَيْر مُختار. علاوة على ذلك، يَعرِض أي مربع اختيار (checkbox) عنوانًا (label) يُخصَّص عند إنشائه كالتالي: CheckBox showTime = new CheckBox("Show Current Time"); لأن الصَنْف CheckBox هو صَنْف فرعي (subclass) من الصَنْف Labeled، يُمكِنك بطبيعة الحال اِستخدَام جميع توابع النُسخ (instance methods) المُعرَّفة بالصَنْف Labeled مع كائنات مربعات الاختيار (checkboxes). بالمثل من مُكوِّنات التَحكُّم السابقة (controls)، يُمكِن لمربعات الاختيار أن تَعرِض رسمة (graphic)، ولكنها لا تُوفِّر باني (constructor) لضَبْط تلك الرسمة وإنما لابُدّ من استدعاء setGraphic(node)‎ لضَبْطها. عادةً ما يَكُون المُستخدِم هو المسئول عن ضَبْط حالة مربع اختيار من الصَنْف CheckBox بالنقر عليه، ولكن من الممكن أيضًا ضَبْط حالته (state) برمجيًا باستدعاء التابع setSelected(boolean)‎. على سبيل المثال، إذا كان لديك كائن مربع اختيار showTime من الصَنْف CheckBox، فبإمكانك اختياره (selected) باستدعاء showTime.setSelected(true)‎ أو إلغاء الاختيار باستدعاء showTime.setSelected(false)‎. يَتَوفَّر أيضًا التابع isSelected()‎ والذي يُعيد قيمة منطقية من النوع boolean تُحدِّد الحالة (state) الحالية لمربع الاختيار. عندما يُغيِّر مُستخدِم من حالة (state) مربع اختيار (checkbox) من الصَنْف CheckBox، يَقَع حَدَث (event) من النوع ActionEvent، لذا إذا أردت أن تُنفِّذ شيئًا أثناء تَغيُّر حالة مربع اختيار معين، فلابُدّ إذًا من أن تُسجِّل معالجًا (handler) بذلك المربع عن طريق استدعاء تابعه setOnAction()‎. ولكن في العادة، لا تحتاج البرامج لذلك وتَقْتصِر على فَحْص حالة مربعات الاختيار باستدعاء التابع isSelected()‎. لاحِظ أنه في حالة تَغيُّر الحالة برمجيًا أي باستدعاء التابع setSelected()‎، لا يَقَع حَدَث من النوع ActionEvent، ولكن هنالك تابع آخر مُعرَّف بالصنف CheckBox اسمه هو fire()‎، والذي يُحاكِي حُدوث نقرة على مربع الاختيار ويُولِّد حَدَثًا من النوع ActionEvent. في الواقع، هنالك حالة ثالثة لمربعات الاختيار (checkboxes): "غير مُحدَّد (indeterminate)" على الرغم من كَوْنها غَيْر مُفعَّلة افتراضيًا. اُنظر توثيق واجهة برمجة التطبيقات (API) لمزيد من التفاصيل. تتشابه أزرار الانتقاء (radio buttons) مع مربعات الاختيار (check boxes) نوعًا ما. كما هو الحال مع مربعات الاختيار، يُمكِن لأي زر انتقاء أن يَكُون مُختارًا (selected) أو غَيْر مُختار. يُفْترَض لأزرار الانتقاء (radio buttons) أن تَقَع ضِمْن مجموعات، ويُسمَح باختيار زر انتقاء وحيد على الأكثر ضِمْن المجموعة بأي لحظة، بتعبير آخر، تَسمَح مجموعات أزرار الانتقاء للمُستخدِم باختيار وحيد من عدة بدائل. تُستخدَم كائنات الصَنْف RadioButton بمنصة جافا إف إكس لتمثيل أزرار الانتقاء (radio button). عند اِستخدَامها بمفردها، فإنها تكون شبيهة تمامًا بمربع اختيار من الصَنْف CheckBox، فلديها نفس الباني (constructor)، والتوابع (methods)، والأحداث (events) بما في ذلك التوابع الموروثة من الصنف Labeled. لكنها غالبًا ما تُستخدَم ضِمْن مجموعة، ويُستخدَم عندها كائن من الصنف ToggleGroup لتمثيل المجموعة. لاحِظ أن الصنف ToggleGroup ليس بمُكوِّن ولا يظهر على الشاشة، فهو يعمل فقط خلف الكواليس كمُنظم لمجموعة من أزرار الانتقاء (radio buttons) ليتأكَّد من اختيار زر واحد فقط ضِمْن المجموعة بأي لحظة. لكي تَستخدِم مجموعة أزرار انتقاء (radio buttons)، لابُدّ أن تُنشِئ كائنًا من الصَنْف RadioButton لكل زر انتقاء ضِمْن المجموعة بالإضافة إلى كائن واحد من النوع ToggleGroup لتنظيمها. لا يلعب الصنف ToggleGroup أي دور فيما يتعلَّق برسم الأزرار على الشاشة، فلابُدّ أن تُضيف كُلًا منها على حدى إلى مبيان المشهد (scene graph) لكي يَظهَر على الشاشة. لابُدّ أيضًا أن تُضيف كُلًا منها إلى كائن الصنف ToggleGroup من خلال استدعاء تابع النُسخة setToggleGroup(group)‎ بكائن زر الانتقاء. إذا أردت اختيار أحد الأزرار بصورة افتراضية، يُمكِنك استدعاء التابع setSelected(true)‎ لذلك الزر، وإن لم تَفعَل، فلن يَكُون أيًا منها مُختارًا (selected) إلى أن يَنقُر المُستخدِم على إحداها. على سبيل المثال، تَستعرِض الشيفرة التالية طريقة تهيئة مجموعة من أزرار الانتقاء (radio buttons) التي تَسمَح للمُستخدِم باختيار لون: RadioButton redRadio, blueRadio, greenRadio, yellowRadio; // تمثل المتغيرات أزرار انتقاء // قد تكون تلك متغيرات نسخة لكي تستخدم عبر البرنامج ToggleGroup colorGroup = new ToggleGroup(); redRadio = new RadioButton("Red"); // اِنشئ زر redRadio.setToggleGroup(colorGroup); // أضفه إلى مجموعة الأزرار blueRadio = new RadioButton("Blue"); blueRadio.setToggleGroup(colorGroup); greenRadio = new RadioButton("Green"); greenRadio.setToggleGroup(colorGroup); yellowRadio = new RadioButton("Yellow"); yellowRadio.setToggleGroup(colorGroup); redRadio.setSelected(true); // Make an initial selection. بدلًا من استدعاء التابع redRadio.setSelected(true)‎، يُمكِنك أن تَستدعِي تابع النسخة selectToggle()‎ المُعرَّف بالصَنْف ToggleGroup لاختيار زر الانتقاء (radio button) كالتالي: colorGroup.selectToggle( redRadio ); تمامًا كمربعات الاختيار (checkboxes)، لست مضطرًّا إلى أن تُسجِّل مُستمِعًا (listener) لأحداث أزرار الانتقاء (radio buttons). يُمكِنك فَحْص حالة (state) زر انتقاء معين من الصَنْف RadioButton باستدعاء تابعه isSelected()‎ أو باستدعاء التابع getSelectedToggle()‎ بكائن المجموعة من الصَنْف ToggleGroup. يُعيد ذلك التابع قيمة نوعها Toggle عبارة عن واجهة (interface) يُنفِّذها (implement) الصَنْف RadioButton. اُنظر المثال التالي: Toggle selection = colorGroup.getSelectedToggle(); if (selection == redRadio) { color = Color.RED; } else if (selection == greenRadio){ . . . تُوضِح الصورة التالية كيف ستبدو أزرار الانتقاء (radio buttons) بالأعلى عند اصطفافها رأسيًا ضِمْن مُكوِّن حاوية (container): الحقول النصية TextField والمساحات النصية TextArea يُمثِل الصنفان TextField و TextArea مُكوِّنات إِدْخَال نصي (text input component) حيث تَعرِض نصًا يستطيع المُستخدِم أن يُعدّله. يُمكِن لأي حقل نصي من الصنف TextField أن يَحمِل سطرًا واحدًا فقط أما المساحة النصية من الصَنْف TextArea فيُمكِنها أن تَحمِل عدة أسطر. تستطيع أن تضبط حقلًا نصيًا TextField معينًا أو مساحة نصية TextArea معينة بحيث تَكُون للقراءة فقط (read-only) أي سيَتَمكَّن المُستخدِم عندها من قراءة النص الموجود لكنه لن يَتَمكَّن من تَعْديله. في الواقع، الأصناف TextField و TextArea هي أصناف فرعية (subclasses) من صَنْف مُجرّد (abstract class) اسمه TextInputControl يُعرِّف بعضًا من الخاصيات المشتركة بينها. يشترك الصَنْفان TextField و TextArea بكثير من التوابع (methods) سنَستعرِض بعضًا منها فيما يلي: يُعيد تابع النُسخة getText() قيمة من النوع String تُمثِل محتويات مُكوِّن إِدْخَال معين. يُستخدَم تابع النسخة setText(text) لتَغْيير النص المعروض بمُكوِّن إِدْخَال حيث يَستقبِل مُعامِلًا من النوع String ويستبدله بالنص الحالي لمُكوِّن الإدخال. يُستخدَم تابع النسخة appendText(text)‎ لإضافة سِلسِلة نصية من النوع String بنهاية النص الموجود بالفعل بمُكوِّن إِدْخَال. قد يَتَضمَّن النص المُمرَّر إلى التابعين setText()‎ و appendText()‎ محرف سطر جديد ‎\n لتمثيل نهاية السطر، ولكنه لن يُؤثِر بالحقول النصية من الصَنْف TextField. يُمكِنك أيضًا أن تَستخدِم تابع النسخة setFont(font)‎ لتَغْيير الخط المُستخدَم بمُكوِّن الإدخال النصي. يُمكِنك أيضًا استدعاء التابع setEditable(false)‎ لمَنْع المُستخدِم من تَعْدِيل نص مُكوِّن إِدْخَال معين. مَرِّر القيمة المنطقية true لنفس التابع لكي تجعله قابل للتَعْدِيل مرة آخرى. يستطيع المُستخدِم أن يَكْتُب بمُكوِّن إِدْخَال نصي (input component) معين فقط بَعْد جَعَله موضع التركيز (focus) عن طريق النقر عليه بالفأرة. يُمكِنك أيضًا استدعاء التابع requestFocus()‎ لمُكوِّن إِدْخَال -مثل الحقول النصية (text fields)- لضبطه برمجيًا ليُصبِح موضع التركيز (focus)، وهو ما قد يَكُون مفيدًا في بعض الأحيان. يستطيع المُستخدِم أيضًا أن يُحدِّد جزءًا من نص مُكوِّن إدخال ويَظهَر عندها مُظلَّلًا ويُمكِن قَصُه (cut) أو نَسخُه (copy) كما يَتَضمَّن الصَنْف TextInputComponent مجموعة من توابع النسخ (instance methods) لأغراض تَحْدِيد النصوص (text selection) منها التابع selectAll()‎ والذي يُحدِّد نص مُكوِّن إِدْخَال بأكمله. على سبيل المثال، عندما تَكْتشِف وجود خطأ بالقيمة التي أَدْخَلها المُستخدِم بحَقْل نصي input من الصَنْف TextField، يُمكِنك عندها أن تَستدعِي كُلًا من التابعين input.requestFocus()‎ و input.selectAll()‎، وهو ما يُساعِد المُستخدِم على اكتشاف مكان حُدوث الخطأ كما يَسمَح له ببدء تصحيحه مباشرة؛ فبمُجرّد أن يبدأ بالكتابة، سيُحذَف النص المُظلَّل. يُعرِّف الصَنْفين TextField و TextArea بانيين (constructors). لا يَستقبِل الباني الأول أي مُعامِلات (parameter) ويُستخدَم لإنشاء مُكوِّن إِدْخَال نصي فارغ أما الثاني فيَستقبِل مُعامِلًا من النوع String يُخصِّص نصًا افتراضيًا لمُكوِّن الإِدْخَال. تملك الحقول النصية من الصَنْف TextField خاصية عدد الأعمدة (columns)، والتي تُخصِّص العرض (width) المُفضّل للحقل، وتُساوِي ١٢ بشكل افتراضي. تُستخدَم تلك القيمة المُفضّلة لضَبْط حجم الحقل إذا لم يُعاد ضَبْطه بواسطة البرنامج على سبيل المثال. بفَرْض وجود كائن حقل نصي input من الصَنْف TextField، يُمكِنك استدعاء التابع input.setPrefColumnCount(n)‎ لضَبْط عدد الأعمدة حيث n هي عدد صحيح موجب. على نحو مُشابه، تَملُك المساحات النصية من الصَنْف TextArea عدد أعمدة يُساوِي ٤٠ افتراضيًا وكذلك عدد صفوف يُساوِي ١٠ افتراضيًا. يُستخدَم تابعي النسخة setPrefColumnCount(n)‎ و setPrefRowCount(n)‎ بالصَنْف TextArea لتَعْدِيل قيمتهما على الترتيب. إلى جانب التوابع (methods) الموروثة (inherit) من الصَنْف TextInputControl، يُعرِّف الصَنْف TextArea عدة توابع آخرى بما في ذلك تابع لضَبْط مقدار المسافة التي نزلها النص، وآخر لجَلْب ذلك المقدار. مثال آخر هو التابع setWrapText(wrap)‎ حيث wrap هو مُعامِل من النوع boolean. يُخصِّص ذلك التابع طريقة عَرْض الأسطر النصية الطويلة التي لا تَتَناسَب مع حجم المساحة النصية (text area). إذا مرَّرنا true كقيمة للمُعامِل wrap، فإنها ستُقسَّم إلى عدة أسطر مع إضافة محرف سطر جديد بين الكلمات إن أمكن. أما إذا مرَّرنا القيمة false، فإنها ستمتد إلى خارج المساحة النصية وسيضطرّ المُستخدِم إلى تمرير المساحة النصية أفقيًا (scroll) ليرى محتوى السطر بالكامل. لاحِظ أن قيمة wrap الافتراضية هي false. لمّا كانت الحاجة لتَحرِيك مساحة نصية (text area) من الصَنْف TextArea أفقيًا (scroll) ضرورية في أحيان كثيرة لكي نَتَمكَّن من رؤية مُحتواها النصي بالكامل، فإن ذلك الصَنْف يُوفِّر شرائط تمرير (scroll bars) تُصبِح مرئية عند الضرورة فقط أي عندما لا يَتَناسَب النص مع المساحة المتاحة. يُمكِنك الإطلاع على ملف البرنامج TextInputDemo.java والذي يُوظِّف حقلًا نصيًا (text field) ومساحة نصية (text area) ضِمْن مثال بسيط. تُبيِّن الصورة التالية نافذة البرنامج بَعْد تَعْدِيل النص وتمريره للأسفل قليلًا: المنزلق Slider يَسمَح مُنزلِق (slider) من الصَنْف Slider للمُستخدِم باختيار قيمة عددية صحيحة ضِمْن نطاق من القيم المُحتملة عن طريق سَحْب عُقدة على طول شريط. يُمكِنك تَزْيِين المُنزلِق بعلامات تجزئة (tick marks) أو بعناوين (labels). تَعرِض نافذة البرنامج SliderDemo.java بالأسفل ثلاثة مُنزلِقات يَسمَح كُلًا منها بنطاق مُختلف من القيم كما أنها مُزيَّنة بشكل مختلف: اُستخدِمت علامات تجزئة لتَزْيِين المُنزلِق الثاني بينما اُستخدِمت عناوين لتَزْيِين المُنزلِق الثالث. يُمكِنك أيضًا تَزْيِين مُنزلِق واحد بكلتا الطريقتين معًا. يُخصِّص الباني (constructor) الأكثر شيوعًا بالصَنْف Slider بداية ونهاية نطاق القيم المُحتملة للمُنزلِق (slider) وكذلك قيمته الافتراضية عند عَرْضه على الشاشة لأول مرة. يُكْتَب ذلك الباني كالتالي: public Slider(double minimum, double maximum, double value) إذا لم نُمرِّر أي مُعامِل (parameter) للباني، ستُستخدَم القيم ٠ و ١٠٠ و ٠ افتراضيًا وعلى الترتيب. يَظهَر المُنزلِق أفقيًا بصورة افتراضية، ولكن يُمكِنك استدعاء setOrientation(Orientation.VERTICAL)‎ لضَبْطه بحيث يَظهَر رأسيًا. لاحِظ أن Orientation عبارة عن تعداد مُعرَّف بحزمة package javafx.geometry. يُمكِنك قراءة القيمة الحالية لمُنزلِق (slider) من الصَنْف Slider بأي لحظة باستدعاء تابعه getValue()‎ والذي يُعيد قيمة من النوع double. أما إذا أردت ضَبْط قيمته، فيُمكِنك استدعاء التابع setValue(val)‎ والذي يَستقبِل مُعاملًا (parameter) من النوع double. إذا كانت القيمة المُمرَّرة لتابع الضَبْط واقعة خارج نطاق القيم المسموح بها، فإنها ستُعدَّل لكي تُصبِح ضِمْن ذلك النطاق. إذا أردت أن تُنفِّذ شيئًا عندما يُغيِّر المُستخدِم قيمة مُنزلِق (slider) معين، فينبغي أن تُسجِّل مُستمِعًا (listener) بذلك المُنزِلق. بخلاف مُكوِّنات التَحكُّم الآخرى، لا تُولِّد المنزلِقات من الصَنْف Slider أحداثًا من النوع ActionEvent، وإنما تَملُك خاصية قابلة للمُراقبة (observable) من النوع Double تُمثِل قيمته (انظر القيم الفرعي ٦.٣.٧). بفَرْض وجود كائن مُنزلِق slider من الصَنْف Slider، يُمكِنك استدعاء التابع slider.valueProperty()‎ لمَعرِفة قيمته. يُمكِنك أيضًا أن تُسجِّل مُستمِعًا (listener) لتلك الخاصية سيُستدعَى بكل مرة تَتَغيَّر فيها قيمة المُنزلِق. تُبيِّن الشيفرة التالية كيفية إضافة مُستمِع (listener) لكائن مُنزلِق: slider1.valueProperty().addListener( e -> sliderValueChanged(slider1) ); سيُستدعَى ذلك المُستمِع (listener) كلما تَغيَّرت قيمة المُنزلِق سواء كان ذلك نتيجة لسَحْب العقدة على الشريط أو لاستدعاء البرنامج للتابع setValue()‎. يُمكِنك استدعاء التابع isValueChanging()‎ المُعرَّف بكائن المُنزلِق لمَعرِفة ما إذا كان المُستخدِم هو المسئول عن وقوع الحَدَث (event) حيث يُعيد ذلك التابع القيمة المنطقية true إذا كان المُستخدِم يَسحَب العقدة على الشريط. لعرض علامات التجزئة (tick marks) على مُنزلِق (slider)، ستحتاج للقيام بالخطوتين التاليتين: اُضبط أولًا الفاصل بين علامات التجزئة (tick marks) ثم بلِّغ المُنزلِق برغبتك بعَرْض علامات التجزئة. في الحقيقة، هنالك نوعين من علامات التجزئة: علامات تجزئة رئيسية (major) وأخرى ثانوية (minor)، ويُمكِنك عَرْْض واحدة منهما فقط أو كلتاهما. علامات التجزئة الرئيسية تَكُون أطول قليلًا بالمُوازنة مع علامات التجزئة الثانوية. يَستقبِل التابع setMajorTickSpacing(x)‎ مُعامِلًا من النوع double ويُشير إلى أن علامات التجزئة الرئيسية ينبغي أن تُعرَض بفارق x من الوحدات على طول المُنزلِق. لاحِظ أن الفاصل بين تلك العلامات يَكُون على أساس قيم المُنزلِق وليس البكسل. في المقابل، يَستقبِل التابع setMinorTickCount(n)‎ مُعامِلًا من النوع int، ويُخصِّص عدد علامات التجزئة الثانوية المُفْترَض عَرْضها بين كل علامتين رئيسيتين متتاليتين وتُساوِي ٤ افتراضيًا. يُمكِنك ضَبْطها إلى صفر إذا لم ترغب بعَرْض أي علامات تجزئة ثانوية. لاحِظ أن استدعاء تلك التوابع (methods) ليس كافيًا لعَرْض علامات التجزئة (tick marks)، بل ستحتاج أيضًا إلى استدعاء setShowTickMarks(true)‎. على سبيل المثال، تُنشِئ التَعْليمَات التالية المُنزلِق (slider) الثاني من البرنامج السابق وتَضبُطه: slider2 = new Slider(); // استخدم القيم الافتراضية ‫(0,100,0) slider2.setMajorTickUnit(25); // المسافة بين علامات التجزئة الرئيسية slider2.setMinorTickCount(5); // ‫5 علامات تجزئة بين كل علامتي تجزئة slider2.setShowTickMarks(true); تُعالَج العناوين (labels) على المنزلق (slider) بنفس الطريقة، فسيُعرَض العنوان بكل علامة تجزئة رئيسية، ولكن قد تُحذَف بعض العناوين إذا تداخلت مع بعضها البعض. ستحتاج إلى استدعاء setShowTickLabels(true)‎ لعَرْض العناوين. على سبيل المثال، تُنشِئ التَعْليمَات التالية المُنزلِق (slider) الثالث من البرنامج السابق وتَضبُطه: slider3 = new Slider(2000,2100,2018); slider3.setMajorTickUnit(50); // لا تعرض علامات التجزئة slider3.setShowTickLabels(true) لاحِظ أن قيمة أي مُنزلِق (slider) تَكُون من النوع double. أحيانا، قد تَرغَب بقَصرِها على الأعداد الصحيحة فقط أو على مضاعفات قيمة معينة. في مثل هذه الحالات، يُمكِنك استدعاء التابع slider.setSnapToTicks(true)‎، وعندها ستُضبَط قيمة المُنزلِق تلقائيًا إلى أقرب علامة تجزئة رئيسية أو ثانوية -حتى لو لم تَكُن مرئية- بعدما ينتهي المُستخدِم من سَحْب العُقدَة. لا يُطبَق ذلك التقييد بينما يسَحَب المُستخدِم العُقدَة وإنما تُضبَط قيمته فقط بَعْد انتهائه. لا يَلتزِم أيضًا التابع setValue(x)‎ بتلك القيود، لذا قد تَستخدِم التابع adjustValue(x)‎ بدلًا عنه والذي يَضبُط قيمة المُنزِلق لأقرب علامة تجزئة. على سبيل المثال، إذا أردت لمُنزلِق أن يَقْتصِر على الأعداد الصحيحة بنطاق يتراوح من ٠ إلى ١٠، يُمكِنك اِستخدَام التالي: Slider sldr = new Slider(0,10,0); sldr.setMajorTickUnit(1); // major ticks 1 unit apart sldr.setMinorTickCount(0); // لا توجد علامة تجزئة ثانوية sldr.setSnapToTicks(true); ضُبِطَ المُنزلِق الثالث بالمثال التوضيحي بحيث يَقْتصِر على قيمة صحيحة بنهاية أي عملية سَحْب. ترجمة -بتصرّف- للقسم Section 4: Basic Controls من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

تعتمد برمجة واجهات المُستخدِم الرسومية (graphical user interface) اعتمادًا رئيسيًا على ما يُعرَف باسم الأحداث (events). بخلاف برامج الطرفية، لا تَحتوِي برامج واجهة المُستخدِم الرسومية (GUI) على البرنامج main()‎ الذي اعتدنا اِستخدَامه لوَصْف ما ينبغي للبرنامج القيام به منذ لحظة تَشْغِيله خطوة بخطوة وحتى انتهائه، وإنما لابُدّ من إعداد برامج الواجهة بحيث تَتَمكَّن من الاستجابة إلى الأنواع المختلفة من الأحداث (events) التي يُمكِنها أن تَقَع بأوقات غَيْر مُتوقعة وبترتيب لا يُمكِن التَحكُّم به. تَقَع مثلًا بعض من أبسط أنواع الأحداث نتيجة لاِستخدَام الفأرة أو لوحة المفاتيح مثل أن يَضغَط المُستخدِم على مفتاح بلوحة المفاتيح أو يُحرِك الفأرة أو يَضغَط على أحد أزرار الفأرة. يستطيع المُستخدِم عمومًا أن يقوم بأي من تلك الأمور بأي لحظة ولابُدّ للحاسوب عندها من أن يستجيب بشكل مناسب. تُمثَل الأحداث (events) بالجافا باِستخدَام كائنات (objects)، فعندما يَقَع حَدَث معين، يُجمّع النظام كل المعلومات المُرتبِطة بذلك الحَدَث (event) ثم يُنشِئ كائنًا يَتَضمَّن تلك المعلومات. تَتَوفَّر أصناف (classes) مختلفة لتمثيل الأنواع المختلفة من الأحداث، فمثلًا، يُنشَئ كائن ينتمي للصَنْف MouseEvent عندما يَضغَط المُستخدِم على أحد أزرار الفأرة بينما يُنشَئ كائن ينتمي للصنف KeyEvent عندما يَضغَط المُستخدِم على مفتاح بلوحة المفاتيح. في حين يَحتوِي الكائن الأول على المعلومات المُتعلِّقة بحَدَث الضغط على زر الفأرة والتي تُجيب عن أسئلة مثل: أي مُكوِّن واجهة نَقر عليه المُستخدِم بالتحديد ويُعرَف ذلك المُكوِّن باسم مقصد الحَدَث (target event)؟ أي نقطة (x,y) ضِمْن المُكوِّن قد نقر عليها بالتحديد؟ هل ضَغَطَ على أحد مفاتيح التباديل (modifier keys) كالمفتاح "shift"؟ أي مفتاح تحديدًا بالفأرة ضَغَطَ عليه؟ في المقابل، يَحتوِي الكائن الآخر على المعلومات المُتعلِّقة بحَدَث الضغط على مفتاح بلوحة المفاتيح. تُمرَّر تلك الكائنات المُنشَئة كمُعامِل (parameter) إلى تابع (method) يُعرَف باسم مُعالِج الحَدَث (event handler) ويُكتَب عادةً بهيئة تعبير لامدا (lambda expressions) بمنصة جافا إف إكس (JavaFX). تُعدّ كتابة مُعالِجات الأحداث (event handler) بمثابة تبلّيغ للحاسوب بما ينبغي له القيام به عند وقوع تلك الأحداث. ينبغي لأي مبرمج جافا أن يَكُون على إطلاع بماهية الأحداث (events) في العموم. تَقَع كثير من الأمور منذ لحظة وقوع حَدَث (event) معين كضَغْط المُستخدِم على مفتاح معين أو كتحريكه للفأرة وحتى لحظة استدعاء التابع (method) الذي يُفْترَض له أن يَستجِيب لذلك الحَدَث. في الواقع، أنت لا تحتاج لمَعرِفة ذلك تفصيليًا، وإنما ينبغي فقط أن تفهم التالي: أثناء زمن التَشْغِيل، هُنالك برنامج (routine) بمكان ما يُنفِّذ حَلْقة التَكْرار (loop) التالية: // بينما البرنامج قيد التنفيذ while the program is still running: // انتظر إلى أن يحين موعد الحدث التالي Wait for the next event to occur // عالج الحدث Handle the event تُسمَى تلك الحَلْقة بحَلْقة الأحداث (event loop)، والتي لابُدّ لأي برنامج واجهة مُستخدِم رسومية (GUI program) من أن يُنفِّذها. لا تحتاج لكتابة تلك الحَلْقة بنفسك ببرامج الواجهة بلغة الجافا لأنها تُعدّ بالفعل جزءًا من النظام، ولكن قد تَضطرّ لذلك بلغة برمجية آخرى. سنَفْحَص خلال هذا القسم كيفية معالجة حَدَثي الفأرة (mouse event) والمفتاح (key event) بلغة الجافا كما سنُغطِي إِطار عمل معالجة الأحداث (handling events) في العموم. وأخيرًا، سنرى طريقة إنشاء تَحرِيكة (animation). معالجة الأحداث لكي يُصبِح لحَدَث (event) معين تأثير ضِمْن برنامج، فلابُدّ لذلك البرنامج من أن يَستمِع (listen) إلى ذاك الحَدَث (event) حتى يَتَمكَّن من رصده، ومِن ثَمَّ الإستجابة إليه. تُوكَل مُهِمّة الاستماع إلى الأحداث إلى ما يُعرَف باسم مُستمِع الحَدَث (event listener)، والذي يُعرَّف باِستخدَام واجهة (interface) تَصِف توابع مُعالجات الأحداث (event handler methods) الخاصة به والتي تَكُون مسئولة بشكل فعليّ عن الاستجابة على تلك الأحداث. غالبًا ما تُعرِّف تلك الواجهات (interface) تابع مُعالج حَدَث (event handler method) وحيد فيما يُعرَف باسم واجهات نوع الدالة (functional interface)، وفي تلك الحالة، قد يُخصَّص المُستمِع (listener) بهيئة تعبير لامدا (lambda expression). تُستخدَم واجهات (interfaces) مختلفة لتعريف مُستمعِي الأحداث (events) من الأصناف المختلفة. يُعرَّف مُستمِع الحدث (event listener) لغالبية الأحداث بمنصة جافا إف إكس (JavaFX) باِستخدَام واجهة نوع الدالة EventHandler. تُعرِّف تلك الواجهة التابع handle(event)‎ والذي يَستقبِل كائن حَدَث (event object) من الصنف Event يتضمن معلومات عن ذلك الحدث. عندما تُوفِّر تعريفًا (definition) للتابع handle()‎، فأنت تَكْتُب الشيفرة التي ستُنفَّذ لمعالجة الحدث. في الواقع، الصَنْف EventHandler هو نوع مُعمَّم أو نوع مُحدَّد بمُعامِلات نوع (parameterized type) أي يُعرِّف عدة أنواع مختلفة: EventHandler<MouseEvent>‎ و EventHandler<KeyEvent>‎ و EventHandler<ActionEvent>‎. في حين يُعرِّف النوعان EventHandler<MouseEvent>‎ و EventHandler<KeyEvent>‎ التابع handle(event)‎، فإن مُعامِل ذلك التابع event يَكُون من الصنف MouseEvent بالنوع الأول ومن الصنف KeyEvent بالثاني. في الحقيقة، نحن لم ولن نَتعرَض للأنواع المُعمَّمة (parameterized types) حتى القسم ٧.٣، ولا حاجة لذلك عمومًا فيما هو مُتعلِّق بهذا الفصل، فكل ما أنت بحاجة لمَعرِفته هو فكرة أن كائن الحَدَث (event object) المُستخدَم للمعالجة دائمًا ما سيتناسب مع ذلك الحَدَث، فمثلًا، يَكُون كائن الحَدَث من النوع MouseEvent عند معالجة حَدَث فأرة. تَرتَبِط غالبية الأحداث (events) بمنصة جافا إف إكس (JavaFX) بإحدى مُكوِّنات واجهة المُستخدِم الرسومية (GUI components). فمثلًا، عندما يَضغَط المُستخدِم على زر بالفأرة، يُعدّ المُكوِّن المُتْضمِّن لمؤشر الفأرة عند وقوع حَدَث الضُغط مُرتبِطًا به، ويُسمَى هذا الكائن بمقصد الحَدَث (event target). لكي تَتَمكَّن من الاستجابة لحدث معين، ستحتاج إلى تسجيل مُستمِع (listener) إِما بمقصد الحَدَث (event target) أو بكائن آخر على علم بذاك الحَدَث. لنَفْحَص مثلًا التَعْليمَة التالية من برنامج HelloWorldFX.java من القسم ٦.١: helloButton.setOnAction( e -> message.setText("Hello World!") ); بالأعلى، helloButton هو كائن زر من النوع Button. عندما ينقر المُستخدِم على هذا الزر بالتحديد، سيقع حَدَث (event) من النوع ActionEvent مقصده (target) هو helloButton. يُسجِّل التابع helloButton.setOnAction()‎ مُستمِع حَدَث (event listener) يُفْترَض له أن يَستقبِل تنبيهًا بكل مرة يقع فيها حَدَث من النوع ActionEvent من ذلك الزر. عُرِّف المُستمِع بالأعلى بهيئة تعبير لامدا (lambda expression) يُنفَّذ كاستجابة على ذلك الحَدَث عند وقوعه، وبحيث يَستقبِل كائن الحَدَث من الصنف ActionEvent كقيمة للمُعامِل e. سنُعالج غالبية الأحداث (events) ضمن هذا الفصل بنفس الطريقة. لا تَقْتصِر الاستجابة على بعض أحداث المفاتيح والفأرة على مقصد الحَدَثَ (event target) فقط. فمثلًا، عندما تَضغَط على زر الفأرة أثناء وجود مؤشرها بحاوية (canvas) من الصَنْف Canvas واقعة ضِمْن مُكوِّن حاوية من الصَنْف BorderPane بمشهد من الصَنْف Scene، يَكُون عندها مقصد الحَدَثَ هو كائن الصَنْف Canvas، ولكن يُمكِن أيضًا لكائني الصَنْفين BorderPane و Scene أن يستجيبا لذلك الحَدَث أي يُمكِن تَسْجيل مُستمِع الحدث (event listener) بأي من تلك الكائنات، ويُعرَف عندها هذا الكائن باسم "مصدر الحدث (event source)". يَستقبِل تابع معالجة الحدث (event handler method) مُعامِل كائن الحدث evt والذي يَملُك مصدر ومقصد يُعطَى باستدعاء كُلًا من evt.getSource()‎ و evt.getTarget()‎ على الترتيب، وغالبًا ما يكونا نفس الكائن ولكنه ليس ضروريًا. لاحِظ أنه يُمكِن إرسال نفس ذات الحدث (event) إلى أكثر من معالج (handler)، ولكن إذا استهلك أي منها الحَدَثَ باستدعاء evt.consume()‎، سيَتَوقَّف إرساله إلى أي معالجات آخرى. مثلًا، عندما تَكْتُب بصندوق إدخال (input box) نصي، فإنه يستهلك أحداث المفاتيح الواقعة أثناء الكتابة، حتى لا يُعطِى أي فرصة للمشهد (scene) المُتْضمِّن للصندوق لمُعالجتها. الأمر في الحقيقة أكثر تعقيدًا من ذلك بقليل. تنتقل بعض أحداث الفأرة والمفاتيح أولًا عبر المشهد (scene) ثم عبر عُقَد مبيان المشهد (scene graph nodes) الحاضنة لمقصد الحدث (event target)، وهو ما يُعرَف بمرحلة "ترشيح الأحداث (event filtering)" أو " (bubble down)" من معالجة الحدث. بعد وصوله للمقصد (target)، ينتقل الحدث عائدًا عبر مبيان المشهد (scene graph) ثم إلى المشهد (scene)، وهو ما يعرف بمرحلة "معالجة الأحداث (event handling)" أو "(bubble up)". قد يُستهَلك الحدث بأي نقطة وعندها تَتَوقَّف العملية. لن نتعرض لذلك خلال هذا الفصل، ولكن يمكنك الإطلاع على توثيق التابعين addEventFilter()‎ و addEventHandler()‎ بالصنفين Scene و Node لمزيد من المعلومات. سنهتم بأحداث المفاتيح (key events) والفأرة (mouse events) بهذا القسم. في الحقيقة، لا تحتاج كثير من برامج واجهات المُستخدِم الرُسومية (GUI programs) للتَعامُل مع تلك الأحداث مباشرةً، وإنما عادةً ما تَتَعامَل مع مُكوِّنات الواجهة المُبرمَجَة بالفعل لمُعالجة تلك الأحداث. فمثلًا، عندما ينقر المُستخدِم على زر من الصَنْف Button، فإن الزر يَكُون مُبرمَجًا بالفعل ليَستمِع لأحداث الفأرة (mouse events) ومِنْ ثَمَّ يَستجيب لها بتوليد كائن حَدَثَ من الصَنْف ActionEvent. لذا عند كتابة تطبيق يحتوي على أزرار، غالبًا ما ستَكْتُب معالج لأحداث الصَنْف ActionEvent وليس لأحداث الفأرة (mouse events). بالمثل، عندما يَكْتُب المُستخدِم داخل صندوق إِدْخَال نصي (input box)، فإن الصندوق يَكُون مُبرمَجًا بالفعل ليَستمِع لأحداث المفاتيح (key events) ومِنْ ثَمَّ يَستجِيب لها. ولكن بالنهاية سيَكُون من المفيد أن تَكُون على دراية بأحداث المفاتيح والفأرة خاصة أنها ستُمكِّنك من القيام ببعض الأمور الشيقة. أحداث الفأرة (mouse events) تُستخدَم كائنات من النوع MouseEvent لتمثيل أحداث الفأرة (mouse event)، والتي لا تقتصر في الواقع على الفأرة، فقد تقع تلك الأحداث أيضًا نتيجة لاستخدام أجهزة إِدْخَال آخرى كلوحات التتبع (trackpad) وشاشات اللمس (touch screen)، ويُترجِم النظام عندها الأحداث الناتجة عن تلك الأجهزة إلى أحداث من الصَنْف MouseEvent. يَقَع هذا الصَنْف بالإضافة إلى غيره من الأصناف المُتعلِّقة بأحداث المفاتيح والفأرة بحزمة javafx.scene.input. تَقَع أنواع مختلفة من الأحداث عند اِستخدَام الفأرة، فمثلًا، تَقَع الأحداث التالية عند النقر على زر فأرة: "mouse pressed" و "mouse released" و "mouse clicked". في المقابل، تَقَع متتالية من الأحداث عند تحريك مؤشر الفأرة من نقطة إلى أخرى على الشاشة. والآن، لكي نَتَمكَّن من الاستجابة إلى أحداث الفأرة الواقعة داخل مُكوِّن معين، يُمكِننا أن نُسجِّل مُستمِع حَدَثَ (event listener) بذلك المُكوِّن. فمثلًا، إذا كان لدينا المكون c، نستطيع أن نُسجِّل به مُستمِع لكل حدث مختلف باستخدام توابع نسخ (instance methods) مثل c.setOnMousePressed(handler)‎ و c.setOnMouseMoved(handler)‎. تَستقبِل تلك التوابع مُعالِج حَدَث (event handler) كمُعامِل، والذي يُمرَّر عادةً بهيئة تعبير لامدا (lambda expression). لنَفْترِض أن لدينا حاوية canvas عبارة عن مُكوِّن من النوع Canvas وأننا نريد استدعاء التابع redraw()‎ في كل مرة ينقر فيها المُستخدِم على تلك الحاوية، يُمكِننا إذًا اِستخدَام التالي: canvas.setOnMousePressed( evt -> redraw() ); في العموم، تُكْتَب تلك التَعْليمَة بمَتْن التابع start()‎ المُعرَّف بالصَنْف Application المُمثِل للتطبيق. لاحِظ أنه من المُمكِن أيضًا مُعالجة حَدَث النقر على زر الفأرة عند وقوع المُؤشر داخل الحاوية (canvas) إما عن طريق المشهد (scene) أو عن طريق أي عقدة (node) آخرى بمبيان المشهد (scene graph) بشَّرْط أن تَكُون مُتضمِّنة لتلك الحاوية بصورة مباشرة أو غير مباشرة، ومع ذلك، عادةً ما تُوكَل مُهِمّة معالجة حََدَث (event) معين إلى مقصده (target). تتضمن أنواع أحداث الفأرة التالي: MouseEntered: يقع عندما يتحرك مُؤشِر الفأرة من خارج مُكوِّن واجهة معين إلى داخل ذلك المُكوِّن. MouseExited: يقع عند خروج مُؤشِر الفأرة من مُكوِّن معين. MousePressed: يقع عندما يَضغَط المُستخدِم على أحد أزرار الفأرة. MouseReleased: يقع عندما يُحرِّر المُستخدِم أحد أزرار الفأرة بَعْد الضَغْط عليه. MouseClicked: يقع بَعْد الحدث MouseReleased إذا كان المُستخدِم قد ضَغَطَ على زر الفأرة وحَرَّرها داخل نفس المُكوِّن. MouseDragged: يقع عندما يُحرِك المُستخدِم مؤشر الفأرة بينما يَضغَط باستمرار على أحد أزرار الفأرة. MouseMoved: يقع عندما يُحرِك المُستخدِم مؤشر الفأرة دون الضَغْط باستمرار على أي زر من أزرار الفأرة. لاحِظ أن مقصد (target) الأحداث MouseDragged و MouseReleased و MouseClicked هو نفس مُكوِّن الواجهة الذي كان قد ضُغِطَ (press) عليه بالأساس حتى لو كان المُؤشِر قد خرج من ذلك المُكوِّن بينما مقصد الأحداث MousePressed و MouseMoved فهو المُكوِّن الحاوي لمُؤشِر الفأرة عند وقوع الحدث. وأخيرًا، فإن مقصد الأحداث MouseEntered و MouseExited هو المُكوِّن الذي يَدْخُل إليه مُؤشِر الفأرة أو يَخرُج منه على الترتيب. عند وقوع حَدَث فأرة (mouse event) معين، نحتاج عادةً إلى مَعرِفة موقع مُؤشِر الفأرة. تُتاح تلك المعلومة بكائن حَدَث الفأرة من الصَنْف MouseEvent والمُمرَّر كمُعامِل إلى تابع معالجة الحدث حيث يَتَضمَّن ذلك الكائن توابع نُسخ (instance methods) تُعيد معلومات عن الحَدَث (event). بفَرْض أن المُتْغيِّر evt هو ذلك المُعامِل، فيُمكِننا إذًا استدعاء التابعين evt.getX()‎ و evt.getY()‎ لمَعرِفة موقع مؤشر الفأرة حيث يعيدان قيم من النوع double تُمثِل كُلًا من الإحداثي x و y لموقع مؤشر الفأرة عند وقوع الحدث. يُعبَر عن نظام الإحداثيات وفقًا لمُكوِّن مصدر الحدث (event source) أي تُمثِل إحداثيات النقطة (٠،٠) ركنه الأيسر العلوي. تَذَكَّر أن مصدر الحدث هو المُكوِّن الذي سُجِّل به مُستمِع الحدث (event listener) أي أنه قد يَكُون مختلفًا عن مقصد الحدث (event target) على الرغم من ندرة حدوث ذلك. يستطيع المُستخدِم أن يَضغَط باستمرار على مفتاح تبديل (modifier key) واحد أو أكثر بينما يَستخدِم الفأرة. تَتَضمَّن مفاتيح التبديل المفاتيح التالية: المفتاح "Shift"، والمفتاح "Control"، والمفتاح "Alt" (أو "Option" بأجهزة ماك)، والمفتاح "Meta" (أو "Command" بأجهزة ماك). قد تَرغَب أحيانًا بالإستجابة إلى حَدَث فأرة (mouse event) معين بصورة مختلفة في حالة كان المُستخدِم يَضغَط باستمرار على مفتاح تبديل معين. يُمكِنك اختبار ذلك باستدعاء توابع النُسخ التالية evt.isShiftDown()‎ و evt.isControlDown()‎ و evt.isAltDown()‎ و evt.isMetaDown()‎ المُعرَّفة بكائن حَدَث الفأرة. قد ترغب بمعالجة أحداث الفأرة بشكل مختلف اعتمادًا على ما إذا كان المُستخدِم قد ضَغَطَ على زر الفارة الأيسر أم الأوسط أم الأيمن. بالنسبة لأحداث الفأرة الصادرة عن الأزرار، يُمكِنك أن تَستدعِي التابع evt.getButton()‎ لمَعرِفة أي زر ضَغَطَ عليه المُستخدِم أو حَرَّره. يُعيد ذلك التابع أحد ثوابت أنواع التعداد (enumerated type constants) التالية: MouseButton.PRIMARY والذي يُمثِل زر الفأرة الأيسر أو MouseButton.MIDDLE أو MouseButton.SECONDARY الذي يُمثِل زر الفأرة الأيمن. أما بالنسبة لأحداث الفأرة غَيْر الصادرة عن الأزرار مثل mouseEntered و mouseExited، يُعيِد التابع evt.getButton()‎ الثابت MouseButton.NONE. قد يَضغَط المُستخدِم باستمرار على أكثر من زر فأرة بنفس الوقت. إذا أردت مَعرِفة أي من أزرار الفأرة كان المُستخدِم يَضغَط عليها باستمرار أثناء وقوع حَدَث معين، يُمكِنك استدعاء الدوال evt.isPrimaryButtonDown()‎ و evt.isMiddleButtonDown()‎ و evt.isSecondaryButtonDown()‎ والتي تُعيد قيم منطقية. كمثال بسيط، لنَفْترِض أننا نَرغَب برَسْم مستطيل أحمر اللون كلما نقر المُستخدِم على كائن حاوية canvas من الصَنْف Canvas، ولكن إذا كان المُستخدِم ضاغطًا باستمرار على المفتاح "Shift" أيضًا أثناء وقوع الحَدَث، فنُريد أن نرسم شكلًا بيضاويًا أزرق اللون. يُمكننا القيام بذلك بتعريف مُعالِج الحَدَث (event handler) التالي: canvas.setOnMousePressed( evt -> { GraphicsContext g = canvas.getGraphicsContext2D(); if ( evt.isShiftDown() ) { g.setFill( Color.BLUE ); g.fillOval( evt.getX() - 30, evt.getY() - 15, 60, 30 ) } else { g.setFill( Color.RED ); g.fillRect( evt.getX() - 30, evt.getY() - 15, 60, 30 ); } } ); سيُساعدك البرنامج SimpleTrackMouse.java على فهم كيفية عَمَل أحداث الفأرة (mouse events) بصورة أفضل. يَستمِع البرنامج لجميع أنواع أحداث الفأرة (mouse events) السبعة، ويستجيب لها بعَرْض كُلًا من إحداثيات مُؤشِر الفأرة، ونوع الحَدَث، بالإضافة إلى قائمة بمفاتيح التعديل (modifier keys) وأزرار الفأرة المضغوط عليها. يُمكِنك أيضًا أن تُجرِّب البرنامج لترى ما يَحدُث أثناء استخدامك للفأرة. يفضَّل أيضًا أن تَطَّلِع على شيفرة البرنامج المصدرية. السحب (dragging) يُقصَد بعملية السحب (dragging) أن يُحرِك المُستخدِم الفأرة بينما يَضغَط باستمرار على أحد أزرار تلك الفأرة. سنناقش الآن كيف يُمكِن لبرنامج معين أن يستجيب لعملية السحب (dragging). تبدأ عملية السحب عندما يَضغَط المُستخدِم على أحد أزرار الفأرة، وتستمر بينما يَسحَب تلك الفأرة، وأخيرًا تنتهي عندما يُحرِّر (release) ذاك الزر. تَتَضمَّن عملية السحب إذًا الأحداث التالية: MousePressed و MouseDragged -قد يُستدعَى أكثر من مرة أثناء تَحرِيك الفأرة- و MouseReleased، لذا تُقسَّم الاستجابة لأحداث السحب على ثلاثة مُعالِجات أحداث (event handlers). في مثل تلك الحالات، عادةً ما نحتاج إلى ضَبْط بعض مُتْغيِّرات النُسخ (instance variables) لنتابع ما يَحدُث بين كل استدعاء لتابع والاستدعاء الذي يليه. فمثلًا، عادةً ما يحتاج مُعالِج الحدث MouseDragged إلى الاحتفاظ بإحداثيات المُؤشِر من الاستدعاء السابق، ولهذا قد نُخزِّن تلك المعلومة بمُتْغيِّرات النُسخ prevX و prevY من النوع double كما قد نُخزِّن إحداثيات المُؤشِر المبدئية -أي عند وقوع الحدث MousePressed- بمُتْغيِّرات نُسخ آخرى. بالإضافة إلى ذلك، قد نُعرِّف مُتْغيِّرًا من النوع boolean يَحمِل الاسم dragging بحيث يُضبَط إلى القيمة المنطقية true إذا كان هنالك عملية سحب (dragging) قيد التّنْفيذ. يُعدّ ذلك ضروريًا لأنه سيُمكِّن توابع معالجة الأحداث من اختبار ما إذا كان هنالك عملية سحب قيد التّنْفيذ أم لا؛ لأنه لا ينبغي لكل حدث MousePressed أن يبدأ عملية سحب جديدة، وكذلك في حالة ضَغَطَ المُستخدِم على زر فأرة آخر بدون أن يُحرِّر الأول، فسيَقَع حدثان MousePressed قبل وقوع الحَدَث MouseReleased، وعندها لا ينبغي عادةً بدء عملية سحب جديدة عند وقوع الحدث MousePressed بالمرة الثانية. سنُعرِّف توابع نسخ (instance methods) لمعالجة الأحداث (events) كالتالي: private double startX, startY; // المَوضع الأصلي الذي نقر عليه المستخدم private double prevX, prevY; // إحداثيات الفأرة الأحدث private boolean dragging; // ‫اضبطه إلى true إذا كانت هناك عملية سحب . . . // متغيرات نسخ أخرى public void mousePressed(MouseEvent evt) { if (dragging) { // يضغط المستخدم على زر الفأرة الآخر قبل أن يحرر الأول // تجاهل الضغط على الزر الثاني return; } if ( we-want-to-start-dragging ) { dragging = true; startX = evt.getX(); // تذكر موضع البداية startY = evt.getY(); prevX = startX; // أحدث مَوضِع prevY = startY; . . // أجري أي معالجات أخرى . } } public void mouseDragged(MouseEvent evt) { // افحص أولًا إذا ما كنا نعالج عملية سحب if ( dragging == false ) return; int x = evt.getX(); // موضع الفأرة الحالي int y = evt.getY(); . . // ‫عالج حركة الفأرة من (prevX, prevY) إلى (x,y). . prevX = x; // تذكر الموضع الحالي للاستدعاء التالي prevY = y; } public void mouseReleased(MouseEvent evt) { // افحص أولًا إذا ما كنا نعالج عملية سحب if ( dragging == false ) return; dragging = false; // .انهي عملية السحب . . // أي معالجات أخرى . } سنُسجِّل الآن معالجات أحداث (event handlers) بالمُكوِّنات ذات الصلة بحيث يَقْتصِر دورها على استدعاء تلك التوابع الثلاثة المُعرَّفة بالأعلى: c.setOnMousePressed( e -> mousePressed(e) ); c.setOnMouseDragged( e -> mouseDragged(e) ); c.setOnMouseReleased( e -> mouseReleased(e) ); يَقْتصِر دور مُعالجات الأحداث (event handlers) بالتَعْليمَات السابقة على استدعاء تابع (method) آخر مُعرَّف ضِمْن نفس الصَنْف، والذي يَستقبِل نفس مُعامِل (parameter) مُعالج الحدث. يُمكِننا إذًا استخدام مَراجِع التوابع (method reference) -اُنظر القسم الفرعي ٤.٥.٤- لكتابة تعبيرات لامدا (lambda expressions) السابقة، ولمّا كانت التوابع المُستدعَاة عبارة عن توابع نُسخ (instance methods) مُعرَّفة بالكائن this، فستُستخدَم أسماء مَراجِع مثل this::mousePressed للإشارة إليها. يُمكِننا الآن تَسْجيل مُعالِجات الأحداث (event handlers) كالتالي: c.setOnMousePressed( this::mousePressed ); c.setOnMouseDragged( this::mouseDragged ); c.setOnMouseReleased( this::mouseReleased ); سنَفْحَص الآن برنامجًا يَتَضمَّن واحدة من الاِستخدَامات التقليدية عملية السحب (dragging): سنَسمَح للمُستخدِم برسم منحنى عن طريق سحب الفأرة بمساحة رسم (drawing area) بيضاء كبيرة، وسنُمكِّنه أيضًا من اختيار اللون المُستخدَم للرسم من خلال النقر على أحد المستطيلات المُلوَّنة على يمين مساحة الرسم. يُمكِنك الإطلاع على شيفرة البرنامج بالكامل بالملف SimplePaint.java. تَعرِض الصورة التالية نافذة البرنامج بَعْد القيام ببعض الرسم: سنُناقش فقط بعضًا من أجزاء الشيفرة المصدرية للبرنامج وليس كلها، ولكن يُفضَّل أن تقرأها كاملة بتأني وستَجِد الكثير من التعليقات (comments) التوضيحية بالشيفرة. بهذا البرنامج، تَقَع عملية الرسم ضِمْن حاوية (canvas) واحدة تُغطِي النافذة بالكامل. صُمّم البرنامج ليتناسب مع أي حجم للحاوية بشَّرْط ألا تَكُون صغيرة أكثر من اللازم. في الحقيقة، يُصعِب ذلك الأمور قليلًا عما لو كنا قد اِفترَضنا حجمًا ثابتًا للحاوية (canvas)؛ فلابُدّ لنا الآن من حساب قيم الإحداثيات وفقًا لعَرْض الحاوية وارتفاعها. يُمكِننا مَعرِفة عَرْض الحاوية وارتفاعها باستدعاء التابعين canvas.getWidth()‎ و canvas.getHeight()‎ على الترتيب. سنَفْحَص الآن بعضًا من تلك الحسابات: تمتد مساحة الرسم (drawing area) البيضاء الكبيرة من y = 3 إلى y = height - 3 رأسيًا، ومن x = 3 إلى x = width - 56 أفقيًا. تُراعِي تلك الحسابات وجود إطار رمادي حول الحاوية (canvas) بعَرْض يَبلُغ ٣ بكسل، وكذلك وجود لوحة الألوان على طول الحافة اليُمنَى للحاوية، والتي يَبلُغ عَرْضها ٥٠ بكسل مع ٣ بكسل للإطار و٣ بكسل للحاجز الفاصل بين مساحة الرسم ولوحة الألوان. وفقًا لذلك، تَبعُد الحافة اليُمنى لمساحة الرسم (drawing area) مسافة قدرها ٥٦ بكسل عن الحافة اليمنى للحاوية (canvas). يوجد مربع أبيض مكتوب عليه كلمة "CLEAR" أسفل لوحة الألوان الواقعة على طول الحافة اليُمنَى للحاوية (canvas). باستبعاد ذلك المربع، نستطيع أن نَحسِب المسافة الرأسية المُتاحة لجميع المستطيلات المُلوَّنة ثم نُقسِّمها على ٧ لنَحصُل على قيمة المسافة الرأسية المُتاحة لكل مستطيل على حدى بحيث تُخزَّن تلك القيمة بالمُتْغيِّر colorSpace. بالإضافة إلى ذلك، يَفصِل فراغ عَرْضه ٣ بكسل بين كل مستطيل وآخر، ولهذا فإن ارتفاع كل مستطيل يُساوِي colorSpacing - 3. بفَرْض بِدء عدّ المستطيلات من الصفر، ستَبعُد إذًا الحافة العلوية لمستطيل N مسافة قدرها N*colorSpacing + 3 بكسل عن الحافة العُلوية للحاوية (canvas)؛ وذلك لوجود عدد N من المستطيلات أعلى المستطيل N يَبلُغ ارتفاع كُلًا منها قيمة تُساوِي colorSpace بكسل بالإضافة إلى ٣ بكسل لإطار الحافة العلوية للحاوية (canvas). نستطيع الآن كتابة الأمر اللازم لرسم مستطيل N كالتالي: g.fillRect(width - 53, N*colorSpace + 3, 50, colorSpace - 3); لم يكن ذلك سهلًا! ولكنه يُوضِح نوعية التفكير والدقة المطلوبين في بعض الأحيان للحصول على نتائج جيدة. تُستخدَم الفأرة بهذا البرنامج لثلاثة أغراض مختلفة هي: اختيار اللون، ومسح الرسوم، ورسم المنحنى. تَشتمِل الأخيرة فقط على عملية سحب (dragging) أي لا تُؤدي كل نقرة على الفأرة إلى بدء عملية سحب. سيَفْحَص التابع mousePressed()‎ إحداثيات النقطة (x,y) التي نقر عليها المُستخدِم ليُقرِّر كيفية الاستجابة. فمثلًا، إذا نقر المُستخدِم على المستطيل "CLEAR"، فستُفرَّغ مساحة الرسم (drawing area) باستدعاء التابع clearAndDrawPalette()‎ والذي يُعيد رَسْم الحاوية (canvas) بالكامل. أما إذا نقر المُستخدِم بموضع آخر داخل لوحة الألوان، فلابُدّ للمعالج من أن يُحدِّد اللون الذي نقر عليه المُستخدِم وذلك بقسمة الإحداثي y على قيمة المُتغيِّر colorSpacing، ثم يُخصِّص ذلك اللون لعملية الرسم. أخيرًا، إذا نقر المُستخدِم على مساحة الرسم (drawing area)، فستبدأ عملية سحب (drag)، وسيُضبَط المُتْغيِّر المنطقي dragging في تلك الحالة إلى القيمة true مما يُمكِّن التابعين mouseDragged و mouseReleased من مَعرِفة أن هنالك عملية رسم منحنى قيد التّنْفيذ. تُوكَل مُهِمّة الرسم الفعليّ للمنحنى للتابع mouseDragged()‎ والذي يَرسِم خطًا من الموضع السابق لمُؤشِر الفأرة وحتى موضعه الحالي. سنحتاج أيضًا إلى التأكُّد من أن الخط المرسوم لن يمتد إلى ما بَعْد مساحة الرسم (drawing area) البيضاء داخل الحاوية (canvas)، وهو ما لا يَحدُث تلقائيًا؛ لأن الحاسوب يَنظُر للإطار وللوحة الألوان على أساس كَوْنهما جزءًا من الحاوية (canvas). سيَضطرّ التابع mouseDragged()‎ إذًا إلى تَعْديل قيم كُلًا من الإحداثي x والإحداثي y بحيث يَقعَا ضِمْن نطاق مساحة الرسم إذا سحب المُستخدِم مؤشر الفأرة إلى خارج مساحة الرسم البيضاء أثناء رسمه لمنحنى. أحداث المفاتيح (key events) تُصبِح أفعال (actions) المُستخدِم في العموم أحداثًا (events) بالبرنامج وبحيث يَكُون مُكوِّن واجهة (GUI component) معين هو مقصد ذلك الحدث (event target). فمثلًا، عندما يَضغَط المُستخدِم على أي من أزرار الفأرة، يُعدّ المُكوِّن المُتَضمِّن لمؤشر الفأرة هو مقصد الحدث. والآن، ماذا عن أحداث لوحة المفاتيح (key events)؟ فمثلًا، عندما يَضغَط المُستخدِم على مفتاح، فأي مُكوِّن واجهة يَكُون مقصدًا للحدث KeyEvent؟ تَعتمِد واجهة المُستخدِم الرُسومية (GUI) على فكرة التركيز (input focus) لتَحْديد مقصد أحداث (event target) لوحة المفاتيح. بأي لحظة، يُمكِن أن يَقَع التركيز على عنصر واجهة (interface element) واحد فقط على الشاشة وبحيث تُوجَّه إليه أحداث لوحة المفاتيح (keyboard events). إذا كان ذلك العنصر مُكوِّن بمنصة جافا إف إكس (JavaFX component)، يُنشَئ كائن من النوع KeyEvent يَتَضمَّن معلومات عن حدث لوحة المفاتيح ثم يُرسَل لأي من مُعالِجات أحداث المفاتيح (key event handlers) المُسجَّلة بذلك المُكوِّن والمُستمعِة للأحداث من الصَنْف KeyEvent. نظرًا للكيفية التي تُعالَج بها أحداث المفاتيح (key events)، يَحصُل كائن المشهد من الصنف Scene بالنافذة المُتْضمِّنة للمُكوِّن الواقع عليه التركيز على فرصة لمعالجة أحداث المفاتيح بل قد يُصبِح مقصدًا (event) لها إذا لم يَكُن هناك أي مُكوِّن آخر واقع عليه التركيز بالنافذة. سنُضيف خلال البرامج التالية مُعالِجات أحداث المفاتيح (key event handlers) إلى كائن المشهد. عادةً ما يُعطِي البرنامج ملحوظة مرئية للمُستخدِم عن مُكوِّن الواجهة الواقع عليه التركيز (input focus). فعلى سبيل المثال، إذا كان المُكوِّن عبارة عن صندوق إدخال نصي، قد تكون تلك الملحوظة بهيئة مُؤشِر وامض أو برَسْم إطار مُلوَّن حول حافة ذلك المُكوِّن، وهو ما قد تلاحظه بمُكوِّنات الأزرار، ويُكافئ عندها الضغط على مفتاح مسطرة المسافات (space bar) النقر على الزر. لنَفْترِض أن comp هو مُكوِّن واجهة ترغب بأن يقع عليه التركيز (input focus)، يُمكِنك عندها أن تَستدعِي comp.requestFocus()‎. بأي واجهة مُستخدِم (user interface) تقليدية، عندما يَنقُر المُستخدِم على مُكوِّن معين باستخدام الفأرة، يقع التركيز على ذلك المُكوِّن تلقائيًا كما ينتقل التركيز من مُكوِّن واجهة إلى آخر بكل مرة يَضغَط فيها المُستخدِم على المفتاح "tab". يَحدُث ذلك تلقائيًا في غالبية الأحوال ودون الحاجة لإجراء أي برمجة، ولكن لا تَطلُب بعض المُكوِّنات أن يقع عليها التركيز تلقائيًا بعد نقر المُستخدِم عليها مثل الصَنْف Canvas، وعندها لابُدّ من استدعاء التابع requestFocus()‎ بكائن ذلك الصنف حتى يُصبِح مَوضِع التركيز وكذلك لابُد من استدعاء comp.setFocusTraversable(true)‎ لتفعيل خاصية انتقال التركيز التلقائي للمُكوِّن عند الضغط على المفتاح "tab". تستطيع أيضًا اِستخدَام التابع comp.isFocused لاختبار ما إذا كان التركيز واقعًا على ذلك المُكوِّن. تُعدّ النافذة التي تَتَضمَّن المُكوِّن الواقع عليه التركيز نافذة "مركزة (focused)" أو "نشطة (active)" وعادةً ما تَكُون النافذة الأمامية بالشاشة. بمنصة جافا إف إكس (JavaFX)، يُمثِل كائن المرحلة من الصَنْف Stage نافذة، ويُمكِنك أن تَستدعِي stage.requestFocus()‎ لتَطلُب نقلها إلى مقدمة الشاشة لكي تُصبِح "نشطة (active)" كما يُمكِنك أن تَستدعِي stage.isFocused()‎ لاختبار ما إذا كانت نشطة. تُفرِّق الجافا بين المفاتيح التي تَضغَط عليها والمحارف (characters) التي تَكْتُبها بصورة واضحة. هنالك الكثير من المفاتيح بأي لوحة مفاتيح: مفاتيح الحروف، ومفاتيح الأعداد، ومفاتيح التَعْدِيل (modifier keys) مثل "Control" و "Shift"، ومفاتيح الأسهم، ومفتاحي "صفحة لأعلى" و"صفحة لأسفل"، ومفاتيح الوظائف (function keys)، وغيره. أحيانًا لا يؤدي الضَغْط على مفتاح معين إلى كتابة محرف كالمفتاح "shift". في المقابل، أحيانًا ما تَتَطلَّب كتابة محرف واحد الضَغْط على أكثر من مفتاح. فمثلًا، تَتَطلَّب كتابة الحالة الكبيرة من الحرف "A" الضغط باستمرار على المفتاح "Shift" ثُمَّ الضَغْط على المفتاح "A" وأخيرًا تحرير المفتاح "Shift". كذلك تَتَطلَّب كتابة "é" بأجهزة ماك الضَغْط باستمرار على المفتاح "Option" ثم الضَغْط على المفتاح "E" ثم تحرير المفتاح "Option" وأخيرًا الضغط على "E" مجددًا. كُتِبَ بالنهاية محرف واحد فقط على الرغم من الحاجة للضغط على ثلاثة مفاتيح مع تحرير إحداها بالوقت المناسب. بمنصة جافا إف إكس، هنالك ثلاثة أنواع من أحداث المفاتيح (key event):‏ KeyPressed و KeyReleased و KeyTyped. يَقَع الأول عندما يَضغَط المُستخدِم على أي مفتاح بلوحة المفاتيح أما الثاني فيَقَع عندما يُحرِّر مفتاحًا كان قد ضَغَطَ عليه أما الثالث فيَقَع عندما يَكْتُب محرفًا سواء كان ذلك نتيجة لضَغْطه على مفتاح واحد أو أكثر. قد يُؤدي فِعْل (action) واحد كالضَغْط على المفتاح "E" إلى وقوع الحَدَثَين keyPressed و keyTyped. على سبيل المثال، تُؤدي كتابة الحالة الكبيرة من الحرف "A" إلى وقوع حدثين keyPressed وآخرين keyReleased بالإضافة إلى حَدَث keyTyped. في العموم، يُفضَّل أن تُفكِّر بوجود مجريين منفصلين من الأحداث (events) الأول يحتوي على أحداث keyPressed و keyReleased والآخر يَتَضمَّن أحداث keyTyped بحيث تستمع بعض أنواع التطبيقات إلى أحداث المجرى الأول بينما تستمع تطبيقات آخرى إلى أحداث المجرى الثاني. يُمكِنك استخراج نفس المعلومات الموجودة بمجرى أحداث keyTyped من مجرى أحداث keyPressed/keyReleased ولكنها عملية صعبة نوعًا ما كما أنها تعتمد على النظام إلى درجة معينة. لاحظ أن بعض أفعال المُستخدِم (user actions) -مثل الضغط على المفتاح "Shift"- يُمكِن فقط رصدها بهيئة أحداث keyPressed. على سبيل المثال، تُميِّز لعبة الحاسوب Solitaire ورق اللعب الذي يُمكِن نقله عند الضَغْط باستمرار على المفتاح "Shift". يُمكِنك القيام بذلك بالجافا عن طريق تَمْييز ورق اللعب عند الضَغْط على المفتاح "Shift" ثم إلغاء ذلك التَمْييز عند تحرير المفتاح. لاحِظ أيضًا أنه عند الضَغْط باستمرار على مفتاح معين، فقد يتكرَّر ذلك المفتاح تلقائيًا أي ستَقَع متتالية من أحداث KeyPressed متبوعة بحَدَث KeyReleased وحيد بالنهاية كما قد تَقَع أيضًا متتالية من أحداث KeyTyped. لن يُؤثِر ذلك في الغالب على أسلوب كتابة البرامج ولكن لا تَفْترِض أن كل حَدَث KeyPressed لابُدّ وأن يُقابله حَدَث KeyReleased. كل مفتاح بلوحة المفاتيح له ترميز (key code) يُميِّزه والتي تُمثَل بمنصة جافا إف إكس (JavaFX) باستخدام ثوابت التعداد KeyCode. عندما يُستدعَى مُعالِج الحَدَث KeyPressed أو KeyReleased، فإن المُعامِل evt يحتوي على ترميز المفتاح المضغوط عليه أو المُحرَّر على الترتيب، ويُمكِننا مَعرِفته باستدعاء الدالة evt.getCode()‎. على سبيل المثال، عندما يَضغَط المُستخدِم على المفتاح "shift"، تُعيد تلك الدالة القيمة KeyCode.SHIFT. يُمكِنك الإطلاع على توثيق التعداد KeyCode لمَعرِفة اسم الثابت لترميز مفتاح معين مع أنه من السهل تَخْمِين أسمائها عمومًا. فمثلًا، مفاتيح الحروف لها أسماء مثل KeyCode.A و KeyCode.Q بينما مفاتيح الأسهم لها أسماء مثل KeyCode.LEFT و KeyCode.RIGHT و KeyCode.UP و KeyCode.DOWN أما مفتاح مسطرة المسافات (space bar) هو KeyCode.SPACE وأخيرًا مفاتيح الوظائف لها أسماء مثل KeyCode.F7. في حالة الحَدَث KeyTyped، سترغب عادةً بمَعرِفة المحرف المَكْتُوب لذا يُمكِنك استدعاء الدالة evt.getCharacter()‎ لمَعرِفة ذلك حيث تُعيد قيمة من النوع String تَحتوِي على المحرف المَكْتُوب. كأول مثال، يَرسِم البرنامج KeyboardEventDemo.java مربعًا صغيرًا داخل حاوية (canvas). يستطيع المُستخدِم أن يُحرِك ذلك المربع إلى اليسار أو إلى اليمين أو إلى أعلى أو إلى أسفل عن طريق الضَغْط على مفاتيح الأسهم (arrow keys). نُفِذَ (implement) ذلك بالتابع التالي: private void keyPressed( KeyEvent evt ) سيُستدعَى التابع بالأعلى بواسطة مُعالِج حَدَث (event handler) يَستمِع لأحداث KeyPressed. تُسجِّل التَعْليمَة التالية ذلك المُعالِج بكائن المشهد من الصَنْف Scene بمَتْن التابع start()‎: scene.setOnKeyPressed( e -> keyPressed(e) ); يَفْحَص التابع keyPressed()‎ قيمة الدالة evt.getCode()‎، فإذا كان المفتاح المضغوط عليه واحدًا من مفاتيح الأسهم (arrow keys)، يُعاد رسم الحاوية (canvas) بحيث تُظهِر المربع بمَوضِع مختلف. يُسجِّل البرنامج أيضًا مُعالِجات (handlers) للأحداث KeyReleased و KeyTyped بنفس الكيفية. فمثلًا، سيُغيِّر مُعالِج الحَدَث KeyTyped لون المربع عندما يَكْتُب المُستخدِم الحرف "r" أو "g" أو "b" أو "k". اِحرص على قراءة الشيفرة الكاملة للبرنامج بتأني وجرِّب تَشْغِيله. الصنف AnimationTimer سنناقش الآن نوعًا آخر من الأحداث البسيطة المستخدمة بالتحريك الحاسوبي (animation). تقع الأحداث (events) في هذه الحالة بالخلفية لذا أنت لا تكون مضطرًا لتسجيل مستمع (listener) ليستجيب لها، ولكن ستحتاج إلى كتابة تابع (method) يستدعيه النظام عند وقوع تلك الأحداث. يَعتمِد التَحرِيك الحاسوبي (computer animation) على متتالية من الصور الثابتة المُنفصلة، يُطلَق على كُل منها اسم الإطار (frame). تُعرَض هذه الصور بشكل سريع واحدة تلو الآخرى، فإذا كان التَغْيِير بين كل صورة والصورة التي تَليها طفيفًا، ستبدو متتالية الصور وكأنها تَحرِيكة مُستمرة (continuous animation). بمنصة جافا إف إكس (JavaFX)، تُستخدَم كائنات من النوع AnimationTimer المُعرَّف بحزمة javafx.animation لبرمجة تحريكة (animation). بفَرْض أن الكائن animator من ذلك الصنف، فيُمكِننا استدعاء التابع animator.start()‎ لبدء التحريكة إذا كانت مُتوقِّفة أو لإعادة تَشْغِيلها إذا كانت مشغَّلة. يُمكِننا أيضًا استدعاء التابع animator.stop()‎ لإيقاف التحريكة. يَتَضمَّن الصنف التابع handle(time)‎ والذي لا يُمكِنك استدعائه وإنما ينبغي أن تَكْتُب تّنْفيذه لتُحدِّد ما ينبغي أن يَحدُث بالتَحرِيكة. سيَستدعِي النظام ذلك التابع مرة واحدة لكل إطار (frame) بالتحريكة لكي يُنفِّذ كل ما هو ضروري لتّنْفيذ الإطار. يَستدعِى النظام التابع handle()‎ بخيط تطبيق جافا إفا إكس (JavaFX application thread) مما يَعنِي إمكانية الرسم على حاوية (canvas) أو مُعالجة مُكوِّن واجهة (GUI component) أو القيام بأي أشياء آخرى مشابهة بشَّرْط ألا تَستغرِق وقتًا طويلًا؛ لأن التحريكات بمنصة جافا إف إكس (JavaFX) تُنفَّذ بمُعدل ٦٠ إطار لكل ثانية أي يُستدعَى التابع handle()‎ كل ١\٦٠ ثانية. ملحوظة: بُلِّغ عن وجود خطأ برمجي (bug) قد يؤدي أحيانًا إلى استدعاء التابع handle()‎ أكثر من ٦٠ مرة بالثانية، ولذلك أضفنا بعض الشيفرة إلى تّنْفيذ (implementation) الصَنْف AnimationTimer لنتجنَّب ذلك الخطأ البرمجي وأرفقنا معها تعليقات توضيحية. لاحِظ أن الصَنْف AnimationTimer هو صَنْف مُجرّد (abstract class) كما أن التابع handle()‎ هو تابع مُجرّد (abstract method) لذا ستحتاج إلى كتابة صَنْف فرعي (subclass) من AnimationTimer يُعرِّف التابع handle()‎ لتَتَمكَّن من برمجة تَحرِيكة (animation). لنَفْترِض أنك ترغب باستدعاء تابع اسمه draw()‎ بكل إطار بالتحريكة، يُمكِنك القيام بذلك باِستخدَام صَنْف فرعي مجهول الاسم (anonymous subclass) من الصَنْف AnimationTimer كالتالي (اُنظر القسم الفرعي ٥.٨.٣): AnimationTimer animator = new AnimationTimer() { public void handle( long time ) { draw(); } }; سنحتاج الآن إلى استدعاء animator.start()‎ لتَشْغِيل التَحرِيكة، وهو ما يُمكِنك القيام به بمَتْن تابع التطبيق start()‎. يُمثِل المُعامِل time -بالأعلى- الوقت الحالي مُقاس بحساب الفارق بين الوقت الحالي ووقت آخر عشوائي بالماضي بوحدة النانوثانية. يُمكِنك اِستخدَام time ضِمْن الحسابات المطلوبة لرسم الإطار (frame) كطريقة لتّمْيِيز كل إطار عما يليه. آلات الحالة (state machines) نحن الآن جاهزين لفحص برنامج يوظف كلا من التحريك (animation) وأحداث المفاتيح (key events) لتنفيذ لعبة بسيطة. يستخدم البرنامج الصنف AnimationTimer لإدارة التحريك كما يستخدم عددًا من متغيرات النسخ (instance variables) لمتابعة "الحالة (state)" الحالية للعبة. تُعبِر القيم المُخزَّنة بمُتْغيِّرات نُسخ (instance variables) كائن معين عن "حالة (state)" ذلك الكائن. عند استدعاء إحدى توابعه، قد يَعتمِد ما يُنفِّذه الكائن حينها على حالته، أو بتعبير آخر، يُمكِن للتابع أن يَفْحَص قيم مُتْغيِّرات النُسخ (instance variables) ليُقرِّر ما ينبغي له القيام به. قد تَتَغيَّر حالة الكائن، أو بتعبير آخر، يُمكِن للتابع أن يُسنِد (assign) قيم جديدة لمُتْغيِّرات النُسخ. هنالك فكرة بعلوم الحاسوب (computer science) تُعرَف باسم "آلة الحالة (state machine)"، وهي تُعبِر عن شيء ذات حالة (state)، والتي قد تَتغيَّر استجابة لبعض الأحداث (event) أو المُدْخَلات (input)، وبحيث تَعتمِد كيفية استجابة الآلة لحَدَث معين على حالتها عند وقوع ذلك الحَدَث. في الواقع، يُعدّ الكائن بمثابة آلة حالة (state machine)، وأحيانًا ما تَكُون وجهة النظر تلك مفيدة أثناء تصميم الأصناف. تبرز أهمية وجهة النظر تلك ببرمجة واجهات المُستخدِم الرُسومية (graphical user interfaces) والتي تعتمد على فكرة الأحداث (events) اعتمادًا كليًا. عند تصميم برنامج واجهة، ينبغي أن تُفكِّر بالأسئلة التالية: أي معلومات ينبغي تَضْمِينها ضِمْن حالة (state) البرنامج؟ ما هي الأحداث التي يُمكِنها أن تُغيِّر من حالة البرنامج؟ كيف ستعتمد استجابة حَدَث معين على حالة البرنامج الحالية؟ هل ينبغي تَغْيير مَظهَر الواجهة ليَعكِس تَغْييرًا بحالة البرنامج؟ كيف ستُؤثِر حالة البرنامج على رسم محتويات الحاوية (canvas)؟ يُعدّ ذلك كله بمثابة بديل عن نهج التصميم المتدرج (step-wise-refinement) الذي يقع ضِمْن "الاستراتيجيات من أعلى لأسفل (top-down)"، وهو ما لا يُطبَق على كيفية تصميم برنامج حَدَثي التوجه (event-oriented). بالبرنامج KeyboardEventDemo -بالأعلى-، تُخزَّن حالة (state) البرنامج بمُتْغيِّرات نُسخ (instance variables) مثل squareColor و squareLeft و squareTop تُمثِل كُلًا من لون المربع ومَوضِعه. يَستخدِم التابع draw()‎ مُتْغيِّرات الحالة (state variables) تلك لرَسْم المربع على الحاوية (canvas) بينما تُغيِّر توابع مُعالجة أحداث المفاتيح (key events) من قيمها. سنَفْحَص ببقية هذا القسم مثالًا آخر تَلعَب فيه حالة (state) البرنامج دورًا أكبر حيث سيَلعَب المُستخدِم لعبة بسيطة من خلال الضَغْط على مفاتيح الأسهم (arrow keys). البرنامج متاح بملف الشيفرة SubKiller.java، وكالعادة، سيَكُون من الأفضل لو تَمَكَّنت من تصريف (compile) البرنامج وتَشْغِيله وكذلك قراءة شيفرته المصدرية بالكامل. اُنظر الصورة التالية: تُغطِى حاوية (canvas) نافذة التطبيق بالكامل. بأسفل تلك الحاوية، يَعرِض البرنامج "غواصة" سوداء تتحرك عشوائيًا ذهابًا وإيابًا بالقرب من أسفل النافذة. بأعلى النافذة، هناك "قارب" أزرق يُمكِنك تَحرِيكه ذهابًا وإيابًا بالضَغْط على مفتاحي "سهم يسار" و"سهم يمين". رُبِط بالقارب "قنبلة" حمراء يُمكِنك قذفها بالضَغْط على مفتاح "سهم لأسفل". الهدف من اللعبة هو تفجير الغواصة عن طريق ضربها بقنبلة. إذا سَقَطَت القنبلة إلى خارج أسفل الشاشة، فستَحصُل على قنبلة جديدة أما إذا انفجرت الغواصة، فستُنشَئ غواصة جديدة وستَحصُل أيضًا على قنبلة جديدة. جرِّب اللعبة وتَأكَّد من ضرب الغواصة مرة واحدة على الأقل حتى تَتَمكَّن من رؤية الانفجار. سنُفكِّر الآن بالكيفية التي ينبغي لنا بها برمجة تلك اللعبة. أولًا، لأننا نَعتمِد على البرمجة كائنية التوجه (object-oriented programming)، فسنُمثِل كُلًا من القارب والقنبلة والغواصة ككائنات. كل كائن منها مُعرَّف باِستخدَام صَنْف مُتداخِل (nested class) منفصل ضِمْن صَنْف التطبيق الأساسي كما أن كُلًا منها لديه حالته (state) الخاصة والمُمثَلة باِستخدَام مُتْغيِّرات النُسخ (instance variables) المُعرَّفة بصنفه. سنَستخدِم المُتْغيِّرات boat و bomb و sub للإشارة إلى كُلًا من كائنات القارب والقنبلة والغواصة على الترتيب. الآن، ما هي حالة (state) البرنامج؟ أو ما الأشياء التي ستَتَغيَّر من وقت لآخر بحيث تُؤثِر على مَظهَر أو سُلوك البرنامج؟ بدايةً، تَتَكوَّن الحالة من مَوضِع كُلًا من القارب والقنبلة والغواصة، ولذلك ستَتَضمَّن كائناتها مُتْغيِّرات نُسخ (instance variables) لتَخْزِين مَواضِعها. ثانيًا، من المحتمل أن تَسقُط القنبلة إلى أسفل الشاشة، وهو ما يُشكِّل فارقًا بالحالة، لذلك سنُمثِل ذلك الجانب من الحالة ضِمْن الكائن bomb باِستخدَام مُتْغيِّر من النوع boolean لوجود احتمالين وحيدين، وسيَكُون اسمه هو bomb.isFalling. ثالثًا، قد تتحرك الغواصة لليسار أو لليمين، لذا سنُمثِل ذلك الفرق باِستخدَام مُتْغيِّر آخر من النوع boolean هو sub.isMovingLeft. رابعًا، قد تنفجر الغواصة، وهو ما يُعدّ جزءًا من الحالة، لذا سنُمثِله باِستخدَام مُتْغيِّر من النوع boolean هو sub.isExploding. يَقَع الانفجار عبر متتالية من الأُطر (frames) يزداد حجمه خلالها بصورة تؤثر على مَظهَر الغواصة بكل إطار. بالإضافة إلى ذلك، سنحتاج أيضًا إلى مَعرِفة وقت انتهاء الانفجار حتى نَتَمكَّن من العودة إلى تَحرِيك الغواصة ورسمها بالطريقة العادية، لذا سنُعرِّف مُتْغيِّرًا من النوع int هو sub.explosionFrameNumber للاحتفاظ بعدد الأُطر المرسومة منذ بداية الانفجار، وستُستخدَم قيمته فقط أثناء وقوع الانفجار. كيف ستَتَغيَّر قيم تلك المُتْغيِّرات؟ ومتى؟ في الواقع سيَتَغيَّر بعضها من تلقاء نفسه. على سبيل المثال، تَتَغيَّر مُتْغيِّرات الحالة (state variables) المُمثِلة لمَوضِع الغواصة أثناء تحركها لليسار ولليمين نتيجة للتحريكة (animation) المُدارة باِستخدَام الصَنْف AnimationTimer. بكل مرة يُستدعَى فيها التابع handle()‎، فإنه سيُعدِّل بعض مُتْغيِّرات الحالة لكي تُصبح جاهزة لرسم الإطار (frame) التالي من التحريكة. لمّا كانت كُلًا من الكائنات boat و bomb و sub تُعرِّف التابع updateForNextFrame()‎ المسئول عن تحديث مُتْغيِّراتها لتُصبِح جاهزة للرسم بإطار (frame) التحريكة التالي، فإن التابع handle()‎ فقط يَستدعِي تلك التوابع كالتالي: boat.updateForNewFrame(); bomb.updateForNewFrame(); sub.updateForNewFrame(); بالإضافة إلى مَوضِع الغواصة، تُعدِّل توابع التحديث -بالأعلى- قيم بعض مُتْغيِّرات الحالة (state variables) الآخرى: أولًا، ستزداد قيمة الإحداثي y أثناء سقوط القنبلة. ثانيًا، إذا تَمكَّنت القنبلة من ضَرْب الغواصة، فسيُضبَط المُتْغيِّر isExploding بالكائن المُمثِل للغواصة إلى القيمة true كما سيُضبَط المُتْغيِّر isFalling بالكائن المُمثِل للقنبلة إلى false. ثالثًا، عندما تَسقُط القنبلة إلى أسفل الشاشة، سيُضبَط المُتْغيِّر isFalling إلى false. رابعًا، أثناء انفجار الغواصة، ستزداد قيمة المُتْغيِّر explosionFrameNumber بمقدار الواحد مع كل إطار إلى أن تَصِل إلى قيمة مُحدّدة، سينتهي عندها الانفجار وسيُضبَط المُتْغيِّر isExploding إلى القيمة false. أخيرًا، تُبدِّل الغواصة بين الحركة لليمين والحركة لليسار من وقت لآخر، ولمّا كان اتجاه حركتها مُخزَّنًا بالمُتْغيِّر isMovingLeft بالكائن المُمثِل للغواصة، فإن التابع updateForNewFrame()‎ المُعرَّف بكائن الغواصة سيُغيِّر قيمة isMovingLeft عشوائيًا كالتالي: if ( Math.random() < 0.02 ) { isMovingLeft = ! isMovingLeft; } هنالك احتمالية واحد من الخمسين أن يُعيد الاستدعاء Math.random()‎ قيمة أقل من ٠,٠٢ أي ستُنفَّذ التَعْليمَة isMovingLeft = ! isMovingLeft بمتوسط إطار واحد لكل خمسين إطار. تَعكِس تلك التَعْليمَة قيمة isMovingLeft من false إلى true أو من true إلى false أي أنها تَعكِس اتجاه حركة الغواصة. بالإضافة إلى تَغْييرات الحالة (state) الواقعة بين كل إطار (frame) والإطار الذي يليه، فهنالك تَغْييرات آخرى بمُتْغيِّرات الحالة ولكنها تَقَع عندما يَضغَط المُستخدِم على مفاتيح معينة. يَفْحَص مُعالِج الحَدَث KeyPressed المفتاح الذي ضَغَطَ عليه المُستخدِم، فإذا كان أي من المفتاحين "سهم يسار" أو "سهم يمين"، فإنه سيُعدِّل من مَوضِع القارب. أما إذا كان مفتاح "سهم لأسفل"، فإنه سيُغيِّر حالة القنبلة من عدم السقوط إلى السقوط. تَستعرِض الشيفرة التالية جزءًا من مَتْن تابع التطبيق start()‎ يُعرِّف خلالها المُعالِج بهيئة تعبير لامدا (lambda expression) مُسجَّل بالكائن scene المُمثِل للمشهد: scene.setOnKeyPressed( evt -> { // ‫يستجيب مستمع الحدث إلى أحداث KeyPressed على الحاوية // تحرك مفاتيح سهم يمين و سهم يسار القارب // بينما يحرر مفتاح سهم لأسفل القنبلة KeyCode code = evt.getCode(); // أي مفتاح ضُغط عليه if (code == KeyCode.LEFT) { boat.centerX -= 15; } else if (code == KeyCode.RIGHT) { boat.centerX += 15; } else if (code == KeyCode.DOWN) { if ( bomb.isFalling == false ) bomb.isFalling = true; } } ); لاحِظ أنه ليس من الضروري إعادة رَسْم الحاوية (canvas) بذلك التابع؛ لأنها في الواقع تَعرِض تحريكة (animation) يُعَاد رسمها باستمرار على أية حال أي ستُصبِح أي تغييرات بالحالة (state) مرئية للمُستخدِم بمُجرّد رسم الإطار التالي. لابُدّ لنا من أن نَتَأكَّد من أن المُستخدِم لا يُحاوِل تحريك القارب إلى خارج الشاشة، وهو ما كان بإمكاننا القيام به بمُعالِج الحدث (event handler)، ولكننا سنقوم به ببرنامج (routine) آخر مُعرَّف بالكائن المُمثِل للقارب. سيَكُون من الأفضل لو تَمكَّنت من قراءة الشيفرة المصدرية للبرنامج بالملف SubKiller.java. قد تَكُون بعض أجزاء تلك الشيفرة صعبة نوعًا ما، ولكن بقليل من الجهد، ينبغي أن تَكُون قادرًا على قراءة البرنامج بالكامل وفهمه. حَاوِل التَفْكير بالبرنامج من وجهة نظر "آلات الحالة (state machines)"، ولاحِظ كيفية تَغيُّر حالة كُلًا من الكائنات الثلاثة نتيجة للأحداث الواقعة من المؤقت والمُستخدِم. على الرغم من أن تلك اللعبة ليست متقدمة بالموازنة مع لعب آخرى إلا أنها تُبيِّن كيفية تطبيق فكرة آلة الحالة (state-machine) بالبرمجة المبنية على الأحداث (event-oriented programming). القيم القابلة للمراقبة (observable) هنالك نوع آخر من الأحداث البسيطة تلعب دورًا مُهِمًّا بمنصة جافا إف إكس (JavaFX) هي الأحداث الواقعة عند تَعْدِيل قيمة "قابلة للمراقبة (observable)". فمثلًا، يَستخدِم البرنامج SubKiller من القسم السابق كائن stage من الصَنْف Stage لديه خاصية (property) من النوع ObservableBooleanValue تُحدِّد ما إذا كان الكائن يُمثِل النافذة الواقع عليها التركيز (focused window)، والتي تستطيع جَلْب قيمتها باستدعاء stage.focusedProperty()‎. عندما تَتَغيَّر قيمة خاصية من النوع ObservableBooleanProperty، يَقَع حدث (event). يُمكِنك أن تُسجِّل مُستمِع تَغْيير (change listener) من الصَنْف ChangeListener بتلك الخاصية، والذي يَتَضمَّن تابع معالج حدث (event handler) يُستدعَى عند وقوع الحدث. في تلك الحالة، سيَستقبِل ذلك التابع ثلاثة مُعامِلات: الخاصية القابلة للمراقبة (observable) المسئولة عن توليد الحَدَث، والقيمة السابقة للخاصية، والقيمة الجديدة. نوع القيمة القديمة والجديدة لخاصية من النوع ObservableBooleanValue هو boolean. هنالك أنواع قيمة آخرى "قابلة للمراقبة (observable)" مثل ObservableIntegerValue و ObservableStringValue و ObservableObjectValue. ستبقى التحريكة (animation) مُشغَّلة حتى لو لم يَعُدْ التركيز واقعًا على نافذة SubKiller، وهو ما قد يَكُون مزعجًا عند محاولة العمل على نافذة آخرى، لهذا سنُوقِف التحريكة (animation) مؤقتًا عندما تفقد النافذة التركيز وسنُعيد تَشْغِيلها عندما تَكْتسِبه مرة آخرى. عندما تفقد النافذة التركيز أو تَكْتسِبه، ستَتَغيَّر قيمة الخاصية stage.focusedProperty()‎ المنطقية والقابلة للمراقبة (observable). للاستجابة لذلك التَغْيير، سنُضيف مُستمِع تَغْيير (change listener) لتلك الخاصية بحيث يُوقِف التحريكة عن العمل عندما تَتَغيَّر قيمة الخاصية إلى false ويُشغِّلها عندما تَتَغيَّر قيمتها إلى true. سنُضيف الشيفرة التالية إلى التابع start()‎: stage.focusedProperty().addListener( (obj,oldVal,newVal) -> { // يوقف المستمع التحريكة إذا لم تعد نافذة البرنامج // محل التركيز if (newVal) { // أصبحت النافذة محل التركيز timer.start(); } else { // لم تعد النافذة محل التركيز timer.stop(); } draw(); // أعد رسم الحاوية }); يُسجِّل التابع addListener()‎ لخاصية "قابلة للمراقبة" (observable) مُستمِع تَغْيير (change listener) بتلك الخاصية. يَستقبِل تعبير لامدا (lambda expression) لمُعالِج الحَدَث (event handler) ثلاثة مُعامِلات (parameters). اِستخدَمنا فقط المُعامِل newVal بالأعلى، والذي يُمثِل القيمة الحالية للخاصية focused بالكائن المُمثِل للمرحلة (stage). تتضمن مكونات واجهة المستخدم الرسومية (GUI) بمنصة جافا إف إكس (JavaFX) خاصيات عديدة قابلة للمراقبة (observable) من أنواع مختلفة. على سبيل المثال، نص الزر هو خاصية من النوع ObservableStringProperty وكذلك عَرْض حاوية (canvas) وارتفاعها عبارة عن قيم من النوع ObservableDoubleProperty. سنَتَعرَّض لمزيد من الأمثلة بالقسم التالي. ترجمة -بتصرّف- للقسم Section 3: Basic Events من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

سنُناقش خلال هذا القسم بعضًا من الأصناف البسيطة المُستخدَمة لتَمثيِل كُلًا من الألوان والخطوط والصور، كما سنرى طريقة اِستخدَامها مع كائن السياق الرسومي GraphicsContext الذي تَعرَّضنا له مبدئيًا بالقسم ٣.٩. إلى جانب ذلك، تستطيع أيضًا اِستخدَام تلك الأصناف بأجزاء آخرى من مكتبة جافا إف إكس (JavaFX). وأخيرًا، سنتناول مقدمة مُختصَرة عن أوراق الأنماط المُتعاقبة (CSS style sheet) والتي يُمكِنك أن تَستخدِمها للتَحكُّم بالكثير من الجوانب المرئية لمُكوِّنات واجهة المُستخدِم الرسومية (GUI). الأصناف Color و Paint يشيع اِستخدَام نظام الألوان RGB لتَخْصِيص الألوان عمومًا. يَتَألف كل لون وفقًا لهذا النظام من ثلاثة أعداد يُطلق عليها اسم "مُكوِّنات اللون (color components)" والتي تُعطِي درجات الأحمر والأخضر والأزرق باللون. بمكتبة جافا إف إكس (JavaFX)، يُستخدَم كائن من النوع Color المُعرَّف بحزمة javafx.scene.paint لتمثيل لون معين. كل مُكوِّن لون من المُكوِّنات الثلاثة هو قيمة من النوع double تَقَع بنطاق يتراوح بين ٠ و ١. تَملُك الكائنات من النوع Color مُكوِّنًا رابعًا أيضًا تتراوح قيمته بين ٠ و ١، ويُشار إليه باسم مكون اللون "ألفا (alpha)"، ويُستخدَم لتَمثيِل درجة شفافية (transparency) أو عتمة (opaqueness) اللون عند اِستخدَامه للرَسْم. إذا اِستخدَمت لونًا مُعتِمًا تمامًا (مُكوِّن اللون ألفا يُساوِي ١) للرَسْم، فسيَحلّ ذلك اللون مَحلّ اللون الحالي لسطح الرسم أما إذا اِستخدَمت لونًا شفافًا تمامًا (مُكوِّن اللون ألفا يُساوِي ٠)، فلن يَكُون له أي تأثير نهائيًا. إذا وَقَع مُكوِّن اللون ألفا بين ٠ و ١، يُخلَط لون الرسم مع اللون الحالي ليُعطِي لونًا جديدًا لسطح الرسم، ويبدو عندها المحتوي الأصلي لسطح الرسم كما لو كان مرئيًا من خلف نظارة مُلوَّنة شفافة. يُمكِنك إنشاء كائن من النوع Color بإعطاء قيمة مُكوِّنات اللون الأربعة (الأحمر والأخضر والأزرق وألفا) على النحو التالي: Color myColor = new Color( r, g, b, a ); حيث r و g و b و a واقعة بنطاق يَتَراوح من ٠ إلى ١. يَملُك الصَنْف Color أيضًا عددًا من التوابع الساكنة (static methods) لإنشاء كائنات. ملحوظة: يُطلق اسم "التوابع المُنتِجة (factory methods)" على التوابع الساكنة التي يَقْتصِر دورها على إنشاء كائنات. تستطيع إذًا أن تَستخدِم تابعًا منتجًا بدلًا من باني الكائن (constructor) كالتالي: Color myColor = Color.color( r, g, b, a ); كما تستطيع اِستخدَام ما يلي إذا كنت تَرغَب بلون مُعتِم تمامًا، أي بقيمة a تُساوِي ١: Color myColor = Color.color( r, g, b ); تُفضَّل التوابع المُنتِجة (factory methods) الساكنة على البواني (constructor) عمومًا لأنها تُمكِّنك من إعادة اِستخدَام نفس كائنات الألوان من الصَنْف Color. على سبيل المثال، إذا استدعيت التعبير Color.color(0.2,0.3,1.0)‎ أكثر من مرة، فسيُعاد دائمًا نفس الكائن من الصَنْف Color، وهو ما يُعدّ مناسبًا لأن كائنات الألوان غَيْر قابلة للتَعْدِيل (immutable) أي ليس هناك طريقة لتَغْيِير لون بَعْد إِنشائه، لذلك لا حاجة لاِستخدَام كائنات مختلفة لتمثيل نفس اللون. عادةً ما تَستخدِم شاشات الحاسوب لونًا حجمه ٣٢ بت أي تُستخدَم مساحة قدرها ٨ بت لتمثيل كل مُكوِّن من مُكوِّنات اللون (color components) الأربعة، والتي يُمكِنها أن تُمثِل ٢٥٦ عدد صحيح بنطاق يتراوح من ٠ إلى ٢٥٥، ولهذا تُخصَّص ألوان الحاسوب باِستخدَام مُكوِّنات لون قيمتها تتراوح بين ٠ و ٢٥٥. يمتلك الصَنْف Color التابع الساكن (static method) التالي لإنشاء ألوان بتلك الطريقة: Color.rgb( r, g, b ) حيث r و g و b هي أعداد صحيحة واقعة بنِطاق يَتَراوح من ٠ إلى ٢٥٥. يَتَوفَّر أيضًا Color.rgb(r,g,b,a)‎ حيث r و g و b هي أعداد صحيحة واقعة بنطاق يَتَراوح من ٠ إلى ٢٥٥ بينما a هي قيمة من النوع double تتراوح من ٠ إلى ١. يَتَألف كل لون وفقًا لهذا النظام من ثلاثة أعداد يُطلق عليها اسم "مُكوِّنات اللون (color components)" والتي تُعطِي درجات الأحمر والأخضر والأزرق باللون. بالإضافة إلى نظام الألوان RGB، يَشيِع أيضًا اِستخدَام نظام الألوان HSB. يَتَألف كل لون وفقًا لهذا النظام من ثلاثة أعداد تُحدِّد كُلًا من: درجة اللون (hue) والإشباع (saturation) والسطوع (brightness). درجة اللون (hue) هي اللون الأساسي بدايةً من الأحمر مرورًا بالبرتقالي وغيرها من ألوان الطيف الأخرى أما السطوع (brightness) فمعناها مفهوم ضمنيًا. بالنسبة للإشباع (saturation)، فاللون المُشبع (saturated) تمامًا هو لون نقي، ويُمكِننا تَقْليِل درجة إشباع لون معين بخلطه مع لون أبيض أو رمادي. بمكتبة جافا إف إكس (JavaFX)، تُعطَى درجة اللون (hue) كقيمة من النوع double تَتَراوح من ٠ إلى ٣٦٠ أما الإشباع (saturation) والسطوع (brightness) فهي قيم من النوع double تتراوح من ٠ إلى ١. تُخصَّص قيمة درجة اللون بوحدة الدرجة (degrees) كما لو كانت جميع الألوان مُمدَّدة عبر دائرة بحيث تُمثِل الدرجتان ٠ و ٣٦٠ لونًا أحمرًا نقيًا. يُعرِّف الصَنْف Color التابعين الساكنين Color.hsb(h,s,b)‎ و Color.hsb(h,s,b,a)‎ لإنشاء ألوان بنظام HSB. على سبيل المثال، يُمكِنك اِستخدَام الشيفرة التالية لإنشاء لون مُشِع (bright) ومُشبِع (saturated) بأقصى ما يُمكِن، وبدرجة لون (hue) عشوائية: Color randomColor = Color.hsb( 360*Math.random(), 1.0, 1.0 ); يُعدّ نظامي اللون RGB و HSB طريقتين مختلفين لوصف نفس مجموعة الألوان، ويُمكِننا في الواقع أن نُحوِّل بينهما. الطريقة الأفضل عمومًا لفهم أنظمة الألوان هو تجريبها، وهو ما تستطيع القيام به باِستخدَام المثال التوضيحي SimpleColorChooser.java. لن تَفهَم شيفرة البرنامج بالكامل، ولكن يُمكِنك أن تُشغِّله وتُجرِّبه. يحتوي الصنف Color على عدد كبير من الثوابت (constants) الممثلة للألوان مثل Color.RED و Color.BLACK و Color.LIGHTGRAY و Color.GOLDENROD. لاحظ أن اللون Color.GREEN يمثل اللون الأخضر الداكن المعطى باستخدام Color.rgb(0,128,0)‎ أما ذلك المعطى باستخدام Color.rgb(0,255,0)‎ فيُمثِل Color.LIME. يتوفر أيضًا اللون Color.TRANSPARENT والذي يمثل لونًا شفافًا تمامًا حيث جميع مكونات اللون RGBA الأربعة تُساوي صفر. بفَرْض وجود مُتْغيِّر c يُشير إلى كائن من النوع Color، يُمكِنك استدعاء دوال مثل c.getRed()‎ و c.getHue()‎ و c.getOpacity()‎ لجَلْب قيم مُكوِّنات اللون المختلفة. تُعيد تلك التوابع (methods) قيمًا من النوع double بنطاق يَتَراوح من ٠ إلى ١ باستثناء التابع c.getHue()‎ والذي يُعيد قيمًا من النوع double تَقَع بنطاق يَتَراوح من ٠ إلى ٣٦٠. لاحِظ أن Color هو صَنْف فرعي (subclass) من الصَنْف Paint والذي يُمثِل الفكرة الأعم لشيء يُمكِن اِستخدَامه لمَلْئ (fill) الأشكال ورَسْم حوافها (stroke). إلى جانب الألوان، يُمكِنك أيضًا اِستخدَام طلاءً مُكوَّنًا من صور (image paints) أو طلاءً مُتدرجًا (gradient paints). سنُعود للحديث عن ذلك بالقسم الفرعي ١٣.٢.٢ أما الآن فينبغي أن تَعلَم فقط أنه بإِمكانك أن تَستخدِم كائنًا من النوع Color كقيمة لمُعامل (parameter) من النوع Paint. الخطوط Font يُعبِر الخط (font) عن كُلًا من هيئة النص وحجمه، فيختلف مَظهَر المحرف (character) ذاته بتَغَيُّر الخط. تُستخدَم كائنات من النوع Font المُعرَّف بحزمة javafx.scene.text لتمثيل الخطوط بمنصة جافا إف إكس (JavaFX). يُوفِّر الصَنْف Font عددًا من البواني (constructors) وكذلك بعضًا من التوابع المُنتِجة (factory methods) الساكنة لإنشاء كائن خط من الصَنْف Font، ويُفضَّل عمومًا استخدام التوابع المُنتِجة عن التوابع. كل خط له اسم عبارة عن سِلسِلة نصية تُخصِّص نوع الخط (font family) مثل "Times New Roman". عادة ما تَتَوفَّر نسخ مختلفة لنفس نوع الخط، مثلًا نُسخة عريضة (bold) وآخرى مائلة (italic). أخيرًا، يُقاس حجم الخط (size) بوحدة النقاط (points)، والتي تُعادِل حوالي ١\٧٢ بوصة، وتُساوِي عمليًا حجم بكسل واحد. يُمكِنك اِستخدَام الدالة (function) التالية لإنشاء خط: Font myFont = Font.font( family, weight, posture, size ); إذا لَمْ يَجِد النظام خطًا تَتَطابَق خاصياته مع قيم المُعامِلات (parameters) المُمرَّرة تطابقًا كليًا، فإنه يُعيِد خطًا أقرب ما يَكُون إليها. أولًا، المُعامِل family هو عبارة عن سِلسِلة نصية من الصنف String تُخصِّص إحدى أنواع الخطوط المتاحة للبرنامج. في الواقع، ليس هنالك مجموعة خطوط لابُدّ أن تَكُون متاحة في العموم، ومع ذلك من المُتوقَّع دومًا أن تَعمَل خطوط مثل "Times New Roman" و "Arial" و "Verdana"، والتي صنعتها مايكروسوفت (Microsoft) ونشرتها للاستخدام الحر، وهي مُثبَّتة بالكثير من الأنظمة. يُمكِنك أن تُمرِّر null كقيمة لهذا المُعامِل، وسيَستخدِم النظام عندها نوع الخط الافتراضي. ثانيًا: يَستقبِل المُعامِل weight إحدى قيم نوع التعداد FontWeight لتَخْصِيص وزن الخط. عادة ما تَكُون القيمة المُمرَّرة هي FontWeight.BOLD أو FontWeight.NORMAL على الرغم من وجود عدة قيم آخرى مثل FontWeight.EXTRA_BOLD. بالمثل، يُمرَّر للمُعامِل posture أي من الثابتين FontPosture.ITALIC و FontPosture.REGULAR لتَخْصيص وَضْع الخط. لاحِظ أن التعدادين FontWeight و FontPosture مُعرَّفان بحزمة javafx.scene.text. يَتَضمَّن الصَنْف Font بعض الدوال (functions) الساكنة الآخرى المُستخدَمة لإنشاء خطوط، وتَستقبِل كل واحدة منها مجموعة معينة من الخاصيات الأربعة: family و weight و posture و size مثل الدوال Font.font(size)‎ و Font.font(family)‎ و Font.font(family,weight,size)‎ وغيرها. تَتَوفَّر قيم افتراضية للخاصيات غَيْر المُمرَّرة تعتمد عادةً على الحاسوب المُشغَّل عليه البرنامج. تُعيد الدالة الساكنة Font.getDefault()‎ خطًا تَستخدِم جميع خاصياته قيمها الافتراضية، ويُمكِنك مثلًا أن تَستدعِي Font.getDefault().getSize()‎ لمَعرِفة الحجم الافتراضي للنقطة (point). اُنظر الأمثلة التالية لإنشاء خطوط: Font font1 = Font.font(40); Font font2 = Font.font("Times New Roman", FontWeight.BOLD, 24); Font font3 = Font.font(null, FontWeight.BOLD, FontPosture.ITALIC, 14); الصور Image تُوفِّر منصة جافا إف إكس (JavaFX) الصَنْف Image بحزمة javafx.scene.image لتمثيل "الصور (images)"، والتي قد تَكُون بهيئة صورة فوتوغرافية أو رسم أو أي شيء آخر يُمكِن تمثيله بهيئة شبكة مستطيلة من البكسلات الملونة. تُخزَّن تلك الصور بملفات يُمكِن تحميلها بسهولة تمهيدًا لعَرْضها ضِمْن البرنامج. يُكْتَب الباني (constructor) كالتالي: new Image( path ) يُحمِّل الباني بالأعلى صورة من ملف. يَستقبِل ذلك الباني سِلسِلة نصية (string) كقيمة للمُعامِل path تُخصِّص موقع (location) الملف. قد يَقَع الملف بشبكة الإنترنت أو بجهاز المُستخدِم، وسنُركِّز هنا فقط على تلكم الواقعة ضِمْن ملفات الموارد (resource). تُسمَى أجزاء البرنامج من غير ملفات الشيفرة باسم الموارد (resource)، والتي قد تَتَضمَّن أنواع مختلفة من الملفات كملفات الصوت والبيانات والخطوط والصور. بإمكان النظام أن يُحمِّل تلك الموارد (resources) من نفس المسارات التي يبحث فيها عن ملفات ‎.class. مثلًا، إذا كان لدينا ملف مورد (resource file) بمجلد البرنامج الرئيسي، فإن مساره يَقْتصِر على اسمه أما إذا كان الملف موجودًا بمجلد فرعي داخل المجلد الرئيسي، فلابُدّ أن يَتَضمَّن مساره اسم ذلك المجلد الفرعي. مثلًا، يُشير المسار "images/cards.png" إلى ملف اسمه "cards.png" بمجلد فرعي اسمه "images"، أما المسار "resources/sounds/beep.aiff" فيُشير إلى ملف اسمه "beep.aiff" بمجلد اسمه "sounds" والذي بدوره يَقَع بمجلد اسمه "resources". تَتَوفَّر صيغ (formats) مختلفة لتَخْزين الصور، وتستطيع الكائنات من الصَنْف Image أن تتعامل في العموم مع ملفات الصور التي تنتهي أسمائها بإحدى الامتدادات التالية: ‎.gif و ‎.jpeg و ‎.jpg و ‎.png و ‎.bmp. فمثلًا، إذا كان الملف "cards.png" واقعًا بمجلد البرنامج الرئيسي، يُمكِننا أن نُنشِئ كائنًا من الصنف Image لتمثيله كالتالي: Image cards = new Image( "cards.png" ); سنرى بعد قليل طريقة عَرْض الصورة ضِمْن سياق رسومي (من الصنف GraphicsContext)، كما سنناقش بعض الاستخدامات الأخرى للصور لاحقًا. الحاوية Canvas والسياق الرسومي GraphicsContext تَتَكوَّن أي شاشة حاسوب من شبكة من المربعات الصغيرة يُطلَق على كُلًا منها اسم "بكسل (pixel)". نستطيع أن نَضبُط لون كل بكسل منها على حدى، وبالتالي يُمكِننا أن نَرسِم أي شيء على الشاشة مثل أي من مُكوِّنات الواجهة (GUI component). تستطيع غالبية مُكوِّنات الواجهة أن تَرسِم نفسها كما تَملُك نظامًا إحداثيًا لتَحْوِيل الإحداثيات (x,y) إلى نقط واقعة عليها. بالإضافة إلى ذلك، يتوفَّر مُكوِّن وحيد عبارة عن "مساحة رسم (drawing surface)" تستطيع أن تَرسِم عليه أي شيء فقط باستدعاء بعض التوابع (methods) المناسبة. مُكوِّنات مساحة الرسم تلك هي من نوع الحاوية Canvas المُعرَّف بحزمة javafx.scene.canvas، والتي تُعدّ عُقدًا من الصَنْف Node أي يُمكِنها أن تَكُون جُزءًا من مبيان مَشهَد (scene graph)، ولكنها ليست من الصَنْف Parent لذا لا يُمكِنها أن تَعمَل كحاوي (container) لعُقَد آخرى كما لا يُمكِنها أن تَكُون المُكوِّن الجذري (root) لمبيان مَشهَد. يَعنِي ذلك أنه حتى لو رغبت برسم كائن حاوية (canvas) فقط على نافذة، فلابُدّ من أن تَضَعُه أولًا ضِمْن حاوي (container) يَعمَل كمُكوِّن جذري لمبيان مشهد (scene graph) تلك النافذة. تبدو الحاوية من الصَنْف Canvas بهيئة مستطيل من البكسلات (pixels) على الشاشة. يُستخدَم زوج من الإحداثيات (x,y) للإشارة إلى مَوضِع معين ضِمْن ذلك المستطيل، والذي يُمثِل رُكنه الأيسر العلوي إحداثيات النقطة (٠،٠)، وبحيث تزداد قيمة الإحداثي x من اليسار إلى اليمين بينما تزداد قيمة الإحداثي y من الأعلى إلى الأسفل. تُوضِح الصورة التالية الكيفية التي تُلوَّن بها البكسلات لرَسْم شكل معين مثل خط صغير أو مستطيل أو شكل بيضاوي على حاوية (canvas) بمساحة ١٢ * ١٢ بكسل. لا تَقَع إحداثيات النقط داخل البكسلات ذاتها وإنما على خطوط الشبكة (grid) الفاصلة بينها، ولمّا كانت تلك الإحداثيات أعدادً من النوع double، فإنها قد تُضبَط لكي تُشيِر إلى موضع داخل بكسل. على سبيل المثال، تُمثِل الإحداثيات (٠.٥، ٠.٥) مركز البكسل الأيسر العلوي بحاوية (canvas) معينة. ملحوظة: تُرسَم كل الأشكال عمومًا باستخدام إحداثيات من النوع double. يُوفِّر الصَنْف Canvas باني كائن (constructor) يَستقبِل كُلًا من عرض الحاوية (canvas) وارتفاعها. يُمكِننا مثلًا إنشاء حاوية صغيرة جدًا بحجم ٢٠ * ١٢ بكسل كالتالي: Canvas canvas = new Canvas(20,12) نستطيع مَعرِفة حجم حاوية (canvas) معينة باستدعاء التابعين canvas.getWidth()‎ و canvas.getHeight()‎ ويُعيد كُلًا منهما قيمة من النوع double. لا نحتاج عادةً إلى إعادة ضَبْط حجم حاوية بَعْد إنشائها، ومع ذلك يُوفِّر الصَنْف التابعين canvas.setWidth(w)‎ و canvas.setHeight(h)‎ لإعادة ضَبْط حجم حاوية إن اقتضت الضرورة. لاحِظ أن الحاوية (canvas) تَكُون شفافة (transparent) بمُجرّد إنشائها، وذلك لأنها تُملأ افتراضيًا بلون أسود شفاف (transparent black) جميع مُكوِّناته RGBA مُساوية للصفر، ولهذا يُمكِن رؤية ما هو موجود خلفها ضِمْن المشهد (scene). الآن لكي نَتَمكَّّن من الرسم على أي حاوية (canvas)، سنحتاج إلى كائن سياق رسومي (graphics context) من النوع GraphicsContext. يُقابِل أي كائن حاوية من الصَنْف Canvas كائن سياق رسومي من الصَنْف GraphicsContext خاص به. بتعبير آخر، يَرسِم كل كائن سياق رسومي مختلف من الصَنْف GraphicsContexts على كائن حاوية مختلف من الصَنْف Canvas. بفَرْض أن لدينا مُتْغيِّر كائن حاوية اسمه canvas من الصنف Canvas، يُمكِننا استدعاء التابع canvas.getGraphicsContext2D()‎ لمَعرِفة كائن السياق الرسومي (graphics context) للحاوية. سيُعيد ذلك التابع (method) نفس كائن السياق الرسومي دومًا لنفس كائن الحاوية. خلال القسم ٣.٩، تَعامَلنا مع كائن سياق رسومي (graphics context)، وتَعلَّمنا عمومًا كيفية رَسْم حواف (stroke) شكل معين أو ملؤه (fill) في حالة كان لديه جزءًا داخليًا. نَستعرِض الآن التوابع التي يُمكِننا اِستخدَامها بكائن سياق رسومي g من الصَنْف GraphicsContext مع مراعاة كَوْن جميع المُعامِلات (parameters) العَدَدية لتلك التوابع من النوع double: التابعان g.strokeRect(x,y,w,h)‎ و g.fillRect(x,y,w,h)‎: يَرسِم كلاهما مستطيلًا بعَرْض w وارتفاع h وبحيث يَقَع ركنه الأيسر العلوي بإحداثيات النقطة (x,y). لن يُرسَم أي شيء إذا كانت قيمة أي من المُعامِلين w أو h أقل من أو تُساوِي الصفر. التابع g.clearRect(x,y,w,h)‎: يَملأ المستطيل بلون شفاف (transparent) تمامًا، وبالتالي يُمكن رؤية ما كان موجودًا خلفه عبر الحاوية (canvas)، وهو ما يختلف عن استدعاء التابع g.fillRect(x,y,w,h)‎ باِستخدَام لون مَلْئ (fill color) شفاف، ففي تلك الحالة، لا يَكُون هناك أي تأثير على محتويات المستطيل. التابعين g.strokeOval(x,y,w,h)‎ و g.fillOval(x,y,w,h)‎: يَرسِم كلاهما شكلًا بيضاويًا يَقَع داخل مستطيل عَرْضه هو w وارتفاعه هو h وبحيث يَقَع ركنه الأيسر العلوي بإحداثيات النقطة (x,y). التابعان g.strokeRoundRect(x,y,w,h,rh,rv)‎ و g.fillRoundRect(x,y,w,h,rh,rv)‎: يَرسِم كلاهما مستطيلًا دائري الأركان بعَرْض w وارتفاع h وبحيث يَقَع ركنه الأيسر العلوي بإحداثيات النقطة (x,y). يُقطَّع من كل ركن ربع بيضاوي نصفي قطره الأفقي والرأسي مُساوي للقيم rh و rv على الترتيب. التابعان g.strokeText(str,x,y)‎ و g.fillText(str,x,y)‎: يَرسِم كلاهما سِلسِلة نصية من النوع String وبحيث يَقَع الطرف الأيسر من خط النص الأساسي (text baseline) بنقطة الإحداثيات (x,y). تُرسَم أي سِلسِلة نصية (string) عمومًا فوق خط أساسي (baseline) مع إمكانية لتدلّي بعض الأجزاء كذيل الحرف "y" الذي يَمتد إلى ما بَعْد الخط الأساسي بقليل. إذا اِمتدَّت سِلسِلة نصية معينة عَبْر عدة أسطر مفصولة بمحرف سطر جديد ‎\n، ستُشير عندها نقطة الإحداثيات (x,y) إلى طرف الخط الأساسي (baseline) الأيسر لأول سطر بالسِلسِلة النصية. لاحِظ أن رَسْم حواف (stroking) نص معين يعني مُجرّد رَسْم حواف محارفه (characters) الخارجية. التابعان g.strokePolygon(xcoords,ycoords,n)‎ و g.fillPolygon(xcoords,ycoords,n)‎: يَرسِم كلاهما مُضلعًا (polygon) مُكوَّنًا من عدة خطوط تَربُط مجموعة من النقط بعضها ببعض، والتي تُحدَّد إحداثياتها بالقيم المُمرَّرة للمُعامِلين الأول والثاني، وتَكُون بهيئة مصفوفة من النوع double[]‎. يَستقبِل التابعان أيضًا مُعامِلًا ثالثًا n يُشير إلى عدد تلك النقاط. يَصِل المُضلع النقط التالية مع بعضها البعض: (xcoords[0],ycoords[0]‎) و (xcoords[1],ycoords[1]‎) و … و (xcoords[n-1],ycoords[n-1]‎) و (xcoords[0],ycoords[0]‎) أي يَصِل تلقائيًا خط إضافي أخير بين النقطتين الأولى والأخيرة. التابع g.strokeLine(x1,y1,x2,y2)‎: يَرسِم خطًا يبدأ من إِحداثيَّات نقطة البداية (x1,y1) وحتى إِحداثيَّات نقطة النهاية (x2,y2). ولأن الخط لا يَملُك جزءًا داخليًا، فليس هنالك أي مَعنَى لمحاولة ملؤه (fill). يَملُك أي كائن سياق رُسومي g من الصَنْف GraphicsContext عددًا من الخاصيات التي تُؤثِر على عملية الرَسْم حيث تُستخدَم القيم الحالية لخاصياته عند اِستخدَامه لرَسْم أي شيء. يُناظِر كل خاصية منها تابعي ضَبْط (setter method) وجَلْب (getter method)، ولكن لاحِظ أن أي تَغْيِير يُجرَى على أي من تلك الخاصيات لن يُؤثِر على ما قد رُسِم بالفعل وإنما يُطبَق فقط على ما سيُرسَم مستقبلًا. على سبيل المثال، تُعدّ الطريقة المُستخدَمة للمَلْئ (filling) واحدة من تلك الخاصيات ويُسنَد إليها كائن من الصَنْف Paint. يَتَوفَّر التابعان g.setFill(paint)‎ و g.getFill()‎ لضَبْط قيمة تلك الخاصية وجَلْبها على الترتيب. سنَستخدِم كائنًا من الصَنْف Color لهذه الخاصية دائمًا خلال هذا الفصل. الطريقة المُستخدمَة لرَسْم حواف الأشكال (stroking) هي خاصية آخرى بكائن السياق الرسومي ويُسنَد إليها أيضًا كائن من الصَنْف Paint يُمكِن ضَبْطه وجَلْبه باِستخدَام التابعين g.setStroke(paint)‎ و g.getStroke()‎ على الترتيب. يُمكِن أيضًا ضَبْط خاصية حجم الحواف (strokes) وجَلْب قيمتها باستدعاء التابعين g.setLineWidth(w)‎ و g.getLineWidth()‎ على الترتيب حيث w قيمة من النوع double. يَتَوفَّر أيضًا التابعان g.setFont(font)‎ و g.getFont()‎ لضَبْط قيمة خاصية الخط (font) المُستخدَم لرسم النصوص وجَلْب قيمتها على الترتيب. إن عملية رَسْم حواف شكل معين (stroking) هي أَشْبه ما تَكُون بعملية سَحب قلم على طول حواف ذلك الشكل، وبحيث تُرسَم تلك الحواف على جانبي المسار الفعلي للقلم بعَرْض يُساوِي نصف عَرْض (width/size) القلم على كل جانب. يُحدَّد عَرْض القلم باِستخدَام الخاصية linewidth. على سبيل المثال، إذا رسمنا خطًا أفقيًا بين النقطتين (١٠٠ ،١٠٠) و (٣٠٠، ١٠٠) بعَرْض يُساوِي ١، فسيَقَع نصف الحافة (stroke) أعلى الخط الأفقي بينما سيقع النصف الآخر أسفله، لذلك لا يُغطَى البكسل بالكامل ويضطرّ الحاسوب عندها لخَلْط كُلًا من اللون المُستخدَم لرسم الحافة واللون الحالي للبكسل. في المقابل، إذا رسمت خطًا بين النقطتين (١٠٠.٥، ١٠٠.٥) و (٣٠٠.٥، ١٠٠.٥)، فسيُغطَي البكسل بالكامل. في العموم، عندما تَرسِم شيئًا يُغطِي بكسلًا معينًا تغطية جزئية، فإن اللون المُستخدَم للرسم يُمزَج مع اللون الحالي للبكسل بدلًا من أن يستبدله، وذلك لتقليل خشونة الأشكال المُكوَّنة من بكسلات كاملة مثل الخط والشكل البيضاوي بالصورة السابقة، وهو ما يُعرَف بإجراء "التنعيم (anti-aliasing)". يُمكِننا أيضًا أن نرسم كائن صورة من النوع Image داخل حاوية (canvas)، ونَستعرِض فيما يلي بعضًا من التوابع (methods) المُستخدَمة لهذا الغرض: التابع g.drawImage(image,x,y)‎: يَستقبِل صورة من خلال المُعامِل image من النوع Image، ويَرسمها بحيث يَقَع ركنها الأيسر العلوي بإحداثيات النقطة (x,y)، وتَظَهَر الصورة بحجمها الفعليّ. التابع g.drawImage(image,x,y,w,h)‎: يَرسِم الصورة المُمثَلة بالمُعامِل image داخل مستطيل يَقَع ركنه الأيسر العلوي بإحداثيات النقطة (x,y) بعَرْض يُساوِي w وارتفاع يُساوِي h. قد تَمتدّ الصورة أو تنكمش بحيث تتلائم مع المستطيل الحاضن لها. التابع g.drawImage(image,sx,sy,sw,sh, dx,dy,dh,dw)‎: يَرسِم المحتويات الموجودة "بمستطيل مصدر (source)" مُحدَّد ضِمْن الصورة المُمرَّرة image إلى "مستطيل مقصد (destination)" مُحدَّد ضِمْن الحاوية (canvas) مما يَسمَح برسم جزء معين من صورة. يُحدِّد المُعامِلان sx و sy إحداثيات النقطة التي يَقَع بها الركن الأيسر العلوي "لمستطيل المصدر" بينما يُحدِّد المُعامِلان sw و sh كُلًا من عَرْض المستطيل وارتفاعه. بالمثل، تُحدِّد المُعامِلات (parameters) الأربعة الأخيرة المُمرَّرة مَوضِع "مستطيل المقصد" وأبعاده. لنأخُذ بعض الأمثلة الفعلية. يَستخدِم المثال التالي تشكيلة مختلفة من الخطوط (fonts) لرَسْم نص (text). تحديدًا، يَرسِم البرنامج السِلسِلة النصية "Hello JavaFX" بخطوط مختلفة كما يَملْئ (fill) النص بلون عشوائي مع حواف (stroke) سوداء نحيفة، وأخيرًا يضعها بمكان عشوائي. يَستخدِم التابع start()‎ بعض التوابع المُنتجة (factory methods) الساكنة المُعرَّفة بالصنف Font لإنشاء خمسة خطوط (fonts): font1 = Font.font("Times New Roman", FontWeight.BOLD, 20); font2 = Font.font("Arial", FontWeight.BOLD, FontPosture.ITALIC, 28); font3 = Font.font("Verdana", 32); font4 = Font.font(40); font5 = Font.font("Times New Roman",FontWeight.BOLD,FontPosture.ITALIC,60); يُعرِّف البرنامج تابعًا اسمه draw()‎ ويُوكِل إليه مُهِمّة إعادة رَسْم محتويات حاوية (canvas). يُستدعَى ذلك التابع عند إنشاء حاوية (canvas) لأول مرة، وكذلك بكل مرة يَنقُر فيها المُستخدِم على زر "أَعِد الرسم (redraw)". يَملأ التابع أولًا تلك الحاوية (canvas) بخلفية بيضاء لمسح محتوياتها السابقة، ثم يَرسِم ٢٥ نسخة من السِلسِلة النصية "Hello JavaFX" بأماكن عشوائية ضِمْن الحاوية، وبحيث تَكُون كل نُسخة منها مملوءة بلون (fill color) عشوائي ومُحاطة بحواف سوداء وكذلك مرسومة بخط (font) عشوائي: private void draw() { GraphicsContext g = canvas.getGraphicsContext2D(); double width = canvas.getWidth(); double height = canvas.getHeight(); g.setFill( Color.WHITE ); // fill with white background g.fillRect(0, 0, width, height); for (int i = 0; i < 25; i++) { // اضبط الخط لأي من الخطوط الخمسة المتاحة int fontNum = (int)(5*Math.random()) + 1; switch (fontNum) { case 1: g.setFont(font1); break; case 2: g.setFont(font2); break; case 3: g.setFont(font3); break; case 4: g.setFont(font4); break; case 5: g.setFont(font5); break; } // end switch // اضبط اللون إلى درجة لون عشوائية ساطعة ومشبعة double hue = 360*Math.random(); g.setFill( Color.hsb(hue, 1.0, 1.0) ); // اضبط مَوضِع السلسلة النصية عشوائيًا double x,y; x = -50 + Math.random()*(width+40); y = Math.random()*(height+20); // ارسم الرسالة النصية g.fillText("Hello JavaFX",x,y); // ارسم حواف النص باللون الأسود g.setStroke(Color.BLACK); g.strokeText("Hello JavaFX",x,y); } // end for } // end draw() تَتَوفَّر شيفرة البرنامج كاملة بالملف RandomStrings.java. يَرسِم البرنامج التالي ٥ ورق لعب سُحبَت عشوائيًا من مجموعة ورق لعب (deck) كالتالي: اِستخدَمنا الصَنْفين Card و Deck من القسم ٥.٤ لتمثيل كُلًا من ورقة اللعب ومجموعة ورق اللعب على الترتيب. أُخذَت صور ورق اللعب بالأعلى من ملف المورد cards.png الموجود بالبرنامج، والمأخوذ من مشروع جينوم لسطح المكتب. يَتَضمَّن ذلك الملف صورًا لجميع ورق اللعب مُرتَّبة ضِمْن عدد من الصفوف والأعمدة. تَعرِض الصورة التالية نُسخة مُصغرة من ذلك الملف: يُمكِننا تحميل ملف الصورة إلى البرنامج بكتابة التالي داخل التابع start()‎: cardImages = new Image("cards.png"); حيث cardImages هو مُتْغيِّر نُسخة (instance variable) من النوع Image. لنَفْترِض الآن أننا نريد رَسْم ورقة اللعب الواقعة برقمي الصف والعمود R و C على الترتيب ضِمْن كائن سياق رُسومي g من النوع GraphicsContext مع مراعاة أن الصفوف والأعمدة مُرقَّّمة بدءًا من الصفر. لمّا كان حجم أي ورقة لعب بالصورة هو ٧٩ * ١٢٣ بكسل، فإن الركن الأيسر العلوي لأي ورقة لعب يقع بإحداثيات النقطة (‎79*C,123*R) . إذًا، لكي نَضَع ورقة لعب داخل حاوية (canvas) بحيث يقع ركنها الأيسر العلوي بإحداثيات النقطة (x,y)، يُمكِننا أن نَستخدِم النسخة الثالثة من التابع drawImage()‎، والتي تَستقبِل "مستطيل مصدر" ضِمْن صورة بالإضافة إلى "مستطيل مقصد" ضِمْن حاوية (canvas) كالتالي: g.drawImage( cardImages, 79*C,123*R,79,123, x,y,79,123 ); بفَرْض أن المُتْغيِّر card -من النوع Card- يُمثِل ورقة اللعب التي نَرغَب برسمها، يُمكِننا إذًا أن نَستخدِم التابعين card.getValue()‎ و card.getSuit()‎ لمَعرِفة كُلًا من قيمة (value) ورقة اللعب ورمزها (suit) على الترتيب. بعد ذلك، سنحتاج إلى تَحْوِيل هاتين القيمتين بطريقة ما إلى رقمي الصف والعمود المُناظرين لتلك الورقة. لمّا كنا ننوي ترك مسافة قدرها ٣٠ بكسل بين كل ورقة لعب والورقة التي تليها بالحاوية (canvas)، فلابُدّ من مراعاة ذلك عند حِسَاب مَوضِع ورقة اللعب. بالشيفرة التالية، يَسحَب التابع draw()‎ خمسة أوراق من مجموعة ورقة اللعب (deck) سحبًا عشوائيًا ثم يَرسِمها: private void draw() { GraphicsContext g = canvas.getGraphicsContext2D(); Deck deck = new Deck(); deck.shuffle(); // الركن الأيسر العلوي لمستطيل المصدر بصورة ورق اللعب double sx,sy; // الركن الأيسر العلوي لمستطيل المقصد بالحاوية double dx,dy; for (int i = 0; i < 5; i++) { Card card = deck.dealCard(); System.out.println(card); // for testing sx = 79 * (card.getValue()-1); sy = 123 * (3 - card.getSuit()); dx = 20 + (79+20) * i; dy = 20; g.drawImage( cardImages, sx,sy,79,123, dx,dy,79,123 ); } } // end draw() يُمكِنك الإطلاع على النسخة الكاملة من البرنامج بالملف RandomCards.java. التنسيق عبر CSS تُعدّ لغة أوراق الأنماط المتعاقبة (Cascading Style Sheets) -وتُختصَر إلى CSS-، واحدة من ضِمْن عدة لغات يَشيِع اِستخدَامها لإنشاء صفحات الإنترنت، فبإمكانها أن تَتَحكَّم بالألوان والخطوط وكذلك بحواف العناصر ضِمْن الصفحة. تُدعِّم منصة جافا إف إكس (JavaFX) تلك اللغة بغرض ضَبْط مظهر مُكوِّنات واجهة المُستخدِم الرسومية (GUI). في الواقع، يُمكِن للغة الجافا أن تُنفِّذ أي شيء قد تقوم به تلك اللغة، ولكن هنالك بعض الأمور التي يَكُون من الأسهل تّنْفيذها باِستخدَام لغة CSS، وهو ما سنَتعرَض لبعض منه خلال هذا القسم. إذا كنت على دراية بلغة CSS، يُمكِنك الإطلاع على دليل استخدامها بجافا إف إكس. تَتَكوَّن أي قاعدة نمط (style rule) بلغة CSS من خاصية (property) وقيمة، وتبدأ أسماء جميع تلك الخاصيات بمنصة جافا إف إكس (JavaFX) بـالمحارف "-fx-" لتفريقها عن خاصيات CSS العادية. على سبيل المثال، تَتَوفَّر الخاصيات ‎-fx-border-color و ‎-fx-border-width لوَضْع حافة (border) حول كثير من مُكوِّنات الواجهة. يُمكِنك أن تَستخدِم اسم لون مثل red أو lightblue كقيمة للخاصية ‎-fx-border-color أو قد تختار أن تَستخدِم الصياغة ‎#RRGGBB حيث R و G و B هي عبارة عن أرقام ست عشريّة (hexadecimal digits). يُمكِن للأعداد الست عشريّة (hexadecimal number) المُكوَّنة من رقمين (digit) أن تُمثِل الأعداد من ٠ وحتى ٢٥٥، لذا تستطيع RR و GG و BB تمثيل كُلًا من المُكوِّن الأحمر والأخضر والأزرق للون على الترتيب، وتتراوح قيم جميعها من ٠ وحتى ٢٥٥. على سبيل المثال، يُمثِل ‎#FF0000 لونًا أحمرًا نقيًا بينما يُمثِل ‎#004444 لونًا أخضر-أزرق داكنًا. أما بالنسبة لخاصية عَرْض الحافة (border width)، فيُمكِنها أن تُخصَّص بقيمة واحدة مُفردة مُكوَّنة من عدد متبوع بوحدة قياس وبدون أي فراغ بينهما، وفي تلك الحالة، تُطبَق تلك القيمة على جميع جوانب الحافة الأربعة. على سبيل المثال، قد تُستخدَم القيمة "3px" أو "0.2cm". تُشير "px" إلى "بكسل (pixel)" وبالتالي "3px" تَعنِي ثلاثة بكسل. في المقابل، يُمكِن لقيمة الخاصية أن تُخصَّص بأربع قيم يَفصِل بين كُلًا منها فراغ، وذلك لتَحْديد عَرْض كل جانب من جوانب الحافة على حدى وفقًا لهذا الترتيب: أعلى، يمين، أسفل، يسار. يُمكِننا مثلًا تَخْصِيص حافة زرقاء سميكة كالتالي: -fx-border-color: blue; -fx-border-width: 5px أو يُمكِننا اِستخدَام التالي للحصول على حافة حمراء داكنة أكثر سماكة من الأعلى الموازنة مع الجوانب الآخرى: -fx-border-color: #550000; -fx-border-width: 3px 1px 1px 1px عندما تُستخدَم عدة قواعد CSS معًا، لابُدّ أن يَفصِل بينها فاصلة منقوطة. يُمكِننا أيضًا أن نَضبُط لون الخلفية لمُكوِّن واجهة باِستخدَام الخاصية ‎-fx-background-color، وتُخصَّص قيمتها بنفس طريقة تَخْصِيص اللون للخاصية ‎-fx-border-color. في المقابل، يُشار إلى الفراغ المتروك بين محتويات المُكوِّن وحافته الخارجية باسم "الحشوة (padding)"، وتُستخدَم الخاصية ‎-fx-padding لتَحْدِيد عَرْضها. بالمثل من خاصية عَرْض الحافة (border width)، تُخصَّص قيمة ‎-fx-padding إما كقيمة مُفردة مثل ‎-fx-padding: 8px أو كقائمة من أربع قيم. يَستقبِل التابع setStyle()‎ مُعامِلًا (parameter) من النوع String يَتَضمَّن قاعدة نمط (style rule) واحدة أو أكثر، ويُطبِقها على مُكوِّن واجهة معين. على سبيل المثال، لنَفْترِض أن المُتْغيِّر message عبارة عن عنوان نصي (label) من النوع Label. لا تَشتمِل العناوين النصية (labels) على حافة (border) أو حشوة (padding) افتراضيًا، ولكن يُمكِن تَخْصِيص أيًا منها كالتالي: message.setStyle( "-fx-padding: 5px; -fx-border-color: black; -fx-border-width: 1px" ); تَضبُط الخاصية ‎-fx-font الخط المُستخدَم لعَرْض النصوص ضِمْن مُكوِّن واجهة. تُخصِّص قيمة تلك الخاصية كُلًا من نوع الخط (font family) وحجمه، كما يُمكِنها أن تُخصِّص وزن الخط (font weight) مثل "bold" و طريقة تَموضُعه (font posture) مثل "italic" أو كليهما. اُنظر الأمثلة التالية: -fx-font: 30pt "Times New Roman"; -fx-font: bold italic 18pt serif; -fx-font: bold 42pt monospace; لابُدّ من إحاطة اسم نوع الخط (font family) بعلامتي اقتباس (quotes) في حالة احتوائه على أي فراغات. تُعدّ أنواع الخطوط "serif" و "monospace" المُخصَّصة بالمثالين الأخيرين وكذلك الأنواع "sans-serif" و "cursive" و "fantasy" أسماءً عامة (generic) أي أنها تُحدِّد نمط عام للخطوط. على سبيل المثال، يُضَاف إلى المحارف (characters) بالنمط "serif" خطوطًا قصيرة لأغراض جمالية أعلى الحرف "I" وأسفله. في المقابل، لا يُضَاف ذلك إلى المحارف بالنمط "sans-serif". أخيرًا، تَحتَل جميع المحارف بالنمط "monospace" نفس المساحة الأفقية، ولذلك فإنها تُستخدَم عادةً عند الحاجة إلى طباعة المحارف بصورة مُصطفّة ضِمْن أعمدة. يُمكِنك ضَبْط خاصيات أخرى كثيرة باِستخدَام CSS، ولكننا سنكتفي بهذا القدر كما أننا سنَستخدِم CSS فقط لضَبْط الحواف (borders) والحشوات (paddings) وألوان الخلفية والخطوط. عادةً ما تَكُون عملية ضبط الأنماط (style) مملة خاصة عند وجود عدد كبير من مُكوِّنات الواجهة. في المقابل تُسهِل أوراق الأنماط المتعاقبة (CSS style sheet) من تلك العملية حيث يُمكِنها أن تُطبِق نمطًا معينًا (style) على مُكوِّن مُفرد وحيد أو على مجموعة معينة من المُكوِّنات أو على جميع مُكوِّنات صَنْف معين. ورقة النمط (style sheet) هي عبارة عن ملف بامتداد ‎.css. نَستعرِض خلال المثال التالي ورقة نمط (style sheet) تُطبِق بعضًا من قواعد النمط (style rules) على جميع المكونات من الصَنْفين Label و Button: Button { -fx-font: bold 16pt "Times New Roman"; -fx-text-fill: darkblue; } Label { -fx-font: 15pt sans-serif; -fx-padding: 7px; -fx-border-color: darkred; -fx-border-width: 2px; -fx-text-fill: darkred; -fx-background-color: pink; } كأي ملف صورة، يُمكِن لأي ملف ورقة نمط (style sheet) أن يَكُون ملف مورد (resource) ضِمْن البرنامج أي تستطيع تَخْزينه بنفس أماكن تَخْزِين الملفات بامتداد ‎.class. بفَرْض وجود ملف ورقة نمط اسمه "mystyle.css" بالمجلد الرئيسي للبرنامج، نستطيع إذًا أن نُطبِقه على جميع المُكوِّنات الموجودة ضِمْن مشهد (scene) باِستخدَام التَعْليمَة التالية: scene.getStylesheets().add("mystyle.css"); يُمكِننا إضافة مجموعة من أوراق النمط (style sheets) إلى مشهد (scene) من الصَنْف Scene أو إلى حاويات (containers) مفردة. ترجمة -بتصرّف- للقسم Section 2: Some Basic Classes من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

غالبية مُستخدمِي الحاسوب غَيْر مُعتَادون في العموم على برامج سطر الأوامر (command-line programs)، حيث يَجدُون أسلوب التَفاعُل القائم على تَناوُب الحاسوب والمُستخدِم على كتابة النصوص غَيْر مألوف. منذ منتصف الثمانينات، أُتيحَت الحواسيب المنزلية المُدعِّمة لواجهات المُستخدِم الرُسومية (graphical user interfaces)، والتي تُوفِّر للمُستخدِم واجهة أكثر ثراءً يَتَمكَّن من خلالها من اِستخدَام أدوات إِدْخَال مُتعدِّدة مثل الفأرة ولوحة المفاتيح وغيرها للتَفاعُل مع مجموعة من مُكوِّنات الواجهة مثل النوافذ والقوائم والأزرار وصناديق الإِدْخَال النصية وشرائط التمرير وغيرها. سنتناول خلال هذا القسم بعضًا من أساسيات برمجة الواجهات باِستخدَام مكتبة جافا إف إكس (JavaFX) من خلال دراسة تطبيق بسيط يَعرِض وَاجهة مُكوَّنة من نافذة (window) تَحتوِي على رسالة نصية وثلاثة أزرار كما هو مُبيَّن بالصورة التالية. لاحِظ أننا قد اِستخدَمنا مصطلح تطبيق (application) وليس برنامج (program) ضِمْن هذا السياق. إذا ضَغَطت على زر "Say Hello"، سيَرُد الحاسوب بالرسالة "Hello World!" أما إذا ضَغَطت على زر "Say Goodbye"، فسيَتَغيَّر نص الرسالة إلى "Goodbye". تستطيع إغلاق التطبيق إما بالنَقْر على زر "Quit" أو على زر غَلْق النافذة. تطبيقات جافا إف إكس (JavaFX) تَحتوِي حزمة javafx.application على الصَنْف المُجرّد (abstract class)‏ Application، والذي يَحتوِي على تابع النُسخة (instance method) المُجرّد start()‎ من بين أشياء أخرى. لكي تُنشِئ تطبيق جافا إف إكس (JavaFX application)، ينبغي أن تُعرِّف صنفًا جديدًا مُمثِلًا للتطبيق. لابُدّ أن يتوسَّع (extend) الصَنْف الجديد من الصَنْف Application كما لابُدّ أن يُوفِّر تعريفًا (definition) للتابع start()‎. (اُنظر كُلًا من القسمين الفرعيين "توسيع (extend) الأصناف الموجودة"، و "الأصناف المجردة (abstract classes)" من الفصل "الوراثة والتعددية الشكلية (Polymorphism) والأصناف المجردة (Abstract Classes) في جافا"). سيَحتوِي الصَنْف أيضًا على التابع main()‎، والذي سيتولَّى مُهِمّة تّنْفيذ التطبيق، ويُكْتَب عمومًا على النحو التالي: public static void main(String[] args) { launch(args); } عندما يُنفِّذ الحاسوب البرنامج main()‎، سيُنشِئ التابع launch()‎ خيطًا (thread) جديدًا يُعرَف باسم خيط تطبيق جافا إف إكس (JavaFX application thread). كما ذَكَرَنا بالقسم ١.٢، يَضُمّ كل خيط متتالية من التَعْليمَات يُمكِن تّنْفيذها بالتوازي مع خيوط أخرى. ينبغي عمومًا لأي شيفرة تَتَعامَل مع واجهة مُستخدِم رسومية (GUI) أن تَقَع ضِمْن خيط تطبيق جافا إف إكس، وهو ما سيَحدُث أتوماتيكيًا فيما يَتعلَّق بما سنقوم به ضِمْن هذا الفصل، ولكن عندما ننتقل إلى الحديث عن الخيوط (threads) تفصيليًا بالفصل ١٢، سنُطوِّر تطبيقات واجهة مُستخدِم رسومية (GUI) تَستخدِم أكثر من خيط، وعندها ستَّضِح أهمية ذلك. سيُنشِئ التابع launch()‎ الكائن المُمثِل للتطبيق، وهو في الواقع من نفس صنف التابع، ثم سيَستدعِي تابعه start()‎، والذي تُوكَل له مُهِمّة تجهيز واجهة المُستخدِم الرسومية (GUI)، ومن ثَمَّ فَتْح نافذة (window) بالشاشة. تستطيع إصدارات معينة من الجافا أن تُشغِّل تطبيقات جافا إف إكس (JavaFX) حتى لو لم تَتَضمَّن التابع main()‎، ولكن لا تَعتمِد على ذلك، واِحرِص دومًا على كتابة التابع main()‎ ضِمْن التطبيقات الخاصة بك، وهو ما سنلتزم به. ها هي شيفرة التطبيق التي سنُناقِشها تفصيليًا بهذا القسم: import javafx.application.Application; import javafx.scene.Scene; import javafx.stage.Stage; import javafx.application.Platform; import javafx.scene.layout.BorderPane; import javafx.scene.layout.HBox; import javafx.geometry.Pos; import javafx.scene.control.Label; import javafx.scene.control.Button; import javafx.scene.text.Font; public class HelloWorldFX extends Application { public void start(Stage stage) { Label message = new Label("First FX Application!"); message.setFont( new Font(40) ); Button helloButton = new Button("Say Hello"); helloButton.setOnAction( e -> message.setText("Hello World!") ); Button goodbyeButton = new Button("Say Goodbye"); goodbyeButton.setOnAction( e -> message.setText("Goodbye!!") ); Button quitButton = new Button("Quit"); quitButton.setOnAction( e -> Platform.exit() ); HBox buttonBar = new HBox( 20, helloButton, goodbyeButton, quitButton ); buttonBar.setAlignment(Pos.CENTER); BorderPane root = new BorderPane(); root.setCenter(message); root.setBottom(buttonBar); Scene scene = new Scene(root, 450, 200); stage.setScene(scene); stage.setTitle("JavaFX Test"); stage.show(); } // end start(); public static void main(String[] args) { launch(args); // Run this Application. } } // end class HelloWorldFX عادةً ما تَستخدِم تطبيقات جافا إف إكس (JavaFX) أصنافًا عديدة، غالبيتها مُعرَّف بحزم javafx الفرعية (subpackages)، ولهذا ستُلاحِظ وجود عدد كبير من تَعْليمَات الاستيراد import ببداية أي من تطبيقاتها كالمثال بالأعلى. سنَذكُر دومًا الحزمة التي يَقَع بها صَنْف معين عندما نَتَعرَّض له لأول مرة كما تستطيع البحث عن أي صَنْف منها بـ توثيق واجهة برمجة تطبيقات جافا إف إكس (JavaFX API). يحتوي الصنف المُمثِل للتطبيق HelloWorldFX -بالأعلى- على التابع main المسئول عن بدء تّنْفيذ التطبيق، بالإضافة إلى التابع start()‎. نُضيف عادةً توابعًا آخرى لذلك الصنف بحيث يَستدعِيها التابع start()‎ عند تّنْفيذه. علاوة على ذلك، يَحتوِي الصنف المُجرّد Application على عددًا من التوابع (methods) الآخرى، التي يُمكِنك إعادة تعريفها (override) كالتابعين init()‎ و stop()‎. يَستدعِي النظام init()‎ قبل استدعاء start()‎، بينما يَستدعِى stop()‎ عندما يَكُون التطبيق على وشك الإغلاق. في حين أن تعريفهما ضِمْن الصَنْف Application لا يَتَضمَّن أي شيء فعليّ، تستطيع أن تُعيد تعريفهما لإجراء بعض التهيئة المبدئية (initialization) أو لإجراء أي تنظيف (cleanup) ضروري. ومع ذلك، يُمكِن تّنْفيذ أي تهيئة مطلوبة ضِمْن التابع start()‎، لذا نادرًا ما سنلجأ إليهما. المرحلة Stage والمشهد Scene ومبيان المشهد SceneGraph تُوفِّر حزمة javafx.stage الصَنْف Stage، والذي يُمثِل أي كائن منه نافذةً (window) على شاشة الحاسوب. يُنشِئ النظام كائن مرحلة (stage) من ذلك الصَنْف، ويُمرِّره كمُعامِل (parameter) إلى التابع start()‎. يُمثِل كائن المرحلة، في تلك الحالة تحديدًا، نافذة البرنامج الرئيسية، ويُشار إليه عادةً باسم "المرحلة الرئيسية (primary stage)". قد يُنشِئ البرنامج كائنات مرحلة (stage) آخرى من نفس الصَنْف إذا أراد فَتْح نوافذ آخرى. تُعدّ أي نافذة (window) بمثابة مساحة ضِمْن شاشة الحاسوب، والتي يُمكِن مَلْؤها بمحتوى معين، فمثلًا قد نَملْؤها ببعض مما يُعرَف باسم مُكونات واجهة المُستخدِم الرُسومية (GUI components) كالقوائم، والأزرار، وصناديق الإِدْخَال النصية، ومساحات الرسم (drawing areas) التي كنا قد اِستخدَمناها ببعض البرامج الرسومية بالقسم ٣.٩. كما ذَكَرَنا مُسْبَقًا، يُنشِئ النظام كائنًا من الصنف Stage، ليُمثِل النافذة الرئيسية -ويُعرَف باسم "المرحلة الرئيسية (primary stage)"- قبل استدعاء التابع start()‎، ومع ذلك تَكُون تلك النافذة (window) ما تزال فارغة وغَيْر مرئية إلى حين استدعائه، وتُوكَل إليه في الحقيقة مُهِمّة مَلْؤها بالمحتوى المناسب، ومن ثَمَّ إظهارها على الشاشة. فمثلًا، بتطبيق HelloWorldFX بالأعلى، يُظهِر السطر الأخير من التابع start()‎ -أيّ التعبير stage.show()‎- النافذة على الشاشة بينما تُنشِئ أسطر التابع الآخرى المحتوى، وتُضيفه إلى النافذة إلى جانب ضَبْط بعض الخيارات المُتعلِّقة بكُلًا من المحتوى والنافذة ذاتها، فمثلًا، تَضبُط الشيفرة التالية نص شريط عنوان النافذة: stage.setTitle("JavaFX Test"); تتكوَّن أي مرحلة (stage) -تُمثِل نافذة- من مساحة لعَرْض المحتوى (content area)، والتي يُمكِن مَلْئها بـ"مشهد (scene)" يَضُمّ مُكونات واجهة المُستخدِم الرسومية (GUI components) المُفْترَض عَرْضها بالنافذة. تُوفِّر حزمة javafx الصَنْف Scene، والذي يُمثِل أي كائن منه مشهدًا (scene). يُمكِننا ضَبْط المشهد (scene) المُفْترَض عَرْضه بمساحة المحتوى (content area) الخاصة بمرحلة معينة (stage) باِستخدَام التَعْليمَة التالية: stage.setScene(scene); يُمكِنك أن تمَلْئ أي مشهد (scene) بمُكوِّنات واجهة المُستخدِم الرسومية (GUI components) كالأزرار وأشرطة القوائم وغيرها. تُوفِّر منصة جافا إف إكس (JavaFX) صَنْفًا لكل مُكوِّن منها، فمثلًا، يُمكِنك أن تَستخدِم كائنًا من الصنف Button من حزمة javafx.scene.control لتمثيل "زر ضغط (push button)" مثل الزر "Say Hello" بالتطبيق السابق. بالإضافة إلى ذلك، تُوفِّر منصة جافا إف إكس (JavaFX) أصنافًا لمُكوِّنات تَعمَل بمثابة حاويات (containers) تُمثِل قسمًا من النافذة (window) مثل الكائن buttonBar من النوع HBox. قد يَشتمِل ذلك القسم من النافذة على مُكوِّنات واجهة آخرى بما في ذلك أي مُكوِّن حَاوِي آخر. بتعبير آخر، قد تحتوي نافذة معينة على عدد من مُكوِّنات واجهة المُستخدِم الرسومية داخل حاويات (containers) تَقَع بدورها ضِمْن حاويات أكبر، وجميعها مُمثَل بواسطة كائن. تُشكِّل كل تلك الكائنات ما يُعرَف باسم "مبيان المشهد (scene graph)"، والذي يُبيِّن علاقات الاحتواء بين جميع مُكوِّنات المشهد (scene). تُبيِّن الصورة التالية "مبيان المشهد (scene graph)" للتطبيق السابق: لا تُمثِل الصورة بالأعلى سلالة أصناف (class hierarchy) كما قد تَظُنّ، فهي لا تُبيِّن العلاقات بين أصناف تلك الكائنات، وإنما هي بمثابة تَسَلسُل هرمي لعلاقات الاحتواء (containment hierarchy) بين تلك الكائنات، أي تُبيِّن الكيفية التي تَتَضمَّن بها بعض مُكوِّنات المشهد البعض الآخر. فمثلًا، يَتَّضِح من مبيان المشهد (scene graph) أن كُلًا من root و buttonBar عبارة عن مُكوِّنات حاوية (containers) أما message بالإضافة إلى الأزرار الثلاثة فهي مُجرّد مُكوِّنات بسيطة. يَحتوِي أي مشهد (scene) على مُكوِّن جذري (root component) وحيد. هذا المُكوِّن هو عبارة عن حَاوِي (container) لجميع المُكوِّنات الآخرى الموجودة بالمشهد. أطلقنا الاسم root على المُكوِّن الجذري بالتطبيق السابق، ويُمكِنك بالطبع أن تختار أي اسم آخر تُفضِّله. يُمكِنك ضَبْط المُكوِّن الجذري لمشهد معين بينما تُنشِئ كائن الصنف Scene كالتالي: Scene scene = new Scene(root, 450, 200); تُحدِّد الأعداد المُمرَّرة لهذا الباني (constructor) كُلًا من عرض المشهد وارتفاعه بوحدة البكسل (pixel). يُمكِنك حَذْف تلك الأعداد، وفي تلك الحالة، ستُحسَب مساحة المشهد بما يتناسب مع محتوياتها. العقد (nodes) والتخطيط (layout) يتكوَّن أي مبيان مشهد (scene graph) من مجموعة من الكائنات، تُعرَف باسم "العُقَد (nodes)". لابُدّ أن تنتمي تلك الكائنات إلى إحدى الأصناف الفرعية (subclasses) المُشتقَّة من الصَنْف javafx.scene.Node، وقد يَعمَل بعضها كمُكوِّنات حاوية (container)، وفي تلك الحالة، لابُدّ لها من أن تنتمي إلى إحدى الأصناف الفرعية المُشتقَّة من الصَنْف javafx.scene.Parent، والذي هو بدوره صنف فرعي من نفس الصنف Node. لمّا كانت العُقْدة الجذرية (root node) تَعمَل كمُكوِّن حاوي، فلابُدّ أن تَكُون من الصنف Parent. تَشتمِل العُقَد المُمثلة لمُكوِّنات حاوية (containers) على مجموعة من العُقَد (nodes) الآخرى، والتي تُعدّ أبناءً (children) لها. بتطبيق HelloWorldFX السابق، اِستخدَمنا كائنات من النوع Button لتمثيل الأزرار. في الواقع، هذا الصنف هو صنف فرعي (subclass) من الصنف Parent، وسنرى لاحقًا أن بإمكانه أن يَتَضمَّن عُقَدًا (nodes) آخرى. يَستقبِل باني (constructor) الصنف Button مُعامِلًا لتَخْصِيص النص المكتوب على الزر. بالمثل، message هو عبارة عن كائن عُقْدة (node) من النوع Label المُعرَّف بحزمة javafx.scene.control، ويُستخدَم لعَرْض سِلسِلة نصية من النوع String. يَتَضمَّن أي كائن عُقْدة من الصنف Label على خاصية نوع الخط، والتي تَتَحكَّم بحجم محارف السِلسِلة النصية، وهيئتها، ويُمكِن ضَبْطها باِستخدَام التابع setFont()‎ المُعرَّف بنفس الصنف. بالتطبيق السابق، اِستخدَمنا الباني new Font(40)‎، والذي يُحدِّد مُعامِله (parameter) الوحيد حجم الخط المطلوب. المُكوِّنات الحاوية (containers) هي أيضًا عُقَد (nodes) من النوع Node، ولكن يُمكِنها أن تَشتمِل على عُقَد آخرى كأبناء (children)، ويُشار إلى الكيفية التي يُرتَّب بها هؤلاء الأبناء على الشاشة باسم "التخطيط (layout)". يعني التخطيط (layout) عمومًا ضَبْط كُلًا من حجم المُكوِّنات الواقعة ضِمْن الحاوي ومَوضِعها. على الرغم من تَوفُّر إمكانية لضَبْط تلك القيم بصورة مباشرة، فلربما تُفضِّل الاعتماد على ضَبْطها أتوماتيكيًا بالاستعانة بالمُكوِّن الحاوي (container) نفسه، وفي الواقع، تُعدّ تلك الطريقة أكثر شيوعًا. عمومًا، يُطبِق كل مُكوِّن حاوي سياسة تخطيط (layout policy) مختلفة، فمثلًا، تُرتِّب المُكوِّنات الحاوية من الصنف HBox مُكوِّناتها ضِمْن صف أفقي. اُنظر الباني (constructor) التالي: HBox buttonBar = new HBox( 20, helloButton, goodbyeButton, quitButton ); تُمثِل جميع مُعامِلات (parameter) ذلك الباني فيما عدا الأول عُقَدًا (nodes) ينبغي إضافتها كأبناء (children) للمُكوِّن الحاوي (container)، بحيث يَفصِل بينها فراغًا تُحدِّد مساحته القيمة المُمرَّرة لمُعامِل الباني الأول. في المقابل، تُطبِق المُكوِّنات الحاوية من الصنف BorderPane سياسة تخطيط (layout policy) مختلفة تمامًا. يستطيع أي مُكوِّن حاوي منها أن يحتوى على ما يَصِل إلى ٥ مُكوِّنات (components)، واحدة بالمنتصف، أما البقية فبالأعلى وبالأسفل وعلى اليسار وعلى اليمين. بالتطبيق السابق، كان المُكوِّن الجذري للمشهد عبارة عن مُكوِّن حاوي من الصنف BorderPane، واستخدمنا التَعْليمَات التالية لإضافة مُكوّنات آخرى إلى منتصفه والجزء السفلي منه: root.setCenter(message); root.setBottom(buttonBar); تتوفَّر أيضًا الكثير من الخيارات لضَبْط التخطيط (layout)، فمثلًا يَستخدِم التطبيق السابق إحداها بالتَعْليمَة التالية: buttonBar.setAlignment(Pos.CENTER); تُستخدَم تلك التَعْليمَة لوَضْع الأزرار بمنتصف مُكوّن حاوي من الصنف HBox؛ فبدونه، ستَقَع الأزرار على حافة النافذة اليسرى. تعتمد منصة جافا إف إكس (JavaFX) على أنواع التعداد (enumerated type) بكثرة، والتي كنا قد ناقشناها بالقسم الفرعي ٢.٣.٤، وذلك لتخصيص الخيارات المختلفة، مثل نوع التعداد Pos بالشيفرة السابقة. الأحداث (event) ومعالجاتها (handlers) لا يَقْتصِر دور التابع start()‎ على ضَبْط تخطيط (layout) النافذة، وإنما يُستخدَم أيضًا لضَبْط ما يُعرَف باسم "معالجة الحَدَث (event handling)". مثلًا، بتطبيق HelloWorldFX بالأعلى، عندما يَنقُر المُستخدِم على زر معين، يَقَع ما يُعرَف باسم "الحَدَث (event)"، ويُمكِن عندها للتطبيق أن يُعالِج (handle) ذلك الحَدَث من خلال ما يُعرَف باسم "مُعالِجات الأحداث (event handlers)". تَشتمِل معالجة أي حَدَث على كائنين، يُعبِر الأول عن الحَدَث نفسه ويَحمِل معلومات عنه، فمثلًا، عند النقر على زر، يَكُون كائن الحَدَث من النوع ActionEvent ويَحمِل معلومات عن الزر المنقور عليه. أما الكائن الآخر فيُعبِر عن مُعالِج الحدث، ويَكُون من نوع واجهة نوع الدالة EventHandler، والتي تُعرِّف التابع handle(e)‎ حيث e هو كائن الحَدَث. والآن لكي تُعالِج حَدَثًا معينًا، ينبغي أن تُنشِئ صنفًا يُنفِّذ (implements) الواجهة EventHandler، ويُوفِّر تعريفًا للتابع handle()‎. ولكن لمّا كانت EventHandler عبارة عن واجهة نوع دالة (functional interface)، فيُمكِن كتابة المُعالِج (handler) بصورة تعبير لامدا (lambda expression). كنا قد ناقشنا تعبيرات لامدا تفصيليًا بالقسم ٤.٥، وهي في العموم شائعة الاِستخدَام بتطبيقات جافا إف إكس (JavaFX)، فتُستخدَم لكتابة مُعالِجات الأحداث (event handlers) من ضِمْن عدة استخدامات آخرى. اُنظر تعبير لامدا التالي على سبيل المثال: e -> message.setText("Hello World!") يُمثِل ذلك التعبير مُعالِج حَدَث (event handler) يَستجيب لحَدَث (event) ما بتغيير نص الرسالة إلى "Hello World". يَستقبِل ذلك المُعالِج مُعامِلًا e، يُمثِل الحَدَث، ويَكُون من النوع ActionEvent، والذي لابُدّ من كتابته دائمًا حتى لو لم يَستخدِمه المُعالِج كالمثال بالأعلى؛ وذلك ليَستوفِي صيغة تعبير اللامدا (lambda expression). ينبغي الآن أن نُسجِّل (register) مُعالِج الحَدَث (event handler) بَعْد كتابته بالكائن المُنتج للحَدَث. فمثلًا بنفس المثال، كان الكائن هو helloButton، ونستطيع أن نُسجِّل المُعالِج (handler) باستدعاء تابع الكائن setOnAction()‎، كالتالي: helloButton.setOnAction( e -> message.setText("Hello World!") ); ضَبطَنا أيضًا مُعالجي (handlers) الزرين الآخرين بنفس الطريقة. لاحِظ أن لدينا ثلاثة كائنات: كائن مُنتج للحَدَث (event) نتيجة لفعل (action) قام به المُستخدِم، وكائن يُمثِل الحَدَث ذاته، وأخيرًا كائن يُمثِل مُعالِج الحَدَث (event handler) كما يَحتوِي على الشيفرة المطلوب تّنْفيذها استجابةً للحَدَث (event)، كما هو مُوضَح بالصورة التالية: يَتبقَّى لنا فقط توضيح الاستجابة على فعل (action) النقر على زر "Quit"، اِستخدَمنا التعبير Platform.exit()‎ لاستدعاء التابع الساكن exit()‎ المُعرَّف بالصنف Platform. يُفضَّل عمومًا اِستخدَام تلك الطريقة للإنهاء البرمجي لتطبيقات جافا إف إكس (JavaFX)؛ لأنها تُغلِق خيط التطبيق (application thread)، كما تَستدعِي التابع stop()‎ المُعرَّف بالصنف المُمثِل للتطبيق، مما يُعطِي فرصة للمبرمج لإجراء أي تنظيف (clean up) قد يَرغَب به قَبْل الإغلاق، وذلك بخلاف التابع System.exit()‎ مثلًا. يُعدّ هذا القسم بمثابة نظرة عامة ومُختصرة لتطبيقات جافا إف إكس (JavaFX)، ومع ذلك فقد تَعرَّضنا خلالها للكثير من المفاهيم الأساسية. بالأقسام التالية، سنتناول كل ذلك على نحو تفصيلي. ترجمة -بتصرّف- للقسم Section 1: A Basic JavaFX Application من فصل Chapter 6: Introduction to GUI Programming من كتاب Introduction to Programming Using Java.

تُعدّ الأصناف (classes) اللَبِنة الأساسية عالية المستوى (high-level) بالبرنامج، حيث تُستخدَم لتمثيل الأفكار والكيانات المُعقدة ضِمْن البرنامج وما يَرتبِط بها من بيانات (data) وسلوكيات (behavior). يَدفَع ذلك البعض إلى وَضْع الأصناف بمكانة خاصة، فيُحاولون تَجنُّب كتابة الأصناف الصغيرة جدًا والموجودة فقط لتجميع مجموعة من البيانات معًا، ويَرَونَها تافهة مع أنها قد تَكُون مفيدة أحيانًا أو حتى ضرورية في بعض الأحيان الآخرى. لحسن الحظ، تَرفَع الجافا هذا الحرج؛ حيث تَسمَح بكتابة تعريف صَنْف (class definition) ضِمْن تعريف صَنْف آخر، وبذلك لَمْ تَعُدْ تلك الأصناف الصغيرة جدًا موجودة بمُفردها، وإنما أَصبحَت جُزءًا من أصناف أكبر ذات هيبة. إلى جانب ذلك، هنالك العديد من الأسباب الآخرى التي قد تَدفَعك لتَضْمِين تعريف صنف (class definition) داخل صنف آخر. الصَنْف المُتداخِل (nested class) هو ببساطة أيّ صنف يَقَع تعريفه (definition) داخل تعريف صنف آخر. وفي الواقع، يُمكِن حتى كتابة تعريف صَنْف داخل تابع (method) والذي بدوره يَقَع ضِمْن صنف. الأصناف المُتداخِلة إِما أن تَكُون مُسمَاة (named) أو مجهولة الاسم (anonymous). سنعود لاحقًا إلى الأصناف مجهولة الاسم (anonymous classes) أما بالنسبة للأصناف المُتداخِلة المُسمَاة (named nested class)، فيُمكِنها أن تَكُون ساكنة (static) أو غَيْر ساكنة (non-static) وذلك كأي شيء مُعرَّف ضِمْن صَنْف. بالمثل من الأصناف، يُمكِن للواجهات (interfaces) أيضًا أن تَقَع ضِمْن تعريفات الأصناف (class definitions) وقد تَكُون ساكنة (static) أو غَيْر ساكنة (non-static)، كما قد تَحتوِي تعريفات الواجهات (interface definitions) على أصناف مُتداخِلة ساكنة (static nested classes) أو واجهات آخرى، ولكننا لن نَتَعرَّض لذلك. الأصناف المتداخلة (nested) الساكنة تُعرَّف الأصناف المُتداخِلة (nested class) الساكنة كأي تعريف لصَنْف عادي باستثناء أمرين: أولهما وقوع التعريف ضِمْن صنف آخر، والآخر اِستخدَام المُبدِّل static ضِمْن التّصْريح. يُعدّ أي صنف مُتداخِل ساكن جزءًا من البنية الساكنة (static) للصَنْف الحاضن له والذي قد يَستخدِمه لإنشاء كائنات بالطريقة العادية. في المقابل، يُمكِن اِستخدَامه أيضًا خارج صَنْفه الحاضن، ولكن ينبغي أن يُشير اسمه في تلك الحالة إلى كَوْنه عضوًا بصَنْفه الحاضن، أي ينبغي أن يُستخدَم الاسم الكامل للصنف والذي يَتَكوَّن من اسم صَنْفه الحاضن متبوعًا بنقطة ثم باسمه. كأيّ مُكوِّن ساكن آخر ضِمْن صَنْف، تُعدّ الأصناف المُتداخِلة (nested class) الساكنة جزءًا من الصَنْف ذاته بنفس الطريقة التي يُعدّ بها أي مُتْغيِّر عضو (member variable) ساكن جزءًا من الصَنْف ذاته. لنَفْترِض مثلًا وجود صَنْف، اسمه WireFrameModel يُمثِل مجموعة من الخطوط بفضاء ثلاثي الأبعاد. يَحتوِي ذلك الصنف على صَنْف مُتداخِل ساكن Line يُمثِل خطًا واحدًا. يُمكِننا الآن كتابة تعريف الصنف WireFrameModel والصنف المُتداخِل Line كالتالي: public class WireFrameModel { . . . // أعضاء آخرى ضمن الصنف static public class Line { // ‫يمثل خطًا من النقطة (x1,y1,z1) إلى النقطة (x2,y2,z2) بفضاء // ثلاثي الأبعاد double x1, y1, z1; double x2, y2, z2; } // ‫نهاية الصنف Line . . . // أعضاء آخرى ضمن الصنف } // ‫نهاية الصنف WireFrameModel لاحِظ أن الاسم الكامل للصَنْف المُتداخِل هو WireFrameModel.Line ويُمكِنك اِستخدَامه للتّصْريح عن مُتْغيِّر مثلًا. تستطيع تَحْديدًا إنشاء كائن من الصَنْف Line باِستخدَام البَانِي new Line()‎ من داخل الصَنْف WireFrameModel، بينما قد تَستخدِم التعبير new WireFrameModel.Line()‎ لإنشائه من خارج الصَنْف. يستطيع أي صَنْف مُتداخِل (nested) ساكن الوصول إلى أي عُضو ساكن (static members) مُعرَّف بالصنف الحاضن له حتى وإن كان عضوًا خاصًا (private). بالمثل، يستطيع الصَنْف الحاضن لصَنْف مُتداخِل (nested) ساكن الوصول إلى أعضاء ذلك الصنف المُتداخِل (nested) حتى وإن كانت خاصة (private). يُمثِل ذلك دافعًا قويًا لاِستخدَام الأصناف المُتداخِلة (nested)؛ نظرًا لأنها تَسمَح لصَنْف معين بالوصول إلى الأعضاء الخاصة (private) المُعرَّفة بصَنْف آخر دون الحاجة إلى إِتاحة تلك الأعضاء بصورة أعم لجميع الأصناف الآخرى. وأخيرًا، يُمكِن لأي صَنْف مُتداخِل (nested) أن يَكُون خاصًا (private) وعندها يُمكِن اِستخدَامه من داخل الصَنْف الحاضن له فقط. على الرغم من أن تعريف الصَنْف Line يَقَع ضِمْن الصَنْف WireFrameModel، ستُخزَّن النسخة المُصرَّفة (compiled) من الصَنْف Line بملف مُنفصل، اسمه هو WireFrameModel$Line.class، أي أنه عند تصريف تعريف الصَنْف (class definition) -بالأعلى-، سيُنشِئ المُصرِّف ملفًا منفصلًا لكل صَنْف. الأصناف الداخلية (inner) يُطلَق على الأصناف المُتداخِلة (nested) غَيْر الساكنة (non-static) اسم "الأصناف الداخلية (inner classes)". من الناحية العملية، هي لا تَختلِف كثيرًا عن الأصناف المُتداخِلة الساكنة (static)، مع أنها تُعدّ جزءًا من كائنات الأصَنْاف الحاضنة لها لا الأصناف ذاتها. لا تُعدّ الأعضاء غَيْر الساكنة (non-static) المُعرَّفة بأي صنف جزءًا فعليًا من الصنف ذاته على الرغم من أن شيفرتها مُتضمَّنة بتعريف ذلك الصنف (class definition)، وهو ما يَنطبِق على الأصناف الداخلية (inner classes). تُحدِّد تلك الأعضاء ما ستَحتوِيه كائنات ذلك الصنف عند إنشائها، وهو ما يَنطبِق أيضًا على الأصناف الداخلية على الأقل منطقيًا أي كما لو كان كل كائن من الصنف الحاضن يَتَضمَّن نسخة خاصة من الصَنْف المُتداخِل (nested) -لا تَأخُذ ذلك بالمعنى الحرفي-. بإمكان تلك النُسخة الوصول لجميع توابع النُسخ (instance methods) ومُتْغيَّرات النُسخ (instance variables) المُعرَّفة بالكائن حتى وإن كانت خاصة (private). مثلًا، إذا كان لدينا كائنين من صَنْف يَتَضمَّن صنفًا داخليًا (inner class)، فإن نُسختي الصَنْف الداخلي بهذين الكائنين مختلفتان؛ لأنهما يُشيران إلى مُتْغيَّرات نُسخ وتوابع نُسخ تَقَع ضِمْن كائنات مختلفة. كيف تُقرِّر ما إذا كان ينبغي لصنف مُتداخِل (nested) معين أن يَكُون ساكنًا أو غَيْر ساكن؟ الأمر بسيط للغاية: إذا اِستخدَم الصنف المُتداخِل مُتْغيِّر نسخة (instance variable) أو تابع نسخة (instance method) من الصَنْف الحاضن، فلابُدّ أن يَكُون غَيْر ساكن (non-static)، أما إن لم يَستخدِم أيًا منها، فيُمكِنه أن يَكُون ساكنًا (static). يُستخدَم الصنف الداخلي (inner class) في غالبية الأحوال ضِمْن الصَنْف الحاضن له فقط. وفي تلك الحالة، لا يَختلِف اِستخدَامه كثيرًا عن اِستخدَام أيّ صنف آخر؛ فيُمكِنك أن تُصرِّح عن مُتْغيِّر أو أن تُنشِئ كائنًًا باِستخدَام الاسم البسيط للصَنْف الداخلي، ولكن فقط ضِمْن الأجزاء غَيْر الساكنة (non-static) من الصَنْف. أما إذا أردت اِستخدَامه من خارج صَنْفه الحاضن له، فلابُدّ من الإشارة إليه باِستخدَام اسمه الكامل والذي يُكْتَب بالصياغة .، حيث أن هو مُتْغيِّر يُشير إلى كائن مُتضمِّن لصَنْف داخلي (inner class). لاحِظ أنه لكي تَتَمكَّن من إنشاء كائن ينتمي لصَنْف داخلي، لابُدّ أولًا أن تُنشِئ كائنًا من صَنْفه الحاضن. لنَفْترِض أننا نريد كتابة صنف يُمثِل مباراة بوكر، بحيث يَتَضمَّن صنفًا داخليًا يُمثِل لاعبي المباراة. يُمكِننا كتابة تعريف الصنف PokerGame كالتالي: public class PokerGame { // يمثل مباراة بوكر class Player { // يمثل أحد لاعبي المباراة . . . } // ‫نهاية الصنف Player private Deck deck; // مجموعة ورق اللعب private int pot; // قيمة الرهان . . . } // ‫نهاية الصنف PokerGame إذا كان game مُتْغيِّرًا من النوع PokerGame، فإنه سيَتَضمَّن نسخة خاصة به من الصَنْف Player على نحو منطقي. كأي صَنْف عادي آخر، تستطيع اِستخدَام التعبير new Player()‎ لإنشاء كائن جديد من الصَنْف Player بشَّرْط أن يَقَع ذلك داخل تابع نسخة (instance method) بكائن الصَنْف PokerGame. في المقابل، تستطيع اِستخدَام تعبير مثل game.new Player()‎ لإنشاء كائن من الصَنْف Player من خارج الصَنْف PokerGame، ولكنه في الواقع أمر نادر الحدوث. يستطيع أي كائن من الصَنْف Player الوصول إلى مُتْغيِّرات النُسخ deck و pot المُعرَّفة بكائن الصَنْف PokerGame. من الجهة الأخرى، يَمتلك أي كائن من الصَنْف PokerGame نسخة خاصة به من كُلًا من deck و pot و Players. فمثلًا، يَستخدِم لاعبو مباراة بوكر معينة المُتْغيِّرين deck و pot الخاصين بتلك المباراة تَحْديدًا، بينما يَستخدِم لاعبو مباراة بوكر آخرى المُتْغيِّرين deck و pot الخاصين بتلك المباراة الآخرى. ذلك بالتحديد هو تأثير كَوْن الصَنْف Player غير ساكن، وهو في الواقع الطريقة الطبيعية التي ينبغي للاعبين التصرُّف على أساسها. يُمثِل كل كائن من الصَنْف Player لاعبًا ضِمْن مباراة بوكر مُحدَّدة، أما إذا كان الصَنْف Player صَنْْفًا مُستقلًا أو صنفًا مُتداخِلًا (nested) ساكنًا، فسيُمثِل عندها الفكرة العامة للاعب البوكر بصورة مُستقلة عن أي مباراة بوكر مُحدَّدة. الأصناف الداخلية مجهولة الاسم (anonymous) قد تُعرِّف صنفًا داخليًا (inner class)، ثم تَجِد نفسك تَستخدِمه بسطر وحيد بالبرنامج، فهل ينبغي حقًا في تلك الحالة تعريف مثل ذلك الصنف؟ ربما، ولكن قد تُفضِّل أيضًا أن تَستخدِم صنفًا داخليًا مجهول الاسم (anonymous) في مثل هذه الحالات. يُكْتَب أي صَنْف داخلي مجهول الاسم بالصيغة التالية: new <superclass-or-interface> ( <parameter-list> ) { <methods-and-variables> } يُعرِّف الباني -بالأعلى- صَنْفًا جديدًا بدون أن يُعطيه أي اسم، ويُنشِئ كائنًا يَنتمِي إلى ذلك الَصَنْف عند تَشْغِيل البرنامج. في العموم، يُنشِئ هذا الشكل من العَامِل new -والذي تستطيع اِستخدَامه أينما استطعت اِستخدَام العامل new العادي- كائنًا جديدًا ينتمي لصَنْف مجهول الاسم يُشبه الصَنْف أو الواجهة ، والتي تَعمَل كأساس لصنف ذلك الكائن مع إضافة المُتْغيرِّات والتوابع المُعرَّفة، أي أنه يُنشِئ كائنًا فريدًا. الأهم من ذلك هو أنه يُنشئِه فقط بذلك الجزء من البرنامج حيث تحتاج إليه. لا يُشترَط أن يَكُون ذلك الأساس صنفًا، فيُمكِن أن يَكُون واجهة (interface) أيضًا، ولكن في تلك الحالة -أي اِستخدَام واجهة كأساس-، يَكُون الصَنْف مجهول الاسم مُلزَمًا بتّنْفيذ (implement) الواجهة، أي بتعريف (define) جميع التوابع المُصرَّح (declare) عنها ضِمْن تلك الواجهة كما أن قائمة المُعامِلات لابُدّ أن تَكُون فارغة. في المقابل، إذا اِستخدَمت صنفًا كأساس، فبإمكانك تمرير مُعامِلات (parameters) بحيث يَستقبِلها أحد البواني (constructor) المُعرَّفة بالصَنْف الأعلى . إذا كان لدينا الواجهة Drawable المُعرَّفة كالتالي: public interface Drawable { public void draw(GraphicsContext g); } لنَفْترِض الآن أننا نحتاج إلى كائن من النوع Drawable لكي يَرسِم مربعًا أحمر اللون طوله يُساوِي ١٠٠ بكسل. قد تختار أن تُعرِّف صنفًا جديدًا يُنفِّذ الواجهة Drawable، ثم تُنشِئ كائنًا منه. في المقابل، قد تَستخدِم صنفًا مجهول الاسم (anonymous class) لإنشاء الكائن بتَعْليمَة واحدة فقط، كالتالي: Drawable redSquare = new Drawable() { public void draw(GraphicsContext g) { g.setFill(Color.RED); g.fillRect(10,10,100,100); } }; يُشير redSquare -بالأعلى- إلى كائن يُنفِّذ الواجهة Drawable، ويَرسِم مربعًا أحمر اللون عند استدعاء تابعه draw()‎. لاحِظ أن الفاصلة المنقوطة بنهاية التَعْليمَة ليست جزءًا من تعريف الصنف (class definition)، وإنما هي تلك التي تُوجد بنهاية أي تَعْليمَة تّصْريح (declaration). يَشيع تمرير الأصناف مجهولة الاسم (anonymous class) كمُعامِلات فعليّة (actual parameters) للتوابع. فمثلًا، يَستقبِل التابع التالي كائنًا من النوع Drawable، ثم يَرسمه بسياقين رُسوميين (graphics contexts) مختلفين: void drawTwice( GraphicsContext g1, GraphicsContext g2, Drawable figure ) { figure.draw(g1); figure.draw(g2); } عندما تَستدعِي ذلك التابع، يُمكِنك أن تُمرِّر صنفًا داخليًا (inner class) مجهول الاسم (anonymous) كقيمة للمُعامِل (parameter) الثالث، كالتالي: drawTwice( firstG, secondG, new Drawable() { void draw(GraphicsContext g) { g.fillOval(10,10,100,100); } } ); يُنشِئ المُصرِّف ملف صنف ‎.class منفصل لكل صنف مُتداخِل (nested) مجهول الاسم ضِمْن الصَنْف. إذا كان اسم الصنف الأساسي هو MainClass، فإن أسماء ملفات الأصناف المتداخلة مجهولة الاسم تكون كالتالي: MainClass$1.class و MainClass$2.class و MainClass$3.class وهكذا. تُمثِل الواجهة Drawable المُعرَّفة بالأعلى واجهة نوع دالة (functional interface)، وبالتالي نستطيع في هذه الحالة اِستخدَام تعبيرات لامدا (lambda expressions) بدلًا من الأصناف مجهولة الاسم. يُمكِن إعادة كتابة المثال الأخير كالتالي: drawTwice( firstG, secondG, g -> g.fillOval(10,10,100,100) ); كما يُمكِن إعادة تعريف المُتْغيِّر redSquare كالتالي: Drawable redSquare = g -> { g.setFill(Color.RED); g.fillRect(10,10,100,100); }; لا يُنشِئ المُصرِّف أي ملفات جديدة لتعبيرات لامدا (lambda expressions) وهو ما يُحسَب لها، ولكن لاحِظ أنها تُستخدَم فقط مع واجهات نوع الدالة (functional interfaces). في المقابل، تستطيع اِستخدَام الأصناف مجهولة الاسم (anonymous classes) مع أي واجهة أو صنف. قبل الإصدار ٨ من الجافا، كانت الأصناف مجهولة الاسم تُستخدَم لمعالجة الأحداث (events) ببرامج واجهات المُستخدِم الرُسومية (GUI)، ولكن مع الإصدار ٨ ومنصة جافا إف إكس (JavaFX)، أصبحت تعبيرات لامدا مُستخدَمة بكثرة ضِمْن هذا السياق بدلًا من الأصناف مجهولة الاسم. الأصناف المحلية (local) وتعبيرات لامدا تستطيع أن تُعرِّف صنفًا ضِمْن تعريف برنامج فرعي (subroutine definition). تُعرَف تلك النوعية من الأصناف باسم "الأصناف المحلية (local classes)". يَقْتصِر اِستخدَام أي صنف محلي على البرنامج الفرعي (subroutine) المُعرَّف بداخله، ولكن يُمكِن لكائنات ذلك الصنف أن تُستخدَم خارج البرنامج الفرعي، فمثلًا، قد يُعاد كائن ينتمي لصنف محلي من برنامج فرعي أو قد يُمرَّر كمُعامِل (parameter) لبرنامج فرعي آخر. هذا ممكن لأننا نستطيع عمومًا إِسْناد كائن ينتمي لصنف معين B إلى مُتْغيِّر من النوع A طالما كان B صنفًا فرعيًا من A في حالة كان A عبارة عن صنف، أما إذا كان واجهة فطالما كان B يُنفِّذ A. لنَفْترِض مثلًا أن لدينا برنامج فرعي (subroutine) يَستقبِل مُعامِلًا من النوع Drawable -الواجهة المُعرَّفة بالأعلى-، فنستطيع ببساطة أن نُمرِّر إليه أي كائن طالما كان يُنفِّذ (implements) تلك الواجهة، وعليه، قد ينتمي الكائن لصنف محلي (local class) يُنفِّذ تلك الواجهة. بمثال سابق بهذا القسم، مَرَّرنا كائنًا من النوع Drawable إلى التابع drawTwice()‎، والذي يَستقبِل مُعاملًا (parameter) من النوع Drawable. في ذلك المثال، كان الصنف المُمرَّر صنفًا داخليًا مجهول الاسم (anonymous inner class). لاحِظ أن الأصناف المحلية عادة ما تَكُون مجهولة الاسم (anonymous) والعكس، لكنه مع ذلك ليس أمرًا ضروريًا. فمثلًا، قد تَستخدِم صنفًا مجهول الاسم لتعريف القيمة المبدئية لمُتْغيِّر عام (global variable). في تلك الحالة، لا يَقع الصَنْف ضِمْن أي برنامج فرعي (subroutine)، وبالتالي لا يُعدّ محليًا (local). يُمكِن لأي صَنْف محلي (local class) أن يُشير إلى أي مُتْغيِّر محلي (local variables) ضِمْن برنامجه الفرعي أو إلى أي من مُعامِلاته (parameters) المُمرَّرة، ولكن وفقًا لعدة شروط: لابُدّ أن يُصرَّح عن ذلك المُتْغيِّر المحلي (local variable) أو المُعامِل (parameter) باستخدام المُبدِّل final أو أن يَكُون على الأقل "نهائيًا على نحو فعال". يُعدّ المُعامِل (parameter) "نهائيًا على نحو فعال" إذا لم تَتغيّر قيمته داخل البرنامج الفرعي (subroutine) بما في ذلك أصنافه المحلية (local class) التي أشارت إلى ذلك المُعامِل (parameter) بينما يُعدّ المُتْغيِّر المحلي (local variable) "نهائيًا على نحو فعال" إذا لم تَتغيّر قيمته أبدًا بعد التهيئة المبدئية (initialize). في المقابل، تستطيع الأصناف المحلية الإشارة إلى أي مُتْغيِّر عام (global variables) ودون أي شروط. تَنطبِق نفس شروط اِستخدَام المُتْغيِّرات المحلية (local variables) على تعبيرات لامدا (lambda expressions)، والتي هي كثيرة الشبه بالأصناف مجهولة الاسم (anonymous classes). تَستعرِض الشيفرة التالية برنامجًا فرعيًا يَستخدِم كُلًا من واجهة برمجة التطبيقات stream والواجهة Runnable -ناقشناها بالقسم ٤.٥-؛ لطباعة الأعداد من ١ إلى ١٠ بترتيب غير مُحدَّد يَعتمِد على مجرى مُتوازي (parallel stream): static void print1to10() { ArrayList<Runnable> printers = new ArrayList<>(); for (int i = 1; i <= 10; i++) { int x = i; printers.add( () -> System.out.println(x) ); } printers.parallelStream().forEach( r -> r.run() ); } لمّا كان المُتْغيِّر المحلي x "نهائيًا على نحو فعال"، تَمكَّنا من اِستخدَامه ضِمْن تعبير لامدا (lambda expression). في المقابل، لا يُمكِن اِستخدَام المُتْغيِّر i ضِمْن تعبير لامدا؛ لأنه غَيْر نهائي حيث تَتغيّر قيمته عند تّنْفيذ التعبير i++‎. ترجمة -بتصرّف- للقسم Section 8: Nested Classes من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

تَسمَح بعض اللغات البرمجية كائنية التوجه (object-oriented programming)، مثل C++‎، للصَنْف بأن يَتمدَّد (extend) من أكثر من مُجرّد صَنْف أعلى (superclass) واحد، وهو ما يُعرَف باسم الوراثة المُتعدّدة (multiple inheritance). بالرسم التالي مثلًا، يَتمدَّد الصنف E من صنفين أعليين (superclasses) مباشرةً، هما الصنفين A و B، بينما يَتمدَّد الصنف F من ثلاثة أصناف أعلين (superclasses) مباشرةً: أراد مُصمِّمي الجافا أن يجعلوا اللغة بسيطة على نحو معقول، ولمّا وجدوا أن مزايا الوراثة المُتعدّدة (multiple inheritance) لا تَستحِقّ ما يُقابِلها من تعقيد مُتزايد، فإنهم لم يُدعِّموها باللغة. ومع هذا، تُوفِّر الجافا ما يُعرَف باسم الواجهات (interfaces) والتي يُمكِن اِستخدَامها لتحقيق الكثير من أهداف الوراثة المُتعدّدة. لقد تَعرَّضنا -بالقسم ٤.٥- لواجهات نوع الدالة (functional interfaces) وعلاقتها بتعبيرات لامدا (lambda expressions)، ورأينا أنها تُخصِّص تابعًا (method) وحيدًا. في المقابل، يُمكِن للواجهات (interfaces) أن تَكُون أكثر تعقيدًا بمراحل كما أن لها استخدامات آخرى كثيرة. من غَيْر المُحتمَل أن تحتاج إلى كتابة واجهات (interfaces) خاصة بك حاليًا؛ فهي ضرورية فقط للبرامج المُعقَّدة نسبيًا، ولكن هنالك عدة واجهات (interfaces) مُستخدَمة بحزم جافا القياسية (Java's standard packages) بطرائق مُهِمّة وتحتاج إلى تَعلُّم طريقة اِستخدَامها. تعريف الواجهات (interfaces) وتنفيذها (implementation) لقد تَعرَّضنا لمصطلح "الواجهة (interface)" ضِمْن أكثر من سياق، سواء فيما يَتَعلَّق بالصناديق السوداء (black boxes) في العموم أو فيما يَتَعلَّق بالبرامج الفرعية (subroutines) على وجه الخصوص. تَتكوَّن واجهة أي برنامج فرعي (subroutine interface) من اسمه، ونوعه المُعاد (return type)، وعدد مُعامِلاته (parameters) وأنواعها. تُمثِل تلك المعلومات كل ما أنت بحاجة إلى مَعرِفته لكي تَتَمكَّن من استدعاء البرنامج الفرعي. بالإضافة إلى ذلك، يَمتلك أي برنامج فرعي جزءًا تّنْفيذيًا (implementation)، هو كتلة الشيفرة المُعرِّفة له (defines) والتي تُنفَّذ عند استدعاءه. بلغة الجافا، كلمة interface هي كلمة محجوزة تَحمِل معنًى تقنيًا إضافيًا. وفقًا لهذا المعنى، تَتكوَّن الواجهة من مجموعة من واجهات توابع النُسخ (instance method interfaces) بدون أجزائها التّنفيذية (implementations). يستطيع أي صنف أن يُنفِّذ (implement) واجهة معينة بتوفير الأجزاء التّنْفيذية (implementation) لجميع التوابع المُخصَّصة ضِمْن تلك الواجهة. اُنظر المثال التالي لواجهة (interface) بسيطة جدًا بلغة الجافا: public interface Strokeable { public void stroke(GraphicsContext g); } تبدو الشيفرة بالأعلى مشابهة لتعريف صنف (class definition) باستثناء حَذْف الجزء التّنْفيذي (implementation) للتابع stroke()‎. إذا أراد صنف معين أن يُنفِّذ تلك الواجهة Strokeable، فلابُدّ له من أن يُوفِّر جزءًا تّنْفيذيًا للتابع stroke()‎ كما قد يَتَضمَّن أي توابع أو متغيرات آخرى. اُنظر الشيفرة التالية على سبيل المثال: public class Line implements Strokeable { public void stroke(GraphicsContext g) { . . . // ارسم خطًا } . . . // توابع ومتغيرات وبواني آخرى } لكي يُنفِّذ صنف واجهةً (interface) معينةً، ينبغي عليه أن يَفعَل أكثر من مُجرّد توفير الأجزاء التّنْفيذية (implementation) لجميع التوابع ضِمْن تلك الواجهة، فعليه تحديدًا أن يُعلن صراحةً عن تّنفيذه (implements) لتلك الواجهة باستخدام الكلمة المحجوزة implements كالمثال بالأعلى. لابُدّ لأي صنف حقيقي (concrete class) يَرغَب بتّنْفيذ الواجهة Strokeable من أن يُعرِّف تابع نسخة اسمه stroke()‎، لذا سيَتضمَّن أي كائن (object) مُنشَئ من هذا الصنف التابع stroke()‎. يُعدّ الكائن مُنفِّذًا (implement) لواجهة معينة إذا كان ينتمي لصنف يُنفِّذ (implements) تلك الواجهة، فمثلًا، يُنفِّذ أي كائن من النوع Line الواجهة Strokeable. في حين يستطيع الصنف أن يَتمدَّد (extend) من صنف واحد فقط، فإنه في المقابل يستطيع أن يُنفِّذ (implements) أي عدد من الواجهات (interfaces). وفي الواقع، يُمكِن للصنف أن يَتمدَّد (extend) من صنف آخر، وأن يُنفِّذ واجهة واحدة أو أكثر بنفس ذات الوقت، لذلك نستطيع كتابة التالي مثلًا: class FilledCircle extends Circle implements Strokeable, Fillable { . . . } على الرغم من أن الواجهات (interfaces) ليست أصنافًا (classes)، فإنها تُشبهها إلى حد كبير. في الواقع، أي واجهة (interface) هي أَشْبه ما تَكُون بصنف مُجرّد (abstract class) لا يُستخدَم لإنشاء كائنات، وإنما كقاعدة لإنشاء أصناف فرعية (subclasses). تُعدّ البرامج الفرعية (subroutines) ضِمْن أي واجهة توابعًا مجردةً (abstract methods)، والتي لابُدّ لأيّ صنف حقيقي (concrete class) يَرغَب بتّنْفيذ تلك الواجهة من أن يُنفِّذها (implement). تستطيع الموازنة بين الواجهة Strokeable والصَنْف المُجرّد (abstract class) التالي: public abstract class AbstractStrokeable { public abstract void stroke(GraphicsContext g); } يَكمُن الفرق بينهما في أن الصنف الذي يَتمدَّد (extend) من الصنف AbstractStrokeable لا يُمكِنه أن يَتَمدَّد من أي صنف آخر. أما الصنف الذي يُنفِّذ الواجهة Strokeable يستطيع أن يَتَمدَّد من أي صنف آخر كما يستطيع أن يُنفِّذ (implement) أي واجهات (interfaces) آخرى. بالإضافة إلى ذلك، يُمكِن لأي صنف مُجرّد (abstract class) أن يَتَضمَّن توابعًا غير مُجرّدة (non-abstract) وآخرى مُجرّدة (abstract). في المقابل، تستطيع أي واجهة (interface) أن تَتَضمَّن توابعًا مُجرّدة فقط، لذا فهي أَشْبه ما تَكُون بصنف مُجرّد نقي (pure). ينبغي أن تُصرِّح عن التوابع ضِمْن أي واجهة (interface) على أساس كَوْنها -أي التوابع- عامة public ومُجردّة abstract. ولمّا كان هذا هو الخيار الوحيد المُتاح، فإن تَخْصِيص هذين المُبدِّلين (modifiers) ضِمْن التّصْريح (declaration) ليس ضروريًا. إلى جانب التّصريح (method declarations) عن التوابع، يُمكِن لأي واجهة (interface) أن تُصرِّح عن وجود مُتْغيِّرات (variable declarations)، وينبغي عندها أن تُصرِّح عنها على أساس كَوْنها عامة public، وساكنة static، ونهائية final، ولذا فإنها تَصيِر عامة وساكنة ونهائية بأي صنف يُنفِّذ (implements) تلك الواجهة. ولمّا كان هذا هو الخيار الوحيد المُتاح للتّصْريح عنها، فإن تَخْصِيص تلك المُبدِّلات (modifiers) ضِمْن التّصْريح (declaration) ليس ضروريًا. اُنظر المثال التالي: public interface ConversionFactors { int INCHES_PER_FOOT = 12; int FEET_PER_YARD = 3; int YARDS_PER_MILE = 1760; } هذه هي الطريقة المناسبة لتعريف (define) ثوابت مُسماة (named constants) يُمكِن اِستخدَامها بعدة أصناف. يُمكِن لأي صنف يُنفِّذ (implements) الواجهة ConversionFactors أن يَستخدِم الثوابت المُعرَّفة بتلك الواجهة (interface) كما لو كانت مُعرَّفة بالصنف. لاحِظ أن أي مُتْغيِّر مُعرَّف ضِمْن واجهة (interface) هو بالنهاية ثابت (constant) وليس مُتْغيِّرًا على الإطلاق. وفي العموم، لا يُمكِن لأي واجهة (interface) أن تُضيف مُتْغيِّرات نُسخ (instance variables) إلى الأصناف التي تُنفِّذها (implement). يُمكِن لأي واجهة (interface) أن تَتَمدَّد (extend) من واجهة واحدة أو أكثر. على سبيل المثال، إذا كان لدينا الواجهة Strokeable المُعطاة بالأعلى، بالإضافة إلى الواجهة Fillable والتي تُعرِّف التابع fill(g)‎، نستطيع عندها تعريف الواجهة التالية: public interface Drawable extends Strokeable, Fillable { // المزيد من التوابع أو الثوابت } ينبغي لأي صَنْف حقيقي (concrete class) يُنفِّذ الواجهة Drawable من أن يُوفِّر الأجزاء التّنْفيذية (implementations) لكُلًا من التابع stroke()‎ من الواجهة Strokeable، والتابع draw()‎ من الواجهة Fillable، بالإضافة إلى أي توابع مُجرّدة (abstract methods) آخرى قد تُخصِّصها الواجهة Drawable مباشرة. عادة ما تُعرَّف (define) الواجهة (interface) ضِمْن ملف ‎.java الخاص بها، والذي لابُدّ أن يَكُون له نفس اسم الواجهة. فمثلًا، تُعرَّف الواجهة Strokeable بملف اسمه Strokeable.java. وبالمثل من الأصناف (classes)، يُمكِن للواجهة (interface) أن تقع ضِمْن حزمة (package)، كما يُمكِنها أن تَستورِد (import) أشياءً من حزم آخرى. التوابع الافتراضية (default methods) بداية من الإصدار الثامن من الجافا، تستطيع الواجهات (interfaces) أن تَتَضمَّن ما يعرف باسم "التوابع الافتراضية (default methods)"، والتي تَملُك جزءًا تّنْفيذيًا (implementation) بعكس التوابع المُجرّدة (abstract methods) المُعتادة. تُورَث التوابع الافتراضية من الواجهات (interfaces) إلى أصنافها المُنفِّذة (implement) بنفس الطريقة التي تُورَث بها التوابع العادية من الأصناف إلى أصنافها الفرعية. لذا عندما يُنفِّذ (implement) صنف معين واجهةً تَحتوِي على توابع افتراضية، فإنه لا يَكُون مضطرًا لأن يُوفِّر جزءًا تّنْفيذيًا (implementation) لأي تابع افتراضي (default method) ضِمْن الواجهة، مع أن بإمكانه القيام بذلك إذا كان لديه تّنْفيذًا (implementation) مُختلفًا. تَدفَع التوابع الافتراضية (default methods) لغة الجافا خطوة للأمام بطريق دَعْم الوراثة المُتعدّدة (multiple inheritance)، ولكنها مع ذلك ليست وراثة مُتعدّدة بحق؛ لأن الواجهات لا تستطيع تعريف مُتْغيِّرات نُسخ (instance variables). تستطيع التوابع الافتراضية (default methods) استدعاء التوابع المجردة (abstract methods) المُعرَّفة بنفس الواجهة، لكنها لا تستطيع الإشارة إلى أي مُتْغيِّر نسخة (instance variable). ملحوظة: تستطيع واجهات نوع الدالة (functional interfaces) أيضًا أن تَحتوِي على توابع افتراضية (default methods) بالإضافة إلى التابع المُجرّد (abstract method) الوحيد الذي بإمكانها تَخْصِيصه. ينبغي أن تُصرِّح عن التوابع الافتراضية (default methods) على أساس كَوْنها عامة public، ولمّا كان ذلك هو الخيار الوحيد المُتاح، فإن تَخْصِيص المبدل public ضِمْن التّصْريح (declaration) ليس ضروريًا. في المقابل، لابُدّ من كتابة المُبدِّل default بشكل صريح أثناء التّصْريح عن أي تابع افتراضي (default method). اُنظر المثال التالي: public interface Readable { // تمثل مصدر إدخال public char readChar(); // اقرأ المحرف التالي المُدْخَل default public String readLine() { //اقرأ حتى نهاية السطر StringBuilder line = new StringBuilder(); char ch = readChar(); while (ch != '\n') { line.append(ch); ch = readChar(); } return line.toString(); } } لابُدّ لأي صنف حقيقي (concrete class) يُنفِّذ الواجهة (interface) -بالأعلى- من أن يُوفِّر تّنْفيذًا (implementation) للتابع readChar()‎. في المقابل، سيَرِث ذلك الصنف تعريف readLine()‎ من الواجهة، ولكنه قد يُوفِّر تعريفًا (definition) جديدًا إذا كان ذلك ضروريًا. عندما يَتَضمَّن صنف معين تّنفيذًا (implementation) لتابع افتراضي (default method)، فإن ذلك التّنْفيذ الجديد يُعيد تعريف (overrides) التابع الافتراضي الموجود بالواجهة (interface). بالمثال السابق، يَستدعِي التابع الافتراضي readLine()‎ التابع المُجرّد readChar()‎، والذي يَتوفَّر تعريفه (definition) فقط من خلال الأصناف المُنفِّذة للواجهة، ولهذا تُعدّ الإشارة إلى readChar()‎ مُتعدِّدة الأشكال (polymorphic). كُتب التّنْفيذ الافتراضي للتابع readLine()‎ بحيث يَكُون ملائمًا لأي صنف يُنفِّذ الواجهة Readable. اُنظر الشيفرة التالية والتي تَتَضمَّن صنفًا يُنفِّذ الواجهة Readable كما يَحتوِي على البرنامج main()‎ لاختبار الصَنْف: public class Stars implements Readable { public char readChar() { if (Math.random() > 0.02) return '*'; else return '\n'; } public static void main(String[] args) { Stars stars = new Stars(); for (int i = 0 ; i < 10; i++ ) { // اِستدعي التابع الافتراضي String line = stars.readLine(); System.out.println( line ); } } } تُوفِّر التوابع الافتراضية (default methods) إمكانية شبيهة لما يُعرَف باسم "المخلوط (mixin)" المُدعَّم ببعض اللغات البرمجية الآخرى، والتي تَعنِي المقدرة على خَلْط وظائف مصادر آخرى إلى داخل الصنف. لمّا كان بإمكان أي صنف أن يُنفِّذ أي عدد من الواجهات (interfaces)، فإنه يستطيع خلط وظائف عدة مصادر آخرى مختلفة. الواجهات كأنواع كما هو الحال مع الأصناف المُجرّدة (abstract classes)، لا يُمكِنك إنشاء كائن فعليّ من واجهة (interface)، ولكن تستطيع التّصْريح (declare) عن مُتْغيِّر نوعه عبارة عن واجهة. لنَفْترِض مثلًا أن لدينا الواجهة Strokeable المُعرَّفة بالأعلى، ويُنفِّذها كُلًا من الصنفين Line و Circle، يُمكِنك عندها كتابة التالي: // صرح عن متغير من النوع‫ Strokeable والذي يمكنه الإشارة إلى أي // كائن ينفذ تلك الواجهة Strokeable figure; figure = new Line(); // ‫يشير إلى كائن من الصنف Line figure.stroke(g); // ‫اِستدعي التابع stroke() من الصنف Line figure = new Circle(); // ‫يشير الآن إلى كائن من الصنف Circle figure.stroke(g); // ‫اِستدعي التابع stroke() من الصنف Circle يُمكِن لأي مُتْغيِّر من النوع Strokeable أن يُشير إلى أي كائن طالما كان صَنْفه يُنفِّذ الواجهة Strokeable. لمّا كان figure مُتْغيِّرًا من النوع Strokeable، ولأن أي كائن من النوع Strokeable يَحتوِي على التابع stroke()‎، فحتمًا سيَحتوِي الكائن الذي يُشير إليه المُتْغيِّر figure على التابع stroke()‎، ولهذا فإن التَعْليمَة figure.stroke(g)‎ صالحة تمامًا. تُستخدَم الأنواع (types) في العموم إما للتّصْريح (declare) عن مُتْغيِّر، أو لتَخْصِيص نوع معامل برنامج فرعي (routine)، أو لتَخْصِيص النوع المُعاد (return type) من دالة (function). النوع في العموم إما أن يَكُون صنفًا أو واجهة (interface) أو أحد الأنواع البسيطة (primitive) الثمانية المَبنية مُسْبَقًا (built-in). ليس هنالك من أيّ احتمال آخر، ربما باستثناء بعض الحالات الخاصة كأنواع التعداد (enum) والتي هي بمثابة نوع خاص من الأصناف. من بين كل تلك الأنواع، الأصناف هي الوحيدة التي يُمكِن اِستخدَامها لإنشاء كائنات (objects). يُمكِنك أيضًا اِستخدَام الواجهات (interface) لتَخْصِيص النوع الأساسي (base type) لمصفوفة. فمثلًا، تستطيع أن تُصرِّح عن مُتْغيِّر أو أن تُنشِئ مصفوفة باستخدام نوع المصفوفة Strokeable[]‎، وفي تلك الحالة، يُمكِن لعناصر تلك المصفوفة الإشارة إلى أي كائن طالما كان يُنفِّذ الواجهة Strokeable. اُنظر الشيفرة التالية: Strokeable[] listOfFigures; listOfFigures = new Strokeable[10]; listOfFigures[0] = new Line(); listOfFigures[1] = new Circle(); listOfFigures[2] = new Line(); . . . تَملُك جميع عناصر تلك المصفوفة التابع stroke()‎، مما يَعنِي إمكانية كتابة تعبيرات مثل listOfFigures.stroke(g)‎. ترجمة -بتصرّف- للقسم Section 7: Interfaces من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

تُعدّ الأفكار الأساسية التي تَرتَكِز عليها البرمجة كائنية التوجه (object-oriented programming) واضحة وبسيطة على نحو معقول، ومع ذلك فإنها ستَأخُذ منك بعض الوقت لكي تَعتَاد عليها تمامًا. بالإضافة إلى ذلك، هنالك الكثير من التفاصيل الدقيقة وراء تلك الأفكار الأساسية والتي قد تَكُون مزعجة في بعض الأحيان. سنُحاوِل أن نُغطِي بعضًا منها بالجزء المُتبقِي من هذا الفصل، وتَذَكَّر أنه ليس ضروريًا أن تَتَمكَّن من إِتقان كل تلك التفاصيل خاصة عند قرائتها لأول مرة. سنَفْحَص بهذا القسم تحديدًا المُتْغيِّرين this و super المُعرَّفين تلقائيًا بأي تابع نسخة (instance method) أو بَانِي كائن (constructor). المتغير الخاص this ما الذي يعنيه اِستخدَام مُعرِّف بسيط مثل amount أو process()‎ للإشارة إلى مُتْغيِّر أو تابع؟ تعتمد الإجابة بشكل أساسي على قواعد النطاق (scope rules)، والتي تُوضِح الأماكن التي يُمكِنها الوصول إلى أيّ مُتْغيِّر أو تابع قد صَرَّح عنه البرنامج وكيفية القيام بذلك. فمثلًا، قد يُشير اسم بسيط لمُتْغيِّر بتعريف تابع (method definition) إلى مُتْغيِّر محليّ (local variable) أو مُعامِل (parameter) في حالة وجود أي منهما ضِمْن النطاق (scope)، أيّ إن كان التَّصْريح (declaration) عن أيّ منهما ما يزال فعالًا بمكان حُدوث تلك الإشارة بالشيفرة، فإذا لم يَكُن كذلك، فإن ذلك الاسم لابُدّ وأنه يُشير إلى مُتْغيِّر عضو (member variable) مُعرَّف بنفس الصنف الذي حدثت فيه تلك الإشارة. بالمثل، أي اسم بسيط لتابع لابُدّ وأنه يُشير إلى تابع (method) مُعرَّف بنفس الصنف. يَملُك أي عضو ساكن (static member) بصنف اسمًا بسيطًا يُمكِن اِستخدَامه داخل تعريف الصَنْف (class definition) فقط. في المقابل، يُستخدَم الاسم الكامل للعضو . للإشارة إليه من خارج الصَنْف. فمثلًا، Math.PI هو مُتْغيِّر عضو ساكن (static member variable) اسمه البسيط هو PI داخل الصنف Math. لاحِظ أنه من المُمكن دومًا الإشارة إلى أي عضو ساكن باِستخدَام اسمه الكامل حتى من داخل الصنف المُعرَّف بداخله بل قد يَكُون ذلك ضروريًا في بعض الأحيان، مثلًا عندما يَكُون الاسم البسيط للمُتغير الساكن مخفيًا نتيجة وجود مُتْغيِّر محليّ (local variable) أو مُعامِل (parameter) بنفس الاسم. بالمثل، يَملُك أي عضو نسخة (instance member)، سواء كان مُتْغيِّر نسخة (instance variable) أو تابع نسخة (instance method)، اسمًا بسيطًا يُمكِن اِستخدَامه بتوابع النسخ (instance methods) -لا التوابع الساكنة (static methods)- بالصنف المُعرَّف بداخله. تَذَكَر أن أي مُتْغيِّر نسخة أو تابع نسخة هو جزء من الكائن ذاته وليس صَنْفه، فكل كائن يَمتلك نسخة خاصة به من ذلك المُتْغيِّر أو التابع. بالإضافة إلى الاسم البسيط، يَملُك أي عضو نسخة (instance member) اسمًا كاملًا، شطره الأول عبارة عن مَرجِع (reference) يُشير إلى الكائن المُتضمِّن لذاك العضو. مثلًا، إذا كان std مُتْغيِّر يُشير إلى كائن من النوع Student، فقد تُمثِل std.test1 الاسم الكامل لمُتْغيِّر نسخة (instance variable) اسمه test1 مُعرَّف ضِمْن الكائن. إذًا، عندما تَستخدِم الاسم البسيط لمُتْغيِّر نُسخة (instance variable) مثل test1 بداخل صنف معين، أين الكائن الذي يَتَضمَّن ذلك المُتْغيِّر؟ في الواقع، الأمر بسيط نوعًا ما. لنَفْترِض أنك أَشرت إلى الاسم test1 بتعريف تابع نسخة (instance method) معين، والذي هو بالتأكيد جزء من كائن من النوع Student. عندما يُنفَّذ ذلك التابع، فإن الاسم البسيط test1 يُشير عندها إلى المُتْغيِّر test1 المُعرَّف بذلك الكائن. في الواقع، هذا هو السبب وراء عدم إمكانية استخدام الأسماء البسيطة لأعضاء النسخ (instance members) ضِمْن أي تابع ساكن (static methods)؛ لأنه وبينما يُنفَّذ ذلك التابع الساكن، لا يَكُون هناك أي كائن، ومن ثم لا يَكُون هناك أي أعضاء نُسخ (instance members). يَضَعنا هذا أمام السؤال التالي: كيف نَستخدِم الاسم الكامل لعضو نسخة (instance members) داخل نفس الصَنْف المُعرَّف بداخله؟ نُريد ببساطة طريقة تُمكِّنا من الإشارة إلى "نفس ذات الكائن الحاضن للتابع". في الواقع، تُوفِّر الجافا المُتْغيِّر الخاص this لهذا الغرض. تستطيع اِستخدَام المُتْغيِّر this بتابع نسخة معين (instance method)؛ للإشارة إلى نفس ذات الكائن الحاضن لنفس ذات التابع. فمثلًا، إذا كان var هو مُتْغيِّر نسخة (instance variable) مُعرَّف بنفس ذات الكائن الحاضن لنفس ذات التابع، فإن this.var هو الاسم الكامل لذلك المُتْغيِّر. وبالمثل، إذا كان otherMethod()‎ هو تابع نسخة (instance method) بنفس ذات الكائن، فيُمكِن اِستخدَام this.otherMethod()‎ لاستدعاء ذلك التابع. عندما يُنفِّذ الحاسوب تابع نسخة (instance method) معين، فإنه تلقائيًا يَضَع المُتْغيِّر this بحيث يُشير إلى نفس ذات الكائن الحاضن للتابع. تَستخدِم بعض اللغات البرمجية كائنية التوجه (object oriented) الاسم self بدلًا من this. يُرَى عندها الكائن ككيان يَستقبِل الرسائل، ويَرُد عليها بتَّنْفيذ أمر معين. وفقًا لذلك الكيان، يُشير مُتْغيِّر نسخة (instance variable) مثل self.name إلى نسخة name الخاصة بالكيان، بينما يَكُون استدعاء تابع نسخة (instance method) مثل self.redraw()‎ بمثابة قوله "اِرسِل إلى نفسي رسالة redraw". يَشيع استخدام المُتْغيِّر الخاص this ببواني الكائنات (constructors)، كالتالي: public class Student { private String name; // اسم الطالب public Student(String name) { this.name = name; } . . // المزيد من المتغيرات والتوابع . } بباني الكائن (constructor) -بالأعلى-، أَصبَح مُتْغيِّر النسخة (instance variable)‏ name مَخفيًّا نتيجة اِستخدَام مُعامِل صُّوريّ (formal parameter) يَحمِل نفس الاسم name. مع ذلك، تستطيع اِستخدَام اسمه الكامل this.name للإشارة إليه. يُشير الاسم name على يمين تَعْليمَة الإِسْناد this.name = name إلى المُعامِل الصُّوريّ (formal parameter)، وتُسنَد قيمته إلى مُتْغيِّر النسخة this.name. يَشيِع اِستخدَام تلك الصياغة، وهي مقبولة في العموم؛ فليس هناك أي حاجة لاختيار أسماء جديدة للمُعامِلات الصُّوريّة المُستخدَمة فقط لتهيئة مُتْغيِّرات النُسخ (instance variables)، لذا اِستخدِم نفس الاسم لكليهما ببساطة. يُستخدَم المُتْغيِّر الخاص this لأغراض آخرى أيضًا. على سبيل المثال، بينما تَكْتُب تابع نسخة (instance method)، قد تحتاج إلى تمرير الكائن الحاضن للتابع إلى برنامج فرعي (subroutine) كمُعامِل فعليّ (actual parameter). في تلك الحالة، تستطيع ببساطة تمرير this. مثلًا، يُستخدَم System.out.println(this);‎ لطباعة تمثيل نصي (string representation) للكائن. بالإضافة إلى ذلك، قد تُسنِد this إلى مُتْغيِّر آخر ضِمْن تَعْليمَة إِسْناد (assignment statement) أو تُخزِّنه بمصفوفة. وفي العموم، تستطيع أن تَفعَل به أي شيء يُمكِنك فعله مع أي مُتْغيِّر آخر باستثناء تَعْدِيل قيمته (اِفْترِض أنه مُتْغيِّر نهائي مُعرَّف باِستخدَام المُبدِّل final). المتغير الخاص super تُعرِّف الجافا المُتْغيِّر الخاص super للاِستخدَام بتعريفات توابع النُسخ (instance methods) بالأصناف الفرعية (subclasses) تحديدًا. بالمثل من this، يُشير المُتْغيِّر الخاص super إلى نفس ذات الكائن الحاضن للتابع، ولكنه يَنسَى -إذا جاز التعبير- أن ذلك الكائن ينتمي إلى صَنْفه الفرعي (subclass)، ويَتَذكَّر فقط انتماءه إلى صَنْفه الأعلى (superclass). الفكرة ببساطة كالتالي: قد يَتَضمَّن الصَنْف الفرعي بعض الإضافات إلى الصَنْف الأعلى (superclass) أو حتى بعض التَعْديلات عليه، فكانت الحاجة إلى وجود طريقة للإشارة إلى التوابع (methods) والمُتْغيِّرات المُعرَّفة بالصَنْف الأعلى (superclass)، وهذا ما يُوفِّره المُتْغيِّر super فهو ببساطة لا يَعلَم أي شيء عن تلك الإضافات والتعديلات. لنَفْترِض أن لديك صَنْف فرعي يَحتوِي على تابع نسخة (instance method) اسمه doSomething()‎، ثُمَّ كَتبَت بأحد توابعه تَعْليمَة استدعاء البرنامج الفرعي التالية super.doSomething()‎. لمّا كان المُتْغيِّر super لا يَعلَم أي شيء عن التابع doSomething()‎ المُعرَّف بالصنف الفرعي، فهو فقط يَعلَم الأشياء المُعرَّفة بالصنف الأعلى (superclass)، فإنه سيُحاوِل تَّنْفيذ تابع اسمه doSomething()‎ من الصَنْف الأعلى (superclass)، فإذا لم يَجِدْه، أيّ في حالة كان التابع doSomething()‎ إضافةً وليس تعديلًا، فستَحصُل على خطأ في بناء الجملة (syntax error). وفَّرت الجافا المُتْغيِّر الخاص super لكي تَتَمكَّن من الوصول إلى أشياء كانت قد عُرِّفت بالصنف الأعلى (superclass)، ولكنها أصبحت مَخفيّة بواسطة بعض الأشياء المُعرَّفة بالأصناف الفرعية (subclasses). مثلًا، دائمًا ما سيُشير الاسم super.var إلى مُتْغيِّر النسخة (instance variable)‏ var المُعرَّف بالصنف الأعلى (superclass). يَكُون ذلك مفيدًا في بعض الحالات كالتالي: إذا اِحتوَى صنف معين على مُتْغيِّر نسخة (instance variable) له نفس اسم مُتْغيِّر نسخة بصنفه الأعلى (superclass)، فعندها سيَحتوِي أي كائن من الصَنْف الفرعي على مُتْغيِّرين لهما نفس الاسم، الأول مُعرَّف كجزء من الصنف نفسه، والآخر مُعرَّف كجزء من الصنف الأعلى، أيّ لا يَحلّ المُتْغيِّر بالصنف الفرعي (subclass) مَحلّ المُتْغيِّر بالصَنْف الأعلى حتى لو كان لهما نفس الاسم وإنما يُخفيه فقط، وعليه ما يزال المُتْغيِّر من الصنف الأعلى قابلًا للوصول باِستخدَام super. بالمثل، عندما يَتَضمَّن صنف فرعي (subclass) تابع نسخة (instance method) له نفس بصمة (signature) تابع مُعرَّف بالصنف الأعلى (superclass)، فإن التابع من الصنف الأعلى يُصبِح مَخفيًّا بنفس الطريقة، ويُقال عندها أن التابع من الصنف الفرعي أعاد تعريف (override) التابع من الصنف الأعلى. ومع ذلك، يُمكِن اِستخدَام المُتْغيِّر الخاص super للوصول إلى التابع من الصنف الأعلى (superclass). غالبًا ما يُستخدَم المُتْغيِّر super لتمديد (extend) سلوك تابع موروث بدلًا من أن يستبدله بالكامل، وذلك بكتابة تابع جديد يُعيد تعريف (override) التابع الأصلي. يَتَضمَّن التابع الجديد استدعاءً لتابع الصنف الأعلى (superclass) من خلال المُتْغيِّر super إلى جانب الشيفرة الجديدة المطلوب إضافتها بالأساس. لنَفْترِض مثلًا أن لدينا الصنف PairOfDice والذي يَتَضمَّن تابعًا اسمه roll()‎، والآن نريد إنشاء صنف فرعي GraphicalDice ليُمثِل حجري نَّرد مرسومين على الشاشة. ينبغي للتابع roll()‎ المُعرَّف بالصنف الفرعي GraphicalDice أن يُنفِّذ كل شيء يقوم به التابع roll()‎ المُعرَّف بالصنف الأعلى PairOfDice، وهو ما يُمكِننا التعبير عنه بالاستدعاء super.roll()‎، والذي سيَستدعِي نسخة التابع بالصنف الأعلى (superclass). بالإضافة إلى ذلك، ينبغي للتابع roll()‎ المُعرَّف بالصنف الفرعي GraphicalDice أن يُعيد رسم حجرى النَّرد لإظهار القيم الجديدة. يُمكِننا تعريف الصنف GraphicalDice كالتالي: public class GraphicalDice extends PairOfDice { public void roll() { super.roll(); // ‫استدعي roll من الصنف PairOfDice redraw(); // استدعي تابع لرسم حجري النرد } . . // ‫المزيد بما يتضمن تعريف redraw() . } يَسمَح ذلك عمومًا بتمديد (extend) سلوك التابع roll()‎ حتى لو لم تَكُن على علم بطريقة تَّنْفيذه (implementation) بالصنف الأعلى. super و this كبواني كائن لا تُورَث بواني الكائن (constructors) عمومًا، أي أنك إذا أنشأت صنفًا فرعيًا (subclass) من صنف موجود، فإن بواني الكائن المُعرَّفة بالصنف الأعلى (superclass) لا تُصبِح جزءًا من الصنف الفرعي. يُمكِنك إضافة بواني جديدة بالصنف الفرعي إذا أردت، وفي حالة عدم إضافتها، سيُنشِئ الحاسوب بَانِي كائن افتراضي (default constructor) بدون أي مُعامِلات (parameters). إذا كان الصنف الأعلى (superclass) يَحتوِي على باني كائن (constructor) يُنفِّذ الكثير من التهيئة الضرورية، فيبدو أنك ستَضطرّ إلى تَكْرار كل ذلك العمل بالصنف الفرعي. بالإضافة إلى ذلك، قد لا تَملُك شيفرة الصنف الأعلى (superclass)، ولا تَعلَم حتى طريقة تَّنْفيذها (implementation)، وهو ما قد يُمثِل مشكلة حقيقية، والتي قد تُصبِح مستحيلة إذا كان الباني المُعرَّف بالصنف الأعلى يَستخدِم مُتْغيِّرات أعضاء خاصة (private member variables)، ففي تلك الحالة، أنت لا تَملُك حتى صلاحية للوصول إليها من الصنف الفرعي. لابُدّ إذًا من وجود طريقة لإصلاح ذلك. في الواقع، قد يُستخدَم المُتْغيِّر الخاص super كأول تَعْليمَة بالباني (constructor) المُعرَّف بالصنف الفرعي؛ لكي يَستدعِي الباني (constructor) المُعرَّف بالصنف الأعلى (superclass). قد تَكُون طريقة كتابة ذلك مُضللة نوعًا ما؛ فهي تبدو كما لو كنت تَستدعِي super كبرنامج فرعي (subroutine) على الرغم من أنه ليس كذلك، وفي العموم لا يُمكِنك استدعاء البواني (constructors) بنفس طريقة استدعاء البرامج الفرعية. والآن، لنَفْترِض أن الصنف PairOfDice يَتَضمَّن باني كائن (constructor) يَستقبِل مُعامِلين (parameters) من النوع int، يُمكِننا إذًا أن نُعرِّف صنفًا فرعيًا (subclass) منه كالتالي: public class GraphicalDice extends PairOfDice { public GraphicalDice() { // باني كائن لهذا الصنف // استدعي الباني من الصنف الأساسي بقيم المعاملات 3 و 4 super(3,4); initializeGraphics(); // نفذ التهيئة الخاصة بالصنف الفرعي } . . // المزيد من البواني والمتغيرات والتوابع . } تَستدعِي التَعْليمَة super(3,4);‎ الباني (constructor) المُعرَّف بالصنف الأعلى. لابُدّ من كتابته بالسطر الأول من الباني المُعرَّف بالصنف الفرعي (subclass)، وفي حالة عدم استدعاء أي باني من الصنف الأعلى بصورة صريحة، يُستدعَى تلقائيًا بَانِي الصنف الأعلى الافتراضي (default constructor) أي ذلك الذي لا يَستقبِل أي مُعامِلات (parameters)، وإذا لم يَكُن موجودًا، سيُبلِّغ المُصرِّف (compiler) عن وجود خطأ في بناء الجملة (syntax error). يُستخدَم المُتْغيِّر الخاص this بنفس الطريقة تمامًا، ولكن لاستدعاء باني (constructor) آخر ضِمْن نفس الصنف. سيَبدُو عندها السطر الأول من الباني كما لو كان استدعاءً لبرنامج فرعي اسمه هو this، وسيُنفَّذ عندها مَتْن الباني المُستدعَى مما يُجنّبك تكرار نفس الشيفرة ضِمْن عدة بواني مختلفة. على سبيل المثال، يُستخدَم الصنف MosaicCanvas -من القسم ٤.٧- لتمثيل شبكة من المستطيلات الملونة، ويَتَضمَّن باني يَستقبِل أربعة مُعامِلات (parameters) كالتالي: public MosaicCanvas(int rows, int columns, int preferredBlockWidth, int preferredBlockHeight) يَستقبِل ذلك الباني مجموعة من الخيارات يُنفِّذ على أساسها الكثير من التهيئة (initialization). قد تحتاج إلى إضافة بواني (constructors) آخرى بعدد أقل من الخيارات لتَكُون أسهل في الاِستخدَام، ولكن ما يزال تَّنْفيذ التهيئة كاملة أمرًا ضروريًا. يَحتوِي الصنف على البواني التالية: public MosaicCanvas() { this(42,42); } public MosaicCanvas(int rows, int columns) { this(rows,columns,16,16); } يَستدعِى كل باني كائن (constructor) منهما باني كائن آخر بالإضافة إلى توفير قيم ثابتة للمُعامِلات الآخرى التي لم يَستقبِلها. على سبيل المثال، يَستدعِي التعبير this(42,42)‎ الباني الثاني، والذي بدوره يَستدعِي الباني الأساسي ذو المُعامِلات الأربعة. في الواقع، يُستدعَى الباني الأساسي بجميع الحالات وذلك لضمان تَّنْفيذ التهيئة (initialization) الضرورية كاملةً. ترجمة -بتصرّف- للقسم Section 6: this and super من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

تُستخدَم الأصناف (classes) لتمثيل مجموعة كائنات (objects) تَتَشارَك نفس البِنْية (structure) والسلوك (behavior). يُحدِّد الصَنْف بِنْية تلك الكائنات عن طريق تَخْصِيصه للمُتْغيِّرات الموجودة ضِمْن أي نسخة (instance) من الصَنْف، كما يُحدِّد سلوكها بتَعْريفه لتوابع نُسخ (instance methods) تُعبر عن سلوك (behavior) تلك الكائنات. هذه الفكرة قوية للغاية، ولكنها مع ذلك مُمكِنة بغالبية اللغات البرمجية التقليدية، فما هي إذًا الفكرة الجديدة التي تُقدِّمها البرمجة كائنية التوجه (object-oriented programming)، وتُفرِّقها عن البرمجة التقليدية؟ في الواقع، تُدعِّم البرمجة كائنية التوجه كُلًا من الوراثة (inheritance) والتعددية الشكلية (polymorphism)، والتي تسمح للأصناف (classes) بتمثيل التشابهات بين مجموعة كائنات تَتَشارَك بعضًا من بِنْيتها وسُلوكها، وليس كلها. توسيع (extend) الأصناف الموجودة لابُدّ لأي مبرمج أن يفهم المقصود بكُلًا من المفاهيم التالية: الصَنْف الفرعي (subclass)، والوراثة (inheritance)، والتعددية الشكلية (polymorphism). قد تَستغرِق بعض الوقت حتى تستطيع تَوْظِيف مواضيع مثل الوراثة (inheritance) تَوْظِيفًا فعليًا بعيدًا عن مُجرَّد تَمْديد (extending) بعض الأصناف الموجودة، وهو ما سنُناقشه بالجزء الأول من هذا القسم. ببداية تَعامُل المبرمجين مع الكائنات، عادةً ما يَقْتصر اِستخدَامهم للأصناف الفرعية على موقف واحد فقط: "التَعْديل على صَنْف موجود بالفعل أو الإضافة إليه بحيث يَتلائَم مع ما يُريدونه". يُعدّ ذلك أكثر شيوعًا من تصميم مجموعة كاملة من الأصناف الأعلى والأصناف الفرعية (subclasses). تستطيع أن تُمدِّد (extend) صَنْف فرعي من صَنْف آخر باستخدام الصيغة التالية: public class <subclass-name> extends <existing-class-name> { . . // التعديلات والإضافات . } لنَفْترِض أنك تُريد كتابة برنامج للعبة الورق "بلاك جاك (Blackjack)" تَستخدِم فيه الأصناف Card و Hand و Deck من القسم ٥.٤. أولًا، تَختلِف اليد (hand) بلعبة بلاك جاك نوعًا ما عن اليد في العموم؛ حيث تُحسَب قيمة اليد بلعبة بلاك جاك وِفقًا لقواعد اللعبة، والتي يُمكِن تَلخَّيصها كالتالي: تُحسَب قيمة اليد بجَمْع قيم ورق اللعب باليد، بحيث تَكُون قيمة ورقة اللعب العددية (numeric card)، مثل "ثلاثة" أو "عشرة"، مُساوِية لنفس قيمتها العددية، أما ورقة اللعب المُصورة، مثل "الرجل" أو "الملكة" أو "الملك"، فقيمتها تُساوِي عشرة. وأخيرًا، قيمة ورقة "الآص" قد تُساوِي ١ أو ١١. إنها في العموم تُساوِي ١١ إلا لو أدى ذلك إلى قيمة كلية أكبر من ٢١، مما يَعنِي أن ورقة "الآص" الثانية والثالثة والرابعة قيمها بالضرورة ستُساوِي ١. أحد الطرائق لمعالجة ما سبق هو توسيع (extend) الصنف Hand الموجود بإضافة تابع (method) يَحسِب قيمة اليد وفقًا للعبة بلاك جاك. اُنظر تعريف (definition) الصنف: public class BlackjackHand extends Hand { /** * Computes and returns the value of this hand in the game * of Blackjack. */ public int getBlackjackValue() { int val; // قيمة اليد boolean ace; int cards; // عدد ورق اللعب باليد val = 0; ace = false; cards = getCardCount(); // تابع معرف بالصنف الأعلى for ( int i = 0; i < cards; i++ ) { // أضف قيمة ورقة اللعب الحالية Card card; // ورقة اللعب الحالية int cardVal; // قيمة بلاك جاك لورقة اللعب الحالية card = getCard(i); cardVal = card.getValue(); // قيمة ورقة اللعب if (cardVal > 10) { cardVal = 10; } if (cardVal == 1) { ace = true; // هناك على الأقل ورقة آص } val = val + cardVal; } if ( ace == true && val + 10 <= 21 ) val = val + 10; return val; } // نهاية‫ getBlackjackValue } // نهاية الصنف‫ BlackjackHand لمّا كان الصَنْف BlackjackHand هو صَنْف فرعي (subclass) من الصَنْف الأعلى Hand، فإن أيّ كائن من الصَنْف الفرعي BlackjackHand سيَتَضمَّن، إلى جانب تابع النسخة getBlackjackValue()‎ المُعرَّف ضِمْن صَنْفه الفرعي، جميع مُتْغيِّرات النسخ (instance variables) وتوابع النسخ (instance methods) المُعرَّفة بالصَنْف الأعلى Hand. فمثلًا، إذا كان bjh مُتْغيِّرًا من النوع BlackjackHand، يَصِِح اِستخدَام أي من الاستدعاءات التالية: bjh.getCardCount()‎ و bjh.removeCard(0)‎ و bjh.getBlackjackValue()‎. على الرغم من أن التابعين الأول والثاني مُعرَّفين بالصَنْف Hand، إلا أنهما قد وُرِثَا إلى الصَنْف BlackjackHand. تُورَث المُتْغيِّرات والتوابع من الصَنْف الأعلى Hand إلى الصَنْف الفرعي BlackjackHand، ولهذا تستطيع اِستخدَامها بتعريف الصَنْف الفرعي BlackjackHand كما لو كانت مُعرَّفة فعليًا بذلك الصَنْف، باستثناء تلكم المُعرَّفة باِستخدَام المُبدِّل private ضِمْن الصَنْف الأعلى؛ حيث يَمنَع ذلك المُبدِّل الوصول إليها حتى من الأصناف الفرعية (subclasses). مثلًا، بتعريف التابع getBlackjackValue()‎ -بالأعلى-، تَمَكَّنت التَعْليمَة cards = getCardCount();‎ من استدعاء تابع النسخة getCardCount()‎ المُعرَّف بالصَنْف Hand. يُساعد تَمْديد (extend) الأصناف على الاعتماد على أعمالك السابقة، وفي الواقع لقد كُتبَت الكثير من الأصناف القياسية (standard classes) خصيصًا لتَكُون قاعدةً وأساسًا لإنشاء أصناف فرعية. تُستخدَم مُبدِّلات الوصول (access modifiers) مثل public و private للتَحكُّم بالوصول إلى أعضاء (members) الصَنْف. عندما نَأخُذ الأصناف الفرعية (subclasses) بالحُسبان، يُصبِح من المناسب الحديث عن مُبدِّل وصول آخر تُوفِّره الجافا، هو protected. عند اِستخدَام ذلك المُبدِّل أثناء التَّصْريح عن تابع (method) أو مُتْغيِّر عضو (member variable) بصَنْف، يُصبِح اِستخدَام ذلك العضو مُمكنًا ضِمْن الأصناف الفرعية لذلك الصَنْف وليس بأي مكان آخر. هنالك استثناء: عندما تَستخدِم المُبدِّل protected للتّصريح عن عضو (member)، فإنه يَكُون قابلًا للوصول من أي صَنْف بنفس الحزمة (package). ذَكَرَنا من قَبْل أنه في حالة عدم تخصيص أي مُبدِّل وصول (access modifier) لعضو معين، فإنه يُصبِح قابلًا للوصول من جميع الأصناف الواقعة ضِمْن نفس الحزمة وليس بأي مكان آخر. يُعدّ المُبدَّل protected أكثر تحررًا من ذلك بقليل؛ فبالإضافة إلى الأصناف الواقعة ضِمْن نفس الحزمة، فإنه يجعل العضو أيضًا قابلًا للوصول من الأصناف الفرعية (subclasses) التي لا تقع ضِمْن نفس الحزمة. عندما تُصرِّح عن تابع أو مُتْغيِّر عضو باستخدام المُبدِّل protected، يُصبِح ذلك العضو جزءًا من تّنْفيذ (implementation) الصنف لا واجهته (interface) العامة، كما يُسمَح للأصناف الفرعية (subclasses) باِستخدَام ذلك الجزء من التّنْفيذ (implementation) أو تَعْدِيله. على سبيل المثال، يَتَضمَّن الصَنْف PairOfDice مُتْغيِّري النسخة die1 و die2 لتمثيل الأعداد الظاهرة على حجرى نَّرد. قد نُصرِّح عنهما باِستخدَام المُبدِّل private لكي يُصبِح تَعْديل قيمتهما من خارج الصنف مستحيلًا، ثُمَّ نُعرِّف توابع جَلْب (getter methods) للسماح بقراءة قيمتهما من خارج الصنف، لكن لو تَبيَّن لك إمكانية الحاجة لاِستخدَام الصنف PairOfDice لإنشاء أصناف فرعية (subclasses)، فقد يَكُون من الأفضل حينها السماح لتلك الأصناف الفرعية (subclasses) بتَعْديل قيم تلك الأعداد، أي تعديل قيم تلك المُتْغيِّرات. فمثلًا، يَرسم الصنف الفرعي GraphicalDice حجري النَّرد، وقد يَضطرّ إلى تعديل قيم تلك الأعداد بتوقيت غَيْر ذلك الذي يُرمَي فيه حجري النَّرد. بدلًا من اِستخدَام المُبدِّل public في تلك الحالة، قد نَستخدِم المُبدِّل protected للتَّصْريح عن كُلًا من die1 و die2، مما سيَسمَح للأصناف الفرعية فقط -دون العالم الخارجي- بتَعْديل قيمتهما. كبديل، قد تُفضِّل تعريف توابع ضَبْط (setter methods) لتلك المُتْغيِّرات ضِمْن الصنف الأعلى، بحيث يُصرَّح عنها باِستخدَام المُبدِّل protected، وذلك لكي تَتَمكَّن من التَأكُّد من أن القيمة المطلوب إِسْنادها للمُتْغيِّر تقع ضِمْن نطاق يتراوح بين ١ و ٦. الوراثة (inheritance) وسلالة أصناف (class hierarchy) يُمكِن لصَنْف معين أن يَرِث جزء أو كل بِنيته (structure)، وسلوكه (behavior) من صَنْف آخر، وهو ما يُعرَف باسم الوراثة (inheritance). يُقال عن الصنف الوَارِث أنه صنفًا فرعيًا (subclass) من الصنف المَورُوث. إذا كان الصنف B هو صنف فرعي من الصنف A، فإننا نستطيع أيضًا أن نقول أن الصنف A هو صنف أعلى (superclass) من الصنف B. قد يُضيف الصنف الفرعي إلى ما وَرِثه من بنية وسلوك، كما قد يُعدِّل أو يَستبدِل ما وَرِثه من سلوك. تَستخدِم بعض اللغات البرمجية الآخرى، مثل لغة C++‎، مصطلحات أخرى كالصنف المُشتقّ (derived class) والصنف الأساسي (base class) بدلًا من الصنف الفرعي (subclass) والصنف الأعلى (superclass). عادةً ما تُوضَح العلاقة بين الصنف الفرعي (subclass) والصنف الأعلى (superclass) برسم توضيحي، يقع فيه الصنف الفرعي (subclass) أسفل صنفه الأعلى (superclass) ويَكُون مُتصلًا به، تمامًا كما هو مُوضَح بيسار الصورة التالية: تُستخدَم الشيفرة التالية لإنشاء صَنْف اسمه B بحيث يكون صنفًا فرعيًا من صنف آخر اسمه A: class B extends A { . . // إضافات أو تعديلات على الموروث من الصنف‫ A . } يُمكِنك أن تُصرِّح عن عدة أصناف على أساس كَوْنها أصناف فرعية (subclasses) من نفس الصنف الأعلى (superclass)، وتُعدّ الأصناف الفرعية في تلك الحالة "أصناف أخوة (sibling classes)" تَتَشارَك بعضًا من بِنيتها (structure) وسلوكها (behavior)، تَحْديدًا تلك المُوروثة من الصَنْف الأعلى المشترك، فمثلًا، الأصناف B و C و D بيمين الصورة السابقة هي أصناف أخوة (sibling classes). يُمكِن للوراثة (inheritance) أن تتمدَّد أيضًا عَبْر أجيال من الأصناف، فمثلًا، الصنف E -بالصورة السابقة- هو صنف فرعي من الصنف D، والذي هو بدوره صنف فرعي من الصنف A، ويُعدّ الصنف E عندها صنفًا فرعيًا من الصنف A حتى وإن لَمْ يَكُن صنفًا فرعيًا مباشرًا. تُشكِّل مجموعة الأصناف تلك سُلالة أصناف (class hierarchy) صغيرة. مثال والآن، لنَفْترِض أننا نريد كتابة برنامج ينبغي له التَعامُل مع المركبات المتحركة كالسيارات، والشاحنات، والدراجات النارية (قد يَستخدِمه قسم المركبات المتحركة لأغراض تَعقُّب التسجيلات). يُمكِننا أن نُعرِّف صَنْفًا اسمه Vehicle لتمثيل جميع أنواع المركبات، ولأن السيارات والشاحنات والدراجات النارية هي أنواع من المركبات، يُمكِننا تمثيلها باستخدام أصناف فرعية (subclasses) من الصنف Vehicle، كما هو مُوضَح بسُلالة الأصناف (class hierarchy) التالية: قد يَتَضمَّن الصنف Vehicle مُتْغيِّرات نُسخ (instance variables) مثل registrationNumber و owner، بالإضافة إلى توابع نُسخ (instance methods) مثل transferOwnership()‎. ستَملُك جميع المركبات تلك المُتْغيِّرات والتوابع. نستطيع الآن تعريف الأصناف الفرعية (subclasses) الثلاثة Car و Truck و Motorcycle المُشتقّة من الصَنْف Vehicle بحيث يَحمِل كُلًا منها مُتْغيِّرات وتوابع تَخُصّ ذلك النوع المُحدَّد من المركبات، فمثلًا، قد يُعرَّف الصنف Car مُتْغيِّر نسخة numberOfDoors، بينما قد يُعرَّف الصنف Truck مُتْغيِّر نسخة numberOfAxles، وقد يُضيف الصنف Motorcycle مُتْغيِّرًا منطقيًا اسمه hasSidecar. يُمكِننا التَّصْريح عن تلك الأصناف كالتالي (ببرنامج حقيقي، ستُعرَّف تلك الأصناف عادةً بملفات مُنفصلة وعلى أساس كَوْنها عامة): class Vehicle { int registrationNumber; Person owner; // (بفرض تعريف الصنف Person) void transferOwnership(Person newOwner) { . . . } . . . } class Car extends Vehicle { int numberOfDoors; . . . } class Truck extends Vehicle { int numberOfAxles; . . . } class Motorcycle extends Vehicle { boolean hasSidecar; . . . } لنَفْترِض أن myCar هو مُتْغيِّر من النوع Car صُرِّح عنه وهُيئ باِستخدَام التَعْليمَة التالية: Car myCar = new Car(); الآن، نستطيع الإشارة إلى myCar.numberOfDoors؛ لأن numberOfDoors مُتْغيِّر نسخة بالصنف Car. بالإضافة إلى ذلك، لمّا كان الصنف Car مُشتقًّا من الصنف Vehicle، فإن أي كائن من الصنف Car يَملُك بنية وسلوك الكائنات من الصنف Vehicle، مما يعني إمكانية الإشارة إلى كُلًا من myCar.registrationNumber و myCar.owner و myCar.transferOwnership()‎. بالعالم الحقيقي، تُعدّ كُلًا من السيارات والشاحنات والدراجات النارية مركبات، وهو ما أَصبَح مُتحقِّقًا بالبرنامج أيضًا، فأيّ كائن من النوع Car أو Truck أو Motorcycle يُعدّ كذلك كائنًا من النوع Vehicle تلقائيًا. يَقُودنا ذلك إلى الحقيقة الهامة التالية: إذا أمكَّن لمُتْغيِّر حَمْل مَرجِع إلى كائن من الصَنْف A، فحتمًا بإِمكانه حَمْل مَرجِع إلى الكائنات المُنتمية لأيّ من أصناف A الفرعية. عمليًا، يَعنِي ذلك إمكانية إِسْناد كائن من الصنف Car إلى مُتْغيِّر من النوع Vehicle، كالتالي: Vehicle myVehicle = myCar; أو كالتالي: Vehicle myVehicle = new Car(); بَعْد إجراء أيّ من التَعْليمَتين -بالأعلى-، سيَحمِل المُتْغيِّر myVehicle مَرجِعًا (reference) إلى كائن من النوع Vehicle، والذي هو في حقيقته نُسخة (instance) من الصَنْف الفرعي Car. يُدرك الكائن حقيقة انتماءه للصنف Car وليس فقط للصنف Vehicle، كما تُخزَّن تلك المعلومة -أيّ صنف الكائن الفعليّ- كجزء من الكائن نفسه، وتستطيع حتى اختبار ما إذا كان كائن معين ينتمي إلى أحد الأصناف عن طريق العَامِل instanceof، كالتالي: if (myVehicle instanceof Car) ... تَفْحَص التَعْليمَة -بالأعلى- ما إذا كان الكائن المُشار إليه باستخدام المُتْغيِّر myVehicle هو بالأساس من النوع Car. في المقابل، لا تَصِح تَعْليمَة الإِسْناد (assignment) التالية: myCar = myVehicle; // خطأ لأن myVehicle قد يُشير إلى أنواع آخرى غَيْر النوع Car. يُشبه ذلك المشكلة التي تَعرَّضنا لها بالقسم الفرعي ٢.٥.٦: لن يَسمَح الحاسوب بإِسْناد قيمة من النوع int إلى مُتْغيِّر من النوع short؛ لأن ليس كل int هو short بالضرورة. بالمثل، فإنه لن يَسمَح بإِسْناد قيمة من النوع Vehicle إلى مُتْغيِّر من النوع Car؛ لأن ليس كل كائن من النوع Vehicle هو كائن من النوع Car بالضرورة. بإِمكانك تَجاوُز تلك المشكلة عن طريق إجراء عملية التَحْوِيل بين الأنواع (type-casting)، فمثلًا، إذا كنت تَعلَم -بطريقة ما- أن myVehicle يُشير فعليًا إلى كائن من النوع Car، تستطيع اِستخدَام ‎(Car)myVehicle لإجبار الحاسوب على التَعامُل مع myVehicle كما لو كان من النوع Car. لذا تستطيع كتابة التالي: myCar = (Car)myVehicle; تستطيع حتى الإشارة إلى ‎((Car)myVehicle).numberOfDoors. لاحِظ أن الأقواس ضرورية لأسباب تَتَعلَّق بالأولوية (precedence)؛ فالعَامِل . لديه أولوية أكبر من عملية إجراء التَحْوِيل بين الأنواع (type-cast) أيّ أن التعبير ‎(Car)myVehicle.numberOfDoors سيُقرأ كما لو كان مَكْتُوبًا على الصورة (Car)(myVehicle.numberOfDoors) وستُجرَى عندها محاولة للتَحْوِيل من النوع int إلى Vehicle وهو أمر مستحيل. سنَفْحَص الآن مثالًا لكيفية اِستخدَام ما سبق ضِمْن برنامج. لنَفْترِض أننا نُريد طباعة البيانات المُتعلّقة بالكائن المُشار إليه باِستخدَام المُتْغيِّر myVehicle، فمثلًا، نَطبَع numberOfDoors إذا كان الكائن من النوع Car. لا نستطيع ببساطة الإشارة إليه باستخدام myVehicle.numberOfDoors؛ لأن الصَنْف Vehicle لا يَتَضمَّن أي numberOfDoors، وإنما نستطيع كتابة التالي: System.out.println("Vehicle Data:"); System.out.println("Registration number: " + myVehicle.registrationNumber); if (myVehicle instanceof Car) { System.out.println("Type of vehicle: Car"); Car c; c = (Car)myVehicle; // تحويل للنوع للوصول إلى numberOfDoors System.out.println("Number of doors: " + c.numberOfDoors); } else if (myVehicle instanceof Truck) { System.out.println("Type of vehicle: Truck"); Truck t; t = (Truck)myVehicle; // تحويل للنوع للوصول إلى numberOfAxles System.out.println("Number of axles: " + t.numberOfAxles); } else if (myVehicle instanceof Motorcycle) { System.out.println("Type of vehicle: Motorcycle"); Motorcycle m; m = (Motorcycle)myVehicle; // تحويل للنوع للوصول إلى hasSidecar System.out.println("Has a sidecar: " + m.hasSidecar); } فيما هو مُتعلِّق بالأنواع الكائنية (object type)، عندما يُجرِي الحاسوب عملية التَحْويل بين الأنواع (type cast)، فإنه يَفْحص أولًا ما إذا كانت تلك العملية صالحة أم لا، فمثلًا، إذا كان myVehicle يُشير إلى كائن من النوع Truck، فلا تَصِح العملية ‎(Car)myVehicle، وعليه، سيُبلَّغ عن اعتراض (exception) من النوع ClassCastException، ولهذا تَستخدِم الشيفرة -بالأعلى- العَامِل instanceof لاختبار نوع المُتْغيِّر قَبْل إجراء عملية التحويل بين الأنواع (type cast)؛ لتتجنَّب حُدوث الاعتراض ClassCastException. لاحِظ أن هذا الفَحْص يَحدُث وقت التنفيذ (run time) وليس وقت التصريف (compile time)؛ لأن النوع الفعليّ للكائن الذي يُشير إليه المُتْغيِّر myVehicle لا يَكُون معروفًا وقت تصريف البرنامج. التعددية الشكلية (polymorphism) لنَفْحص برنامجًا يَتعامَل مع أشكال تُرسَم على الشاشة، والتي قد تَكُون مستطيلة (rectangles)، أو بيضاوية (ovals)، أو مستطيلة بأركان دائرية (roundrect)، ومُلوَّنة جميعًا بألوان مختلفة. سنَستخدِم الأصناف الثلاثة Rectangle و Oval و RoundRect لتمثيل الأشكال المختلفة بحيث تَرِث تلك الأصناف من صَنْف أعلى (superclass) مُشترك Shape، وذلك لتمثيل السمات المشتركة بين جميع الأشكال. فمثلًا، قد يَتَضمَّن الصنف Shape مُتْغيِّرات نُسخ (instance variables) لتمثيل كُلًا من لون الشكل، وموضعه، وحجمه، كما قد يَتَضمَّن توابع نُسخ (instance methods) لتَعْديل قيم تلك السمات. مثلًا، لتَعْديل لون أحد الأشكال، فإننا سنُعدِّل قيمة مُتْغيِّر نُسخة ثم نُعيد رسم الشكل بلونه الجديد: class Shape { Color color; // لابد من استيرادها من حزمة‫ javafx.scene.paint void setColor(Color newColor) { // تابع لتغيير لون الشكل color = newColor; // غير قيمة متغير النسخة redraw(); // أعد رسم الشكل ليظهر باللون الجديد } void redraw() { // تابع لرسم الشكل ? ? ? // ما الذي ينبغي كتابته هنا؟ } . . . // المزيد من متغيرات النسخ والتوابع } // نهاية الصنف‫ Shape يُرسَم كل نوع من تلك الأشكال بطريقة مختلفة، ولهذا ستُواجهنا مشكلة بخصوص التابع redraw()‎. نستطيع عمومًا استدعاء التابع setColor()‎ لأي نوع من الأشكال، وبالتالي سيَحتَاج الحاسوب إلى تَّنْفيذ الاستدعاء redraw()‎، فكيف له إذًا أن يَعرِف الشكل الذي ينبغي عليه رَسْمه؟ نظريًا، يَطلُب الحاسوب من الشكل نفسه أن يقوم بعملية الرسم، فبالنهاية، يُفْترَض أن يَكُون كل كائن من النوع Shape على علم بما عليه القيام به لكي يَرسِم نفسه. عمليًا، يَعنِي ذلك أن كل صنف من الأصناف الثلاثة ينبغي له أن يُعرِّف نسخته الخاصة من التابع redraw()‎، كالتالي: class Rectangle extends Shape { void redraw() { . . . // تعليمات رسم مستطيل } . . . // المزيد من توابع ومتغيرات النسخ } class Oval extends Shape { void redraw() { . . . // تعليمات رسم شكل بيضاوي } . . . // المزيد من توابع ومتغيرات النسخ } class RoundRect extends Shape { void redraw() { . . . // تعليمات رسم مستطيل دائري الأركان } . . . // المزيد من توابع ومتغيرات النسخ } لنَفْترِض أن someShape هو مُتْغيِّر من النوع Shape، أيّ أنه يستطيع الإشارة إلى أيّ كائن ينتمي لأيّ من الأنواع Rectangle و Oval و RoundRect. أثناء تَّنْفيذ البرنامج، قد تَتغيَّر قيمة المُتْغيِّر someShape، مما يَعنِي أنه قد يُشير إلى كائنات من أنواع مختلفة بأوقات مختلفة! لذا، عندما تُنفَّذ التَعْليمَة التالية: someShape.redraw(); فإن نسخة التابع redraw المُستدعَاة فعليًا تَكُون تلك المُتناسبة مع النوع الفعليّ للكائن الذي يُشير إليه المُتْغيِّر someShape. بالنظر إلى نص الشيفرة فقط، قد لا تَتَمكَّن حتى من مَعرِفة الشكل الذي ستَرسِمه تلك التَعْليمَة حيث يعتمد ذلك بالأساس على القيمة التي تَصادَف أن احتواها someShape أثناء تَّنْفيذ البرنامج. علاوة على ذلك، لنَفْترِض أن تلك التَعْليمَة مُضمَّنة بحَلْقة تَكْرار (loop) وتُنفَّذ عدة مرات. إذا كانت قيمة someShape تتغيَّر بينما تُنفَّذ حَلْقة التَكْرار، فقد تَستدعِي نفس تلك التَعْليمَة someShape.redraw();‎ -أثناء تَّنْفيذها عدة مرات- توابعًا (methods) مختلفة، وتَرسِم أنواعًا مختلفة من الأشكال. يُقال عندها أن التابع redraw()‎ هو مُتعدِّد الأشكال (polymorphic). في العموم، يُعدّ تابع معين مُتعدد الأشكال (polymorphic) إذا كان ما يُنفِّذه ذلك التابع مُعتمدًا على النوع الفعليّ (actual type) للكائن المُطبقّ عليه التابع أثناء وقت التَّنْفيذ (run time)، وتُعدّ التعددية الشكلية (polymorphism) واحدة من أهم السمات المميزة للبرمجة كائنية التوجه (object-oriented programming). تَتضِح الصورة أكثر إذا كان لديك مصفوفة أشكال (array of shapes). لنَفْترِض أن shapelist هو مُتْغيِّر من النوع Shape[]‎ يُشير إلى مصفوفة قد أُنشأت وهُيأت عناصرها بمجموعة كائنات، والتي قد تَكُون من النوع Rectangle أو Oval أو RoundRect. نستطيع رسم جميع الأشكال بالمصفوفة بكتابة التالي: for (int i = 0; i < shapelist.length; i++ ) { Shape shape = shapelist[i]; shape.redraw(); } بينما تُنفَّذ الحلقة (loop) -بالأعلى-، فإن التَعْليمَة shape.redraw()‎ قد تَرسِم مستطيلًا أو شكلًا بيضاويًا أو مستطيلًا دائري الأركان اعتمادًا على نوع الكائن الذي يُشير إليه عنصر المصفوفة برقم المَوضِع i. ربما تَتضِح الفكرة أكثر إذا بدّلنا المصطلحات قليلًا كالتالي: بالبرمجة كائنية التوجه (object-oriented programming)، تُعدّ تَعْليمَة استدعاء أي تابع بمثابة إرسال رسالة إلى كائن، بحيث يَرُد ذلك الكائن على تلك الرسالة بتَّنْفيذ التابع المناسب. مثلًا، التَعْليمَة someShape.redraw();‎ هي بمثابة رسالة إلى الكائن المُشار إليه باِستخدَام someShape، ولمّا كان هذا الكائن يَعرِف بالضرورة النوع الذي ينتمي إليه، فإنه يَعرِف الكيفية التي ينبغي أن يَرُد بها على تلك الرسالة. وفقًا لذلك، يُنفِّذ الحاسوب الاستدعاء someShape.redraw();‎ بنفس الطريقة دائمًا، أيّ يُرسِل رسالة يَعتمِد الرد عليها على المُستقبِل. تَكُون الكائنات (objects) عندها بمثابة كيانات نَشِطة تُرسِل الرسائل وتَستقبِلها، كما تَكُون التعددية الشكلية (polymorphism) -وفقًا لهذا التصور- جزءًا طبيعًيا، بل وضروريًا، فتَعنِي فقط أنه من الممكن لكائنات مختلفة الرد على نفس الرسالة بطرائق مختلفة. تَسمَح لك التعددية الشكلية (polymorphism) بكتابة شيفرة تُنفِّذ أشياء قد لا تَتَصوَّرها حتى أثناء الكتابة، وهو في الواقع أحد أكثر الأشياء الرائعة المُتعلِّقة بها. لنَفْترِض مثلًا أنه قد تَقرَّر إضافة مستطيلات مشطوفة الأركان (beveled rectangles) إلى أنواع الأشكال التي يُمكِن للبرنامج التَعامُل معها. لتَّنْفيذ (implement) المستطيلات مشطوفة الأركان، يُمكِننا أن نُضيف صنفًا فرعيًا (subclass) جديدًا، وليَكُن BeveledRect، مُشتقًّا من الصنف Shape، ثم نُعرِّف به نسخته من التابع redraw()‎. تلقائيًا، ستَجِدْ أن الشيفرة التي كنا قد كتبناها سابقًا، أيّ someShape.redraw()‎، قد أَصبَح بإِمكانها فجأة رسم المستطيلات مشطوفة الأركان على الرغم من أن صَنْف تلك المستطيلات لم يَكُن موجودًا من الأساس أثناء كتابة تلك التَعْليمَة. تُرسَل الرسالة redraw إلى الكائن someShape أثناء تَّنْفيذ التَعْليمَة someShape.redraw();‎. لنَفْحَص مرة آخرى التابع المسئول عن تَعْديل لون الشكل والمُعرَّف بالصنف Shape: void setColor(Color newColor) { color = newColor; // غير قيمة متغير النسخة redraw(); // أعد رسم الشكل ليظهر باللون الجديد } بالأعلى، تُرسَل الرسالة redraw ولكن إلى أي كائن؟ حسنًا، يُعدّ التابع setColor هو الآخر بمثابة رسالة كانت قد أُرْسِلَت إلى كائن معين. لذا، فإن الرسالة redraw تُرسَل إلى نفس ذلك الكائن الذي كان قد اِستقبَل الرسالة setColor. إذا كان هذا الكائن مستطيلًا، فإنه يَحتوِي على تابع redraw()‎ لرسم المستطيلات وذاك التابع هو ما سيُنفَّذ. أما إذا كان هذا الكائن شكلًا بيضاويًا، فسيُنفَّذ التابع redraw()‎ المُعرَّف بالصنف Oval. يَعنِي ذلك أنه ليس من الضروري لتَعْليمَة redraw();‎ بالتابع setColor()‎ أن تَستدعِي التابع redraw()‎ المُعرَّف بالصنف Shape، وإنما قد يُنفَّذ أي تابع redraw()‎ طالما كان مُعرَّفًا بصنف فرعي مشتق من Shape. هذه هي فقط حالة آخرى من التعددية الشكلية (polymorphism). الأصناف المجردة (abstract classes) وقتما يَضطرّ كائن من الصنف Rectangle أو Oval أو RoundRect إلى رَسْم نفسه، سيُنفَّذ التابع redraw()‎ المُعرَّف بالصنف المناسب، وهو ما يَقُودنا للسؤال التالي: ما دور التابع redraw()‎ المُعرَّف بالصنف Shape؟ وكيف لنا أن نُعرِّفه؟ قد تتفاجئ من الإجابة، ففي الحقيقة ينبغي أن نَترُكه فارغًا لأن الصنف Shape لا يُمثِل سوى فكرة مُجردة (abstract) لشكل، وبالتأكيد ليس هناك طريقة لرسم شيء كذلك، وإنما يُمكِن فقط رَسْم الأشكال الحقيقية (concrete) كالمستطيلات والأشكال البيضاوية. إذًا، لماذا ينبغي أن نُعرِّف التابع redraw()‎ بالصنف Shape من الأساس؟ حسنًا، نحن مُضطرون إلى ذلك وإلا لن يَصِح استدعائه بالتابع setColor()‎ المُعرَّف بالصنف Shape كما لن يَصِح كتابة شيئًا مثل someShape.redraw();‎؛ حيث سيَعترِض المُصرِّف لكَوْن someShape مُتْغيِّرًا من النوع Shape في حين لا يَحتوِي ذلك الصَنْف على التابع redraw()‎. وعليه، لن يُستدعَى التابع redraw()‎ المُعرَّف بالصنف Shape نهائيًا، وربما -إذا فكرت بالأمر- ستَجِدْ أنه ليس هناك أي سبب قد يَضطرّنا حتى إلى إنشاء كائن فعليّ من الصنف Shape. تستطيع بالتأكيد إنشاء مُتْغيِّرات من النوع Shape، ولكنها دومًا ستُشير إلى كائنات (objects) من الأصناف الفرعية (subclasses) للصَنْف Shape. في مثل تلك الحالات، يُعدّ الصنف Shape صنفًا مُجرَّدًا (abstract class). لا تُستخدَم الأصناف المُجرّدة (abstract class) لإنشاء كائنات، وإنما فقط تُمثِل قاعدة وأساسًا لإنشاء أصناف فرعية أيّ أنها موجودة فقط للتعبير عن بعض السمات والخاصيات المشتركة بجميع أصنافها الفرعية (subclasses). أما الصَنْف غَيْر المُجرّد فيُعدّ صنفًا حقيقيًا (concrete class). في العموم، تستطيع إنشاء كائنات تنتمي لأصناف حقيقية (concrete class) وليس لأصناف مُجرّدة (abstract class)، كما يستطيع مُتْغيِّر من نوع هو عبارة عن صنف مُجرّد (abstract class) أن يُشير فقط إلى كائنات تنتمي لأحد الأصناف الفرعية الحقيقية (concrete subclasses) المُشتقّة من ذلك الصنف المُجرّد (abstract class). بالمثل، يُعدّ التابع redraw()‎ المُعرَّف بالصنف Shape تابعًا مجردًا (abstract method)؛ فهو لا يُستدعَى نهائيًا وإنما تُستدعَى توابع redraw()‎ المُعرَّفة بالأصناف الفرعية للصنف Shape لرَسْم الأشكال بصورة فعليّة. اِضطرّرنا مع ذلك لتعريف التابع redraw()‎ بالصَنْف Shape للتأكيد على فِهم جميع الأشكال للرسالة redraw، أي أنه موجود فقط لتَخْصِيص الواجهة (interface) المُشتركة لنُسخ التابع redraw()‎ الفعليّة والحقيقية (concrete) والمُعرَّفة بالأصناف الفرعية، وبالتالي ليس هناك ما يَستدعِي احتواء التابع المُجرَّد redraw()‎ بالصنف Shape على أيّ شيفرة. كما ذَكَرَنا سابقًا، يُعدّ كُلًا من الصنف Shape وتابعه redraw()‎ بمثابة أفكارًا مجردةً (abstract) على نحو دلالي فقط حتى الآن، ولكن تستطيع إِعلام الحاسوب بهذه الحقيقة على نحو صياغي (syntactically) أيضًا عن طريق إضافة المُبدِّل abstract إلى تعريف (definition) كُلًا منهما. بخلاف أي تابع عادي، لا يُكتَب الجزء التنفيذي (implementation) للتوابع المُجرّدة (abstract method) وإنما تُستخدَم فاصلة منقوطة (semicolon). في المقابل، لابُدّ من كتابة الجزء التنفيذي (implementation) للتابع المُجرّد (abstract method) ضِمْن أي صَنْف فرعي حقيقي (concrete subclass) مُشتقّ من الصنف المُجرّد (abstract class). تَستعرِض الشيفرة التالية طريقة تعريف الصَنْف Shape كصنف مُجرّد (abstract class): public abstract class Shape { Color color; // لون الشكل void setColor(Color newColor) { // تابع لتغيير لون الشكل color = newColor; // غير قيمة متغير النسخة redraw(); // أعد رسم الشكل ليظهر باللون الجديد } abstract void redraw(); // تابع مجرد ينبغي أن يُعرَّف بالأصناف الفرعية الحقيقية . . . // المزيد من التوابع والنسخ } // نهاية الصنف‫ Shape بمُجرّد اِستخدَامك للمُبدِّل abstract أثناء التَّصْريح عن الصَنْف، لا تستطيع إنشاء كائنات فعليّة من النوع Shape، وسيُبلِّغ الحاسوب عن حُدوث خطأ في بناء الجملة (syntax error) إذا حاولت القيام بذلك. ربما يُعدّ الصَنْف Vehicle -الذي ناقشناه بالأعلى- صنفًا مجردًا (abstract class) أيضًا، فليس هناك أي طريقة لامتلاك مركبة كتلك، وإنما لابُدّ للمركبة الفعليّة أن تَكُون سيارة أو شاحنة أو دراجة نارية أو حتى أي نوع حقيقي (concrete) آخر. ذَكَرنا بالقسم الفرعي ٥.٣.٢ أن أيّ صنف لا يُصرَّح عن كَوْنه صنف فرعي (subclass) من أيّ صنف آخر -أيّ بدون الجزء extends- فإنه تلقائيًا يُصبِح صنفًا فرعيًا من الصنف القياسي Object كالتالي: public class myClass { . . . يُعدّ التَّصْريح بالأعلى مُكافئًا للتالي تمامًا: public class myClass extends Object { . . . يُمكِننا القول إذًا أن الصَنْف Object يقع بقمة سُلالة أصناف (class hierarchy) ضخمة تَتَضمَّن جميع الأصناف الآخرى. من الناحية الدلالية، يُعدّ الصنف Object صنفًا مجردًا (abstract class) بل ربما أكثر صنف مجرد على الإطلاق، ومع ذلك، لم يُصرَّح عنه على هذا الأساس من الناحية الصياغية، أيّ تستطيع إنشاء كائنات من النوع Object ولكن لن تَجِدْ الكثير لتفعله بها. ولأن أيّ صَنْف هو بالضرورة صنف فرعي (subclass) من الصَنْف Object، فيُمكِن لمُتْغيِّر من النوع Object أن يُشير إلى أي كائن مهما كان نوعه. بالمثل، تستطيع مصفوفة من النوع Object[]‎ أن تَحمِل كائنات من أي نوع. تَستخدِم الشيفرة المصدرية بالملف ShapeDraw.java الصَنْف المُجرّد Shape، بالإضافة إلى مصفوفة من النوع Shape[]‎ لحَمْل قائمة من الأشكال. قد تَرغَب بإلقاء نظرة على ذلك الملف مع أنك لن تَتَمكَّن من فهمه بالكامل حاليًا؛ فتعريفات الأصناف الفرعية بالملف مختلفة نوعًا ما عن تلك التي رأيتها بالأعلى. مثلًا، يَستقبِل التابع draw()‎ مُعامِلًا (parameter) من النوع GraphicsContext؛ لأن الرَسْم بالجافا يَتطلَّب سياقًا رُسوميًا. سنَتَعرَّض لأمثلة شبيهة بالفصول اللاحقة بعدما تَتَعرَف على برمجة واجهات المُستخدِم الرُسومية (GUI). يُمكِنك مع ذلك فَحْص تعريف الصنف Shape وأصنافه الفرعية (subclasses) بالإضافة إلى طريقة اِستخدَام المصفوفة لحَمْل قائمة الأشكال. تَستعرِض الصورة التالية لقطة للشاشة أثناء تَشْغِيل البرنامج: بعد تَشْغِيل البرنامج ShapeDraw، تستطيع أن تُضيف شكلًا جديدًا إلى الصورة عن طريق الضغط على أيّ من الأزرار الموجودة بالأسفل. يُمكِنك أيضًا اختيار لون ذلك الشكل من خلال قائمة الألوان الموجودة أسفل مساحة الرسم (drawing area). سيَظهَر الشكل الجديد بالركن الأيسر العلوي من مساحة الرسم (drawing area)، وبمُجرّد ظُهوره، تستطيع سَحْبه باستخدَام الفأرة. سيُحافِظ الشكل دومًا على ترتيبه بالنسبة لبقية الأشكال الموجودة على الشاشة حتى أثناء عملية السَحْب، ومع ذلك، تستطيع اختيار شكل معين ليُصبِح أمام جميع الأشكال الأخرى عن طريق الضغط باستمرار على المفتاح "shift" بينما تَضغَط على ذلك الشكل. في الحقيقة، يُستخدَم الصنف الفعليّ للشكل أثناء إضافته إلى الشاشة فقط. بعد ذلك، يُعالَج بالكامل على أساس كَوْنه شكلًا مجردًا (abstract). على سبيل المثال، يَتعامَل البرنامج (routine) المسئول عن عملية السَحْب مع مُتْغيِّرات من النوع Shape، ولا يُشير نهائيًا إلى أي من الأصناف الفرعية (subclasses). عندما يحتاج إلى رَسْم شكل، فإنه فقط يَستدعِي التابع draw أي أنه غَيْر مضطرّ لمَعرِفة طريقة رَسْم الشكل أو حتى مَعرِفة نوعه الفعليّ، وإنما تُوكَل عملية الرسم إلى الكائن ذاته. إذا أردت أن تُضيف نوعًا جديدًا من الأشكال إلى البرنامج، كل ما عليك القيام به هو الآتي: أولًا، ستُعرِّف صنفًا فرعيًا (subclass) جديدًا مُشتقًّا من Shape، ثم ستُضيف زرًا جديدًا وتُبرمجه بحيث يُضيف الشكل إلى الشاشة. ترجمة -بتصرّف- للقسم Section 5: Inheritance, Polymorphism, and Abstract Classes من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

سنتناول خلال هذا القسم عدة أمثلة للتصميم كائني التوجه (object-oriented). اخترنا أن تَكُون تلك الأمثلة بسيطة بما فيه الكفاية لتَسمَح لنا بتصميم أصناف قابلة لإعادة الاِستخدَام على نحو معقول. تحديدًا، سنُصمّم لعبة ورق تَستخدِم مجموعة ورق اللعب القياسية (deck) والمعروفة باسم "مجموعة ورق لعب البوكر". تصميم الأصناف يمكننا توصيف لعبة الورق كالتالي: "كأيّ لعبة ورق عادية، سيَحصُل كل لاعب على أكثر من ورقة لعب. بدايةً ستُخلَط (shuffle) مجموعة ورق اللعب (deck). بعد ذلك، ستُسحَب ورقة واحدة بكل مرة من مجموعة ورق اللعب (deck)، ثُمَّ تُوزَّع إلى يد (hand) أحد اللاعبين. قد يُستبعَد بعض ورق اللعب (cards) من يد أحد اللاعبين، وقد يُضاف ورق جديد. يَعتمِد فوز لاعب معين بالمباراة أو خسارته لها على كُلًا من قيم (values) (آص، ٢، ٣، ..، ملك)، ورموز (suits) ("بستوني spades"، "ديناري diamonds"، "قلب hearts"، "سباتي clubs") ورق اللعب الذي تَسلَّمه". إذا بحثنا عن الأسماء المذكورة بالتوصيف (specification) السابق، فسنَجِدْ التالي: لعبة، لاعب، يد (hand)، ورقة لعب (card)، مجموعة ورق اللعب (deck)، قيمة (value)، رمز (suit). يُعدّ كُلًا من الاسمين "قيمة" و "رمز" مُجرَّد قيم بسيطة، ويُمكِن تمثيلها كمُتْغيِّرات نُسخ (instance variables) بالصنف المُمثِل لورقة اللعب Card. يُمكِننا تمثيل الأسماء الخمسة الآخرى بواسطة أصناف (classes)، ولكننا سنَقْتصِر فقط على تلك الأسماء الأكثر قابلية لإعادة الاِستخدَام: ورقة لعب (card)، يد (hand)، مجموعة ورق اللعب (deck). أما إذا بحثنا عن الأفعال المذكورة بالتوصيف، فسنَجِدْ التالي: "خلط (shuffle) مجموعة ورق اللعب" و "توزيع ورقة لعب من مجموعة ورق اللعب". سنَستخدِم تابعي النُسخ (instance methods)‏ shuffle()‎ و dealCard()‎ لتمثيل كُلًا منهما ضِمْن الصَنْف Deck. بالإضافة إلى ذلك، هنالك أيضًا: "إضافة ورقة لعب إلى يد اللاعب" و "استبعاد ورقة لعب من يد اللاعب". سنَستخدِم تابعي النُسخ (instance methods)‏ addCard()‎ و removeCard()‎ لتمثيل كُلًا منهما ضِمْن الصنف Hand. أخيرًا، ورق اللعب هو كيان سلبي نوعًا ما، ولكن ينبغي على الأقل أن نَتَمكَّن من تَحْديد كُلًا من قيمته (value) ورمزه (suit). سنكتشف المزيد من توابع النُسخ الضرورية لاحقًا. أولًا، سنبدأ بتصميم الصنف Deck تفصيليًا. عندما نُنشِئ مجموعة ورق لعب (deck) لأول مرة، فإنها ستَحتوِي على ٥٢ ورقة لعب (card) مُرتَّبة معياريًا. لإنشاء مجموعة ورق لعب (deck) جديدة، سيَحتاج الصَنْف Deck إلى بَانِي (constructor) بدون أي مُعامِلات (parameters)؛ لأن أي مجموعة ورق لعب جديدة دائمًا ما تَكُون هي نفسها. سيَتَضمَّن الصَنْف Deck تابع النُسخة (instance method)‏ shuffle()‎ المسئول عن ترتيب مجموعة ورق اللعب عشوائيًا، كما سيَتَضمَّن تابع النُسخة dealCard()‎ المسئول عن جَلْب ورقة اللعب (card) التالية من مجموعة ورق اللعب (deck). هذا التابع هو عبارة عن دالة (function) تُعيد قيمة من النوع Card؛ لأن المُستدعِي يحتاج إلى مَعرِفة ورقة اللعب (card) المُوزَّعة. في المقابل، لن يَستقبِل ذلك التابع أي مُعامِلات (parameters)؛ فليس هناك أيّ معلومات ينبغي تمريرها إلى مجموعة ورق اللعب (deck) عند سَحْب ورقة لعب (card)، فأنت فقط تُوزِّع ورقة اللعب التالية أيًا كانت. لكن ماذا سيَحدُث عند استدعاء التابع dealCard()‎ بينما لم يَعُدْ هناك أي ورق لعب إضافي بمجموعة ورق اللعب؟ في العموم، تُعدّ محاولة توزيع ورقة لعب من مجموعة ورق لعب فارغة بمثابة خطأ، لذا يُمكِن للصَنْف عندها أن يُبلِّغ عن اعتراض (exception). ولكن كيف سيَتَمكَّن البرنامج من مَعرِفة ما إذا كانت مجموعة ورق اللعب فارغة أم لا؟ قد يحتفظ البرنامج بعدد ورق اللعب المُستخدَم إلى الآن، ولكن ينبغي لمجموعة ورق اللعب نفسها أن تَكُون على دراية بتلك المعلومة، ولهذا سنُضيف تابع النسخة cardsLeft()‎ ليُعيد عدد ورق اللعب المُتبقِّي بمجموعة ورق اللعب، مما سيُمكِّن البرنامج أيضًا من سؤال مجموعة ورق اللعب عن العدد المُتبقِّي. اُنظر التوصيف الكامل لجميع البرامج الفرعية (subroutines) بالصنف Deck: /** * Constructor. Create an unshuffled deck of cards. */ public Deck() /** * Put all the used cards back into the deck, * and shuffle it into a random order. */ public void shuffle() /** * As cards are dealt from the deck, the number of * cards left decreases. This function returns the * number of cards that are still left in the deck. */ public int cardsLeft() /** * Deals one card from the deck and returns it. * @throws IllegalStateException if no more cards are left. */ public Card dealCard() يَتَضمَّن التوصيف كل ما تحتاج إلى مَعرِفته لكي تَتَمكَّن من اِستخدَام الصَنْف Deck، ولكنه لا يُخبرنا عن كيفية تّنْفيذ الصنف، فبالنهاية هذا ليس تمرينًا على كتابة الشيفرة (coding) وإنما على التصميم (design). يمكنك أيضًا الإطلاع على الشيفرة المصدرية للصنف بالملف Deck.java إذا شئت. ستلاحظ أن الصنف يحتوي على متغير نسخة (instance variable) عبارة عن مصفوفة من النوع Cards. ربما لن تفهم بعض النقاط بالتنفيذ (implementation) الداخلي للصنف، ولكن ما يزال بإمكانك استخدامه بالبرامج الخاصة بك كصندوق أسود (black box). بالمثل، يُمكِننا تحليل الصَنْف Hand. عندما نُنشِئ يد (hand) لأول مرة، فإنها لا تَحتوِي على أي ورق لعب (card). سيَتَضمَّن الصَنْف Hand تابع النُسخة (instance method)‏ addCard()‎ المسئول عن إضافة ورقة لعب إلى اليد. يَستقبِل ذلك التابع مُعامِلًا (parameter) من النوع Card لتَخْصِيص ورقة اللعب (card) المضافة. سيَتَضمَّن الصنف أيضًا تابع النُسخة removeCard()‎ المسئول عن استبعاد ورقة لعب من اليد. بالمثل، يَستقبِل ذلك التابع مُعامِلًا (parameter) من النوع Card لتَخْْصِيص ورقة اللعب (card) المُستبعدَة. والآن، لنطرح السؤال التالي: عند استبعاد ورقة لعب معينة من يد، هل ينبغي أن نُخصِّص ورقة اللعب ذاتها كأن نقول "استبعد ورقة الآص البستوني" أم عَبْر مَوضِعها باليد كأن نقول "استبعد ورقة اللعب الثالثة باليد"؟ يُمكِننا في الواقع السماح بالخيارين، فكما تَعلَم، يُمكِن لأيّ صنف أن يَتَضمَّن تابعين (methods) بنفس الاسم بشَّرْط أن يَكُون لديهما أعداد مختلفة أو أنواع مختلفة من المُعامِلات. ولهذا، سيَتَضمَّن الصَنْف نسختين من تابع النسخة removeCard()‎. يَستقبِل الأول مُعامِلًا (parameter) من النوع Card؛ لتَخْصِيص ورقة اللعب ذاتها المطلوب استبعادها، بينما يَستقبِل الآخر مُعامِلا (parameter) من النوع int؛ لتَخْصِيص مَوضِع ورقة اللعب المطلوب استبعادها. قد تَحتوِي اليد على عدد مُتْغيِّر من ورق اللعب، لذا سنُضيف تابع النُسخة getCardCount()‎ ليُعيد عدد ورق اللعب الموجود باليد. وأخيرًا، يُمكِننا أيضًا أن نضيف توابع نسخ (instance methods) آخرى لترتيب ورق اللعب باليد؛ حيث يُفضِّل كثير من اللاعبين ترتيب ورق اللعب بأيديهم بحيث يَتجَاوَر ورق اللعب من نفس القيمة. اُنظر التوصيف الكامل للصَنْف Hand القابل لإعادة الاستخدام: /** * Constructor. Create a Hand object that is initially empty. */ public Hand() /** * Discard all cards from the hand, making the hand empty. */ public void clear() /** * Add the card c to the hand. c should be non-null. * @throws NullPointerException if c is null. */ public void addCard(Card c) /** * If the specified card is in the hand, it is removed. */ public void removeCard(Card c) /** * Remove the card in the specified position from the * hand. Cards are numbered counting from zero. * @throws IllegalArgumentException if the specified * position does not exist in the hand. */ public void removeCard(int position) /** * Return the number of cards in the hand. */ public int getCardCount() /** * Get the card from the hand in given position, where * positions are numbered starting from 0. * @throws IllegalArgumentException if the specified * position does not exist in the hand. */ public Card getCard(int position) /** * Sorts the cards in the hand so that cards of the same * suit are grouped together, and within a suit the cards * are sorted by value. */ public void sortBySuit() /** * Sorts the cards in the hand so that cards are sorted into * order of increasing value. Cards with the same value * are sorted by suit. Note that aces are considered * to have the lowest value. */ public void sortByValue() يمكنك الإطلاع على الشيفرة المصدرية للصَنْف بالملف Hand.java. لاحِظ أنك لن تَتَمكَّن من فهم بعض الأشياء ضِمْن تَّنْفيذ (implementation) الصَنْف، ولكنها لن تمنعك من اِستخدَام الصَنْف بمشروعاتك. الصنف Card سنَفْحَص تصميم الصَنْف Card وتَّنْفيذه (implementation) تفصيليًا. يَحتوِي الصنف على بَانِي (constructor) يَستقبِل كُلًا من قيمة (value) ورقة اللعبة المُنشئة ورمزها (suit). نستطيع تمثيل الرموز الأربعة باستخدام الأعداد الصحيحة ٠ و ١ و ٢ و ٣، ولكن لصعوبة تَذكُّر الرمز الذي يُمثله كل عدد منها، عَرَّفنا أربعة ثوابت مُسماة (named constants) بالصَنْف Card لتمثيل الاحتمالات الأربعة، فمثلًا، يُمثِل Card.SPADES الرمز "بستوني spades". صَرَّحنا عن تلك الثوابت لتَكُون من النوع int، وباِستخدَام المُبدِّلات public final static. كان من المُمكن أن نَستخدِم أنواع التعداد (enumerated type)، ولكن سنكتفي بالاعتماد على الثوابت من النوع العددي الصحيح. أما قيم ورق اللعب المُحتملة فهي الأعداد من ١ وصولًا إلى ١٣، بحيث تُمثِل الأعداد ١ و ١١ و ١٢ و ١٣ كُلًا من "الآص" و "الرجل أو الشبّ" و "الملكة أو البنت" و "الملك أو الشايب" على الترتيب. بالمثل، عَرَّفنا بعض الثوابت المُسماة (named constants) لتمثيل كُلًا من ورقة الآص، وورق اللعب المُصور. ستَجِدْ أيضًا أننا قد أضفنا ورقة "الجوكر". بمُجرَّد معرفة كُلًا من قيمة (value) ورقة اللعب، ورمزها (suit)، نستطيع استدعاء البَانِي (constructor) لإنشاء كائن من النوع Card، كالتالي: card1 = new Card( Card.ACE, Card.SPADES ); // أنشئ ورقة آص بستوني card2 = new Card( 10, Card.DIAMONDS ); // أنشئ ورقة عشرة ديناري // ‫يُسمَح بذلك طالما كانت s و v تعبيرات من النوع العددي الصحيح card3 = new Card( v, s ); يحتاج أي كائن من الصَنْف Card إلى مُتْغيِّرات نُسخ (instance variables) لتمثيل كُلًا من قيمة ورقة اللعب ورمزها، لذلك أضفنا مُتْغيِّرات النسخ suit و value للصَنْف. بدايةً، صَرَّحنا عنها باِستخدَام المُبدِّل private حتى يَستحِيل تَعْديلها من خارج الصَنْف، وفي المقابل، أضفنا تابعي الجَلْب getSuit()‎ و getValue()‎ لكي تَتَمكَّن الشيفرة خارج الصَنْف من قراءة قيمة ورقة اللعب ورمزها. يَعنِي ذلك أن قيم تلك المُتْغيِّرات لن تتغير نهائيًا بَعْد تهيئتها المبدئية بالباني (constructor)، ولهذا كان من المنطقي التَّصْريح عنها باستخدام المُبدِّل final. يُمكِنك التَّصْريح عن أيّ مُتْغيِّر نُسخة (instance variable) عمومًا باِستخدَام المُبدِّل final، بشَّرْط إِسْناد قيمة إليه إما بتَعْليمَة التَّصْريح (declaration) أو بكل البواني (constructor) المُعرَّفة بذلك الصَنْف. تعدّ كائنات ذلك الصَنْف كائنات ثابتة أو غَيْر قابلة للتعديل (immutable)؛ لأن جميع مُتْغيِّرات النسخ المُعرَّفة ضِمْنها قد صُرِّح عنها باِستخدَام المُبدِّل final. أضفنا أيضًا بعض التوابع (methods) الآخرى إلى الصَنْف لطباعة كائناته (objects) بصيغة مقروءة، فمثلًا، بدلًا من طباعة العدد ٢ المُستخدَم لتمثيل الرمز "ديناري diamonds" ضِمْن الصَنْف، يُفضَّل طباعة الكلمة "Diamonds". ولأن عملية طباعة رمز ورقة اللعب شيئًا يُرجَح أن نحتاج إليه بالكثير من البرامج الآخرى، كان من المعقول إضافته للصَنْف، ولهذا أضفنا توابع النُسخ getValueAsString()‎ و getSuitAsString()‎ بحيث تُعيد التمثيل النصي (string representations) لكُلًا من قيمة ورقة اللعب ورمزها على الترتيب. بالإضافة إلى ذلك، عَرَّفنا تابع النسخة toString()‎ ليُعيد سِلسِلة نصية تَتَضمَّن كُلًا من قيمة ورقة اللعب ورمزها، مثل "ملكة القلوب". يُستدعَى هذا التابع (method) تلقائيًا لتَحْوِيل كائن من النوع Card إلى النوع String أينما اِستخدَمناه ضِمْن سياق يحتاج إلى سِلسِلة نصية، مثلًا عند ضمه (concatenate) إلى سِلسِلة نصية باِستخدَام العَامِل +. أي أن التَعْليمَة التالية: System.out.println( "Your card is the " + card ); تُكافئ تمامًا التَعْليمَة: System.out.println( "Your card is the " + card.toString() ); إذا كانت ورقة اللعب هي "ملكة القلوب"، فستَطبَع التَعْليمَتان السابقتان نفس السِلسِلة النصية "Your card is the Queen of Hearts". اُنظر شيفرة الصَنْف Card بالكامل، كما أنها موجودة بالملف Card.java. يُعدّ هذا الصنف عامًا بما فيه الكفاية بما يُتيِح إعادة اِستخدَامه، أيّ أن العمل الذي بذلناه أثناء كُلًا من التصميم (designing)، وكتابة الشيفرة، والاختبار (testing) سيُؤتي ثماره على المدى الطويل. public class Card { public final static int SPADES = 0; public final static int HEARTS = 1; public final static int DIAMONDS = 2; public final static int CLUBS = 3; public final static int JOKER = 4; public final static int ACE = 1; public final static int JACK = 11; public final static int QUEEN = 12; public final static int KING = 13; /** * This card's suit, one of the constants SPADES, HEARTS, DIAMONDS, * CLUBS, or JOKER. The suit cannot be changed after the card is * constructed. */ private final int suit; /** * The card's value. For a normal card, this is one of the values * 1 through 13, with 1 representing ACE. For a JOKER, the value * can be anything. The value cannot be changed after the card * is constructed. */ private final int value; /** * Creates a Joker, with 1 as the associated value. (Note that * "new Card()" is equivalent to "new Card(1,Card.JOKER)".) */ public Card() { suit = JOKER; value = 1; } /** * Creates a card with a specified suit and value. * @param theValue the value of the new card. For a regular card (non-joker), * the value must be in the range 1 through 13, with 1 representing an Ace. * You can use the constants Card.ACE, Card.JACK, Card.QUEEN, and Card.KING. * For a Joker, the value can be anything. * @param theSuit the suit of the new card. This must be one of the values * Card.SPADES, Card.HEARTS, Card.DIAMONDS, Card.CLUBS, or Card.JOKER. * @throws IllegalArgumentException if the parameter values are not in the * permissible ranges */ public Card(int theValue, int theSuit) { if (theSuit != SPADES && theSuit != HEARTS && theSuit != DIAMONDS && theSuit != CLUBS && theSuit != JOKER) throw new IllegalArgumentException("Illegal playing card suit"); if (theSuit != JOKER && (theValue < 1 || theValue > 13)) throw new IllegalArgumentException("Illegal playing card value"); value = theValue; suit = theSuit; } /** * Returns the suit of this card. * @returns the suit, which is one of the constants Card.SPADES, * Card.HEARTS, Card.DIAMONDS, Card.CLUBS, or Card.JOKER */ public int getSuit() { return suit; } /** * Returns the value of this card. * @return the value, which is one of the numbers 1 through 13, inclusive for * a regular card, and which can be any value for a Joker. */ public int getValue() { return value; } /** * Returns a String representation of the card's suit. * @return one of the strings "Spades", "Hearts", "Diamonds", "Clubs" * or "Joker". */ public String getSuitAsString() { switch ( suit ) { case SPADES: return "Spades"; case HEARTS: return "Hearts"; case DIAMONDS: return "Diamonds"; case CLUBS: return "Clubs"; default: return "Joker"; } } /** * Returns a String representation of the card's value. * @return for a regular card, one of the strings "Ace", "2", * "3", ..., "10", "Jack", "Queen", or "King". For a Joker, the * string is always numerical. */ public String getValueAsString() { if (suit == JOKER) return "" + value; else { switch ( value ) { case 1: return "Ace"; case 2: return "2"; case 3: return "3"; case 4: return "4"; case 5: return "5"; case 6: return "6"; case 7: return "7"; case 8: return "8"; case 9: return "9"; case 10: return "10"; case 11: return "Jack"; case 12: return "Queen"; default: return "King"; } } } /** * Returns a string representation of this card, including both * its suit and its value (except that for a Joker with value 1, * the return value is just "Joker"). Sample return values * are: "Queen of Hearts", "10 of Diamonds", "Ace of Spades", * "Joker", "Joker #2" */ public String toString() { if (suit == JOKER) { if (value == 1) return "Joker"; else return "Joker #" + value; } else return getValueAsString() + " of " + getSuitAsString(); } } // end class Card لعبة ورق بسيطة أخيرًا، تَستعرِض الشيفرة التالية برنامجًا كاملًا يَستخدِم الصَنْفين Card و Deck. يَسمَح البرنامج للمُستخدِم بلعب لعبة ورق بسيطة اسمها هو HighLow. تُخلَط مجموعة ورق اللعب (deck)، وتُسحَب ورقة لعب واحدة، ليراها المُستخدِم. بَعْد ذلك، عليه أن يَتوقَّع ما إذا كانت ورقة اللعب التالية ستَكُون أكبر أو أقل من ورقة اللعب الحالية. إذا كان تَوقُّع المُستخدِم صحيحًا، تَحلّ ورقة اللعب التالية مَحلّ ورقة اللعب الحالية، ثم يَتوقَّع المُستخدِم مرة آخرى، ويستمر الأمر إلى أن يَتوقَّع المُستخدِم تَوقُّعًا خاطئًا. مجموع النقاط التي تَحصَّل عليها المُستخدِم تُساوِي عدد التوقُّعات الصحيحة. يَتَضمَّن البرنامج تابعًا ساكنًا (static method). تُوكَل مُهِمّة لعب مباراة واحدة فقط من لعبة الورق HighLow لذلك التابع. يَسمَح البرنامج main()‎ للمُستخدِم بلعب عدة مباريات، وبالنهاية، يُخبره بمتوسط النقاط التي تَحصَّل عليها خلال جميع المباريات. لن نَمُرّ عَبْر مراحل تطوير الخوارزمية (algorithm) المُستخدَمة بالبرنامج، لكن ينبغي عليك أن تقرأها بحرص، وأن تتأكَّد من فِهم طريقة عملها. يُعيد البرنامج الفرعي (subroutine) المَسئول عن لعب مباراة واحدة من لعبة الورق HighLow نقاط المُستخدِم بالمباراة كقيمة مُعادة (return value) إلى البرنامج main حيث تُستخدَم. اُنظر البرنامج: import textio.TextIO; public class HighLow { public static void main(String[] args) { System.out.println("This program lets you play the simple card game,"); System.out.println("HighLow. A card is dealt from a deck of cards."); System.out.println("You have to predict whether the next card will be"); System.out.println("higher or lower. Your score in the game is the"); System.out.println("number of correct predictions you make before"); System.out.println("you guess wrong."); System.out.println(); int gamesPlayed = 0; // عدد المباريات التي لعبها المستخدم int sumOfScores = 0; // مجموع نقاط المستخدم double averageScore; // متوسط نقاط المستخدم // يحمل رد المستخدم على سؤاله عما إذا كان يريد لعب مباراة إضافية boolean playAgain; do { int scoreThisGame; // نقاط المستخدم بمباراة واحدة scoreThisGame = play(); // العب مباراة مع المستخدم sumOfScores += scoreThisGame; gamesPlayed++; System.out.print("Play again? "); playAgain = TextIO.getlnBoolean(); } while (playAgain); averageScore = ((double)sumOfScores) / gamesPlayed; System.out.println(); System.out.println("You played " + gamesPlayed + " games."); System.out.printf("Your average score was %1.3f.\n", averageScore); } // ‫نهاية main() /** * Lets the user play one game of HighLow, and returns the * user's score in that game. The score is the number of * correct guesses that the user makes. */ private static int play() { // أنشئ كائن مجموعة ورق لعب جديدة وخزن مرجعه بالمتغير Deck deck = new Deck(); Card currentCard; // ورقة اللعب الحالية التي يراها المستخدم // ورقة اللعب التالية التي يتوقع المستخدم ما // إذا كانت أكبر أو أقل من ورقة اللعب الحالية Card nextCard; int correctGuesses ; // عدد توقعات المستخدم الصحيحة char guess; // ‫تخمين المستخدم ويحمل القيمة L أو H deck.shuffle(); // رتب مجموعة ورق اللعب عشوائيًا correctGuesses = 0; currentCard = deck.dealCard(); System.out.println("The first card is the " + currentCard); while (true) { // تنتهي الحلقة عند التخمين الخاطئ /* اقرأ تخمين المستخدم */ System.out.print("Will the next card be higher (H) or lower (L)? "); do { guess = TextIO.getlnChar(); guess = Character.toUpperCase(guess); if (guess != 'H' && guess != 'L') System.out.print("Please respond with H or L: "); } while (guess != 'H' && guess != 'L'); /* اسحب ورقة اللعب التالية وأظهرها للمستخدم */ nextCard = deck.dealCard(); System.out.println("The next card is " + nextCard); /* افحص تخمين المستخدم */ if (nextCard.getValue() == currentCard.getValue()) { System.out.println("The value is the same as the previous card."); System.out.println("You lose on ties. Sorry!"); break; // أنهي المباراة } else if (nextCard.getValue() > currentCard.getValue()) { if (guess == 'H') { System.out.println("Your prediction was correct."); correctGuesses++; } else { System.out.println("Your prediction was incorrect."); break; // أنهي المباراة } } else { // إذا كانت ورقة اللعب التالية أقل if (guess == 'L') { System.out.println("Your prediction was correct."); correctGuesses++; } else { System.out.println("Your prediction was incorrect."); break; // أنهى المباراة } } /* تهيئة ضرورية للتكرار التالي ضمن الحلقة */ currentCard = nextCard; System.out.println(); System.out.println("The card is " + currentCard); } // نهاية الحلقة System.out.println(); System.out.println("The game is over."); System.out.println("You made " + correctGuesses + " correct predictions."); System.out.println(); return correctGuesses; } // ‫نهاية play() } // ‫نهاية الصنف HighLow ترجمة -بتصرّف- للقسم Section 4: Programming Example: Card, Hand, Deck من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java. اقرأ أيضًا تعرف على أشهر لغات برمجة الألعاب

يُمكِن تطبيق المفاهيم كائنية التوجه (object-oriented) على عملية تصميم البرامج وكتابتها في العموم بأكثر من طريقة، منها التحليل والتصميم كائني التوجه (object-oriented analysis and design). تُطبِق تلك الطريقة الأساليب كائنية التوجه (object-oriented) على أُولَى مراحل تطوير البرمجيات، والمسئولة عن تصميم البرنامج ككل. تَتَلخَّص تلك الطريقة بتَحْديد مجموعة الكيانات المُرتَبِطة بموضوع المشكلة (problem domain)، والتي يُمكِن تمثيلها ككائنات (objects). على مستوى آخر، تُشجِع البرمجة كائنية التوجه (object-oriented programming) المبرمجين على إنشاء "أدوات برمجية مُعمَّمة" قابلة للاِستخدَام بالعديد من المشروعات البرمجية المختلفة. سنَستخدِم "الأدوات البرمجية المُعمَّمة" بصورة أكبر حين نبدأ باِستخدَام الأصناف القياسية (standard classes) بالجافا. سنبدأ هذا القسم بفَحْص بعضًا من تلك الأصناف المَبنية مُسْبَقًا (built-in)، والمُستخدَمة لإنشاء أنواع معينة من الكائنات (objects)، وسنعود مُجدّدًا إلى الصورة العامة بنهاية القسم. بعض الأصناف المبنية مسبقًا بالبرمجة كائنية التوجه (object-oriented programming)، يَكُون التركيز عادةً على تصميم أصناف جديدة، وكتابة تَّنْفيذها (implementation)، ولكن يَنبغي أيضًا ألا نُهمِل ذلك العدد الكبير من الأصناف (classes) التي وفرها لنا مُصمّمي الجافا. يُمكِننا أن نَستخدِم بعضًا من تلك الأصناف لإنتاج أصناف جديدة، بينما قد نَستخدِم البعض الآخر مُباشرة لإِنشاء كائنات. لكي تَتَمكَّن فعليًا من لغة الجافا، ينبغي أن تَكُون على دراية بعدد كبير من تلك الأصناف المَبنية مُسْبَقًا (built-in classes)، وهو ما يَحتاج إلى الكثير من الوقت والخبرة لتطويره. سنَفْحَص خلال هذا القسم بعضًا من تلك الأصناف. يُمكِننا أن نُنشِئ سِلسِلة نصية (string) من نصوص أصغر باِستخدَام العَامِل +، ولكن لا يَكُون ذلك دائمًا هو الحل الأفضل. فمثلًا، إذا كان str مُتْغيِّرًا من النوع String و ch محرفًا (character)، فإن تّنْفيذ الأمر str = str + ch;‎ يَتَضمَّن إنشاء كائن جديد كليًا من النوع String، مُكوَّن من نُسخة من str مع قيمة ch مُلحقَّة بآخره. يَستغرِق نَسخ السِلسِلة النصية بعض الوقت كما يَتَطلَّب قدرًا كبيرًا من المعالجة. في المقابل، يَسمَح الصنف StringBuilder بإنشاء سِلسِلة نصية طويلة من نصوص أصغر بكفاءة. يُمكِننا أن نُنشِئ كائنًا ينتمي إلى الصنف StringBuilder كالتالي: StringBuilder builder = new StringBuilder(); تُصرِّح تلك التَعْليمَة عن المُتْغيِّر builder، وتُهيئه مبدئيًا، بحيث يُشير إلى كائن من الصَنْف StringBuilder. بالقسم الفرعي ٤.٨.١، ناقشنا دمج عمليتي التّصريح (declaration) والتهيئة المبدئية (initialization) ضِمْن تَعْليمَة واحدة فيما يَتعَلَّق بالأنواع الأساسية (primitive types)، ولكن الأمر هو نفسه بالنسبة للكائنات. تمامًا كأي كائن من الصَنْف String، تَتَكوَّن كائنات الصَنْف StringBuilder من مُتتالية من المحارف. ولكن بإمكانك إلحاق محارف جديدة بدون إنشاء نُسخ جديدة من نفس البيانات التي تَتَضمَّنها تلك الكائنات بالفعل. إذا كانت x عبارة عن قيمة من أيّ نوع، وكان builder هو المُتْغيِّر المُعرَّف بالأعلى، فإن الأمر builder.append(x)‎ سيُضيف تمثيل x النصي (string representation) إلى نهاية البيانات الموجودة بالمُتْغيِّر builder، وهو ما يُعدّ أكثر كفاءة عمومًا من الاستمرار بنَسْخ البيانات مع كل مرة نُلحِق خلالها شيئًا جديدًا. تستطيع إنشاء سِلسِلة نصية طويلة باِستخدَام كائن من الصَنْف StringBuilder، وعبر مُتتالية من أوامر append()‎، وعندما تَكتمِل السِلسِلة النصية، ستُعيد الدالة builder.toString()‎ نُسخة من السِلسِلة النصية كقيمة عادية من النوع String. يَتوفَّر الصَنْف StringBuilder ضِمْن الحزمة (package) القياسية java.lang، ولذلك يُمكِن اِستخدَام الاسم البسيط للصَنْف بدون استيراده (import). تَحتوِي حزمة java.util على عدد من الأصناف المفيدة، فمثلًا، تَتَوفَّر أصناف للتَعامُل مع تجميعات (collections) من الكائنات، والتي سنتناولها تفصيليًا بالفصل العاشر. تَعرَّضنا للصَنْف java.util.Scanner المُعرَّف ضِمْن نفس الحزمة بالقسم الفرعي ٢.٤.٦. يَتوفَّر أيضًا الصَنْف java.util.Date، والذي يُستخدَم لأغراض تمثيل الوقت، فمثلًا، عندما تُنشِئ كائنًا (object) من النوع Date بدون مُعامِلات (parameters)، تُمثِل النتيجة كُلًا من التاريخ والوقت الحالي. يُمكِن عَرْض تلك المعلومة كالتالي: System.out.println( new Date() ); لمّا كان الصَنْف Date مُعرَّفًا بحزمة java.util، كان لابُدّ من إِتاحته أولًا بالبرنامج عن طريق استيراده، وذلك بكتابة أي من التَعْليمَتين import java.util.Date;‎ أو import java.util.*;‎ ببداية البرنامج، وبَعْدها ستَتَمكَّن من اِستخدَام الصَنْف. (ناقشنا الحزم والاستيراد بالقسم الفرعي ٤.٦.٣). لنَفْحَص أيضًا الصَنْف java.util.Random. تُعدّ كائنات ذلك الصَنْف مصدرًا للأعداد العشوائية، فيُمكِن لكائن من النوع Random أن يُنتج أعدادًا عشوائية سواء كانت صحيحة (integers) أو حقيقية (real). وفي الحقيقة، تَستخدِم الدالة القياسية Math.random()‎ كائنًا من ذلك الصَنْف وراء الكواليس؛ لإنتاج أعدادها العشوائية. اُنظر الشيفرة التالية لإنشاء كائن من الصَنْف Random: Random randGen = new Random(); بفَرْض أن N هو عدد صحيح موجب، سيُنتج randGen.nextInt(N)‎ عددًا صحيحًا عشوائيًا ضِمْن نطاق يتراوح من صفر وحتى N-1. يُمكِننا استخدام ذلك بتجربة رمِي حجري النَّرد لتَسهيل المُهِمّة؛ فبدلًا من كتابة die1 = (int)(6*Math.random())+1;‎، يُمكِننا كتابة die1 = randGen.nextInt(6)+1;‎. قد لا تتفق على أن تلك الطريقة أسهل نوعًا ما خاصة مع اضطرارنا لاستيراد (import) الصَنْف java.util.Random، وإنشاء كائن منه. يُمكِننا أيضًا اِستخدَام كائن من النوع Random لإنتاج ما يُعرَف باسم "التوزيع الاحتمالي الغاوسي (gaussian distribution)". تُستخدَم الكثير من أصناف جافا القياسية ببرمجة واجهات المُستخدِم الرسومية (GUI)، وسنَمُرّ عبر الكثير منها بالفصل السادس، ولكن سنَمُرّ هنا سريعًا على الصَنْف Color من حِزمة javafx.scene.paint حتى نَستخدِمه بالمثال التالي. يُمثِل أي كائن من الصَنْف Color لونًا يُستخدَم أثناء الرسم، ولقد تَعرَّضنا بالفعل لعدة ألوان ثابتة (constants) مثل Color.RED بالقسم ٣.٩. في الواقع، تلك الثوابت ما هي إلا مُتْغيِّرات أعضاء ساكنة (static) ونهائية (final) مُعرَّفة بالصَنْف Color، وقيمها عبارة عن كائنات من النوع Color. بالإضافة إلى تلك الألوان المُعرَّفة مُسْبَقًا، يُوفِّر الصَنْف Color مجموعة من البَوانِي (constructors) تَسمَح لك بإنشاء كائنات جديدة من الصَنْف لتَمثيل أيّ لون آخر. يَستقبِل إحداها ٣ مُعامِلات (parameters) من النوع double ويُمكِنك استدعائه باِستخدَام new Color(r,g,b)‎. تُمثِل تلك المُعامِلات كُلًا من اللون الأحمر والأخضر والأزرق بنظام الألوان RGB، ويَنبغي أن تَقع قيمها ضِمْن نطاق يتراوح من ٠ وحتى ١. تَعنِي القيمة ٠ للمُعامِل r أن اللون الفعليّ لا يَتَضمَّن اللون الأحمر نهائيًا، بينما تَعنِي القيمة ١ أنه يَتَضمَّن أكبر قدر مُمكن من اللون الأحمر. يَتوفَّر باني آخر يُستدعَى على الصورة new Color(r,g,b,t)‎، والذي يَستقبِل مُعامِلًا إضافيًا من النوع double، ويَنبغي أن تَقع قيمته ضِمْن نطاق يتراوح من ٠ وحتى ١. يُحدِّد ذلك المعامل درجة شفافية اللون (transparency)، بحيث تُمثِل القيم الأكبر من المُعامِل t لونًا أقل شفافية، فمثلًا، عندما تَرسم بلون شفاف جزئيًا، تَظهَر الخلفية عبر اللون إلى حد معين. .تَتَضمَّن الكائنات من الصَنْف Color عددًا قليلًا من توابع النسخ (instance methods). على سبيل المثال، تَتَوفَّر دوال (functions) مثل getRed()‎ لجَلْب قيمة اللون الأحمر بنظام RGB، وبالمثل للون الأخضر والأزرق. مع ذلك، لا يُوفِّر الصَنْف أي توابع ضَبْط (setter methods) لتَعْديل قيم تلك الألوان، حيث تُعدّ الكائنات من الصَنْف Color كائنات ثابتة أو غَيْر قابلة للتعديل (immutable)، بمعنى أن جميع مُتْغيِّرات النُسخ (instance variables) المُعرَّفة بداخلها هي نهائية -مُعرَّفة باِستخدَام المُبدِّل final-، وبالتالي لا يُمكِن تَعْديلها بَعْد إنشاء الكائن. لاحِظ أن السَلاسِل النصية من النوع String هي مثال آخر على الكائنات غَيْر القابلة للتعديل (immutable). النقطة الرئيسية مما سبق هو التأكيد على أن أصناف جافا القياسية تُوفِّر حلولًا للكثير من المشاكل التي قد تواجهها، لذا إذا تَعرَّضت لمُهِمّة (task) شائعة نوعًا ما، فلرُبما من الأفضل أن تَبحَث قليلًا بمَرجِع الجافا، لتَرى ما إذا كان هناك صَنْف يؤدي الغرض الذي تحتاج إليه. الصنف Object تُعدّ القدرة على إنشاء أصناف فرعية (subclasses) مُشتقَّة من صَنْف واحدة من أهم سمات البرمجة كائنية التوجه (object-oriented programming). يَرِث (inherit) الصَنْف الفرعي جميع خاصيات (properties) الصَنْف الأصلي وسلوكياته (behaviors)، ولكن بإِمكانه تَعْديلها وكذلك الإضافة إليها. ستَتَعلَّم طريقة إنشاء الأصناف الفرعية (subclasses) في القسم ٥.٥. في الواقع، أيّ صَنْف بلغة الجافا -باستثناء صَنْف وحيد- هو بالنهاية صَنْف فرعي من صَنْف آخر، فحتى لو أنشأت صَنْفًا، ولم تُصرِّح عن كَوْنه صَنْفًا فرعيًا من صَنْف آخر، فإنه تلقائيًا يُصبِح صنفًا فرعيًا من صَنْف خاص اسمه Object مُعرَّف بحزمة java.lang، وهو الصَنْف الاستثنائي الوحيد الذي لا يُعدّ صَنْفًا فرعيًا من أي صَنْف آخر. يُعرِّف الصنف Object مجموعة من توابع النُسخ (instance methods)، والتي تَرثها (inherit) جميع الأصناف الآخرى، لذا يُمكِن لأيّ كائن (object) مهما كان أن يَستخدِم تلك التوابع. سنَذكُر واحدة منها فقط بهذا القسم، وسنَتَعرَّض لمجموعة آخرى منها لاحقًا. يُعيد تابع النسخة toString()‎ المُعرَّف بالصنف Object قيمة من النوع String، والتي يُفْترَض أن تَكُون بمثابة تمثيلًا نصيًا (string representation) للكائن. في أي مرة نَطبَع فيها كائنًا أو نَضُمّه (concatenate) إلى سِلسِلة نصية، أو بصورة أعم نَستخدِمه بسياق يَتطلَّب سِلسِلة نصية، يُستدعَى هذا التابع ضمنيًا ليُحوِّل ذلك الكائن تلقائيًا إلى النوع String. تُعيد نسخة toString المُعرَّفة بالصنف Object اسم الصنف الذي ينتمي إليه الكائن مع ترميز التجزئة (hash code) الخاص به، وهو ما قد لا يَكُون مفيدًا. لذا عندما تُنشِئ صَنْفًا، تستطيع إعادة تعريف التابع toString()‎ بحيث تَحلّ النسخة الجديدة مَحلّ النسخة الموروثة، فمثلًا، يُمكِننا إضافة التابع (method) التالي لأيّ من أصناف PairOfDice المُعرَّفة بالقسم السابق: /** * يعيد تمثيلًا نصيًا لحجري نرد */ public String toString() { if (die1 == die2) return "double " + die1; else return die1 + " and " + die2; } إذا كان dice مُتْغيِّرًا يُشير إلى كائن من الصَنْف PairOfDice، فسيُعيد dice.toString()‎ سَلاسِل نصية مثل "‎3 and 6" و "‎5 and 1" و "double 2‎" بِحَسْب الأعداد الظاهرة على حجري النَّرد. يُستدَعى هذا التابع تلقائيًا لتَحْوِيل المُتْغيِّر dice إلى النوع String بالتَعْليمَة التالية: System.out.println( "The dice came up " + dice ); قد يَكُون خَرْج التعليمة -بالأعلى- "The dice came up 5 and 1" أو "The dice came up double 2". سنَتَعرَّض لمثال آخر للتابع toString()‎ بالقسم التالي. كتابة صنف واستخدامه سنَكْتُب الآن برنامج تَحرِيكة (animation)، بالاعتماد على نفس المنصة المُستخدَمة بالقسم الفرعي ٣.٩.٣، سيَكُون بمثابة مثالًا على تصميم صَنْف (class) جديد واِستخدَامه. ستُظهِر التَحرِيكة عددًا من الأقراص شبه الشفافة، والمُلوَّنة عشوائيًا، والمُتموضِعة بأماكن عشوائية عَبْر النافذة. عند تشغيل التحريكة، سيَزدَاد حجم تلك الأقراص، وعندما يَصِل حجم أي منها إلى حد معين، فإنه سيَختفِي ليَحلّ مَحلّه قرص آخر جديد بمكان عشوائي. قد يَحدُث ذلك -أيّ الاختفاء والظهور- بصورة عشوائية أيضًا بعيدًا عن حجم القرص. تَستعرِض الصورة التالية لقطة للشاشة أثناء تَشْغِيل البرنامج: سيَكُون كل قرص ضِمْن التَحرِيكة عبارة عن كائن (object)، ولأن أيّ قرص يَملُك عدة خاصيات (properties)، مثل اللون والموقع والحجم، فسنَستخدِم مُتْغيِّرات نُسخ (instance variables) لتمثيل كُلًا منها ضِمْن الكائن. أما بالنسبة لتوابع النُسخ (instance methods)، فيَنبغِي لنا التفكير أولًا بالكيفية التي سنَستخدِم بها القرص عَبْر البرنامج. سنَحتاج عمومًا إلى رسم القرص، لذا سنُضيف تابع النسخة draw(g)‎، حيث g هو كائن السِّياق الرُسومي (graphics context) المُستخدَم للرسم. يُمكِن للصَنْف أيضًا أن يَتَضمَّن بَانِي كائن (constructors) واحد أو أكثر لتهيئة الكائنات مبدئيًا. لا تَكُون البيانات المُفْترَض تمريرها للباني كمُعامِلات (parameters) واضحة دومًا. في هذا المثال، سنكتفي بتمرير كُلًا من موقع الدائرة وحجمها كمُعامِلات، أما لونها فسيَصنَعه الباني باِستخدَام قيم عشوائية للألوان الثلاثة بنظام RGB. اُنظر تعريف الصَنْف كاملًا: import javafx.scene.paint.Color; import javafx.scene.canvas.GraphicsContext; public class CircleInfo { public int radius; // نصف قطر الدائرة public int x,y; // موقع مركز الدائرة public Color color; // لون الدائرة /** * Create a CircleInfo with a given location and radius and with a * randomly selected, semi-transparent color. * @param centerX The x coordinate of the center. * @param centerY The y coordinate of the center. * @param rad The radius of the circle. */ public CircleInfo( int centerX, int centerY, int rad ) { x = centerX; y = centerY; radius = rad; double red = Math.random(); double green = Math.random(); double blue = Math.random(); color = new Color( red,green,blue, 0.4 ); } /** * Draw the disk in graphics context g, with a black outline. */ public void draw( GraphicsContext g ) { g.setFill( color ); g.fillOval( x - radius, y - radius, 2*radius, 2*radius ); g.setStroke( Color.BLACK ); g.strokeOval( x - radius, y - radius, 2*radius, 2*radius ); } } لاحِظ أننا قد صَرَّحنا عن مُتْغيِّرات النُسخ (instance variables) على أساس كَوْنها عامة (public)؛ لتبسيط الأمور، لكن يُفضَّل عمومًا كتابة ضوابط (setters) وجوالب (setters) لكُلًا منها. سنُعرِّف البرنامج main داخل الصنف GrowingCircleAnimation. ولأن البرنامج سيَستخدِم ١٠٠ قرص، كُلًا منها عبارة عن كائن من الصنف CircleInfo، فإنه سيَحتاج إلى مصفوفة من الكائنات لتَخْزِينها. لذا يُعرِّف البرنامج مُتْغيِّر مصفوفة (array variable) كمُتْغيِّر نُسخة (instance variable) ضِمْن الصنف، كالتالي: private CircleInfo[] circleData; // يحمل بيانات 100 قرص لاحِظ أن المُتْغيِّر circleData ليس ساكنًا (static). تَعتمِد برمجة واجهات المُستخدِم الرسومية (GUI) في العموم على الكائنات (objects) بدلًا من المُتْغيِّرات والتوابع الساكنة. يُمكِننا عمومًا تَخيُّل وجود عدة كائنات من الصنف GrowingCircleAnimation تَعمَل بصورة مُتزامنة. لذا ينبغي لكُلًا منها أن يمتلك مصفوفته الخاصة من الأقراص. بصيغة آخرى، كل تحريكة (animation) عبارة عن كائن، وكل كائن يَمتلك نسخته الخاصة من مُتْغيِّر النسخة circleData. إذا كان circleData ساكنًا، فسيَكُون هناك مصفوفة واحدة فقط، وستبدو جميع التَحرِيكات مُتطابقة تمامًا. الآن، لابُدّ أن نُنشِئ المصفوفة ونَملؤها بالبيانات. في البرنامج التالي، قُمنا بذلك حتى قَبْل رسم أول إطار (frame) ضِمْن التَحرِيكة. أولًا، اِستخدَمنا التعبير new CircleInfo[100]‎ لإنشاء المصفوفة، ثُمَّ أنشأنا مائة كائن من النوع CircleInfo لمَلئ المصفوفة. لاحِظ أن الكائنات الجديدة تَكُون عشوائية فيما يَتعلَّق بحجمها ومَوضِعها. بفَرْض أن width و height هي أبعاد مساحة الرسم (drawing area)، اُنظر الشيفرة التالية: circleData = new CircleInfo[100]; // أنشئ المصفوفة for (int i = 0; i < circleData.length; i++) { // أنشئ الكائنات circleData[i] = new CircleInfo( (int)(width*Math.random()), (int)(height*Math.random()), (int)(100*Math.random()) ); } يَزداد نصف قطر القرص بكل إطار (frame)، ثم يُعاد رسمه كالتالي: circleData[i].radius++; circleData[i].draw(g); قد تبدو التَعْليمَات -بالأعلى- مُعقدة نوعًا ما، لذا دَعْنَا نَفْحَصها عن قرب. أولًا، يُمثِل circleData‎ أحد عناصر المصفوفة circleData، أيّ أنه مُتْغيِّر من النوع CircleInfo. يُشير ذلك المُتْغيِّر إلى كائن من النوع CircleInfo، والذي لابُدّ أن يَحتوِي على مُتْغيِّر النُسخة (instance variable) العام radius، ويَكُون اسمه الكامل هو circleData.radius. لمّا كان مُتْغيِّر النسخة ذاك من النوع int، نستطيع تطبيق عامل الزيادة ++ عليه لزيادة قيمته بمقدار الواحد، أيّ أن تأثير التَعْليمَة circleData.radius++‎ هو زيادة نصف قطر الدائرة بمقدار الواحد. يُعدّ السطر الثاني من الشيفرة مشابهًا للأول، باستثناء أن circleData.draw يُمثِل تابع نُسخة (instance method) بالكائن. تَستدعِي التَعْليمَة circleData.draw(g)‎ تابع النُسخة ذاك، وتُمرِّر له المُعامِل g، والذي يُمثِل كائن السِّياق الرسومي المُستخدَم للرسم. يُمكِنك الإطلاع على الشيفرة المصدرية للبرنامج بالملف GrowingCircleAnimation.java إذا كنت مهتمًا. ولأن البرنامج يَستخدِم الصَنْف CircleInfo، ستحتاج أيضًا إلى نسخة الملف CircleInfo.java لتَصْرِيف البرنامج وتَشْغِيله. التحليل والتصميم كائني التوجه يَبنِي كل مبرمج عادةً مَخزونًا من التقنيات والخبرات، تَتَمثَل بهيئة قطع من الشيفرة مَكْتُوبة ومُجربَة، بحيث يَتمكَّن من إعادة اِستخدَامها ضِمْن أي برامج جديدة. تُنسَخ الشيفرة القديمة ببساطة إلى البرنامج الجديد، ثم تُعدَّل بما يَتلائَم مع البرنامج الجديد. يَعتمِد عندها كامل المشروع على قدرة المبرمج على سَحْب جزء الشيفرة ذاك، الذي كان قد كَتبَه ضِمْن مشروع سابق، والذي بدا أنه قابل للتَخْصِيص بحيث يَتَناسب مع المشروع الجديد. ولكن في الواقع، تُعانِي تلك الطريقة من كَوْن عملية التَعْدِيل تلك عُرضة للخطأ، كما أنها مُستهلِكة للوقت. تُحبِّذ أيضًا الشركات الكبيرة توفير الموارد بتَجنُّب إعادة اختراع العجلة مع كل مشروع جديد، ولكن تُصبِح مُهِمّة تَعقُّب كل تلك العجلات القديمة أكثر صعوبة مع الحجم الهائل من المشروعات بتلك الشركات. من الجهة الآخرى، تُعدّ الأصناف قطعًا برمجية قابلة لإعادة الاِستخدَام بدون الحاجة لإجراء أي تَعْديلات عليها بشَّرْط أن تَكُون قد صُمّمت تصميمًا جيدًا. مثلًا، لا تُعدّ الأصناف المصنوعة خصيصًا لإنجار مُهِمّة مُحدَّدة جدًا ضِمْن برنامج مُحدَّد مُصمّمة تصميمًا جيدًا، وإنما لابُدّ أن يَكُون الصنف مصنوعًا بحيث يُمثِل نوعًا واحدًا محددًا من الأشياء أو مفهومًا واحدًا مترابطًا. لمّا كانت تلك المفاهيم والأشياء عامة كفاية لأن تَتكرَّر ضِمْن العديد من المشاكل، تزداد إمكانية الحاجة لاِستخدَام تلك الأصناف ضِمْن عدة مشروعات وبدون إجراء أي تَعْديلات. ولأننا نَتعامَل مع لغة كائنية التوجه (object-oriented)، يُمكِننا أيضًا إنشاء أصناف فرعية (subclasses) من صَنْف موجود، وهو ما يُزيد من قابلية الأصناف لإعادة الاستخدَام. فمثلًا، إذا احتاج صَنْف معين لمزيد من التَخْصيص، يُمكِننا ببساطة إنشاء صَنْف فرعي (subclass) منه، وإجراء أي إضافات أو تَعْديلات على الصَنْف الفرعي بدون تَعْديل الصَنْف الأصلي. نستطيع القيام بذلك حتى لو لم يَكُن لدينا صلاحية وصول لشيفرة الصَنْف، ولا نعلم أي شيء عن التفاصيل التَّنْفيذية (implementation) الداخلية الخاصة به. في الواقع، يُعدّ الصنف PairOfDice -من القسم السابق- مثالًا على قطعة برمجية مُعمَّمة، حيث يُمثِل الصنف مفهومًا واحدًا متماسكًا هو "حجري نَّرد". تَحمِل مُتْغيِّرات النُسخ (instance variables) بيانات مُتعلِّقة بحالة حجري النَّرد أي العدد الظاهر بكل حجر، كما يُمثِل تابع النُسخة (instance method) سلوك حجري النَّرد أي القدرة على رَميهما. على الرغم من إمكانية تحسِّين ذلك الصَنْف، فإنه قابلًا لإعادة الاستخدام بالكثير من المشروعات البرمجية المختلفة. في المقابل، لا يُعدّ الصنف Student -من القسم السابق- قابلًا لإعادة الاستخدام؛ حيث يُبدو وكأنه قد صُمّم خِصيصًا لتمثيل مجموعة طلبة ضِمْن دورة تدريبية من نوع خاص، تَعتمِد درجاتها على ثلاثة اختبارات فقط، فإذا كان هناك حاجة لمزيد من الاختبارات أو الأوراق، فسيُصبِح الصنف عديم الفائدة. علاوة على ذلك، ستَحدُث مشكلة في حالة وجود شخصين لهما نفس الاسم، لذا عادةً ما يُستخدَم رقم هوية عددي بدلًا من الاسم. ولكن للإنصاف، فإن إنشاء صَنْف مُتعدد الأغراض لتمثيل الطلبة هو أمر أصعب كثيرًا من مُجرّد إنشاء صَنْف مُتعدد الأغراض لتمثيل حجري نَّرد. تَتَكوَّن عملية تطوير أيّ مشروع برمجي ضخم من مجموعة من المراحل، بدايةً من مرحلة توصيف (specification) المشكلة المطلوب حلّها، ثُمَّ تحليلها (analysis)، وتصميم (design) البرنامج اللازم لحلّها، ثُمَّ تأتي مرحلة كتابة الشيفرة (coding)، والتي يَتحوِّل خلالها التصميم إلى لغة برمجية فعليّة، وبعد ذلك تأتي مرحلة الاختبار (testing)، وتَنْقيح الأخطاء (debugging). يَتبَع ذلك فترة طويلة من الصيانة (maintenance)، والتي تَتَضمَّن إصلاح أي مشاكل جديدة عُثر عليها بالبرنامج، وكذلك تَعْديله بحيث يَتكيَّف مع أي تَغْيير بمُتطلبات البرنامج. تُسمَى مُتتالية المراحل تلك باسم "دورة حياة تطوير البرمجيات (software life cycle)". نادرًا ما تَتتابَع تلك المراحل على نحو مُتتالي تمامًا، فمثلًا، قد يَتَّضِح أن التوصيف مُتعارض أو غَيْر مُكتمل أثناء مرحلة التحليل، أو قد يَتطلَّب العُثور على مشكلة أثناء مرحلة الاختبار (testing) عودة سريعة إلى مرحلة كتابة الشيفرة (coding) على الأقل، أو حتى تصميمًا جديدًا إذا كانت المشكلة كبيرة بما فيه الكفاية. وأخيرًا، عادةً ما تَتَضمَّن مرحلة الصيانة (maintenance) إعادة بعض الأعمال من المراحل السابقة. نجاح أيّ مشروع برمجي ضخم عادةً ما يَكُون مَشْرُوطًا بتبَنّي أسلوب منهجي دقيق خلال جميع مراحل التطوير. يُعرَف ذلك الأسلوب المنهجي، والذي يَستخدِم مبادئ التصميم الجيد، باسم "هندسة البرمجيات (software engineering)". يُحاوِل مهندسي البرمجيات عمومًا بناء برامج مستوفية لتوصيفاتها (specifications)، وبحيث تَكُون مكتوبة بطريقة تُسهِل من تَعْدِيلها إن اقْتَضَت الضرورة. هنالك الكثير من الأساليب التي يُمكِن تطبيقها لتصميم البرامج بطريقة منهجية، وتَشتمِل غالبيتها على رسم صناديق صغيرة تُمثِل مُكوِّنات البرنامج مع أسهم مُعنوَنة لتمثيل العلاقات بين تلك الصناديق. لقد ناقشنا كائنية التوجه (object orientation) فيما يَتعلَّق بمرحلة كتابة الشيفرة (coding)، لكن تَتوفَّر أيضًا أساليب كائنية التوجه لمرحلتي التحليل والتصميم. يَكُون السؤال بهذه المرحلة من مراحل تطوير البرمجيات: كيف نَتَمكَّن من اكتشاف أو اختراع البنية الكلية للبرنامج؟ اتبع النصيحة التالية، والتي تُعدّ بمثابة أسلوبًا بسيطًا كائني التوجه لمرحلتي التحليل والتصميم: سَجِّل توصيف المشكلة، ثُمَّ ارسم خطًا أسفل جميع الأسماء الموجودة بذلك التوصيف. ينبغي أن تَكُون تلك الأسماء مُرشَّحة كأصناف (classes) أو ككائنات (objects) ضِمْن تصميم البرنامج. بالمثل، ارسم خطًا أسفل جميع الأفعال (verbs) الموجودة بالتوصيف. ينبغي أن تَكُون تلك الأفعال مُرشَّحة كتوابع (methods). هذه هي نقطة البداية فقط، فقد يَكشِف مزيد من التحليل (analysis) عن الحاجة لإضافة أصناف أو توابع آخرى، كما قد يَكشِف عن إمكانية اِستخدَام أصناف فرعية (subclasses) تَتشارَك الخاصيات والسلوكيات المُتشابهة بينها. "حلّل المشكلة لاكتشاف المفاهيم المُتضمَّنة، ثم عرِّف أصنافًا لتمثيل تلك المفاهيم. ينبغي أن يُحاكِي التصميم المشكلة، أو بتعبير آخر، ينبغي أن تَعكِس بنية البرنامج بنية المشكلة نفسها بصورة طبيعية." قد يَكُون ذلك تبسيطًا مُخِلًّا، ولكنه واضح وفعال عمومًا. ترجمة -بتصرّف- للقسم Section 3: Programming with Objects من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

تختلف الأنواع الكائنية (object types) بلغة الجافا عن الأنواع البسيطة (primitive type)، فمثلًا، لا تُنشِئ تَعْليمَة التّصْريح (declare) عن مُتْغيِّر، نوعه عبارة عن صَنْف (class)، كائنًا (object) من ذلك الصنف، بل ينبغي أن تقوم بذلك صراحةً. وفقًا للحاسوب، تَتَكوَّن عملية إنشاء كائن من محاولة العثور على مساحة غَيْر مُستخدَمة بقسم الكومة (heap) من الذاكرة وبحيث تَكُون كبيرة بما فيه الكفاية لحَمْل الكائن المطلوب إنشائه، ومن ثَمَّ مَلْئ مُتْغيِّرات نُسخ (instance variables) ذلك الكائن. كمبرمج، أنت لا تهتم عادةً بالمكان الذي يُخزَّن فيه الكائن بالذاكرة، ولكن ستَرغَب غالبًا بالتَحكُّم بالقيم المبدئية المُخزَّنة بمُتْغيِّرات نُسخ ذلك الكائن، كما قد تحتاج في بعض الأحيان إلى إجراء تهيئة (initialization) أكثر تعقيدًا مع كل كائن جديد يُنشَئ. تهيئة متغيرات النسخ (initialization) تستطيع عمومًا إِسْناد قيمة مبدئية إلى أيّ مُتْغيِّر نسخة (instance variable) أثناء التَّصْريح (declaration) عنه، وذلك كأيّ مُتْغيِّر عادي آخر. على سبيل المثال، لنَفْترِض مثلًا أن لدينا الصَنْف PairOfDice المُعرَّف بالأسفل. سيُمثِل أيّ كائن من هذا الصَنْف حجري نَّرد، وسيَحتوِي على مُتْغيِّري نسخة لتمثيل الأعداد الظاهرة على حجري النَّرد، بالإضافة إلى تابع نُسخة (instance method) مسئول عن مُهِمّة رمِي حجرى النَّرد. public class PairOfDice { public int die1 = 3; // العدد الظاهر على الحجر الأول public int die2 = 4; // العدد الظاهر على الحجر الثاني public void roll() { // حاكي تجربة رمي حجري النرد die1 = (int)(Math.random()*6) + 1; die2 = (int)(Math.random()*6) + 1; } } // ‫نهاية الصنف PairOfDice وفقًا لتعريف الصَنْف بالأعلى، سيُهيَئ (initialize) مُتْغيِّري النُسخة die1 و die2 إلى القيم ٣ و ٤ على الترتيب أينما بَنينا كائنًا من الصنف PairOfDice. ينبغي أن تفهم كيفية حُدوث ذلك: لمّا كان من المُمكن إِنشاء عدة كائنات من الصَنْف PairOfDice، فإنه، وبكل مرة يُنشَئ فيها واحد منها، فإن الكائن المُنشَىء سيَحصُل على مُتْغيِّري نُسخة (instance variables) خاصين به، ثم ستُنفَّذ تَعْليمتَي الإِسْناد die1 = 3 و die2 = 4 لمَلئ قيم مُتْغيِّراته. اُنظر النسخة التالية من الصَنْف PairOfDice لمزيد من الإيضاح: public class PairOfDice { public int die1 = (int)(Math.random()*6) + 1; public int die2 = (int)(Math.random()*6) + 1; public void roll() { die1 = (int)(Math.random()*6) + 1; die2 = (int)(Math.random()*6) + 1; } } // ‫نهاية الصنف PairOfDice وفقًا للتعريف بالأعلى، فإنه، وبكل مرة يُنشَئ فيها كائن (object) من الصَنْف PairOfDice، ستُهيَئ مُتْغيِّرات النُسخ إلى قيم عشوائية كما لو كنا نَرمِي حجري نَّرد على طاولة اللعب. لمّا كانت تلك التهيئة (initialization) تُنفَّذ لكل كائن على حدى، فستُحسَب تلك القيم لكل حجري نَّرد، وسيَحصُل كل حجري نَّرد مختلفين على قيم مبدئية مختلفة. سيَكُون الوضع مختلفًا بالتأكيد في حالة تهيئة المُتْغيِّرات الأعضاء الساكنة (static member variables)؛ وذلك لوجود نُسخة وحيدة فقط من أيّ مُتْغيِّر ساكن (static)، والتي تُهيَئ (initialization) مرة واحدة فقط عند تحميل الصَنْف (class) لأول مرة. تُهيَئ مُتْغيِّرات النُسخ (instance variable) بقيم مبدئية افتراضية تلقائيًا إذا لَمْ يُوفِّر لها المبرمج قيمة مبدئية. فمثلًا، تُهيَئ مُتْغيِّرات النسخ من الأنواع العددية مثل int و double تلقائيًا إلى الصفر إذا لم يُوفِّر لها المبرمج قيم آخرى، أما المُتْغيِّرات من النوع boolean فتُهيئ إلى القيمة false، بينما المُتْغيِّرات من النوع char تُهيَئ للمحرف المقابل لقيمة ترميز اليونيكود (Unicode code) رقم صفر ‎\u0000. وأخيرًا، بالنسبة لمُتْغيِّرات النُسخ كائنية النوع (object type)، فإن قيمها المبدئية الافتراضية هي القيمة الفارغة null. على سبيل المثال، لمّا كانت السَلاسِل النصية من النوع String عبارة عن كائنات (objects)، فإن القيمة المبدئية الافتراضية للمُتْغيِّرات من النوع String تُساوِي null. بواني الكائنات (constructors) يُستخدَم العَامِل new لإنشاء الكائنات (objects)، فمثلًا، يُمكِننا كتابة الشيفرة التالية لإنشاء كائن من الصَنْف PairOfDice: PairOfDice dice; // ‫صرح عن متغير من النوع PairOfDice // أنشئ كائنا جديدا من الصنف واسنده مرجعه الى المتغير dice = new PairOfDice(); يُخصِّص التعبير new PairOfDice()‎ مساحة بالذاكرة للكائن، ويُهيِئ مُتْغيِّرات النسخ (instance variables) الخاصة به، وأخيرًا، يُعيد مَرجِعًا (reference) إليه كقيمة للتعبير، والتي تُخزِّنها تَعْليمَة الإِسْناد (assignment statement) بالمُتْغيِّر dice، أي سيُشير dice إلى الكائن الجديد المُنشَئ للتو بعد تَّنْفيذ تَعْليمَة الإِسْناد. يبدو الجزء PairOfDice()‎ وكأنه عملية استدعاء لبرنامج فرعي (subroutine call). ليس هذا في الواقع مجرد مصادفة؛ فهو بالفعل يُمثِل عملية استدعاء، ولكن لنوع خاص من البرامج الفرعية تُعرَف باسم "البَانِي أو بَانِي الكائن (constructor)". قد يُربكك ذلك خاصة وأن تعريف الصَنْف PairOfDice لا يَحتوِي على أي برنامج فرعي بنفس تلك البصمة. في الحقيقة، لابُدّ لأيّ صَنْف من أن يَحتوِي على بَانِي كائن (constructor) واحد على الأقل، لذا يُوفِّر النظام بَانِي كائن افتراضي (default constructor) لأي صَنْف لم يُعرِّف له المبرمج بَانِي كائن (constructor). يَقْتصِر دور البواني الافتراضية على تَخْصِيص مساحة بالذاكرة للكائن، وتهيئة مُتْغيِّرات النُسخ (instance variables)، أما إذا أردت تَّنْفيذ أشياء آخرى عند إنشاء كائن من صَنْف معين، فستحتاج إلى تعريف باني كائن (constructor) واحد أو ربما أكثر ضِمْن تعريف ذلك الصَنْف. تُشبه تعريفات البَوانِي (constructors) في العموم تعريف أيّ برنامج فرعي (subroutine) آخر مع ثلاثة استثناءات. أولًا، لا يُمكِن تَخْصيص النوع المُعاد (return type) من البَانِي بما في ذلك المُبدِّل void. ثانيًا، ينبغي أن يَكُون اسم الباني هو نفسه اسم الصَنْف المُعرَّف بداخله. أخيرًا، تَقْتصِر المُبدِّلات (modifiers) التي يُمكِن اِستخدَامها بتعريف أيّ باني على مُبدِّلات الوصول (access modifiers)، أي public و private و protected، ولا يُمكِن اِستخدَام المُبدِّل static بالتحديد أثناء التَّصْريح عنها. في المقابل، يُمكِنك كتابة مَتْن البَانِي ككُتلَة من التَعْليمَات (statements) كأيّ مَتْن برنامج فرعي (subroutine body) تقليدي آخر؛ فلا يوجد أي قيود على التَعْليمَات التي يُمكِن اِستخدَامها ضِمْن المَتْن، كما يُمكِن للبَانِي أن يَستقبِل قائمة من المُعامِلات الصُّوريّة (formal parameters)، بل إن قدرته على اِستقبَال تلك المُعامِلات هي السبب الرئيسي من اِستخدَامه أساسًا، حيث تُوفِّر تلك المُعامِلات البيانات الضرورية لإِنشاء الكائن (object)، فمثلًا، يُمكِن لأحد بواني الصَنْف PairOfDice أن يُوفِّر قيم الأعداد المبدئية لحجري النَّرد. تَعرَض الشيفرة التالية تعريف الصَنْف في تلك الحالة: public class PairOfDice { public int die1; // العدد الظاهر بالحجر الأول public int die2; // العدد الظاهر بالحجر الثاني public PairOfDice(int val1, int val2) { // يُنشئ الباني حجري نرد ويُهيئهما مبدئيًا بالقيم الممررة die1 = val1; die2 = val2; } public void roll() { // حاكي تجربة الرمي die1 = (int)(Math.random()*6) + 1; die2 = (int)(Math.random()*6) + 1; } } // ‫نهاية الصنف PairOfDice صَرَّحت الشيفرة بالأعلى عن بَانِي كائن (constructor) على الصورة public PairOfDice(int val1, int val2) ...‎. ستُلاحِظ أننا لَمْ نُخصِّص النُوع المُعاد (return type) من البَانِي، كما أننا أعطيناه نفس اسم الصَنْف، وهذه هي الكيفية التي تُمكِّن مُصرِّف الجافا (Java compiler) من تَمييز بَوانِي الكائن. نُلاحِظ أيضًا أن البَانِي يَستقبِل مُعامِلين (parameters)، ينبغي لقيمهما أن تُمرَّر عند استدعاء البَانِي. على سبيل المثال، سيُنشِئ التعبير new PairOfDice(3,4)‎ كائنًا (object) من الصَنْف PairOfDice، ويُهيِئ مُتْغيِّرات نُسخه die1 و die2 مبدئيًا إلى القيم ٣ و ٤ على الترتيب. أخيرًا، ينبغي أن تُستخدَم القيمة المُعادة (return value) من البَانِي بطريقة ما، كالتالي: // ‫صرح عن متغير من الصنف PairOfDice PairOfDice dice; // ‫سيشير dice إلى كائن جديد من الصنف PairOfDice مُهيَأ مبدئيًا بالقيم 1 و 1 dice = new PairOfDice(1,1); الآن، وبعد أن أَضفنا بَانِي كائن إلى الصَنْف PairOfDice، لَمْ يَعُدْ بمقدورنا اِستخدَام التعبير new PairOfDice()‎ لإنشاء كائن؛ حيث تَحتوِي النسخة الجديدة من الصَنْف PairOfDice -بالأعلى- على بَانِي وحيد، والذي يَتَطلَّب مُعامِلين فعليين (actual parameter)، بينما نحن نحاول استدعاء بَانِي بدون أيّ مُعامِلات، ولأن النظام لا يُوفِّر البَانِي الافتراضي (default constructor) سوى للأصناف التي لا يَتَضمَّن تعريفها (class definition) أي بَانِي على الإطلاق، فسنحتاج إلى إضافة بَانِي آخر لا يَستقبِل أي مُعامِلات للصنف، وهو في الواقع أمر بسيط. تستطيع عمومًا إضافة أيّ عدد من البَوانِي (constructors) طالما كانت بَصْمتهم (signatures) مختلفة، أيّ طالما كان لديهم أعداد مختلفة أو أنواع مختلفة من المُعامِلات الصُّوريّة (formal parameters). بالشيفرة التالية، أَضفنا بَانِي بدون أي مُعامِلات إلى الصَنْف PairOfDice سيُهيِئ حجري النَّرد بقيم مبدئية عشوائية، كالتالي: public class PairOfDice { public int die1; // العدد الظاهر بالحجر الأول public int die2; // العدد الظاهر بالحجر الثاني public PairOfDice() { // يرمي الباني حجري النرد ليحصل على قيم عشوائية مبدئية roll(); } public PairOfDice(int val1, int val2) { // يُنشئ الباني حجري نرد ويُهيئهما مبدئيًا بالقيم الممررة die1 = val1; die2 = val2; } public void roll() { // حاكي تجربة الرمي die1 = (int)(Math.random()*6) + 1; die2 = (int)(Math.random()*6) + 1; } } // end class PairOfDice الآن، تستطيع إنشاء كائن من الصَنْف PairOfDice بطريقتين، إِما باِستخدَام التعبير new PairOfDice()‎ أو باِستخدَام التعبير new PairOfDice(x,y)‎، حيث x و y هي تعبيرات من النوع العَدَدَي الصحيح. تستطيع أيضًا اِستخدَام نفس الصَنْف -بالأعلى- بأي برنامج آخر يَتَعامَل مع حجري نَّرد، وبذلك لن تَضَطرّ إلى اِستخدَام التعبير الغامض نوعًا ما ‎(int)(Math.random()*6)+1 مرة آخرى؛ لأنه مُضمَّن بالفعل داخل الصَنْف PairOfDice، أيّ ستحتاج للتَعامُل مع مسألة رمِي حجري النَّرد مرة واحدة ضِمْن الصَنْف، ثم لا حاجة للقلق بشأنها مُجددًا. بالمثال التالي، يَستخدِم البرنامج main الصَنْف PairOfDice؛ لعدّ عدد مرات رمِي زوجين من حجري النَّرد حتى يَتساوَى حاصل مجموع كِلا الزوجين، وهو ما يُوضِح إِمكانية إنشاء عدة نُسخ (instances) من نفس الصَنْف: public class RollTwoPairs { public static void main(String[] args) { PairOfDice firstDice; // يشير إلى الزوج الأول من حجري النرد firstDice = new PairOfDice(); PairOfDice secondDice; // يشير إلى الزوج الثاني من حجري النرد secondDice = new PairOfDice(); int countRolls; // عدد مرات الرمي int total1; // حاصل مجموع الزوج الأول int total2; // حاصل مجموع الزوج الثاني countRolls = 0; do { // إرم زوجي حجري النرد حتى يتساوى حاصل مجموع كلا منهما firstDice.roll(); // إرم الزوج الأول total1 = firstDice.die1 + firstDice.die2; // Get total. System.out.println("First pair comes up " + total1); secondDice.roll(); // إرم الزوج الثاني total2 = secondDice.die1 + secondDice.die2; // Get total. System.out.println("Second pair comes up " + total2); countRolls++; // أزد عدد الرميات System.out.println(); // Blank line. } while (total1 != total2); System.out.println("It took " + countRolls + " rolls until the totals were the same."); } // ‫نهاية main() } // ‫نهاية الصنف RollTwoPairs البَوانِي في العموم عبارة عن برامج فرعية (subroutines)، ولكن من نوع خاص. هي بلا شك ليست توابع نُسخ (instance methods)؛ لأنها لا تنتمي إلى الكائنات (objects). لكونها مسئولة عن إِنشاء الكائنات، أي لابُدّ من وُجودها قَبْل وُجود أيّ كائن من الصَنْف، فإنها قد تَكُون أكثر شبهًا بالبرامج الفرعية الأعضاء الساكنة (static) مع أنه لا يُسمَح باِستخدَام المُبدِّل static أثناء تعريفها. تقنيًا، البَوانِي ليست أعضاء (members) ضِمْن الصَنْف على الإطلاق، ولا يُشار إليها على أساس كَوْنها توابع (methods) بالصَنْف. بخلاف البرامج الفرعية (subroutines) الآخرى، تستطيع استدعاء البَوانِي فقط من خلال العَامِل new، ويُكْتَب على الصيغة التالية: new <class-name> ( <parameter-list> ) قد تَكُون قائمة المُعامِلات فارغة. تُعدّ الشيفرة بالأعلى تعبيرًا (expression)؛ لأنها بالنهاية تَحسِب قيمة وتُعيدها، حيث تُعيد مَرجِعًا (reference) إلى الكائن المنُشَئ، والذي يُفترَض عادةً تَخْزِينه بمُتْغيِّر. تستطيع أيضًا اِستدعاء البَوانِي (constructor call) بطرائق شتى آخرى، مثلًا، كمُعامِل (parameter) ضِمْن تَعْليمَة اِستدعاء برنامج فرعي (subroutine call)، أو كجُزء من تعبير (expression) أكثر تعقيدًا. لاحِظ أنه في حالة عَدْم الاحتفاظ بالمَرجِع (reference) المُعاد داخل مُتْغيِّر، فلن تَتَمكَّن من الإشارة إلى الكائن المُنشَئ مرة آخرى. يُعدّ استدعاء البَانِي (constructor call) عمومًا أكثر تعقيدًا من أيّ استدعاء عادي لبرنامج فرعي (subroutine) أو لدالة (function)، لذا من المهم أن تَفهَم الخطوات التي يُنفِّذها الحاسوب أثناء استدعاء البَوانِي: يَعثُر الحاسوب على كُتلَة غَيْر مُستخدَمة بقسم الكَوْمة (heap) من الذاكرة، بشَّرْط أن تَكُون كبيرة بما فيه الكفاية لتَحمِل كائن من النوع المُخصَّص. يُهيِئ الحاسوب مُتْغيِّرات النُسخ (instance variables) للكائن، فإذا كان التَّصْريح عنها يَتَضمَّن قيمة مبدئية، فإنه يَحسِب تلك القيمة ويُخزِّنها بمُتْغيِّر النُسخة. أما إن لَمْ تَكُن مُضمَّنة، فإنه يَستخدِم القيمة المبدئية الافتراضية. تُحسَب قيم المُعامِلات الفعليّة (actual parameters) بالبَانِي -إن وُجدت-، ثم تُسنَد إلى المُعامِلات الصُّوريّة (formal parameters). تُنفَّذ التَعْليمَات الموجودة بمَتْن البَانِي (constructor body) إن وُجدت. يُعاد مَرجِع (reference) إلى الكائن المُنشَئ كقيمة لتعبير استدعاء البَانِي (constructor call) تَكُون النتيجة النهائية هي حُصولك على مَرجِع (reference) يُشير إلى الكائن المُنشَئ حديثًا. كمثال آخر، سنُضيف بَانِي كائن (constructor) إلى الصَنْف Student المُستخدَم بالقسم الأول، كذلك أَضفنا مُتْغيِّر نُسخة (instance variable) خاص اسمه هو name. اُنظر الشيفرة: public class Student { private String name; // اسم الطالب public double test1, test2, test3; // درجات الطالب public Student(String theName) { // يستقبل باني الكائن اسم الطالب if ( theName == null ) throw new IllegalArgumentException("name can't be null"); name = theName; } public String getName() { // تابع جلب لقراءة قيمة متغير النسخة return name; } public double getAverage() { // احسب متوسط درجات الطالب return (test1 + test2 + test3) / 3; } } // ‫نهاية الصنف Student عَرَّفنا بَانِي كائن (constructor) يَستقبِل مُعامِلًا (parameter) من النوع String ليُمثِل اسم الطالب. يَحتوِي أي كائن من النوع Student على بيانات طالب معين، ويُمكِننا عمومًا إِنشاء كائنات من ذلك الصَنْف باِستخدَام التَعْليمَات التالية مثلًا: std = new Student("John Smith"); std1 = new Student("Mary Jones"); بالنسخة الأصلية من ذلك الصَنْف، كان المُبرمج يَضطرّ لإِسْناد قيمة مُتْغيِّر النُسخة name بعد إنشاء الكائن، مما يَعنِي عدم وجود ضمانة لأن يَتَذكَّر المُبرمج ضَبْط قيمة ذلك المُتْغيِّر بصورة سليمة. في المقابل، بالنسخة الجديدة من الصَنْف، لا يُمكِن إنشاء كائن من الصَنْف Student إلا عن طريق استدعاء البَانِي (constructor)، والذي يَضبُط قيمة مُتْغيِّر النُسخة name تلقائيًا، كما أنه يَضمَن ألا تَكُون تلك القيمة فارغة. يُسهِل ذلك عمومًا من عَمَل المبرمج، ويُجنِّبه عددًا كبيرًا من الأخطاء البرمجية (bugs). لاحِظ أننا قد اِستخدَمنا المُبدِّل private ضِمْن تَعْليمَة التَّصْريح عن مُتْغيِّر النُسخة name، وهو ما يُوفِّر نوعًا آخر من الضمانة؛ فبذلك لن يَتَمكَّن أي مكان بالشيفرة خارج الصنف Student من الوصول مباشرة إلى مُتْغيِّر النُسخة name، فمثلًا، تُضبَط قيمته بشكل غَيْر مباشر عند استدعاء البَانِي (constructor). في حين يَتَضمَّن الصَنْف دالة جَلْب (getter function) هي getName()‎، والتي يُمكِن من خلالها مَعرِفة قيمة مُتْغيِّر النُسخة name لطالب معين من مكان خارج الصَنْف، فإن الصَنْف لا يَحتوِي على أيّ تابع ضَبْط (setter method) أو على أي طريقة آخرى لتَعْدِيل قيمة المُتْغيِّر name، أيّ بمُجرَّد إنشاء كائن من ذلك الصَنْف، فإنه سيَظلّ مُحتفِظًا بنفس قيمة المُتْغيِّر name المَبدئية طوال فترة وجوده بالبرنامج. في تلك الحالة، رُبما من الأفضل التَّصْريح عن مُتْغيِّر النُسخة name باِستخدَام المُبدِّل final. يُمكِنك التَّصْريح عن أيّ مُتْغيِّر نُسخة (instance variable) عمومًا باِستخدَام المُبدل final بشَّرْط إِسْناد قيمة إليه إما بتَعْليمَة التَّصْريح (declaration) أو بكل البواني (constructor) المُعرَّفة بذلك الصَنْف. في العموم، لا يُمكِن إِسْناد قيمة إلى مُتْغيِّر نُسخة (instance variable) قد صُرِّح عنه باِستخدَام المُبدِّل final، ولكن يُستَثنَى من ذلك مَتْن البواني (constructor). حسنًا، ماذا سيَحدُث عندما تَستخدِم أعضاء ساكنة (static) وآخرى غَيْر ساكنة (non-static) ضِمْن نفس الصَنْف؟ يَعرِف أيّ كائن عمومًا الصَنْف الذي يَنتمِي إليه، ويُمكِنه الإشارة إلى أعضاء صَنْفه الساكنة (static members). لذا يُمكِن لأيّ تابع نُسخة (instance method) بالصَنْف أن يُشير إلى المُتْغيِّرات الأعضاء (member variables) الساكنة أو أن يَستدعِي البرامج الفرعية الأعضاء (member subroutines) الساكنة. لكن، لاحِظ أن هناك دائمًا نُسخة وحيدة فقط من أيّ عضو ساكن، والتي تَنتمِي للصَنْف ذاته، مما يَعنِي أن جميع كائنات صَنْف معين تَتَشارك نُسخة وحيدة من أيّ عضو ساكن مُعرَّف بالصَنْف. كمثال، اُنظر النسخة التالية من الصَنْف Student، والتي أُضيف إليها مُتْغيِّر نُسخة ID لكل طالب، بالإضافة إلى عضو ساكن (static member) هو nextUniqueID. على الرغم من وجود مُتْغيِّر ID بكل كائن من النوع Student، فهناك مُتْغيِّر nextUniqueID واحد فقط: public class Student { private String name; // اسم الطالب public double test1, test2, test3; // درجات الطالب private int ID; // رقم معرف لهوية الطالب private static int nextUniqueID = 0; // للاحتفاظ برقم الهوية المتاح التالي Student(String theName) { // باني كائن يستقبل اسم الطالب ويسند رقم هوية فريد إليه name = theName; nextUniqueID++; ID = nextUniqueID; } public String getName() { // ‫تابع جلب لقراءة قيمة متغير النسخة name return name; } public int getID() { // تابع جلب لقراءة قيمة رقم الهوية return ID; } public double getAverage() { // احسب متوسط درجات الطالب return (test1 + test2 + test3) / 3; } } // ‫نهاية الصنف Student لمّا كان المُتْغيِّر nextUniqueID ساكنًا (static)، فإنه يُهيَئ مبدئيًا باِستخدَام التعبير nextUniqueID = 0 مرة واحدة فقط عند تحميل الصَنْف لأول مرة. بعد ذلك، عندما نُحاوِل إنشاء كائن من الصَنْف Student، سيُنفِّذ الباني (constructor) التَعْليمَة nextUniqueID++;‎، والتي تُزِيد دائمًا قيمة نفس المُتْغيِّر العضو الساكن (static member variable) بمقدار الواحد، فتُصبِح قيمة المُتْغيِّر nextUniqueID مُساوِية للعدد ١ بَعْد إنشاء أول كائن من الصَنْف Student، ثم تُصبِح مُساوِية للعدد ٢ بَعْد إنشاء الكائن الثاني، وتُصبِح مُساوِية للعدد ٣ بَعْد الكائن الثالث، ويستمر المُتْغيِّر بالزيادة مع كل كائن جديد يُنشَىء من ذلك الصَنْف. في المقابل، لمّا كان المُتْغيِّر ID عبارة عن مُتْغيِّر نُسخة (instance variable)، فإن كل كائن لديه نُسخته الخاصة من ذلك المُتْغيِّر، والتي يُخْزِّن فيها البَانِي القيمة الجديدة من المُتْغيِّر nextUniqueID بَعْد إِنشائه للكائن. صُمّم الصَنْف Student عمومًا بحيث يَحصُل كل طالب على قيمة مختلفة لنُسخته من المُتْغيِّر ID تلقائيًا. ولأننا قد صَرَّحنا عن المُتْغيِّر ID بكَوْنه خاصًا (private)، فيَستحِيل أيضًا التَلاعُب بقيمة ذلك المُتْغيِّر بأيّ طريقة بَعْد إنشاء الكائن، وهو ما يَضمَن تَخْصِيص رقم هوية فريد ودائم لكل كائن من الصَنْف Student، وهو أمر رائع إذا فكرت بالأمر! لو أعدت التفكير بالأمر، ستَجِدْ أن تلك الضمانة ليست مُطلقة تمامًا، وإنما هي مُقْتصِرة فقط على البرامج التي تَستخدِم خيطًا (thread) واحدًا، أما البرامج مُتعددة الخيوط (multi-thread)، أي التي يُمكِن خلالها تَّنْفيذ عدة أشياء بنفس ذات الوقت، فإن الأشياء تُصبِح غريبة قليلًا، فقد يُنشِئ خيطان كائنين من الصَنْف Student بنفس ذات الوقت، ولهذا قد يَحصُل كِلا الكائنين في تلك الحالة على نفس رقم الهوية. سنعود إلى هذا الموضوع بالقسم الفرعي ١٢.١.٣، حيث ستَتَعلَّم كيفية حلّ تلك المشكلة. كانس المهملات (garbage collection) حتى الآن، كان حديثنا خلال هذا القسم مُقْتصِرًا على إنشاء الكائنات، فماذا عن هَدْمِها؟ تُحذَف الكائنات بلغة الجافا أتوماتيكيًا. يَقع أيّ كائن عمومًا بقسم الكَوْمة (heap) من الذاكرة، ويُمكِن الوصول إلى كائن معين فقط عَبْر المُتْغيِّرات التي تَحمِل مَراجِع (references) تُشير إليه. والآن، ماذا سيَحدُث لو لم يَعُدْ هناك أيّ مُتْغيِّرات تُشير إلى كائن معين؟ اُنظر مثلًا للشيفرة التالية (لاحِظ أنها لأغراض تعليمية فقط؛ فليس من المُحتمل على الإطلاق كتابة تَعْليمَتين على هذا النحو ببرنامج فعليّ): Student std = new Student("John Smith"); std = null; بالسطر الأول، اُنشِئ كائن من الصَنْف Student، ثم خُزِّن مَرجِع (reference) يُشير إليه بالمُتْغيِّر std، ثم بالسطر التالي، تَغيَّرت قيمة std، ولم يَعُدْ مَرجِع الكائن المُنشَئ للتو موجودًا، بل لم يَعُدْ هناك أي مَراجِع (references) تُشير إليه بأي مُتْغيِّر آخر، وبالتالي، لن يَتَمكَّن البرنامج من اِستخدَام ذلك الكائن مُجددًا، ولهذا يَنبغي استعادة مساحة الذاكرة المُخصَّصة للكائن لكي تُصبِح مُتاحة للاِستخدَام لأغراض آخرى. تَستخدِم الجافا إجراءً (procedure) يُعرَف باسم "كَنْس المُهملات (garbage collection)"؛ لاستعادة أجزاء الذاكرة التي كانت قد خُصِّصت للكائنات (objects)، والتي لَمْ يَعُدْ بإِمكان البرنامج الوصول إليها. يَتولَّى النظام -لا المبرمج- مسئولية تَعقُّب تلك الكائنات التي أَصبحت ضِمْن "المُهملات (garbage)". بالمثال السابق، تستطيع بسهولة أن تَرى أن الكائن قد أَصبح ضِمْن المُهملات، ولكن تَكُون الأمور في العادة أكثر تعقيدًا خاصة بَعْد اِستخدَام الكائن لفترة، فيُحتمَل عندها وجود عدة مَراجِع (references) تُشير إليه مُخزَّنة بعدة مُتْغيِّرات. لاحِظ أن الكائن لا يُعدّ جزءًا من المُهملات إلا بعد أن تُصبِح جميع مَراجِعه غَيْر مُتوفرة. تَقَع مسئولية حَذْف المُهملات على عاتق المبرمج بالكثير من اللغات البرمجية الأخرى. ولمّا كان تَعقُّب اِستخدَام الذاكرة يَنطوِي على الكثير من التعقيدات، فإنه عادةً ما يَتسبَّب بحُدوث الكثير من الأخطاء البرمجية (bugs) الخطيرة. أحد تلك الأخطاء هو خطأ المُؤشر المُعلّق (dangling pointer)، والذي يَحدُث عندما يَحذِف المبرمج عن طريق الخطأ كائنًا من الذاكرة ما يزال البرنامج يَملُك مَرجِعًا (references) إليه، مما يَتسبَّب بحُدوث مشاكل إذا حَاول البرنامج الوصول إلى كائن لم يَعُدْ موجودًا. نوع آخر من الأخطاء هو تَسريب الذاكرة (memory leak)، والذي يَحدُث عندما لا يهتم المبرمج بحَذْف الكائنات التي لم تَعُدْ مُستخدَمة، مما يُؤدي إلى مَلئ الذاكرة بكائنات غَيْر قابلة للوصول، ومِن ثَمَّّ قد يُعاني البرنامج من مشكلة نفاد الذاكرة مع أنها فقط مُهدرة في الواقع. يَستحِيل حُدوث مثل تلك الأخطاء بالجافا؛ لأنها تَعتمِد على إجراء كَنْس المُهملات (garbage collection)، وهو عمومًا فكرة قديمة اِستخدَمتها بعض اللغات البرمجية بدايةً من ستينيات القرن الماضي. لماذا إذًا لا تَستخدِمها جميع اللغات؟ لأنها في الماضي كانت بطيئة جدًا، ولكنها أَصبحت عملية بفضل العديد من الدراسات العلمية التي تناولت موضوع كَنْس المهملات عن كثب، بالإضافة إلى السرعة الفائقة للحواسيب الحديثة. ترجمة -بتصرّف- للقسم Section 2: Constructors and Object Initialization من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

تُعدّ البرمجة كائنية التوجه (object-oriented programming - OOP) بمثابة محاولة لتَمْكِين البرامج من نمذجة طريقة تفكيرنا بالعالم الخارجي وتَعامُلنا معه. بالأنماط الأقدم من البرمجة، كان المبرمج مُضطرًّا لتَحْديد المُهِمّة الحاسوبية التي ينبغي له تّنْفيذها لكي يَحلّ المشكلة الفعليّة التي تُواجهه. ووفقًا لهذا التصور، فإن البرمجة تَتكوَّن من محاولة إيجاد متتالية التَعْليمَات المسئولة عن إنجاز تلك المُهِمّة. في المقابل، تُحاوِل البرمجة كائنية التوجه (object-oriented programming) العُثور على عدة كائنات (objects) تُمثِل كيانات (entities) حقيقية أو مُجرّدة مرتبطة بموضوع المشكلة (problem domain). تَملُك تلك الكيانات سلوكيات معينة (behavior)، كما تَتَضمَّن مجموعة من البيانات، وتستطيع أن تَتَفاعَل مع بعضها البعض. ووفقًا لهذا التصور، فإن البرمجة تَتكوَّن من عملية تصميم مجموعة الكائنات (objects) التي يُمكِنها محاكاة المشكلة المطلوب حَلّها. يجعل ذلك تصميم البرامج أكثر طبيعية، وأسهل في الكتابة والفهم عمومًا. يُمكِننا القول أن البرمجة كائنية التوجه (OOP) هي مجرد تَغيير بوجهات النظر؛ فبحَسَب مفاهيم البرمجة القياسية، قد نُفكِر بالكائن (object) على أساس أنه مُجرّد مجموعة من المُتْغيِّرات والبرامج الفرعية (subroutines) المسئولة عن معالجة تلك المُتْغيِّرات ضُمِّنت معًا بطريقة ما. بل حتى يُمكِننا اِستخدَام الأساليب كائنية التوجه (object-oriented) بأي لغة برمجية، ولكن بالطبع هنالك فرق كبير بين لغة تَسمَح بالبرمجة كائنية التوجه، وآخرى تُدعِّمها بشكل نَشِط. تُدعِّم اللغات البرمجية كائنية التوجه، مثل الجافا، عدة مِيزَات تَجعلها مختلفة عن أي لغة قياسية آخرى، ولكي نَستغِل تلك السمات والميزات بأكبر قدر مُمكن، ينبغي أن نُعيد توجيه تفكيرنا على نحو سليم. ملحوظة: عادةً ما يُستخدَم مصطلح "التوابع (methods)" للإشارة إلى البرامج الفرعية (subroutines) ضِمْن سياق البرمجة كائنية التوجه (object-oriented)، ولهذا سيَستخدِم هذا الفصل مصطلح "التوابع (method)" بدلًا من مصطلح "البرامج الفرعية (subroutine)". الكائنات (objects) والأصناف (classes) والنسخ (instances) لقد تحدثنا عن الأصناف (classes) خلال الفصول السابقة، واَتضح لنا أن الصَنْف يُمكِنه أن يَحتوِي على مُتْغيِّرات وتوابع (methods) يُشار إليها باسم البرامج الفرعية. سنَنتقل الآن إلى الحديث عما يُعرَف باسم الكائنات (objects)، والتي هي وثيقة الصلة بالأصناف. بدايةً، تَعَرَّضنا للكائنات (objects) مرة وحيدة من قَبْل خلال القسم ٣.٩، ولم نَلحظ خلالها فارقًا جوهريًا؛ فلقد اِستبعدنا فقط كلمة static من تعريف إحدى البرامج الفرعية (subroutine definition). في الواقع، يَتَكوَّن أي كائن من مجموعة من المُتْغيِّرات والتوابع، فكيف يختلف إذًا عن الأصناف (classes)؟ للإجابة على مثل هذا السؤال، ستحتاج إلى طريقة تفكير مختلفة نسبيًا وذلك حتى تُدرِك أهمية الكائنات وتَتَمكَّن من اِستخدَامها بطريقة فعالة. ذَكَرَنا أن الأصناف تُستخدَم لوصف الكائنات (objects)، أو بتعبير أدق، أن الأجزاء غَيْر الساكنة (non-static) من الأصناف تُستخدَم لوصف الكائنات. قد لا يَكُون المقصود من ذلك واضحًا بما فيه الكفاية، لذا دَعْنَا نُصيغه بطريقة آخرى والتي هي أكثر شيوعًا نوعًا ما. نستطيع أن نقول أن الكائنات تنتمي إلى أصناف (classes)، ولكن ليس بنفس الطريقة التي ينتمي بها مُتْغيِّر عضو معين (member variable) لصنف. فلربما من الأدق أن نقول أن الأصناف تُستخدَم لإنشاء كائنات، فالصَنْف (class) هو أَشْبه ما يَكُون بمصنع أو مُخطط أوَّليّ (blueprint) لإنشاء الكائنات بحيث تُحدِّد الأجزاء غَيْر الساكنة (non-static) منه مجموعة المُتْغيِّرات والتوابع التي يُفْترَض أن تَتَضمَّنها كائنات ذلك الصنف. لذا فإن أحد الاختلافات الجوهرية بين الأصناف والكائنات هو حقيقة أن الكائنات تُنشَئ وتُهدَم أثناء تَشْغِيل البرنامج، بل يُمكِن اِستخدَام صَنْف معين لإنشاء أكثر من كائن (object) بحيث يَكُون لها جميعًا نفس البنية. لنَفْترِض أن لدينا الصَنْف التالي، والذي يَحتوِي على عدة مُتْغيِّرات أعضاء ساكنة (static member variables). يُمكِننا أن نَستخدِمه لتَخْزِين معلومات عن مُستخدِم البرنامج مثلًا: class UserData { static String name; static int age; } عندما يُحمِّل الحاسوب ذلك الصَنْف، فإنه سيُكرِّس جزءًا من الذاكرة له بحيث يَتَضمَّن ذلك الجزء مساحة لقيم المُتْغيِّرين name و age، أيّ سيَكُون هناك نسخة وحيدة فقط من كلا المُتْغيِّرين UserData.name و UserData.age ضِمْن البرنامج عمومًا. تُبيِّن الصورة التالية تَصوُّرًا للصَنْف داخل الذاكرة: تُعدّ المُتْغيِّرات الأعضاء الساكنة (static) جزءًا من تمثيل الصنف داخل الذاكرة، ولهذا تُستخدَم الأسماء الكاملة المُتضمِّنة لاسم الصَنْف ذاته مثل UserData.name و UserData.age للإشارة إليها. في المثال السابق، قررنا اِستخدَام الصنف UserData لتمثيل مُستخدِم البرنامج، ولمّا كان لدينا مساحة بالذاكرة لتَخْزِين البيانات المُتعلِّقة بمُستخدِم واحد فقط، فبطبيعة الحال سيَكُون البرنامج قادرًا على حَمْل بيانات مُستخدِم وحيد. لاحِظ أن الصنف UserData والمُتْغيِّرات الساكنة (static) المُعرَّفة بداخله تَظلّ موجودة طوال فترة تَشْغِيل البرنامج، وهذا هو المقصود بكَوْنها ساكنة بالأساس. لنَفْحَص الآن صَنْفًا مُشابهًا، ولكنه يَتَضمَّن بعضًا من المُتْغيِّرات غَيْر الساكنة (non-static): class PlayerData { static int playerCount; String name; int age; } أُضيف إلى الصنف PlayerData مُتْغيِّر ساكن هو playerCount أيّ أن اسمه الكامل هو PlayerData.playerCount، كما أنه مُخزَّن كجزء من تمثيل الصَنْف بالذاكرة، وتَتَوَّفر منه نُسخة واحدة فقط تَظلّ موجودة طوال فترة تَّنْفيذ البرنامج. بالإضافة إلى ذلك، يَتَضمَّن تعريف الصَنْف (class definition) مُتْغيِّرين غَيْر ساكنين (non-static)، ولأن المُتْغيِّرات غَيْر الساكنة لا تُعدّ جزءًا من الصنف ذاته، فإنه لا يُمكِن الإشارة إلى هذين المُتْغيِّرين بالأسماء PlayerData.name أو PlayerData.age. نستطيع الآن اِستخدَام الصَنْف PlayerData لإنشاء كائنات بأيّ قدر نُريده، بحيث يَمتلك كل كائن منها مُتْغيِّراته الخاصة به والتي تَحمِل الأسماء name و age، أيّ يَحصُل كل كائن على نسخته الخاصة من أجزاء الصَنْف غَيْر الساكنة (non-static)، وهذا هو ما يَعنِيه القول بأن أجزاء الصَنْف غَيْر الساكنة تُعدّ بمثابة مُخططًا أوَّليًّا أو قالبًا (template) للكائنات. تُبيِّن الصورة التالية تصورًا لذاكرة الحاسوب بَعْد إِنشاء عدة كائنات: كما ترى بالأعلى، يُعدّ المُتْغيِّر الساكن playerCount جزءًا من الصنف وتَتَوفَّر منه نُسخة وحيدة، بينما تَتَوفَّر نُسخة خاصة من المُتْغيِّرين غَيْر الساكنين name و age بكل كائن (object) مُنشَئ من ذلك الصنف. يُعدّ أيّ كائن (object) نُسخة (instance) من صَنْفه، ويَكُون على دراية بالصَنْف المُستخدَم لإِنشائه. تُبيِّن الصورة أن الصَنْف PlayerData يَحتوِي على ما يُعرَف باسم "البَانِي أو بَانِي الكائن (constructor)". البَانِي ببساطة هو برنامج فرعي (subroutine) يُستخدَم لإِنشاء الكائنات سنتحدث عنه لاحقًا. ولأننا نستطيع إِنشاء كائنات (objects) جديدة من الصَنْف PlayerData لتَمْثيل لاعبين جُدد بقَدْر ما نَشَاء، فقد يُصبِح لدينا الآن مجموعة من اللاعبين. على سبيل المثال، قد يَستخدِم برنامج معين الصَنْف PlayerData لتَخْزين بيانات مجموعة لاعبين ضِمْن لعبة بحيث يَملُك كُلًا منهم name و age خاص به، وعندما يَنضَم لاعب جديد إلى اللعبة، يَستطيع البرنامج أن يُنشِئ كائنًا جديدًا من الصَنْف PlayerData لتمثيل ذلك اللاعب، أما إذا غادر أحد اللاعبين، يَستطيع البرنامج هَدْم الكائن المُمثِل لذلك اللاعب، أي سيَستخدِم ذلك البرنامج شبكة من الكائنات لنَمذجة أحداث اللعبة بصورة ديناميكية (dynamic)، وهو ما لا يُمكِنك القيام به باِستخدَام المُتْغيِّرات الساكنة (static). يُعدّ أيّ كائن (object) نُسخة (instance) من الصَنْف المُستخدَم لإِنشائه، ونقول أحيانًا بأنه يَنتمي إلى ذلك الصَنْف. يُطلَق اسم مُتْغيِّرات النُسخ (instance variables) على المُتْغيِّرات التي يَتَضمَّنها الكائن بينما يُطلَق اسم توابع النُسخ (instance methods) على التوابع (methods) -أو البرامج الفرعية- ضِمْن الكائن. فمثلًا، إذا اِستخدَمنا الصَنْف PlayerData المُعرَّف بالأعلى لإِنشاء كائن، فإن ذلك الكائن يُعدّ نُسخة (instance) من الصنف PlayerData كما يُعدّ كُلًا من name و age مُتْغيِّرات نُسخ (instance variable) ضِمْن الكائن. لا يَتَضمَّن المثال بالأعلى أيّ توابع (methods)، ولكنها تَعَمَل عمومًا بصورة مشابهة للمُتْغيِّرات أيّ تُعدّ التوابع الساكنة (static) جزءًا من الصَنْف ذاته بينما تُعدّ التوابع غَيْر الساكنة (non-static) أو توابع النُسخ (instance methods) جزءًا من الكائنات (objects) المُنشئة من ذلك الصَنْف. لكن، لا تَأخُذ ذلك بمعناه الحرفي؛ فلا يَحتوِي كل كائن على نُسخته الخاصة من شيفرة توابع النُسخ (instance method) المُعرَّفة ضِمْن الصَنْف بشكل فعليّ وإنما يُعدّ ذلك صحيحًا على نحو منطقي فقط، وعمومًا سنستمر بالإشارة إلى احتواء كائن معين على توابع نُسخ (instance method) صَنْفه. ينبغي عمومًا أن تُميز بين الشيفرة المصدرية (source code) للصَنْف والصَنْف ذاته بالذاكرة. تُحدِّد الشيفرة المصدرية كُلًا من هيئة الصَنْف وهيئة الكائنات المُنشئة منه: تُحدِّد التعريفات الساكنة (static definitions) بالشيفرة العناصر التي ستُصبِح جُزءًا من الصَنْف ذاته بذاكرة الحاسوب بينما تُحدِّد التعريفات غَيْر الساكنة (non-static definitions) بالشيفرة العناصر التي ستُصبِح جُزءًا من كل كائن يُنشَئ من ذلك الصنف. بالمناسبة، يُطلَق اسم مُتْغيِّرات الأصناف (class variables) وتوابع الأصناف (class methods) على المُتْغيِّرات الأعضاء (member variables) الساكنة والبرامج الفرعية الأعضاء (member subroutines) الساكنة المُعرَّفة ضِمْن الصنف على الترتيب؛ وذلك لكَوْنها تنتمي للصَنْف ذاته وليس لنُسخ (instances) ذلك الصَنْف. يَتَّضِح لنا الآن الكيفية التي تَختلِف بها الأجزاء الساكنة من صنف معين عن الأجزاء غَيْر الساكنة، حيث يَخدِم كُلًا منهما غرضًا مُختلفًا تمامًا. وفي العموم، ستَجِدْ أن كثيرًا من الأصناف إِما أنها تَحتوِي على أعضاء ساكنة (static) فقط أو على أعضاء غَيْر ساكنة (non-static) فقط، ومع ذلك سنَرى أمثلة قليلة لأصناف تَحتوِي على مَزيج منهما. أساسيات الكائنات اِقْتصَر حديثنا إلى الآن على الكائنات (objects) في العموم دون ذِكْر أيّ تفاصيل عن طريقة اِستخدَامها بصورة فعليّة ضِمْن برنامج، لذا سنَفْحَص مثالًا مُحدَّدًا لنوضح ذلك. لنَفْترِض أن لدينا الصَنْف Student المُعرَّف بالأسفل، والذي يُمكِننا اِستخدَامه لتَخْزِين بعض بيانات الطلبة المُلتحِقة بدورة تدريبية: public class Student { public String name; // اسم الطالب public double test1, test2, test3; // الدرجة بثلاثة اختبارات public double getAverage() { // احسب متوسط درجة الاختبارات return (test1 + test2 + test3) / 3; } } // ‫نهاية الصنف Student لم يُستخدَم المُبدِّل static أثناء التَّصْريح عن أيّ من أعضاء الصَنْف Student، لذا فالصَنْف موجود فقط بغَرْض إِنشاء الكائنات (objects). يُحدِّد تعريف الصَنْف Student -بالأعلى- أن كائناته أو نُسخه (instance) ستَحتوِي على مُتْغيِّرات النُسخ (instance variables)‏ name و test1 و test2 و test3 كما ستَحتوِي على تابع نسخة (instance method) هو getAverage()‎. سيَحتوِي كل كائن -يُمثِل طالبًا- في العموم على اسم طالب معين ودرجاته، وعندما يُستدعَى التابع getAverage()‎ لكائن معين، ستُحسَب قيمة المتوسط باِستخدَام درجات الاختبار ضِمْن ذلك الكائن تَحْديدًا أيّ سيَحصُل كل كائن على قيمة متوسط مختلفة، وهذا هو في الواقع ما يَعنِيه انتماء توابع النُسخ (instance method) للكائنات المُفردة لا الأصناف نفسها. الأصناف بلغة الجافا هي أنواع تمامًا كالأنواع المَبنية مُسْبَقًا (built-in) مثل int و boolean، لذا تستطيع اِستخدَام اسم صَنْف معين لتَحْدِيد نوع مُتْغيِّر ضِمْن تَعْليمَة تَّصْريح (declaration statement) أو لتَخْصِيص نوع مُعامِل صُّوريّ (formal parameter) أو لتَحْدِيد نوع القيمة المُعادة (return type) من دالة (function). يُمكِن مثلًا تعريف مُتْغيِّر اسمه std من النوع Student باِستخدَام التَعْليمَة التالية: Student std; انتبه للنقطة الهامة التالية، لا يُؤدي تَّصْرِيحك (declare) عن مُتْغيِّر نوعه عبارة عن صنف إلى إِنشاء الكائن ذاته! تَرتبط هذه النقطة بالحقيقتين التاليتين: لا يُمكِن لأيّ مُتْغيِّر أن يَحمِل كائنًا. يستطيع المُتْغيِّر أن يَحمِل مَرجِعًا (reference) يُشير إلى كائن. يُفضَّل أن تُفكِر بالكائنات (objects) كما لو أنها تَعيش مُستقلة بذاكرة الحاسوب، تحديدًا بقسم الكَوْمة (heap) من الذاكرة. لا تَحمِل المُتْغيِّرات كائنية النوع (object type) قيم الكائنات نفسها وإنما تَحمِل المعلومات الضرورية للعُثور على تلك الكائنات بالذاكرة، تَحْديدًا تَحمِل عناوين مَواضِعها (location address) بالذاكرة، ويُقال عندها أن المُتْغيِّر يَحمِل مَرجِعًا (reference) أو مُؤشرًا (pointer) إلى الكائن. عندما تَستخدِم مُتْغيِّر كائني النوع (object type)، يَستخدِم الحاسوب المَرجِع (reference) المُخْزَّن بالمُتْغيِّر للعُثور على قيمة الكائن الفعليّة. يُنشِئ العَامِل (operator)‏ new كائنًا جديدًا (object) حيث يَستدعِى برنامجًا فرعيًا -ذكرناه سابقًا- يقع ضِمْن الصَنْف يُطلَق عليه اسم البَانِي (constructor)، ثم يُعيد مَرجِعًا (reference) يُشير إلى الكائن المُنشَىء. لنَفْترِض مثلًا أن لدينا مُتْغيِّر std من النوع Student المُصرَّح عنه بالأعلى، يُمكِننا الآن كتابة تَعْليمَة الإِسْناد التالية (assignment statement): std = new Student(); تُنشِئ تَعْليمَة الإِسْناد -بالأعلى- كائنًًا (object) جديدًا بقسم الكَوْمة (heap) من الذاكرة، والذي يُعدّ نُسخة (instance) من الصَنْف Student، ثم تُخزِّن التَعْليمَة مَرجِعًا (reference) إلى ذلك الكائن بالمُتْغيِّر std أيّ أن قيمة المُتْغيِّر عبارة عن مَرجِع (reference) أو مُؤشر (pointer) إلى الكائن الواقع بمكان ما. لا يَصِح في العموم أن تقول "قيمة المُتْغيِّر std هي الكائن ذاته" على الرغم من صعوبة تَجنُّب ذلك أحيانًا، ولكن لا تَقل أبدًا أن "الكائن مُخزَّن بالمُتْغيِّر std" فهو أمر غَيْر صحيح على الإطلاق. يُفْترَض عمومًا أن تقول "يُشير المُتْغيِّر std إلى الكائن"، وهو ما سنُحاول الالتزام به قَدْر الإِمكان. لاحِظ أنه إذا ذَكَرَنا مثلًا أن "std هو كائن"، فالمقصود هو "std هو مُتْغيِّر يُشيِر إلى كائن". لنَفْترِض أن المُتْغيِّر std يُشير إلى كائن (object) عبارة عن نُسخة (instance) من الصَنْف Student أيّ يَحتوِي ذلك الكائن بطبيعة الحال على مُتْغيِّرات النُسخ name و test1 و test2 و test3. يُمكِننا الإشارة إلى تلك المُتْغيِّرات باِستخدَام std.name و std.test1 و std.test2 و std.test3 على الترتيب. يَتَّبِع ذلك نفس نَمْط التسمية المُعتاد بأنه عندما يَكُون B جزءًا من A، فإن اسم B الكامل هو A.B. اُنظر المثال التالي: System.out.println("Hello, " + std.name + ". Your test grades are:"); System.out.println(std.test1); System.out.println(std.test2); System.out.println(std.test3); ستَطبَع الشيفرة بالأعلى الاسم وقيم الدرجات بالكائن المُشار إليه باِستخدَام المُتْغيِّر std. بنفس الأسلوب، يَحتوِي ذلك الكائن على تابع نسخة هو getAverage()‎، والذي يُمكِننا استدعائه باِستخدَام std.getAverage()‎. يُمكِنك كتابة الشيفرة التالية لطباعة مُتوسط درجات الطالب: System.out.println( "Your average is " + std.getAverage() ); تستطيع عمومًا اِستخدَام std.name أينما أَمَكَن اِستخدَام مُتْغيِّر من النوع String. فمثلًا، قد تَستخدِمه ضِمْن تعبير (expression) أو قد تُسنِد قيمة إليه أو قد تَستخدِمه حتى لاستدعاء أحد البرامج الفرعية (subroutines) المُعرَّفة بالصَنْف String. فمثلًا، يُمثِل التعبير std.name.length()‎ عدد المحارف باسم الطالب. قد لا تُشير مُتْغيِّرات الكائنات (object variables) أيّ تلك التي نوعها هو عبارة عن صَنْف -مثل المُتْغيِّر std- إلى أيّ كائن نهائيًا، وفي تلك الحالة، يُقال أنها تَحمِل مُؤشرًا فارغًا (null pointer) أو مَرجِعًا فارغًا (null reference). يُكْتَب المُؤشر الفارغ (null pointer) باِستخدَام كلمة null، ولهذا تستطيع اِستخدَام الشيفرة التالية لتَخْزِين مَرجِع فارغ بالمُتْغيِّر std: std = null; في المثال بالأعلى، لا يَحتوِي المُتْغيِّر على مُؤشر لأيّ شيء آخر وإنما تُعدّ null هي قيمته الفعليّة، لذا لا يَصِح أن تقول: "يُشير المُتْغيِّر إلى القيمة الفارغة (null)"، فالمُتْغيِّر نفسه هو قيمة فارغة. تستطيع اختبار ما إذا كانت قيمة المُتْغيِّر std فارغة باِستخدَام التالي: if (std == null) . . . عندما تَكُون قيمة مُتْغيِّر كائن (object variable) فارغة أيّ تَحتوِي على null، يَعنِي ذلك أن المُتْغيِّر لا يُشير إلى أيّ كائن، وبالتالي لا يَكُون هناك أيّ مُتْغيِّرات نُسخ (instance variables) أو توابع نُسخ (instance methods) يُمكِن الإشارة إليها، ويَكُون من الخطأ محاولة القيام بذلك عبر ذاك المُتْغيِّر. فمثلًا، إذا كانت قيمة المُتْغيِّر std هي null، وحَاوَل برنامج معين الإشارة إلى std.test1، سيُؤدِي ذلك إلى محاولة اِستخدَام مؤشر فارغ (null pointer) بطريقة خاطئة، ولهذا سيُبلَّغ عن اِعتراض مُؤشِر فارغ (null pointer exception) من النوع NullPointerException أثناء تّنْفيذ البرنامج. لنَفْحَص مُتتالية التَعْليمَات التالية: Student std, std1, // ‫صرح عن أربعة متغيرات من النوع Student std2, std3; // ‫أنشئ كائن جديد من الصنف Student وخزن مرجعه بالمتغير std std = new Student(); // ‫أنشئ كائن آخر من الصنف Student وخزن مرجعه بالمتغير std1 std1 = new Student(); // ‫انسخ مرجع std1 إلى المتغير std2 std2 = std1; // ‫خزن مؤشرا فارغا بالمتغير std3 std3 = null; // اضبط قيم متغيرات الأعضاء std.name = "John Smith"; std1.name = "Mary Jones"; بعدما يُنفِّذ الحاسوب التَعْليمَات بالأعلى، ستُصبِح ذاكرة الحاسوب كالتالي: يَتَبين لنا التالي بَعْد فَحْص الصورة بالأعلى: أولًا، يَحتوِي أيّ مُتْغيِّر على مَرجِع (reference) إلى كائن ظَهَرَت قيمته ضِمْن الصورة بهيئة سهم يُشير إلى الكائن (object). ثانيًا، يُمكِننا أن نَرَى أن السَلاسِل النصية من النوع String هي كائنات. ثالثًا، لا يُشير المُتْغيِّر std3 إلى أيّ مكان؛ لأنه فارغ ويَحتوِي على القيمة null. وأخيرًا، تُشير الأسهم من std1 و std2 إلى نفس ذات الكائن وهو ما يُبرِز النقطة المهمة التالية: عندما نُسنِد مُتْغيِّر كائن (object variable) إلى آخر، يُنسَخ المَرجِع (reference) فقط لا الكائن (object) المُشار إليه بواسطة ذلك المَرجِع. لنَأخُذ مثلًا التَعْليمَة std2 = std1;‎ كمثال، لمّا كانت تَعْليمَة الإِسْناد (assignment statement) في العموم تَنسَخ فقط القيمة المُخْزَّنة بمُعاملها الأيمن std1 إلى مُعاملها الأيسر std2، ولأن القيمة في تلك الحالة هي مُجرَّد مُؤشِر (pointer) إلى كائن وليست الكائن (object) ذاته، فإن تلك التَعْليمَة لم تُنشِئ كائنًا جديدًا، وإنما ضَبَطَت std2 بحيث يُشير إلى نفس الكائن الذي يُشير إليه std1. يَترتَب على ذلك عدة نتائج قد تَكُون مفاجئة بالنسبة لك. مثلًا، تُعدّ كُلًا من std1.name و std2.name أسماءً مختلفة لنفس مُتْغيِّر النُسخة (instance variable) المُعرَّف ضِمْن الكائن الذي يُشير إليه كِلا المُتْغيِّرين std1 و std2، ولهذا عندما تُسنِد السِلسِلة النصية "Mary Jones" مثلًا إلى std1.name، ستُصبِح قيمة std2.name هي أيضًا "Mary Jones". إذا التبس عليك الأمر، حَاوِل فقط أن تَستحضر الحقيقة التالية: "المُتْغيِّر ليس هو الكائن (object)، فالأول يَحمِل فقط مُؤشرًا (pointer) إلى الثاني." يُستخدَم العَامِلان == و ‎!=‎ لاختبار تَساوِي كائنين أو عدم تَساوِيهما على الترتيب، ولكن لاحِظ أن المَعنَى الدلالي (semantics) وراء تلك الاختبارات مُختلف عما أنت مُعتاد عليه. فمثلًا، يَفْحَص الاختبار if (std1 == std2)‎ ما إذا كانت القيم المُخْزَّنة بكُلًا من std1 و std2 مُتساوية، ولأن تلك القيم هي مُجرَّد مَراجِع (references) تُشير إلى كائنات وليست الكائنات ذاتها، فإن ذلك الاختبار يَفْحَص ما إذا كان std1 و std2 يُشيران إلى نفس ذات الكائن أيّ ما إذا كانا يُشيران إلى نفس المَوضِع بالذاكرة. لا يُعدّ ذلك مشكلة إذا كان هذا هو ما تُريد اختباره، لكن أحيانًا يَكُون المقصود هو مَعرِفة ما إذا كانت مُتْغيِّرات النُسخ (instance variables) تَحمِل نفس القيم بغَضْ النظر عن انتمائها لنفس ذات الكائن. في تلك الحالات، ستحتاج إلى إجراء الاختبار التالي: std1.test1 == std2.test1 && std1.test2 == std2.test2 && std1.test3 == std2.test3 && std1.name.equals(std2.name) ذَكَرَنا مُسْبَقًا أن السَلاسِل النصية من النوع String هي بالأساس كائنات، كما أَظَهَرنا السِلسِلتين النصيتين "Mary Jones" و "John Smith" بهيئة كائنات بالصورة التوضيحية بالأعلى ولكن بدون البنية الداخلية للنوع String. تُعدّ تلك السِلاسِل كائنات مميزة، وتُعامَل وفقًا لقواعد صيغة خاصة. كأيّ مُتْغيِّر كائن (object variable)، تَحمِل المُتْغيِّرات من النوع String مَرجِعًا (reference) إلى سِلسِلة نصية وليس السِلسِلة النصية ذاتها. بُناءً على ذلك، لا يَصِح عادةً اِستخدَام العَامِل == لاختبار تَساوِي السَلاسِل النصية. فمثلًا، إذا كان لدينا مُتْغيِّر من النوع String اسمه هو greeting ويُشير إلى السِلسِلة النصية "Hello"، فهل يَكُون الاختبار greeting == "Hello"‎ مُتحقِّقًا؟ في الواقع، يُشير كُلًا من المُتْغيِّر greeting والسِلسِلة النصية المُجرَّدة "Hello" إلى سِلسِلة نصية تَحتوِي على المحارف H-e-l-l-o. ومع ذلك، فإنهما قد يَكُونان كائنين مختلفين صَدَفَ فقط احتوائهما على نفس المحارف، ولأن ذلك التعبير يَختبِر ما إذا كان greeting و "Hello" يَحتوِيان على نفس المحارف، وكذلك ما إذا كانا واقْعين بنفس مَوضِع الذاكرة، فإن الاختبار greeting == "Hello"‎ لا يُعدّ مُتحقِّقًا. في المقابل، تَقْتصِر الدالة greeting.equals("Hello")‎ على اختبار ما إذا كان greeting و "Hello" يَحتوِيان على نفس المحارف وهو عادةً ما تَرغَب باختباره. أخيرًا، يُمكِن للمُتْغيِّرات من النوع String أن تَكُون فارغة أيّ تحتوي على القيمة null، وفي تلك الحالة، سيَكُون اِستخدَام العَامِل == مُناسبًا لاختبار ما إذا كان المُتْغيِّر فارغًا كالتالي greeting == null. ذَكَرَنا أكثر من مرة أن مُتْغيِّرات الكائنات لا تَحمِل الكائنات (objects) ذاتها، وإنما تَحمِل مَراجِع (references) تُشير إلى تلك الكائنات، وهو ما يَترتَب عليه بعض من النتائج الآخرى التي ينبغي أن تَكُون على دراية بها والتي ستَجِدها منطقية إذا استحضرت بذهنك الحقيقة التالية: "لا تُخْزَّن الكائنات (object) بالمُتْغيِّرات، وإنما بأماكن آخرى تُشير إليها المُتْغيِّرات". النتائج كالتالي: أولًا، لنَفْترِض أن لدينا مُتْغيِّر كائن (object variable) صُرِّح عنه باِستخدَام المُبدِّل final أي لا يُمكِن تَغْيير القيمة المُخْزَّنة بذلك المُتْغيِّر نهائيًا بَعْد تهيئته مبدئيًا (initialize)، ولأن تلك القيمة هي مَرجِع (reference) يُشير إلى كائن، فإن المُتْغيِّر سيَستمر بالإشارة إلى نفس الكائن طالما كان موجودًا. مع ذلك، يُمكِن تَعْديل البيانات المُخْزَّنة بالكائن لأن المُتْغيِّر هو ما صُرِّح عنه باِستخدَام المُبدِّل final وليس الكائن نفسه، لذا يُمكِن كتابة الآتي: final Student stu = new Student(); stu.name = "John Doe"; ثانيًا، لنَفْترِض أن obj هو مُتْغيِّر يُشير إلى كائن، ماذا سيَحدُث عند تمرير obj كمُعامِل فعليّ (actual parameter) إلى برنامج فرعي (subroutine)؟ ببساطة، ستُسنَد قيمة obj إلى مُعامِل صُّوريّ (formal parameter)، ثم سيُنفَّذ البرنامج الفرعي، ولأن البرنامج الفرعي ليس لديه سوى نُسخة من قيمة المُتْغيِّر obj، فإنه لن يَستطيع تَغْيير القيمة المُخْزَّنة بالمُتْغيِّر الأصلي. ومع ذلك، لمّا كانت تلك القيمة هي مَرجِع (reference) إلى كائن، سيَتَمكَّن البرنامج الفرعي من تَعْديل البيانات المُخْزَّنة بالكائن. أي أنه وبانتهاء البرنامج الفرعي، فحتمًا ما يزال المُتْغيِّر obj يُشير إلى نفس الكائن، ولكن البيانات المُخزَّنة بالكائن ربما تَكُون قد تَغيَّرت. لنَفْترِض أن لدينا مُتْغيِّر x من النوع int، اُنظر الشيفرة التالية: void dontChange(int z) { z = 42; } x = 17; dontChange(x); System.out.println(x); // output the value 17. لاحظ أن البرنامج الفرعي لم يَتَمكَّن من تَغْيير قيمة x، وهو ما يُكافئ التالي: z = x; z = 42; والآن، لنَفْترِض أن لدينا مُتْغيِّر stu من النوع Student، اُنظر الشيفرة التالية: void change(Student s) { s.name = "Fred"; } stu.name = "Jane"; change(stu); System.out.println(stu.name); // output the value "Fred". في حين لم تَتَغيَّر قيمة stu، تَغيَّرت قيمة stu.name، وهو ما يُكافئ كتابة: s = stu; s.name = "Fred"; الضوابط (setters) والجوالب (getters) ينبغي أن تُراعِي مسألة التَحكُّم بالوصول (access control) عند كتابة أصناف (classes) جديدة، فتَّصْريحك عن كَوْن العضو (member) عامًا (public) يَجعله قابلًا للوصول من أي مكان بما في ذلك الأصناف الآخرى، في حين أن تَّصْريحك عن كَوْنه خاصًا (private) يجعل اِستخدَامه مَقْصورًا على الصَنْف المُعرَّف بداخله فقط. يُفضَّل عمومًا التَّصْريح عن غالبية المُتْغيِّرات الأعضاء (member variables) -إن لم يَكُن كلها- على أساس كَوْنها خاصة (private)؛ حتى يَكُون بإمكانك التَحكُّم بما يُمكِن القيام به بتلك المُتْغيِّرات تَحكُّمًا كاملًا. بَعْد ذلك، إذا أردت أن تَسمَح لأصناف آخرى بالوُصول لقيمة أحد تلك المُتْغيِّرات المُصرَّح عنها بكَوْنها خاصة، فيُمكِنك ببساطة كتابة تابع وُصول عام (public accessor method) يُعيد قيمة ذلك المُتْغيِّر. على سبيل المثال، إذا كان لديك صَنْف يَحتوِي على مُتْغيِّر عضو (member variable) خاص اسمه title من النوع String، تستطيع كتابة التابع (method) التالي: public String getTitle() { return title; } يُعيد التابع -بالأعلى- قيمة المُتْغيِّر العضو title. اُصطلح على تسمية توابع الوصول (accessor methods) للمُتْغيِّرات وفقًا لنمط معين بحيث يَتكوَّن الاسم من كلمة "get" مَتبوعة باسم المُتْغيِّر بعد تَكْبير حُروفه الأولى (capitalizing)، ولهذا يَتكوَّن اسم تابع وصول (accessor method) المُتْغيِّر title -بالأعلى- من الكلمتين "get" و "Title" أيّ يُصبح الاسم getTitle()‎. ولهذا يُطلَق عادةً على توابع الوصول اسم توابع الجَلْب (getter methods)، لأنها تُوفِّر "تَّصْريح قراءة (read access)" للمُتْغيِّرات. انتبه أنه في حالة المُتْغيِّرات من النوع boolean، تُستخدَم عادةً كلمة "is" بدلًا من "get" أيّ أنه إذا كان لدينا مُتْغيِّر عضو من النوع boolean اسمه done، فإن اسم جَالِبه (getter) قد يَكُون isDone()‎. قد تحتاج أيضًا إلى تَوْفِير "تصريح كتابة (write access)" لمُتْغيِّر خاص (private)؛ حتى تَتَمكَّن الأصناف الآخرى من تَخْصيص قيم جديدة لذلك المُتْغيِّر. تُستخدَم توابع الضَبْط (setter method) -أو تسمى أحيانًا بتوابع التَعْدِيل (mutator method)- لهذا الغرض، وبالمثل من توابع الجَلْب (getter methods)، ينبغي أن يَتكوَّن اسم تابع ضَبْط (setter method) مُتْغيِّر معين من كلمة "set" مَتبوعة باسم ذلك المُتْغيِّر بعد تَكْبير حُروفه الأولى. بالإضافة إلى ذلك، لابُدّ أن يَستقبِل تابع الضَبْط مُعامِلًا (parameter) من نفس نوع المُتْغيِّر. يُمكِن كتابة تابع ضْبْط (setter method) المُتْغيِّر title كالتالي: public void setTitle( String newTitle ) { title = newTitle; } ستحتاج غالبًا إلى كتابة كُلًا من تابعي الجَلْب (getter method) والضَبْط (setter method) لمُتْغيِّر عضو خاص معين؛ حتى تَتَمكَّن الأصناف الآخرى من رؤية قيمة ذلك المُتْغيِّر والتَعْدِيل عليها كذلك. قد تتساءل، لما لا نُصرِّح عن المُتْغيِّر على أساس كَوْنه عامًا (public) من البداية؟ قد يَكُون ذلك منطقيًا إذا كانت الجوالب (getters) والضوابط (setters) مُقْتصرة على قراءة قيم المُتْغيِّرات وكتابتها، ولكنها في الحقيقة قادرة على القيام بأيّ شيء آخر. فمثلًا، يستطيع تابع جَلْب (getter method) مُتْغيِّر معين أن يَحتفظ بعَدَدَ مرات قرائته كالتالي: public String getTitle() { titleAccessCount++; // Increment member variable titleAccessCount. return title; } كما يستطيع تابع ضَبْط (setter method) مُتْغيِّر آخر أن يَفْحص القيمة المطلوب إِسْنادها إليه لتَحْديد ما إذا كانت صالحة أم لا كالتالي: public void setTitle( String newTitle ) { if ( newTitle == null ) // لا تسمح بسَلاسِل نصية فارغة title = "(Untitled)"; // استخدم قيمة افتراضية else title = newTitle; } يُفضَّل عمومًا كتابة تابعي ضَبْط (setter method) وجَلْب (getter method) المُتْغيِّر حتى لو وَجَدَت أن دورهما مُقْتصِر على قراءة قيمة المُتْغيِّر وكتابتها، فأنت لا تدري، ربما تُغيِّر رأيك مُستقبلًا بينما تُعيد تصميم ذلك الصنف أو تُحسنه. ولأن تابعي الضبط والجلب جزء من الواجهة العامة (public interface) للصنف بعكس المُتْغيِّرات الأعضاء (member variable) الخاصة، فستستطيع ببساطة أن تُعدِّل تَّنْفيذ (implementations) تلك التوابع -هذا إذا كنت قد اِستخدَمتها منذ البداية- بدون تَغْيير الواجهة العامة للصَنْف وبدون أن تُؤثِر على أيّ أصناف أُخرى كانت قد اِستخدَمت ذلك الصَنْف. أما إذا لَمْ تَكُن قد اِستخدَمتها وتُريد ذلك الآن، فستَضطرّ آسفًا إلى التَواصُل مع كل شخص صَدَف وأن اِستخدَم الصَنْف؛ لتُبلِّغه بأن عليه فقط أن يَتَعقَّب كل مَوضِع بشيفرته يَستخدِم فيه ذلك المُتْغيِّر ويُعدِّله بحيث يَستخدِم تابعي الضَبْط (setter method) والجَلْب (getter method) للمُتْغيِّر العضو بدلًا من اسمه. كملاحظة أخيرة: تَشترِط بعض الخصائص المُتقدمة بلغة الجافا تَسمية توابع الضَبْط (setter methods) والجَلْب (getter methods) وفقًا للنَمْط المذكور بالأعلى، لهذا ينبغي في العموم أن تَتَّبِعه بصرامة. انتبه أيضًا للتالي: في حين أننا قد نَاقشنا تابعي الضَبْط والجَلْب ضِمْن سياق المُتْغيِّرات الأعضاء، فإنه في الواقع يُمكِن تَعْرِيف كُلًا منهما حتى في حالة عدم وجود مُتْغيِّر. يُعرِّف تابعي الضَبْط والجَلْب بالأساس خاصية (property) ضِمْن الصَنْف، والتي قد يُناظرها مُتْغيِّر أو لا. بتعبير آخر، إذا كان لديك صَنْف يَحتوِي على تابع نسخة (instance method) مُعرَّف باِستخدَام المُبدِّلات public void، وبَصمته (signature) هي setValue(double)‎، فإن ذلك الصَنْف حتمًا يَمتلك "خاصية (property)" اسمها value من النوع double، وذلك بغض النظر عن وجود مُتْغيِّر عضو (member variable) يَحمِل الاسم value ضِمْن ذلك الصَنْف من عدمه. المصفوفات والكائنات ذَكَرنا بالقسم الفرعي ٣.٨.١ أن المصفوفات (arrays) هي بالأساس كائنات أو ربما كائنات مميزة -تمامًا كالسَلاسِل النصية من النوع String-، وتُكْتَب وفقًا لقواعد صيغة (syntax) خاصة. فمثلًا تَتَوفَّر نسخة خاصة من العَامِل new لإنشاء المصفوفات. كأيّ مُتْغيِّر كائن (object variable)، لا يَحمِل أيّ مُتْغيِّر مصفوفة (array variable) قيمة مصفوفة فعليّة وإنما يَحمِل مرجعًا (reference) يُشير إلى كائن مصفوفة (array object) والذي يَكُون مُْخْزَّنًا بجزء المَكْدَس (heap) من الذاكرة. يُمكِن أيضًا لمُتْغيِّر مصفوفة أن يَحمِل القيمة null في حالة عدم وجود مصفوفة فعليّة. لاحظ أن كل نوع مصفوفة (array type) كالنوع int[]‎ أو النوع String[]‎ يُقابله صَنْف (class). فلنَفْترِض أن list هو مُتْغيِّر من النوع int[]‎. إذا كان ذلك المُتْغيِّر يَحمِل القيمة null، فسيَكُون من الخطأ أن تحاول قراءة list.length أو قراءة أيّ من عناصر المصفوفة (array element)‏ list‎، وسيَتَسبَّب بحُدوث اعتراض (exception) من النوع NullPointerException. بفَرْض أن newlist هو مُتْغيِّر آخر من نفس النوع int[]‎، اُنظر التَعْليمَة التالية: newlist = list; يَقْتصِر دور تَعْليمَة الإِسْناد (assignment statement) بالأعلى على نَسْخ قيمة المَرجِع (reference) المُخْزَّنة بالمُتْغيِّر list فقط إلى newlist. إذا كان المُتْغيِّر list يَحمِل القيمة null، فسيَحمِل المُتْغيِّر newlist القيمة null أيضًا أما إذا كان المُتْغيِّر list يُشير إلى مصفوفة، فلن تَنسَخ تَعْليمَة الإِسْناد تلك المصفوفة وإنما ستَضبُط المُتْغيِّر newlist فقط بحيث يُشير إلى نفس المصفوفة التي يُشير إليها المُتْغيِّر list. اُنظر الشيفرة التالية كمثال: list = new int[3]; list[1] = 17; // ‫تشير newlist إلى نفس المصفوفة التي يشير إليها list newlist = list; newlist[1] = 42; System.out.println( list[1] ); لأن list[1]‎ و newlist[1]‎ هي مجرد أسماء مختلفة لنفس عنصر المصفوفة، فسيَكُون خَرْج الشيفرة بالأعلى هو 42 وليس 17. قد تَجِدْ كل تلك التفاصيل مُربكة بالبداية، ولكن بمُجرَّد أن تَستحضِر بذهنك أن "أي مصفوفة هي عبارة عن كائن (object) وأن أيّ مُتْغيِّر مصفوفة (array variables) هو فقط يَحمِل مؤشرًا (pointers) إلى مصفوفة"، سيُصبِح كل شيء بديهيًا. تَنطبِق تلك الحقيقة أيضًا على تمرير مصفوفة كمُعامِل (parameter) إلى برنامج فرعي (subroutine) حيث سيَستقبِل البرنامج في تلك الحالة نُسخة فقط من المُؤشر (pointer) وليس المصفوفة ذاتها، وبذلك سيَملُك مَرجِعًا (reference) إلى المصفوفة الأصلية، وعليه فإن أيّ تَعْدِيلات قد يُجرِيها على عناصر المصفوفة (array elements)، سيَمتدّ أثرها إلى المصفوفة الأصلية وستستمر إلى ما بَعْد انتهاء البرنامج الفرعي. بالإضافة إلى كَوْن المصفوفات كائنات (objects) بالأساس، فإنها قد تُستخدَم لحَمل كائنات أيضًا، ويَكُون نوع المصفوفة الأساسي (base type) في تلك الحالة عبارة عن صَنْف. في الواقع، لقد تَعرَّضنا لذلك بالفعل عندما تَعامَلنا مع المصفوفات من النوع String[]‎، ولكن لا يَقْتصِر الأمر على النوع String بل تستطيع اِستخدَام أيّ صَنْف آخر. فمثلًا، يُمكِننا إنشاء مصفوفة من النوع Student[]‎، والتي نوعها الأساسي هو الصنف Student المُعرَّف مُسْبَقًا بهذا القسم، وفي تلك الحالة، يَكُون كل عنصر بالمصفوفة عبارة عن مُتْغيِّر من النوع Student. يُمكِننا مثلًا كتابة الشيفرة التالية لتَخْزين بيانات 30 طالب داخل مصفوفة: Student[] classlist; // Declare a variable of type Student[]. classlist = new Student[30]; // The variable now points to an array. تَتَكوَّن المصفوفة -بالأعلى- من 30 عنصر هي classlist[0]‎ و classlist[1]‎ وحتى classlist[29]‎. عند إنشاء تلك المصفوفة، تُهيَئ عناصرها إلى قيمة مبدئية افتراضية تُساوِي القيمة الفارغة null في حالة الكائنات، لذلك يُصبِح لدينا 30 عنصر مصفوفة، كُلًا منها أينعم من النوع Student لكنه يَحتوِي على القيمة الفارغة (null) وليس على كائن فعليّ من النوع Student. ينبغي أن نُنشِئ تلك الكائنات بأنفسنا كالتالي: Student[] classlist; classlist = new Student[30]; for ( int i = 0; i < 30; i++ ) { classlist[i] = new Student(); } وعليه، يُشير كل عنصر مصفوفة classlist‎ إلى كائن من النوع Student أيّ يُمكِن اِستخدَام classlist‎ بأيّ طريقة يُمكِن بها اِستخدَام مُتْغيِّر من النوع Student. فمثلًا، يُمكِن اِستخدَام classlist[3].name للإشارة إلى اسم الطالب المُخْزَّن برقم المَوضِع الثالث. كمثال آخر، يُمكِن استدعاء classlist.getAverage()‎ لحساب متوسط درجات الطالب المُخْزَّن برقم المَوضِع i. ترجمة -بتصرّف- للقسم Section 1: Objects, Instance Methods, and Instance Variables من فصل Chapter 5: Programming in the Large II: Objects and Classes من كتاب Introduction to Programming Using Java.

كما ذَكَرَنا سابقًا، الأسماء هي أحد أركان البرمجة الأساسية. تَتَضمَّن مسألة التَّصْريح (declaring) عن الأسماء واِستخدَامها الكثير من التفاصيل التي تَجنَّبنا غالبيتها إلى الآن، ولكن حان وقت الكشف عن كثير من تلك التفاصيل. حاول التركيز عمومًا على محتوى القسمين الفرعيين "التهيئة أثناء التصريح" و "الثوابت المسماة (named constants)"؛ لأننا سنُعيد الإشارة إليهما باستمرار. التهيئة (initialization) أثناء التصريح (declaration) عندما نُصرِّح عن مُتَغيِّر ما (variable declaration)، يُخصِّص الحاسوب مساحة من الذاكرة لذلك المُتَغيِّر، والتي ينبغي تَهيئتها (initialize) مبدئيًا، بحيث يَتَضمَّن ذلك المُتَغيِّر قيمة معينة قَبْل أي مُحاولة لاِستخدَامه ضِمْن تعبير (expression). عادةً ما ترى تَعْليمَة التَّصْريح (declaration) عن مُتَغيِّر محليّ معين (local variable) مَتبوعة بتَعْليمَة إِسْناد (assignment statement) لغرض تهيئة ذلك المُتَغيِّر مبدئيًا (initialization). على سبيل المثال: int count; // ‫صرح عن المتغير count count = 0; // ‫أسند القيمة 0 إلى المتغير count في الواقع، تستطيع تَضْمِين التهيئة المبدئية (initialization) للمُتَغيِّر بنفس تَعْليمَة التصريح (declaration statement)، أيّ يُمكِن اختصار التَعْليمَتين بالأعلى إلى التَعْليمَة التالية: int count = 0; // ‫صرح عن المتغير count وأسند إليه القيمة 0 سيُنفِّذ الحاسوب ذلك على خطوتين: سيُصرِّح أولًا عن مُتَغيِّر اسمه count، ثم سيُسنِد القيمة صفر إلى ذلك المُتَغيِّر المُنشَئ للتو. ليس ضروريًا أن تَكُون قيمة المُتَغيِّر المبدئية ثابتة (constant)، وإِنما قد تَتَكوَّن من أي تعبير (expression). يُمكِنك أيضًا تهيئة عدة مُتَغيِّرات بتَعْليمَة تَّصْريح واحدة كالتالي: char firstInitial = 'D', secondInitial = 'E'; int x, y = 1; // ‫صالح ولكن أسندت القيمة 1 إلى المتغير y فقط int N = 3, M = N+2; // ‫صالح، هُيأت القيمة N قبل استخدامها لمّا كان المُتَغيِّر المُتحكِّم بحَلْقة معينة (loop control variable) غير مَعنِي بأي شيء يَقَع خارج تلك الحَلْقة عمومًا، كان من المنطقي التَّصْريح عنه ضِمْن ذلك الجزء من البرنامج الذي يَستخدِمُه فعليًا. ولهذا يَشيَع اِستخدَام التَعْليمَة المُختصرة بالأعلى ضِمْن حَلْقات التَكْرار for؛ حيث تُمكِّنك من التَّصْريح عن المُتَغيِّر المُتحكِّم بالحَلْقة، وتَهيئته مبدئيًا بمكان واحد ضِمْن الحَلْقة ذاتها. على سبيل المثال: for ( int i = 0; i < 10; i++ ) { System.out.println(i); } الشيفرة بالأعلى هي بالأساس اختصار لما يَلي: { int i; for ( i = 0; i < 10; i++ ) { System.out.println(i); } } أَضفنا زوجًا إضافيًا من الأقواس حول الحَلْقة -بالأعلى- للتأكيد على أن المُتَغيِّر i قد أصبح مُتَغيِّرًا محليًا (local) لتَعْليمَة الحَلْقة for، أيّ أنه لَمْ يَعُدْ موجودًا بعد انتهاء الحَلْقة. يُمكِنك أيضًا إجراء التهيئة المبدئية (initialize) للمُتَغيِّرات الأعضاء (member variable) أثناء تَّصْريحك عنها (declare)، كما هو الحال مع المُتَغيِّرات المحليّة (local variable). فمثلًا: public class Bank { private static double interestRate = 0.05; private static int maxWithdrawal = 200; . . // المزيد من المتغيرات والبرامج الفرعية . } عندما يُحمِّل مُفسِّر الجافا (Java interpreter) صنفًا معينًا، فإنه يُنشِئ أي مُتَغيِّر عضو ساكن (static member variable) ضِمْن ذلك الصنف، ويُهيِئ قيمته المبدئية (initialization). لمّا كانت تَعْليمَات التَّصْريح (declaration statements) هي النوع الوحيد من التَعْليمَات التي يُمكِن كتابتها خارج أيّ برنامج فرعي (subroutine)، وعليه فإن تَعْليمَات الإِسْناد (assignment statements) غير ممكنة الكتابة خارجها، كان لزامًا تهيئة المُتَغيِّرات الأعضاء الساكنة أثناء التَّصْريح عنها -إذا أردنا القيام بالتهيئة-، فهو في تلك الحالة ليس مُجرَّد اختصار لتَعْليمَة تَّصْريح (declaration) مَتبوعة بتَعْليمَة إِسناد (assignment statement) مثلما هو الحال مع المُتَغيِّرات المحليّة. لاحِظ عدم إِمكانية القيام بالتالي: public class Bank { private static double interestRate; // غير صالح! لا يمكن استخدام تعليمة إسناد خارج برنامج فرعي interestRate = 0.05; . . . لذلك، غالبًا ما يَحتوِي التَّصْريح عن مُتَغيِّر عضو (member variables) على قيمته المبدئية. وكما ذَكَرَنا سلفًا بالقسم الفرعي ٤.٢.٤، فإنه في حالة عدم تَخْصِيص قيمة مبدئية لمُتَغيِّر عضو معين (member variable)، تُسنَد إليه قيمة مبدئية افتراضية. على سبيل المثال، اِستخدَام التَعْليمَة static int count للتَّصْريح عن المُتَغيِّر العضو count هو مُكافِئ تمامًا للتَعْليمَة static int count = 0;‎. نستطيع أيضًا تهيئة مُتَغيِّرات المصفوفة (array variables) مبدئيًا. ولمّا كانت المصفوفة عمومًا مُكوَّنة من عدة عناصر وليس مُجرَّد قيمة وحيدة، تُستخدَم قائمة من القيم، مَفصولة بفاصلة (comma)، ومُحاطة بزوج من الأقواس؛ لتهيئة (initialize) المُتَغيِّرات من ذلك النوع، كالتالي: int[] smallPrimes = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29 }; تُنشِئ التَعْليمَة بالأعلى مصفوفة أعداد صحيحة (array of int)، وتَملؤها بالقيم ضِمْن القائمة. يُحدِّد عدد العناصر بالقائمة طول المصفوفة المُعرَّفة، أيّ أن طولها (length) -في المثال بالأعلى- يُساوِي ١٠. تَقْتصِر صيغة (syntax) تهيئة المصفوفات -يُقصَد بذلك قائمة العناصر- على تَعْليمَات التَّصْريح (declaration statement)، أي بينما نُصرِّح عن مُتَغيِّر مصفوفة (array variable)، ولا يُمكِن اِستخدَامها ضِمْن تَعْليمَات الإِسْناد (assignment statements). تستطيع أيضًا إنشاء مصفوفة باِستخدَام العَامِل new، ثم تَستخدِمها لتهيئة مُتَغيِّر مصفوفة (array variable). لاحِظ أن تلك الصيغة صالحة ضِمْن تَعْليمَات الإِسْناد أيضًا على العَكْس من الصيغة السابقة. على سبيل المثال: String[] nameList = new String[100]; ستَحتوِي جميع عناصر المصفوفة على القيمة الافتراضية في المثال بالأعلى. التصريح عن المتغيرات باستخدام var منذ الإصدار العاشر، تُوفِّر الجافا صيغة (syntax) جديدة للتَّصْريح عن المُتَغيِّرات، باستخدَام كلمة var، بشَّرْط تَخْصيص قيمة مبدئية ضِمْن تَعْليمَة التَّصْريح. تمتلك المُتَغيِّرات المُصرَّح عنها بتلك الطريقة نوعًا محدَّدًا، كأي مُتَغيِّر عادي آخر، ولكن بدلًا من تَحْديد ذلك النوع تحديدًا صريحًا، يعتمد مُصرِّف الجافا (Java compiler) على نوع القيمة المبدئية المُخصَّصة لتَحْديد نوع ذلك المُتَغيِّر. تَقْتصِر تلك الصيغة، مع ذلك، على المُتَغيِّرات المحليّة (local variables)، أي تلك المُصرَّح عنها ضِمْن برنامج فرعي (انظر القسم الفرعي ٤.٢.٤). اُنظر تَعْليمَة التَّصْريح التالية: var interestRate = 0.05; تُستخدَم التَعْليمَة بالأعلى لتعريف (define) مُتَغيِّر محليّ اسمه interestRate بقيمة مبدئية تُساوِي ٠,٠٥، ولمّا كانت القيمة المبدئية المُخصَّصة من النوع double، يَكُون نوع ذلك المُتَغيِّر هو double. بالمثل، للتَّصْريح عن مُتَغيِّر محليّ اسمه nameList من النوع String[]‎، يُمكِنك كتابة التالي: var nameList = new String[100]; تستطيع أيضًا اِستخدَام كلمة var أثناء التَّصْريح عن المُتَغيِّر المُتحكِّم بالحَلْقة (loop control variable) ضِمْن الحَلْقة for، كالتالي: for ( var i = 0; i < 10; i++ ) { System.out.println(i); } قد لا يبدو ذلك مفيدًا في الوقت الحالي، ولكنك ستُدرِك أهميته عندما نَتَعرَّض لما يُعرَف باسم الأنواع المُعمَّمة أو الأنواع المُحدَّدة بمعاملات نوع (parameterized types)، والتي تُعدّ أكثر تعقيدًا. سنتناول تلك الأنواع بكُلًا من القسم ٧.٢، والفصل العاشر. الثوابت المسماة (named constants) في بعض الأحيان، لا يَكُون هناك حاجة لتَعْديل قيمة المُتَغيِّر بَعْد تهيئتها مبدئيًا (initialize). على سبيل المثال، هُيَئ المُتَغيِّر interestRate بالأعلى، بحيث تَكُون قيمته المبدئية مُساوِية للقيمة ٠,٠٥. دَعْنَا نفْترِض أنه لا حاجة لتَعْديل تلك القيمة طوال فترة تَّنْفيذ البرنامج. في مثل تلك الحالات، قد يبدو المُتَغيِّر عديم الفائدة، ولهذا قد تَتَساءل، لماذا قد يُعرِّف (defining) المبرمج ذلك المُتَغيِّر من الأساس؟ في الواقع، يَلجأ المُبرمجين عادةً إلى تعريف تلك المُتَغيِّرات؛ بهدف إعطاء قيمة عددية معينة (٠,٠٥ في هذا المثال) اسمًا له مَغزى، فبخلاف ذلك، ستَكُون القيمة ٠,٠٥ بلا أي مَعنَى؛ فمن الأسهل عمومًا فِهم تَعْليمَة مثل principal += principal*interestRate;‎ بالمُوازنة مع principal += principal*0.05. يُمكِن اِستخدَام المُبدِّل (modifier)‏ final أثناء التَّصْريح عن مُتَغيِّر معين (variable declaration)؛ للتَأكُّد من اِستحالة تَعْديل القيمة المُخزَّنة بذلك المُتَغيِّر بمجرد تَهيئتها (initialize). إذا صَرَّحت، مثلًا، عن المُتَغيِّر العضو interestRate باستخدام التَعْليمَة التالية: public final static double interestRate = 0.05; فسيَستحِيل تَعْديل قيمة ذلك المُتَغيِّر interestRate بأيّ مكان آخر داخل البرنامج، فإذا حَاوَلت، مثلًا، اِستخدَام تَعْليمَة إِسْناد لتَعْديل قيمته، فإن الحاسوب سيُبلِّغ عن وجود خطأ في بناء الجملة (syntax error) أثناء تَصْرِيف (compile) البرنامج. من المنطقي عمومًا اِستخدَام المُبدِّل final مع مُتَغيِّر عام (public) يُمثِل قيمة "مُعدل الفائدة"؛ فبينما يُريد بنك معين الإعلان عن قيمة "مُعدل الفائدة"، فإنه، وبكل تأكيد، لا يُريد أن يَسمَح لأشخاص عشوائية بتَعْديل قيمة "مُعدل الفائدة". تَبرز أهمية المُبدِّل final عند اِستخدَامه مع المُتَغيِّرات الأعضاء، ولكنه مع ذلك، قابل للاِستخدَام مع كلا من المُتَغيِّرات المحليّة (local variables)، والمُعامِلات الصُّوريّة (formal parameters). يُطلَق مصطلح الثوابت المُسمَاة (named constants) على المُتَغيِّرات الأعضاء الساكنة (static member variable) المُصرَّح عنها باِستخدَام المُبدِّل final؛ لأن قيمتها تَظلّ تابثة طوال فترة تَّنْفيذ البرنامج. اِستخدَامك للثوابت المُسمَاة (named constants) قادر على تَحسِّين شيفرة البرامج بشكل كبير، وجَعْلها مَقروءة؛ فأنت بالنهاية تُعطِي أسماء ذات مَغزى للمقادير المُهمة بالبرنامج، ويُوصَى عمومًا بأن تَكُون تلك الأسماء مُكوَّنة بالكامل من حروف كبيرة (upper case letters)، بحيث يَفصِل محرف الشرطة السُفلية (underscore) بين الكلمات إذا ما لَزِم الأمر. على سبيل المثال، يُمكِن تعريف "مُعدَل الفائدة" كالتالي: public final static double INTEREST_RATE = 0.05; يَشيِع اِستخدَام نَمط التسمية بالأعلى عمومًا بأصناف الجافا القياسية (standard classes)، والتي تُعرِّف الكثير من الثوابت المُسمَاة. فمثلًا، تَعرَّضنا بالفعل للمُتَغيِّر Math.PI من النوع double المُعرَّف ضِمْن الصنف Math باِستخدَام المُبدِّلات public final static. بالمثل، يَحتوِي الصَنْف Color على مجموعة من الثوابت المُسمَاة (named constants) مثل: Color.RED و Color.YELLOW، والتي هي مُتَغيِّرات من النوع Color، مُعرَّفة باِستخدَام نفس مجموعة المُبدِّلات public final static. تُعدّ ثوابت أنواع التعداد (enumerated type constants)، والتي تَعرَّضنا لها خلال القسم الفرعي ٢.٣.٣، مثالًا آخرًا للثوابت المُسمَاة. يُمكِننا تعريف تعداد من النوع Alignment كالتالي: enum Alignment { LEFT, RIGHT, CENTER } يُعرِّف ذلك التعداد كُلًا من الثوابت Alignment.LEFT و Alignment.RIGHT و Alignment.CENTER. تقنيًا، يُعدّ Alignment صنفًا (class)، وتُعدّ تلك الثوابت (constants) الثلاثة أعضاء ساكنة عامة ونهائية (public final static) ضِمْن ذلك الصَنْف. في الواقع، يُشبِه تعريف نوع التعداد (enumerated type) بالأعلى تعريف ثلاثة ثوابت من النوع int كالتالي: public static final int ALIGNMENT_LEFT = 0; public static final int ALIGNMENT_RIGHT = 1; public static final int ALIGNMENT_CENTER = 2; وفي الحقيقة، كانت تلك الطريقة هي الأسلوب المُتبَع قبل ظهور أنواع التعداد (enumerated types)، وما تزال في الواقع مُستخدَمة بكثير من الحالات. فبِتَوفُّر ثوابت الأعداد الصحيحة (integer constants) بالأعلى، تستطيع الآن ببساطة تعريف مُتَغيِّر من النوع int، وإِسْناد واحدة من تلك القيم الثلاثة ALIGNMENT_LEFT و ALIGNMENT_RIGHT و ALIGNMENT_CENTER له؛ بهدف تمثيل أنواع مختلفة من التعداد Alignment. مع ذلك هناك مشكلة، وهي عدم إِطلاع الحاسوب على نيتك باِستخدَام ذلك المُتَغيِّر لتمثيل قيمة من النوع Alignment، لذا فإنه لن يَعترِض إذا حاولت إِسْناد قيمة هي ليست ضِمْن تلك القيم الثلاثة الصالحة. في المقابل، ومع ظهور أنواع التعداد (enumerated type)، فإنه إذا كان لديك مُتَغيِّر من نوع التعداد Alignment، فيُمكِنك فقط إِسْناد إحدى تلك القيم الثابتة المُدرجة بتعريف التعداد إليه، وأي محاولة لإِسْناد قيم آخرى غَيْر صالحة ستُعدّ بمثابة خطأ ببناء الجملة (syntax error) سيَكْتَشفها الحاسوب أثناء تَصْرِيف (compile) البرنامج. يُوفِّر ذلك نوعًا من الأمان الإضافي، وهو أحد أهم مميزات أنواع التعداد (enumerated types). يُسهِل استخدام الثوابت المُسمَاة (named constants) من تَعْديل قيمة الثابت المُسمَى. بالطبع، لا يُقصَد بذلك تَعْديلها أثناء تَّنْفيذ البرنامج، وإنما بين تَّنْفيذ معين والذي يليه، أيّ تَعْديل القيمة داخل الشيفرة المصدرية ذاتها ثم إعادة تَصرِيف (recompile) البرنامج. لنُعيد التفكير بمثال "معدل الفائدة"، غالبًا ما ستَكُون قيمة "مُعدَل الفائدة" مُستخدَمة أكثر من مرة عبر شيفرة البرنامج. لنفْترِض أن البنك قد عَدَّل قيمة "معدل الفائدة"، وعليه ينبغي تَعْديلها بالبرنامج. إذا كانت القيمة ٠,٠٥ مُستخدَمة بشكل مُجرَّد ضِمْن الشيفرة، فسيَضطرّ المبرمج لتَعقُّب جميع الأماكن المُستخدِمة لتلك القيمة بحيث يُعدِّلها إلى القيمة الجديدة. يَصعُب القيام بذلك خصوصًا مع احتمالية اِستخدَام القيمة ٠,٠٥ داخل البرنامج لأهداف مختلفة غير "مُعدَل الفائدة"، بالإضافة إلى احتمالية اِستخدَام القيمة ٠,٠٢٥ مثلًا لتمثيل نصف قيمة "مُعدَل الفائدة". في المقابل، إذا كنا قد صَرَّحنا عن الثابت المُسمَى INTEREST_RATE ضِمْن البرنامج، واستخدَمناه بصورة مُتَّسقِة عبر شيفرة البرنامج بالكامل، فسنحتاج إلى تعديل سطر وحيد فقط هو سَطْر التهيئة المبدئية لذلك الثابت. لنأخذ مثالًا آخر من القسم السابق، سنُعيد خلاله كتابة نسخة جديدة من البرنامج RandomMosaicWalk. ستَستخدِم تلك النسخة عدة ثوابت مُسمَاة (named constants) بهدف تمثيل كُلًا من عدد الصفوف، وعدد الأعمدة، وحجم كل مربع صغير بنافذة الصَنْف mosaic. سيُصرَّح عن تلك الثوابت (constants) الثلاثة كمُتَغيِّرات أعضاء ساكنة نهائية (final static member) كالتالي: final static int ROWS = 20; // عدد صفوف النافذة final static int COLUMNS = 30; // عدد أعمدة النافذة final static int SQUARE_SIZE = 15; // حجم كل مربع بالنافذة عُدِّل أيضًا باقي البرنامج بحرِص بحيث يتلائم مع الثوابت المُسمَاة (named constants) المُعرَّفة، فمثلًا، لفَتْح نافذة Mosaic بالنسخة الجديدة من البرنامج، يُمكِن استخدام التَعْليمَة التالية: Mosaic.open(ROWS, COLUMNS, SQUARE_SIZE, SQUARE_SIZE); ليس من السهل دومًا العُثور على جميع تلك الأماكن التي يُفْترَض بها اِستخدَام ثابت مُسمَى معين. لذا، انتبه! ففي حالة عدم اِستخدَامك لثابت مُسمَى معين بصورة مُتَّسقِة عبر شيفرة البرنامج بالكامل، فأنت تقريبًا قد أَفسدت الهدف الأساسي منه. لذلك يُنصَح عادة بتجربة البرنامج عدة مرات، بحيث تَستخدِم قيمة مختلفة للثابت المُسمَى (named constant) في كل مرة؛ لاِختبار كَوْنه يَعَمَل بصورة سليمة بجميع الحالات. اُنظر النسخة الجديدة من البرنامج كاملة RandomMosaicWalk2 بالأسفل. لاحظ كيفية اِستخدَام الثابتين ROWS و COLUMNS داخل البرنامج randomMove()‎ عند تحريكه للتشويش (disturbance) من إحدى حواف النافذة mosaic إلى الحافة المضادة. لم تُضاف التعليقات (comments) لغرض تَوْفِير المساحة. public class RandomMosaicWalk2 { final static int ROWS = 20; // عدد الصفوف بالنافذة final static int COLUMNS = 30; // عدد الأعمدة بالنافذة final static int SQUARE_SIZE = 15; // حجم كل مربع بالنافذة static int currentRow; // رقم الصف المعرض للتشويش static int currentColumn; // رقم العمود المعرض للتشويش public static void main(String[] args) { Mosaic.open( ROWS, COLUMNS, SQUARE_SIZE, SQUARE_SIZE ); fillWithRandomColors(); currentRow = ROWS / 2; // ابدأ بمنتصف النافذة currentColumn = COLUMNS / 2; while (true) { changeToRandomColor(currentRow, currentColumn); randomMove(); Mosaic.delay(5); } } // نهاية‫ main static void fillWithRandomColors() { for (int row=0; row < ROWS; row++) { for (int column=0; column < COLUMNS; column++) { changeToRandomColor(row, column); } } } // نهاية‫ fillWithRandomColors static void changeToRandomColor(int rowNum, int colNum) { // اختر قيم عشوائية تتراوح بين 0 و 255 // لقيم الألوان الثلاثة (الأحمر، و الأزرق، والأخضر‫) // ‫بنظام الألوان RGB int red = (int)(256*Math.random()); int green = (int)(256*Math.random()); int blue = (int)(256*Math.random()); Mosaic.setColor(rowNum,colNum,red,green,blue); } // نهاية‫ changeToRandomColor static void randomMove() { // ‫اضبط القيمة عشوائيًا بحيث تتراوح من 0 وحتى 3 int directionNum; directionNum = (int)(4*Math.random()); switch (directionNum) { case 0: // تحرك للأعلى currentRow--; if (currentRow < 0) currentRow = ROWS - 1; break; case 1: // تحرك لليمين currentColumn++; if (currentColumn >= COLUMNS) currentColumn = 0; break; case 2: // تحرك للأسفل currentRow++; if (currentRow >= ROWS) currentRow = 0; break; case 3: // تحرك لليسار currentColumn--; if (currentColumn < 0) currentColumn = COLUMNS - 1; break; } } // ‫نهاية randomMove } // نهاية الصنف‫ RandomMosaicWalk2 التسمية وقواعد النطاق (scope rules) عندما نُصرِّح عن مُتَغيِّر ما (variable declaration)، يُخصِّص الحاسوب مساحة من الذاكرة لذلك المُتَغيِّر. بحيث تستطيع اِستخدَام اسم ذلك المُتَغيِّر ضِمْن جزء معين على الأقل من شيفرة البرنامج؛ بهدف الإشارة إلى تلك المساحة من الذاكرة أو إلى تلك البيانات المُخزَّنة بها. يُطلَق على ذلك الجزء من الشيفرة، والذي يَكُون فيه اسم المُتَغيِّر صالحًا للاِستخدَام، اسم نطاق المُتَغيِّر (scope of variable). بالمثل، يُمكِن الإشارة إلى نطاق كُلًا من أسماء البرامج الفرعية (subroutine) وأسماء المُعامِلات الصُّوريّة (formal parameter). لنبدأ بالأعضاء الساكنة من البرامج الفرعية، والتي تُعدّ قواعد نطاقها (scope rule) بسيطة نوعًا ما. يَمتد نطاق (scope) أي برنامج فرعي ساكن إلى كامل الشيفرة المصدرية للصَنْف (class) المُعرَّف بداخله، أيّ يُمكِن استدعاء ذلك البرنامج الفرعي من أيّ مكان داخل الصنف، بما في ذلك تلك الأماكن الواقعة قَبْل تعريف (definition) البرنامج الفرعي. بل أنه حتى من المُمكن لبرنامج فرعي معين استدعاء ذاته، وهو ما يُعرَف باسم التَعاود أو الاستدعاء الذاتي (recursion)، وهو أحد المواضيع المتقدمة نسبيًا، وسنتناوله عمومًا بالقسم ٩.١. وأخيرًا، إذا لم يَكُن البرنامج الفرعي خاصًا (private)، فتستطيع حتى الوصول إليه من خارج الصَنْف المُعرَّف بداخله بشَّرْط اِستخدَام اسمه الكامل. لننتقل الآن إلى الأعضاء الساكنة من المُتَغيِّرات، والتي تَملُك قواعد نطاق (scope rule) مشابهة بالإضافة إلى تعقيد واحد إضافي هو كالآتي. تستطيع عمومًا تعريف مُتَغيِّر محليّ (local variable) أو مُعامِل صُّوريّ (formal parameter) يَحمِل نفس اسم إحدى المُتَغيِّرات الأعضاء (member variable) ضِمْن الصَنْف، وفي تلك الحالة، يُعدّ المُتَغيِّر العضو مخفيًا ضِمْن نطاق المُتَغيِّر المحليّ أو المُعامِل الذي يَحمِل نفس الاسم. فعلى سبيل المثال، إذا كان لدينا الصَنْف Game كالتالي: public class Game { static int count; // متغير عضو static void playGame() { int count; // متغير محلي . . // ‫بعض التعليمات لتعريف playGame() . } . . // المزيد من المتغيرات والبرامج الفرعية . } // ‫نهاية الصنف Game يُشير الاسم count بالتَعْليمات المُؤلِّفة لمَتْن (body) البرنامج الفرعي playGame()‎ إلى المُتَغيِّر المحليّ (local variable). أما ببقية الصنف Game، فإنه سيُشيِر إلى المُتَغيِّر العضو (member variable)، بالطبع إذا لم يُخفَى باستخدام مُتَغيِّر محليّ آخر أو مُعامِلات تَحمِل نفس الاسم count. مع ذلك، ما يزال بإمكانك الإشارة إلى المُتَغيِّر العضو count بواسطة اسمه الكامل Game.count، والذي يُستخدَم، في العادة، خارج الصَنْف الذي عُرِّف به العضو، ولكن ليس هناك قاعدة تَمنع اِستخدَامه داخل الصنف. لهذا يُمكِن اِستخدَام الاسم الكامل Game.count داخل البرنامج الفرعي playGame()‎ للإشارة إلى المُتَغيِّر العضو بدلًا من المُتَغيِّر المحليّ. يُمكِننا الآن تلخيص قاعدة النطاق (scope rule) كالآتي: يَشمَل نطاق مُتَغيِّر عضو ساكن الصنف المُعرَّف بداخله بالكامل، وعندما يُصبِح الاسم البسيط (simple name) للمُتَغيِّر العضو مَخفيًا نتيجة تعريف مُتَغيِّر محليّ أو مُعامِل صُّوريّ يَحمِل نفس الاسم، يُصبِح من الضروري اِستخدَام الاسم الكامل على الصورة . للإشارة إلى المُتَغيِّر العضو. تُشبِه قواعد نطاق الأعضاء غير الساكنة (non-static) عمومًا تلك الخاصة بالأعضاء الساكنة، باستثناء أن الأولى لا يُمكِن اِستخدَامها بالبرامج الفرعية الساكنة (static subroutines)، كما سنرى لاحقًا. أخيرًا، يَتَكوَّن نطاق المُعامِل الصُّوريّ (formal parameter) لبرنامج فرعي معين من الكُتلَة (block) المُؤلِّفة لمَتْن البرنامج الفرعي (subroutine body). في المقابل، يَمتَد نطاق المُتَغيِّر المحليّ (local variable) بدايةً من تَعْليمَة التَّصْريح (declaration statement) المسئولة عن تعريف ذلك المُتَغيِّر وحتى نهاية الكُتلَة (block) التي حَدَثَ خلالها ذلك التَّصْريح. كما أشرنا بالأعلى، تستطيع التَّصْريح عن المُتَغيِّر المُتحكِّم بحَلْقة (loop control variable)‏ for ضمن التعليمة ذاتها على الصورة for (int i=0; i < 10; i++)‎، ويُعدّ نطاق مثل هذا التَّصْريح (declaration) حالة خاصة: فهو صالح فقط ضِمْن تَعْليمَة for، ولا يَمتَد إلى بقية الكُتلَة المتضمنة للتَعْليمَة. لا يُسمَح عمومًا بإعادة تعريف (redefine) اسم المُعامِل الصُّوريّ أو المُتَغيِّر المحليّ ضِمْن نطاقه (scope)، حتى إذا كان ذلك داخل كُتلَة مُتداخِلة (nested block)، كالتالي: void badSub(int y) { int x; while (y > 0) { int x; // ‫خطأ، لأن x مُعرَّفة بالفعل . . . } } في الواقع، تَسمَح بعض اللغات بذلك، بحيث يُخفِي التَّصْريح عن x ضِمْن حَلْقة while التَّصْريح الأصلى، ولكن لا تَسمَح الجافا بذلك، حيث يُصبِح اسم المُتَغيِّر متاحًا للاِستخدَام مرة آخرى فقط بعد انتهاء تَّنْفيذ الكُتلَة (block) المُصرَّح عن المُتَغيِّر ضِمْنها. اُنظر على سبيل المثال: void goodSub(int y) { while (y > 10) { int x; . . . // ينتهي نطاق‫ x هنا } while (y > 0) { int x; // ‫صالح، فتَّصريح x السابق انتهت صلاحيته . . . } } هل تَتَسبَّب أسماء المُتَغيِّرات المحليّة (local variable) بإخفاء أسماء البرامج الفرعية (subroutine names)؟ لا يُمكِن حُدوث ذلك لسبب قد يبدو مفاجئًا. ببساطة، لمّا كانت أسماء البرامج الفرعية دومًا مَتبوعة بزوج من الأقواس (parenthesis)، والتي يُسْتحسَن التفكير بها على أساس أنها جزء من اسم البرنامج الفرعي، كأن تقول البرنامج الفرعي main()‎ وليس البرنامج الفرعي main، فإن الحاسوب عمومًا يُمكِنه دائمًا مَعرِفة ما إذا كان اسم معين يُشير إلى مُتَغيِّر أم إلى برنامج فرعي، لذا ليس ضروريًا أن تكون أسماء المُتَغيِّرات والبرامج الفرعية مختلفة من الأساس، حيث يُمكِنك ببساطة تعريف مُتَغيِّر اسمه count وبرنامج فرعي بنفس الاسم count ضِمْن نفس الصَنْف. كذلك لمّا كان الحاسوب قادرًا على مَعرِفة ما إذا كان اسم معين يُشير إلى اسم صَنْف أم لا وِفقًا لقواعد الصيغة (syntax)، فإنه حتى يُمكِن إعادة اِستخدَام أسماء الأصناف (classes) بهدف تسمية كلا من المُتَغيِّرات والبرامج الفرعية. اسم الصنف هو بالنهاية نوع، لذا يُمكِن اِستخدَام ذلك الاسم للتََّصْريح عن المُتَغيِّرات والمُعامِلات الصُّوريّة (formal parameters)، بالإضافة إلى تَخْصيص نوع القيمة المُعادة (return type) من دالة (function) معينة. يَعنِي ذلك أنك تستطيع التََّصْريح عن الدالة التالية ضِمْن صَنْف اسمه Insanity: static Insanity Insanity( Insanity Insanity ) { ... } يَستخدِم التََّصْريح -بالأعلى- الاسم Insanity ٤ مرات، تُشير الأولى إلى النوع المُعاد (return type) من الدالة، بينما تُشير الثانية إلى اسم تلك الدالة، والثالثة إلى نوع مُعاملها الصُّوريّ (formal parameter)، والرابعة إلى اسم ذلك المُعامِل. لكن تَذَكَّر! لا يُعدّ كل ما هو مُتاح فكرة جيدة بالضرورة. ترجمة -بتصرّف- للقسم Section 8: The Truth About Declarations من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

قُدرتك على اِستيعاب طريقة عمل البرامج، وفهمها هو أمر جيد بلا شك، ولكنه يختلف تمامًا عن تَصميمها بحيث تُنفِّذ مُهِمّة معينة. لقد ناقشنا بالقسم ٣.٢ كيفية تَطْوير الخوارزميات بطريقة مَنهجية باستخدام أسلوب التصميم المُتدرج (stepwise refinement) والشيفرة الوهمية (pseudocode). التصميم المُتدرج هو عملية تَقَع ضِمْن استراتيجيات التصميم من أعلى لأسفل (top-down)، أيّ لابُدّ عمومًا من وجود نقطة معينة تَتَوقَّف عندها عن عملية التحسِّين التدريجي لخوارزمية الشيفرة الوهمية (pseudocode algorithm)، وتُحوِّل عندها تلك الخوارزمية مباشرة إلى شيفرة برنامج فعليّة. بدون البرامج الفرعية (subroutines)، ستُمثِل تلك النقطة مستوًى بدائيًا جدًا من العمليات، كتَعْليمَات الإِسْناد (assignment statements)، وعمليات الدَخْل والخَرْج، أما في حالة تَوفُّر البرامج الفرعية المسئولة عن إنجاز بعض المَهَامّ (tasks) المُحدَّدة، فسيَكُون بإمكانك التَوقُّف عن التحسِّين بمجرد تعبيرك عن الخوارزمية بنفس المصطلحات التي تَستخدِمها البرامج الفرعية. يَعنِي ذلك أننا قد أضفنا عنصر، هو بالأساس يَتَّبِع أسلوب التصميم من أسفل لأعلى (bottom-up)، إلى استراتيجيات التصميم من أعلى لأسفل (top-down approach) الخاصة بالتصميم المُتدرج. بفَرْض وجود مشكلة معينة، تستطيع الآن البدء بكتابة بعض البرامج الفرعية (subroutines) المسئولة عن إنجاز بعض المَهَامّ المُتَعلِّقة بموضوع البرنامج، بحيث تُصبِح تلك البرامج بمثابة صندوق من الأدوات الجاهزة (toolbox) يُمكِنك دَمْجها إلى الخوارزمية أثناء تَطْويرها، أو حتى قد تستطيع شراء صندوق أدوات برمجي جاهز (software toolbox)، كُتب بواسطة شخص آخر، بحيث يَتَضمَّن ذلك الصندوق مجموعة من البرامج الفرعية، التي ستَكُون بمثابة صندوقًا أسودًا (black boxes)، يُمكِنك تَوظِّيفه ضِمْن المشروع الخاص بك. بإمكانك حتى استخدام البرامج الفرعية مباشرة ضِمْن أساليب التصميم من أعلى لأسفل (top-down approach) الأكثر صرامة، بمعنى أنه وبينما تُحسِّن الخوارزمية بالطريقة المُعتادة، يُمكِنك أن تُعبر عن مُهِمّة فرعية (sub-task) معينة ضِمْن الخوارزمية بصورة استدعاء لبرنامج فرعي. يُصبِح تَطْوير ذلك البرنامج الفرعي عندها مشكلة مُستقلة تستطيع العمل عليها بشكل منفصل. لا يَتَعدَى اتباع تلك الطريقة أكثر من مُجرَّد تَقسِّيم للمشكلة الرئيسية إلى مشكلات صغيرة مُنفصلة، أيّ أنها ما تزال تَقَع ضِمْن استراتيجيات التصميم من أعلى لأسفل؛ لأن تحليلك للمشكلة هو الذي وَجَّهك لكتابة البرامج الفرعية. في المقابل، تَبدأ استراتيجيات التصميم من أسفل لأعلى (bottom-up approach) بكتابة البرامج الفرعية المُتَعلِّقة بموضوع البرنامج، أو الحصول عليها بطريقة ما، بحيث تَعَمَل تلك البرامج الفرعية بمثابة أساس أو قاعدة تُستخدَم لبناء حل للمشكلة الأساسية. الشروط المسبقة (precondition) والشروط اللاحقة (postcondition) تَعََمَل البرامج الفرعية (subroutines) عمومًا كلَبِنات أساسية (building blocks) ضِمْن البرنامج الأساسي، لذا لابُدّ أن تَكُون طريقة تَفْاعُلها مع ذلك البرنامج واضحة. تُحدِّد المواصفة الاصطلاحية (contract) لأيّ برنامج فرعي عمومًا طريقة التَفْاعُل تلك، وهو ما ناقشناه بالقسم ٤.١، ويُمكِن كتابتها باِستخدَام ما يُعرَف باسم الشروط المُسَبَّقة (precondition) واللاحقة (postcondition). لابُدّ أن تَكُون الشروط المُسَبَّقة (precondition) لأي برنامج فرعي (subroutine) مُتحقِّقة عند استدعائه. على سبيل المثال، إحدى الشروط المُسَبَّقة (precondition) للدالة Math.sqrt(x)‎ المبنية مُسْبَّقًا (built-in function) يَتمثَل في ضرورة أن تَكُون القيمة المُمرَّرة للمُعامِل (parameter)‏ x أكبر من أو تُساوِي الصفر؛ لأنه لا يُمكِن بطبيعة الحال حِسَاب الجذر التربيعي لعدد سالب. عمومًا، يُمثِل الشَّرْط المُسَبَّق (precondition) بمواصفة اصطلاحية معينة إلزامًا على مُستدعِي (caller) البرنامج الفرعي، أيّ أنه في حالة استدعائك لبرنامج فرعي معين دون تَوْفِية شَّرْطه المُسَبَّق، فما من سبب يَدْفَعك لتَوقع إِنجازه للمُهِمّة بشكل ملائم، فلرُبما يَنهار البرنامج أو يَكتفِي بإعادة نتائج غير صحيحة؛ لأنك ببساطة لم تَلتزِم بجانبك من الاتفاق، ولهذا لا تَلوّمن إلا نفسك. في المقابل، الشروط اللاحقة (postcondition) هي بمثابة الجانب الآخر من المواصفة الاصطلاحية (contract)، حيث تُمثِل إلزامًا على البرنامج الفرعي ذاته، أي بفَرْض اِستيفاء الشروط المُسَبَّقة (preconditions) لبرنامج فرعي معين، وعدم احتوائه على أية أخطاء برمجية (bugs)، فلابُدّ من تَحقُّق شروطه اللاحقة بعد الاستدعاء. على سبيل المثال، الشَّرْط اللاحق للدالة Math.sqrt(x)‎ يَتمثَل في ضرورة تَساوِي كُلًا من مربع القيمة المُعادة من تلك الدالة (function) وقيمة المُعامِل (parameter) المُمرَّرة عند استدعاء البرنامج الفرعي، وهو ما سيَكُون صحيحًا فقط في حالة استيفاء شَّرْطها المُسَبَّق بخصوص كَوْن قيمة المُعامِل أكبر من أو تُساوِي الصفر. مثال آخر هو البرنامج الفرعي System.out.print(x)‎ المَبنِي مُسْبَّقًا، والذي يَتَمثَل شَّرْطه اللاحق (postcondition) بطباعة قيمة مُعامِله (parameter) المُمرَّرة على الشاشة. عادة ما تَضَع الشروط المُسَبَّقة (preconditions) لأي برنامج فرعي قيودًا على قيم مُعاملاته، مثل البرنامج الفرعي Math.sqrt(x)‎، لكن لا يَقْتصِر دورها في الواقع على ذلك. قد تُشيِر تلك الشروط أيضًا إلى المُتَغيِّرات العامة (global variables) المُستخدَمة بالبرنامج الفرعي، أو قد تُحدِّد الحالة (state) التي ينبغي أن يَكُون عليها البرنامج عند استدعاء البرنامج الفرعي، وهو ما يَكُون مفيدًا إذا كانت عملية استدعاء ذلك البرنامج صالحة فقط بأوقات معينة. من الناحية الآخرى، يُحدِّد الشَّرْط اللاحق (postcondition) لأي برنامج فرعي مُهِمّته المُوكَلة إليه. فمثلًا، ينبغي أن يَتضمَّن الشَّرْط اللاحق لأي دالة (function) القيمة المُعادة منها. تُوصَف البرامج الفرعية أحيانًا باِستخدَام تعليقات (comments)، والتي ينبغي أن تُحدِّد شروط ذلك البرنامج المُسَبَّقة (preconditions) واللاحقة (postconditions). عندما تَستخدِم برنامجًا فرعيًا (subroutine) مكتوب مُسْبَّقًا، ستُخبرك تلك الشروط بكيفية اِستخدَام البرنامج بالإضافة إلى تِبيان الغرض منه. في المقابل، عندما تَكْتُب برنامجًا فرعيًا، ستَمنَحك تلك الشروط توصيفًا دقيقًا عما هو مُتوقَّع من ذلك البرنامج. سنَتَعرَّض خلال القسمين الفرعيين التاليين لمثال بسيط، سنَستخدِم فيه التعليقات لهذا الغرض، وستَكُون مَكْتوبة بصياغة تعليقات Javadoc مع عَنونة كُلًا من الشروط المُسَبَّقة واللاحقة. يرى كثير من علماء الحاسوب ضرورة إضافة وُسوم تَوْثيق جديدة ‎@precondition و ‎@postcondition إلى نظام Javadoc لعَنونة الشروط المُسَبَّقة واللاحقة بشكل صريح، ولكن لَمْ يَحدُث ذلك حتى الآن. مثال عن عملية التصميم سنُصمِّم الآن برنامجًا بالاعتماد على البرامج الفرعية بصورة أساسية، بمعنى أننا سنَستخدِم بعض البرامج الفرعية (subroutines) التي سُبق كتابتها كلَبِنة أساسية (building block)، كما أننا سنُصمِّم بعض البرامج الفرعية الجديدة التي قد نحتاجها لإكمال المشروع. فيما يَتعلَّق بالبرامج المَكْتوبة مُسْبَّقًا، سنَستخدِم واجهة برمجة تطبيقات (API) تَحتوِي على صنفين (classes) -كان الكاتب قد كَتَبَهما-، الصَنْف الأول هو Mosaic.java والذي بدوره يَعتمِد على الصنف الثاني MosaicCanvas.java. لاحظ ضرورة تَوفِّير كُلًا من الصنفين Mosaic و MosaicCanvas أثناء تَصْرِيف (compile) البرنامج وتَشْغِيله، مما يَعنِي وجود الملفين Mosaic.java و MosaicCanvas.java -أو ملفات الصَنْفين بَعْد التَصْرِيف- بنفس مجلد الصَنْف المُعرِّف للبرنامج. يَسمَح لك الصَنْف Mosaic بالتَعْامُل مع نافذة (window) مُكوَّنة من مجموعة من المستطيلات الصغيرة المُلوَّنة، والمُرَتَّبة بصورة صفوف وأعمدة، حيث يَتضمَّن أكثر من عضو برنامج فرعي ساكن (static member subroutines) يُمكِن اِستخدَامها لأغراض فَتْح النافذة، وغَلْقها، بالإضافة إلى التَلاعب بمُحتوياتها. يُوفِّر الصَنْف بطبيعة الحال صندوق أدوات (toolbox) أو واجهة برمجة تطبيقات (API) تَتضمَّن تلك المجموعة من البرامج (routines)، والتي نسْتَعْرِض بالأسفل بعضًا منها، مُوثَّقة باِستخدَام تعليقات Javadoc. تَذَكَّر أن تعليق Javadoc يَسبِق العنصر المَعنِي بذلك التعليق. /** * ‫افتح نافذة mosaic على الشاشة * ‫ينبغي أن يُستدعى هذا التابع قبل أي تابع آخر ضمن الصنف Mosaic * سينتهي البرنامج عندما يغلق المستخدم النافذة * * ‫الشرط المسبق: المعاملات rows و cols و h و w هي أعداد صحيحة موجبة * * ‫‫الشرط اللاحق: تفتح نافذة على الشاشة والتي يمكنها عرض صفوف وأعمدة * ‫من المستطيلات الملونة بحيث يكون عرض المستطيل يساوي w وطوله يساوي h * ‫كما أن عدد الصفوف هو قيمة المعامل الأول الممررة بينما عدد الأعمدة * هو قيمة المعامل الثاني. مبدئيًا، تكون جميع المستطيلات سوداء * * ‫ملحوظة: الصفوف مرقمة من 0 وحتى rows - 1 بينما الأعمدة مرقمة * ‫من 0 وحتى cols - 1 */ public static void open(int rows, int cols, int h, int w) /** * ضبط لون أحد مربعات النافذة * * ‫الشرط المسبق: لابد أن كون المعاملين row و col ضمن النطاق المسموح * ‫به لرقمي الصف والعمود، كما لابد أن تقع كلا من المعاملات r و g و b ‫بين العددين 0 و 255 * الشرط اللاحق: سيضبط لون المربع المخصص عن طريق رقمي الصف والعمود * الممررين إلى اللون المحدد عبر المعاملات الثلاثة‫ r و g و b * بحيث تعطي هذه المعاملات قيم اللون الأحمر والأخضر والأخضر * بنظام‫ RGB للمربع، قمثلًا يعطي المعامل r قيمة اللون الأحمر بحيث * تشير القيمة 0 إلى انعدام اللون الأحمر بينما تشير القيمة 255 إلى أكبر قدر ممكن من اللون */ public static void setColor(int row, int col, int r, int g, int b) /** * ‫جلب قيمة اللون الأحمر بنظام RGB لأحد المربعات * * ‫الشرط المسبق: لابد أن يقع كُلا من المعاملين row و col ضمن النطاق المسموح به * ‫الشرط اللاحق: إعادة قيمة اللون الأحمر بنظام RGB للمربع المخصص * ‫كعدد صحيح يقع بين العددين 0 و 255 */ public static int getRed(int row, int col) /** * ‫تعمل بنفس طريقة الدالة getRed */ public static int getGreen(int row, int col) /** * ‫تعمل بنفس طريقة الدالة getRed */ public static int getBlue(int row, int col) /** * لإبطاء تنفيذ البرنامج عبر الانتظار قليلًا * * الشرط المسبق: لابد أن يكون المعامل‫ milliseconds عددا موجبا * ‫الشرط اللاحق: سيتوقف البرنامج مؤقتًا لمدة تساوي الزمن الممرر * بوحدة المللي ثانية */ public static void delay(int milliseconds) تَذَكَّر أن البرامج الفرعية -بالأعلى- هي أعضاء (members) ضِمْن الصَنْف Mosaic، ولهذا ينبغي أن تَتضمَّن أسماء تلك البرامج (routine) اسم الصَنْف ذاته عند اِستدعائها بمكان يَقَع خارج الصنف Mosaic. على سبيل المثال، اِستخدِم الاسم Mosaic.isOpen()‎ بدلًا من الاسم isOpen. لا تُحدِّد تعليقات البرامج الفرعية -بالأعلى- ما سيَحدُث في حالة عدم استيفاء شروطها المُسَبَّقة (preconditions). على الرغم من أن البرامج الفرعية (subroutine)، في العموم، غير مُلزَمة فعليًا بما هو مَكْتوب ضِمْن مواصفاتها الاصطلاحية (contract)، فسيَكُون من الجيد مَعرِفة ما سيَحدُث في مثل تلك الحالات. على سبيل المثال، يُبلِّغ البرنامجين الفرعيين setColor()‎ أو getRed()‎ عن حُدوث اعتراض من النوع IllegalArgumentException في حالة عدم استيفاء شَّرْطهما المُسَبَّق: "ضرورة وقوع كلًا من row و col ضِمْن النِطاق المَسموح به لرَقمي الصف والعمود على الترتيب." تَسمَح مَعرِفتك لمثل تلك الحقيقة بكتابة برامج يُمكِنها التقاط (catch) ذلك الاعتراض (exception)، ومُعالجته، ولهذا سيَكُون من المفيد تَوْثيق (document) تلك المعلومة من خلال إضافة الوَسْم التوثيقي (doc tag)‏ ‎@throws‎ إلى تعليق Javadoc. تَتَبقَّى أسئلة آخرى عديدة تَتَعلَّق بكيفية تَصرُّف البرنامج الفرعي ضِمْن حالات معينة. على سبيل المثال، ماذا سيَحدُث إذا استدعينا البرنامج الفرعي Mosaic.open()‎ بينما هنالك نافذة مفتوحة بالفعل على الشاشة؟ في تلك الحالة، سيتجاهل البرنامج الفرعي عملية الاستدعاء الثانية. في الواقع، يَصعُب عادة إعداد تَوْثيق كامل على تلك الشاكلة، وأحيانًا ستحتاج إلى مُجرَّد تجربة حالة معينة لترى بنفسك كيفية تَصرُّفها، أو قد تَضطرّ أحيانًا للإطلاع على كامل الشيفرة المصدرية (source code) في حالة تَوفُّرها. تَتلخَّص فكرة البرنامج الذي سنقوم بتَطويره بكتابة تحريكة (animation) تَعتمِد على الصنف Mosaic. ببساطة، سنَملْئ نافذة بمربعات مُلوَّنة عشوائيًا، وبعدها، سنُغيِّر تلك الألوان عشوائيًا ضِمْن حَلْقة تَكْرار (loop) تستمر طالما كانت النافذة مفتوحة. قد تَعنِي عبارة "تَغْيِير الألوان عشوائيًا" الكثير من الأشياء المختلفة. المقصود هنا هو إِحداث ما يُشبِه "تشويش (disturbance)" يتحرك عبر النافذة، بحيث يُغيِّر ذلك التشويش من لون أيّ مربع يُواجهه. تُوضِح الصورة التالية ما قد تبدو عليه النافذة بلحظة معينة: مع اعتمادنا على البرامج الفرعية (routines) ضِمْن الصنف Mosaic، نستطيع كتابة التَصوُّر المَبدئي للبرنامج كالتالي: // ‫افتح نافذة Mosaic Open a Mosaic window // اِملئ النافذة بألوان عشوائية Fill window with random colors // تجول وغير لون المربعات عشوائيًا Move around, changing squares at random تبدو الخطوة "اِملئ النافذة بألوان عشوائية" كمُهِمّة (task) مُترابطة يُمكِن فصلها بصورة مستقلة، ولهذا سنَكتُب برنامجًا فرعيًا (subroutine) يَتولَى مسئولية تَّنْفيذ تلك المُهِمّة. في المقابل، يُمكِن إضافة مزيد من التفاصيل للخطوة الثالثة بحيث تُكتَب على عدة خطوات: اِبدأ من منتصف النافذة، ثُمَّ اِستمر بالتحرك إلى مربعات جديدة، وغَيّر لون تلك المربعات. ينبغي الاستمرار بتَّنْفيذ تلك الخطوات طالما كانت النافذة مفتوحة. يُمكِننا إعادة كتابة الخوارزمية (algorithm) لتُصبِح كالتالي: // ‫افتح نافذة Mosaic Open a Mosaic window // اِملئ النافذة بألوان عشوائية Fill window with random colors // اضبط المَوضع الحالي إلى المربع بمنتصف النافذة Set the current position to the middle square in the window // طالما كانت النافذة مفتوحة As long as the mosaic window is open: // غير لون المربع بالمَوضع الحالي عشوائيًا Randomly change color of the square at the current position // حرك الموضع الحالي لأعلى أو لأسفل أو لليسار أو لليمين عشوائيًا Move current position up, down, left, or right, at random سنَستخدِم مُتَغيِّرين من النوع الصحيح int هما currentRow و currentColumn؛ لتَمثيِل "المَوْضِع الحالي (current position)"، سيَحمِلان رقمي الصف (row number) والعمود (column number) للمربع الحالي الذي يُطبَق عليه التشويش (disturbance). لما كانت نافذة mosaic مُكوَّنة من ١٦ صف و ٢٠ عمود من المربعات، يُمكِننا تهيئة قيمة "المَوضِع الحالي" المَبدئية إلى منتصف النافذة عن طريق ضَبْط المُتَغيِّرين currentRow و currentColumn إلى القيمتين ٨ و ١٠ على الترتيب. سنَلجأ لاستخدام البرنامج الفرعي Mosaic.open()‎ لفَتْح النافذة، كما سنَكتُب برنامجين فرعيين (subroutines) إضافيين لإِنجاز مُهِمّتين ضِمْن حَلْقة التَكْرار while بحيث يَظلّ البرنامج main()‎ بسيطًا. نستطيع الآن تَحْوِيل الخوارزمية (algorithm) إلى الشيفرة التالية بلغة الجافا: Mosaic.open(16,20,25,25) fillWithRandomColors(); currentRow = 8; // الصف الواقع بمنتصف النافذة currentColumn = 10; // العمود الواقع بمنتصف النافذة while ( true ) { // ينتهي البرنامج عند غلق النافذة changeToRandomColor(currentRow, currentColumn); randomMove(); } سنُجرِي أيضًا تَعْديلًا إضافيًا، وهو إِبطاء التحريكة (animation) قليلًا، ولذلك سنُضِيف السطر Mosaic.delay(10);‎ إلى حَلْقة التَكْرار while. انتهينا الآن من إِعداد البرنامج main()‎، لكننا نَحتاج لكتابة البرامج الفرعية fillWithRandomColors()‎ و changeToRandomColor(int,int)‎ و randomMove()‎ لنُكمِل البرنامج. تُعدّ عملية كتابة كل برنامج منها بمَثابة مُهِمّة صغيرة مُنفصلة. سنبدأ بالبرنامج الفرعي fillWithRandomColors()‎ والمَسئول عن ضمان تَحقُّق الشَّرْط اللاحق (postcondition) التالي: "سيَتغيَّر لون كل مربع بالنافذة عشوائيًا." يُمكِننا كتابة خوارزمية (algorithm) لإِنجاز تلك المُهِمّة بأسلوب الشيفرة الوهمية (pseudocode) كالتالي: // لكل صف For each row: // لكل عمود For each column: // غير لون المربع بذلك الصف والعمود إلى لون عشوائي set the square in that row and column to a random color يُمكِن تَّنْفيذ (implement) السَطْرين "لكل صف"، و"لكل عمود" -بالأعلى- باِستخدَام حَلْقة التَكْرار for. أما بخصُوص السطر الأخير، فلقد قَررنا بالفعل كتابة البرنامج الفرعي changeToRandomColor(int,int)‎ المَسئول عن ضَبْط اللون. لاحِظ أن إِمكانية إعادة اِستخدَام برنامج فرعي معين بعدة مَواضِع يُعدّ أحد أهم مَكاسِب اِستخدَام البرامج الفرعية. يُمكِننا الآن كتابة البرنامج الفرعي fillWithRandomColors()‎ بلغة الجافا كالتالي: static void fillWithRandomColors() { int row, column; for ( row = 0; row < 16; row++ ) for ( column = 0; column < 20; column++ ) changeToRandomColor(row,column); } سننتقل الآن إلى البرنامج الفرعي التالي changeToRandomColor(int,int)‎. يُوفِّر الصَنْف Mosaic بالفعل التابع (method)‏ Mosaic.setColor()‎، والمُستخدَم لتَغْيِير لون المربع.لمّا كنا نُريد لونًا عشوائيًا، فسنحتاج إلى اختيار قيم عشوائية لكل من r و g و b، والتي ينبغي أن تَكُون أعدادًا صحيحة (integers) مُتراوحة بين العددين ٠ و ٢٥٥، وفقًا للشَّرْط المُسَبَّق (precondition) للبرنامج الفرعي Mosaic.setColor()‎، ولهذا سنَستخدِم المُعادلة (int)(256*Math.random()‎) لاختيار مثل تلك الأعداد. بالتالي، يُمكِننا كتابة البرنامج الفرعي المُستخدَم لتَغْيِير اللون عشوائيًا كالتالي: static void changeToRandomColor(int rowNum, int colNum) { int red = (int)(256*Math.random()); int green = (int)(256*Math.random()); int blue = (int)(256*Math.random()); Mosaic.setColor(rowNum,colNum,red,green,blue); } وأخيرًا، يُمكِننا الانتقال إلى البرنامج الفرعي randomMove()‎، والمَسئول عن تحريك التشويش (disturbance) عشوائيًا، لأعلى، أو لأسفل، أو يسارًا، أو يمينًا. سنَستخدِم عددًا عشوائيًا يَتراوح بين القيمتين ٠ و ٣؛ لإجراء الاختيار ما بين الاتجاهات الأربعة، فمثلًا، عندما تَكُون قيمة العدد مُساوِية للصفر، سيَتحرَك التشويش باتجاه معين، أما إذا كانت قيمته مُساوِية للواحد، فسيَتحرَك باتجاه آخر، وهكذا. لمّا كنا نَستخدِم المُتَغيِّرين currentRow و currentColumn لتحديد المَوضِع الحالي للتشويش، فإن تحريك ذلك المَوضِع لأعلى يَعنِي بالضرورة إِنقاص قيمة المُتَغيِّر currentRow بمقدار الواحد. يَترك ذلك استفهامًا عما يُفْترَض حُدوثه عندما يَصِل المُتَغيِّر currentRow إلى القيمة -١؛ خُصوصًا وأن ذلك سيَتَسبَّب بإخفاء التشويش خارج النافذة، وهو ما سينتهك الشَّرْط المُسَبَّق (precondition) لكثير من البرامج الفرعية ضِمْن الصنف Mosaic، ولهذا سنُحرِك التشويش إلى الحافة المُضادة من النافذة من خلال ضَبْط قيمة المُتَغيِّر currentRow إلى ١٥ (تَذَكَّر أن النافذة مُكوَّنة من ١٦ صف مُرقَّمَين من ٠ وحتى ١٥). بدلًا من القفز إلى الحافة الآخرى، نستطيع أيضًا تَجاهُل تلك الحالة. يُمكِننا معالجة تحريك التشويش (disturbance) للاتجاهات الثلاثة الأخرى بنفس الطريقة، بحيث نستعين بتَعْليمَة switch لتَحْديد الاتجاه ذاته. اُنظر شيفرة البرنامج الفرعي randomMove()‎: int directionNum; directionNum = (int)(4*Math.random()); switch (directionNum) { case 0: // تحرك لأعلى currentRow--; if (currentRow < 0) // إذا أصبح الموضع الحالي خارج النافذة currentRow = 15; // قم بتحريكه للحافة المضادة break; case 1: // تحرك لليمين currentColumn++; if (currentColumn >= 20) currentColumn = 0; break; case 2: // تحرك لأسفل currentRow++; if (currentRow >= 16) currentRow = 0; break; case 3: // تحرك لليسار currentColumn--; if (currentColumn < 0) currentColumn = 19; break; } البرنامج انتهينا الآن من كتابة جميع البرامج الفرعية، وتَبقَّى لنا تَجْميعها معًا بحيث نَحصُل على البرنامج كاملًا، بالإضافة إلى كتابة تعليقات Javadoc للصنف ذاته ولبرامجه الفرعية. لاحظ أننا قد عَرَّفنا المُتَغيِّرين currentRow و currentColumn كأعضاء ساكنة (static members) ضِمْن الصنف، وليس كمُتَغيِّرات محليّة (local)؛ وذلك لكَوْنهما مُستخدَمين ضِمْن أكثر من مُجرَّد برنامج فرعي (subroutines) واحد. تَتَوفَّر نسخة من الشيفرة المصدرية للبرنامج بالملف RandomMosaicWalk.java، وانتبه لكَوْنه يَعتمِد على كُلًا من الملفين Mosaic.java و MosaicCanvas.java. /** * يفتح هذا البرنامج نافذة مليئة بالمربعات الملونة عشوائيًا * بحيث يتحرك نوع من "التشويش" عشوائيًا عبر الشاشة ويغير من * لون أي مربع يواجهه بشكل عشوائي. يستمر البرنامج في العمل * طالما كانت النافذة مفتوحة */ public class RandomMosaicWalk { static int currentRow; // رقم الصف المعرض للتشويش static int currentColumn; // رقم العمود المعرض للتشويش /** * ‫يُنشيء برنامج main النافذة ويملؤها بألوان عشوائية * ثم يحرك التشويش بصورة عشوائية عبر النافذة طالما كانت مفتوحة */ public static void main(String[] args) { Mosaic.open(16,20,25,25); fillWithRandomColors(); currentRow = 8; // ابدأ بمنتصف النافذة currentColumn = 10; while (true) { changeToRandomColor(currentRow, currentColumn); randomMove(); Mosaic.delay(10); // احذف هذا السطر لزيادة سرعة التحريكة } } // نهاية main /** * يملأ النافذة بمربعات ملونة عشوائيا * * الشرط المسبق: لابد أن تكون النافذة مفتوحة * الشرط اللاحق: سيصبح كل مربع النافذة ملون بصورة عشوائية */ static void fillWithRandomColors() { int row, column; for ( row=0; row < 16; row++ ) { for ( column=0; column < 20; column++ ) { changeToRandomColor(row, column); } } } // نهاية fillWithRandomColors /** * يغير من لون مربع معين بالنافذة عشوائيًا * * الشرط المسبق: لابد أن يقع رقمي الصف والعمود الممررين ضمن * النطاق المسموح به لأرقام الصف والعمود * الشرط اللاحق: سيتغير لون المربع المخصص بواسطة رقمي الصف والعمود * * @param rowNum رقم الصف للمربع بحيث يبدأ عد الصفوف من الأعلى * @param colNum رقم الصف للمربع بحيث يبدأ عد الأعمدة من اليسار */ static void changeToRandomColor(int rowNum, int colNum) { // اختر قيم عشوائية تتراوح بين 0 و 255 // لقيم الألوان الثلاثة (الأحمر، والأزرق، والأخضر‫) ‫بنظام الألوان RGB int red = (int)(256*Math.random()); int green = (int)(256*Math.random()); int blue = (int)(256*Math.random()); Mosaic.setColor(rowNum,colNum,red,green,blue); } // ‫نهاية changeToRandomColor /** * يحرك التشويش عبر النافذة * * الشرط المسبق: لابد أن تكون المتغيرات العامة‫ currentRow و * ‫currentColumn ضمن النطاق المسموح به لرقمي الصف والعمود * الشرط اللاحق: يتغير رقمي الصف والعمود إلى أحد المواضع المجاورة * سواء للأعلى أو للأسفل أو لليسار أو لليمين */ static void randomMove() { int directionNum; directionNum = (int)(4*Math.random()); switch (directionNum) { case 0: // move up currentRow--; if (currentRow < 0) currentRow = 15; break; case 1: // move right currentColumn++; if (currentColumn >= 20) currentColumn = 0; break; case 2: // move down currentRow ++; if (currentRow >= 16) currentRow = 0; break; case 3: // move left currentColumn--; if (currentColumn < 0) currentColumn = 19; break; } } // ‫نهاية randomMove } // ‫نهاية الصنف RandomMosaicWalk ترجمة -بتصرّف- للقسم Section 7: More on Program Design من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

كل تَطوُّر يَحدُث بواجهات المُستخدِم، يُقابله تَعقيد أكبر ينبغي على المبرمج التَعامُل معه، ففي حين تستطيع كتابة واجهة برنامج طرفية (console user interface) بواسطة عدد قليل من البرامج الفرعية (subroutines) البسيطة التي تقرأ ما يَكْتُبه المُستخدِم، وتَطبَع خَرْج البرنامج إلى الطرفية، فإن تطوير واجهات المُستخدِم الرسومية (graphical user interface) العصرية هو أمر أكثر تعقيدًا بمراحل عدة، خاصة مع كل هذا الكم الهائل من النوافذ، والأزرار، وشرائط التمرير، والقوائم، وصناديق الإِدْخَال النصية، وغيره، والتي أينعم تَمنَح المُستخدِم تجربة سهلة ومريحة، ولكنها في ذات الوقت تُجبر المبرمج على التَعامُل مع كمية هائلة من الاحتمالات والتعقيدات المتزايدة، والتي تَكُون بهيئة عدد ضخم من البرامج الفرعية المُخصَّصة فقط لأغراض إدارة واجهة المُستخدِم (user interface) ناهيك عن البرامج الفرعية الآخرى المُخصَّصة لغَيْر ذاك الغرض. صناديق الأدوات (toolboxes) اعتاد مبرمجي حاسوب ماكنتوش الأصلي (Macintosh) على التعامل مع "صندوق أدوات ماكنتوش (Macintosh Toolbox)"، والذي يَتكوَّن من أكثر من ألف برنامج فرعي (subroutines) مختلف؛ حيث تَتَوفَّر برامج لتَّنْفيذ جميع العمليات التي يُتوقَّع من الحاسوب القيام بها، فمثلًا، تَتَوفَّر تلك البرامج المُتعلقة بواجهة المُستخدِم (user interface) مثل فَتْح النوافذ (windows) وإِغلاقها، ورَسْم كُلًا من الأشكال الهندسية (geometric) والنصوص على تلك النوافذ، وإضافة الأزرار إليها، والاستجابة إلى ضغطات الفأرة على تلك النوافذ، وإضافة القوائم (menus)، والاستجابة لما يَختاره المُستخدِم منها. إلى جانب برامج واجهة المُستخدِم، تَتَوفَّر أيضًا برامج لفَتْح الملفات، وقراءة البيانات منها، وكذلك للاتصال الشبكي، ولإرسال الخَرْج إلى الطابعة، ولمُعالجة الاتصال بين البرامج. في المُقابل، يُوفِّر مايكروسوفت ويندوز (Microsoft Windows) مجموعة آخرى من البرامج الفرعية (subroutines) للمبرمجين، والتي تَختلِف نوعًا ما عن تلك المُستخدَمة بماكنتوش (Macintosh). علاوة على ذلك، يُوفِّر لينكس (Linux) للمبرمجين أكثر من صندوق أدوات لبرمجة واجهات المُستخدِم الرسومية (GUI toolboxes) يُمكِنهم الاختيار بينها. أيّ مشروع برمجي هو بالنهاية خليط من كُلًا من الابتكار وإعادة الاِستخدَام. يبدأ المبرمج بمجموعة الأدوات البسيطة المَبْنِيَّة باللغة نفسها، كالمتغيرات، وتَعْليمَات الإِسْناد (assignment statements)، وتَعْليمَات التَفْرِيع if، وحَلْقات التَكْرار (loops). إلى جانب ذلك، فإنه قد يَستعِين بصناديق أدوات (toolboxes)، مَكْتوبة من قِبَل مُطوِّرين آخرين، والتي تَتضمَّن مجموعة من البرامج (routines) لتَّنْفيذ مَهَامّ معينة يَحتاجها المبرمج. إذا كانت تلك الأدوات مُصمَّمة تَصْمِيمًا جيدًا، فإنها تَكُون أَشْبه بصندوق أسود (black boxes)، لا يحتاج المبرمج أكثر من مُجرَّد استدعائها، دون مَعرِفة أية تفاصيل أو خطوات تُنفِّذها تلك الأداة لإنجاز المُهِمّة المُسنَدة إليها. كُل ما سبق يصُنَّف ضِمْن ذلك الجزء الخاص بإعادة الاِستخدَام، أما الجزء الآخر المُتَعلِّق بالابتكار، فيَتكوَّن من توظيف كل تلك الأدوات السابق ذِكرَها ضِمْن مشروع معين بهدف حل مشكلة معينة كمُعالجة النصوص، أو الاحتفاظ بالحسابات البنكية، أو مُعالجة الصور المُلتقَطة بواسطة مسبار فضاء، أو ألعاب الكمبيوتر، أو تَصفُّح الإنترنت، ..إلخ. يُطلَق على ذلك برمجة التطبيقات (applications programming). صندوق الأدوات البرمجي (software toolbox) هو أَشْبه ما يَكُون بصندوق أسود، لابُدّ أن يَكُون مَصحُوبًا بواجهة (interface)، والتي تَتَكوَّن من توصيف لجميع البرامج (routines) المُعرَّفة بداخله، أيّ ذِكْر مُعامِلات (parameters) كل برنامج، والغرض منه. تُكوِّن تلك التوصيفات ما يُعرَف باسم واجهة برمجة التطبيقات (Application Programming Interface)، وتُختصَر إلى API، فمثلًا، تَحتوِي واجهة برمجة تطبيقات ماكنتوش (Macintosh API) على تَوصِيف لجميع البرامج (routines) المُتاحة "بصندوق أدوات ماكنتوش (Macintosh Toolbox)". عادةً ما تُصدر الشركات المُصنعة للأجهزة العتادية (hardware device) -مثل بطاقات الشبكة (network cards) المسئولة عن توصيل الحاسوب بشبكة معينة- واجهة برمجة تطبيقات (API) خاصة بذلك الجهاز، تَحتوِي على قائمة بالبرامج (routines) التي يُمكِن للمبرمجين استدعائها؛ للاتصال مع الجهاز والتَحكُّم به. علاوة على ذلك، يُوفِّر العلماء المُساهمين بكتابة البرامج المسئولة عن حِسَاب بعض العمليات المُعقدة نوعًا ما -مثل حلّ المعادلات التفاضلية (differential equations)- واجهة برمجة تطبيقات (API)، تَسمَح للآخرين باستدعاء تلك البرامج (routines) دون الحاجة إلى فهم تفاصيل تلك العمليات. لغة الجافا مُدعَّمة بواجهة برمجة التطبيقات القياسية (standard API)، والتي تَعرَّضنا لأجزاء منها بالفعل، مثل البرنامج الفرعي الرياضي Math.sqrt()‎، والصَنْف String، وما يَحتوِيه من برامج (routines)، بالإضافة إلى برامج طباعة الخَرْج System.out.print()‎. تَتضمَّن أيضًا تلك الواجهة برامج (routines) لبرمجة واجهات المُستخدِم الرسومية (graphical user interfaces)، وللاتصالات الشبكية (network communication)، ولقراءة الملفات وكتابتها، وغيرها. يَظُنّ البعض أن تلك البرامج (routines) هي جزء من لغة الجافا ذاتها، ولكنها في الواقع مُجرَّد برامج فرعية (subroutines) قد كُتبت وأُتيحت للاِستخدَام ببرامج (programs) الجافا. ينبغي لأيّ واجهة برمجة تطبيقات جافا (Java API) العَمَل على جميع المنصات، وعندها يُعدّ برنامج (program) الجافا المَكْتوب وفقًا لتلك الواجهة مُستقلًا عن أيّ منصة (platform-independent)، أيّ أنه من المُمكِن تَشْغِيل نفس البرنامج (program) على منصات (platform) مُتعدِّدة، مثل ويندوز (Windows)، وماك (Mac OS)، ولينكس (Linux) وغيرها. ومع ذلك، لاحِظ أن الواجهة (interface) ذاتها هي التي تُعدّ مُستقلة عن المنصات (platform-independent)، أما تَّنْفيذ (implementation) تلك الواجهة فإنه قد يختلف من منصة لآخرى. فيما يتعلق بواجهة برمجة التطبيقات القياسية (standard API)، يَتضمَّن نظام الجافا (Java system) بأي حاسوب عمومًا تَّنْفيذًا (implementations) لجميع البرامج الموجودة بتلك الواجهة. عندما يَستدعِي برنامج جافا (Java program) واحدة من تلك البرامج القياسية (standard routines) ضِمْن الواجهة القياسية، فإن مُفسِّر الجافا (Java interpreter) -عند تَّنْفيذه للبرنامج (program)- يَسحَب تَّنْفيذ البرنامج المُستدعَى (routine implementation) المُتناسب مع المنصة (platform) الحالية، ثم يُنفِّذه. يَعنِي ذلك أنه بمُجرَّد تَعلُّمك لواجهة برمجة تطبيقات (API) واحدة، سيُصبِح بإمكانك استهداف مجموعة واسعة من المنصات، وهو ما يُعدّ ميزة قوية جدًا. حزم الجافا القياسية (standard packages) تُكتَب البرامج (routines) بواجهة برمجة التطبيقات القياسية (standard API) داخل أصناف (classes) كما هو الحال مع أي برنامج فرعي (subroutine). بالإضافة إلى ذلك، فإنه من المُمكِن تَجْميع الأصناف ضِمْن حزم (packages)، والتي تَعرَّضنا لها باختصار بالقسم الفرعي ٢.٦.٧؛ بهدف تنظيمها على نطاق أوسع (large-scale). يُمكِن أيضًا تَضْمِين الحزم (packages) داخل حزم آخرى لتحقيق مُستوى أعلى من التَجْميع. في الواقع، واجهة برمجة تطبيقات جافا القياسية (standard Java API) مُنفَّذة (implement) بالكامل ضِمْن عدة حزم، فمثلًا، تَحتوِي حزمة java على عدة حزم آخرى غَيْر مُتَعلِّقة بواجهة المُستخدِم الرسومية (non-GUI)، بالإضافة إلى احتوائها على أصناف AWT المُتَعَلِّقة بتلك الواجهات الرسومية. حزمة javax هي مثال آخر، وتَحتوِي على أصناف كثيرة، من ضِمْنها تلك الأصناف التي تَستخدِمها واجهة المُستخدِم الرسومية (GUI)‏ Swing. كذلك حزمة javafx والتي تَحتوِي على واجهة برمجة تطبيقات جافا إف إكس (JavaFX API) التي يَستخدِمها الكتاب لبرمجة واجهات المُستخدِم الرسومية (GUI)‏. قد تَحتوِي أي حزمة (package) على أصناف أو حزم آخرى، وتُسمَى تلك الأخيرة باسم الحزم الفرعية (sub-package). تَتضمَّن كُلًا من الحزمتين java و javafx على حزم فرعية (sub-packages). فمثلًا، تَحتوِي الحزمة الفرعية util على تشكيلة من الأصناف، بما في ذلك الصَنْف Scanner الذي ناقشناه بالقسم الفرعي ٢.٤.٦، وهي في الواقع مُتضمَّنة داخل حزمة java، ولذا يَكُون اسمها الكامل هو java.util. مثال آخر هو الحزمة الفرعية java.io، والتي تُسهِل من عمليات الخَرْج والدَخْل (input/output). كذلك الحزمة الفرعية java.net، والتي تتعامل مع الاتصالات الشبكية. أخيرًا الحزمة الفرعية الأكثر بساطة java.lang، والتي تَحتوِي على الأصناف الأساسية مثل String و Math و Integer و Double. اُنظر الصورة التالية والتي تَتضمَّن تمثيلًا رسوميًا (graphical representation) لمُستويات التَدَاخُل (nesting levels) بحزمة java، بما في ذلك حزمها الفرعية (sub-packages)، والأصناف الموجودة ضِمْن تلك الحزم الفرعية، بالإضافة إلى البرامج الفرعية (subroutines) الموجودة ضِمْن تلك الأصناف. لاحِظ أن هذا التمثيل الرسومي غَيْر كامل، فهو يَعرِض فقط عددًا قليلًا جدًا من العناصر الكثيرة الموجودة بكل عنصر. ] بالمثل، تَحتوِي حزمة javafx على الحزمة الفرعية javafx.scene، والتي تَحتوِي بدورها على كُلًا من الحزمتين الفرعيتين javafx.scene.control و javafx.scene.paint. تَحتوِي أولاهما على أصناف (classes) لتمثيل مُكوِّنات واجهة المُستخدِم الرسومية (GUI components)، كالأزرار (buttons)، وصناديق الإِدْخال (input boxes)، بينما تَحتوِي الآخرى على الصَنْف Color، وأصناف آخرى لأغراض مَلْئ الأشكال (filling) وتَحْدِيد حوافها (stroking). تَتضمَّن واجهة برمجة تطبيقات جافا القياسية (standard Java API) آلافًا من الأصناف مُجمَّعة ضِمْن مئات من الحزم. الكثير من تلك الأصناف هو، في الواقع، مُتخصِّص للغاية أو غَيْر مَعْروف، لذا لا داعي للإلمام بكامل واجهة برمجة تطبيقات جافا (Java API)، ولا حتى غالبيتها، فحتى خبراء المبرمجين ليسوا على دِرَايَة بكامل الواجهة. ستُواجه عشرات الأصناف (classes) أثناء دراستك لهذا الكتاب، وستَجِدْ أنهم كافيين تمامًا لكتابة تشكيلة واسعة من البرامج (programs). مع ذلك، يُمكِنك تَصفُّح توثيق واجهة برمجة التطبيقات (API) للإصدار ٨ من الجافا بالإضافة إلى توثيق واجهة برمجة تطبيقات جافا إف إكس (JavaFX) للإطلاع على ما هو مُتاح عمومًا. يُناقِش القسم الفرعي "الوحدات (modules)" بالأسفل بعضًا من التَغْيِيرات التي طرأت بالإصدار ٩ من الجافا، كما ستَجِدْ روابط تَوْثيق (documentation) الإصدار ١١ من الجافا. لكن لاحِظ أن تَوْثيق الإصدار ٨ يُعدّ أكثر سهولة في الاِستخدَام فيما يَتعلَّق بدراسة هذا الكتاب. استخدام الأصناف ضمن الحزم تَتضمَّن الحزمة javafx.scene.paint الصَنْف Color، لذا فإن الاسم الكامل للصنف هو javafx.scene.paint.Color. ذلك الصَنْف، وكأي صنف، هو بالنهاية نوع، أيّ أنك تستطيع اِستخدَامه للتَّصْريح (declare) عن كلًا من المُتَغيِّرات، والمُعامِلات (parameters)، وكذلك لتَخْصيص نوع القيمة المعادة (return type) من دالة (function). إذا أردت اِستخدَام ذلك الصَنْف ضِمْن أحد البرامج (program) التي تقوم بكتابتها، فإن أحد الطرائق للقيام بذلك هو استخدام الاسم الكامل للصَنْف كاسم للنوع. مثلًا، إذا كنت تريد التَّصْريح عن مُتَغيِّر اسمه rectColor من النوع Color، تستطيع كتابة التالي: javafx.scene.paint.Color rectColor; تُمثِل الشيفرة بالأعلى مُجرَّد تَّصْريح (declaration) عن مُتَغيِّر عادي على الصياغة ‎;‎. مع ذلك، فإن اِستخدَام الاسم الكامل للصَنْف هو حتمًا أمر مُتعب، وفي الواقع، نادرًا ما ستَجِدْ تلك الأسماء الكاملة مُستخدَمة بأيّ برنامج (program)؛ حيث تَسمَح الجافا بتَجَنُّب اِستخدَام الاسم الكامل للصَنْف، وفي المقابل، ستحتاج إلى اِستيراد (importing) ذلك الصَنْف أولًا. يُمكِنك استيراد الصَنْف بإضافة السَطْر التالي إلى بداية ملف الشيفرة المصدرية (source code): import javafx.scene.paint.Color; بذلك، تستطيع ببقية ذلك الملف كتابة الاسم البسيط (simple name) للصَنْف، أيّ Color، بدلًا من الاسم الكامل javafx.scene.paint.Color. لابُدّ أن يُكتَب سَطْر الاستيراد import ببداية الملف (بعد تَعْليمَة package في حالة وجودها)، وبحيث لا يَقَع سَطْر الاستيراد import ضِمْن أيّ صَنْف (class) مُعرَّف داخل الملف. يُسمِى البعض سَطْر الاستيراد import -بالأعلى- أحيانًا باسم التَعْليمَة (statement)، ولكن من الأنسب تَسميته بالمُوجِّه (directive)‏ import؛ لأنه ليس تَعْليمَة بالمعنى المُعتاد. والآن، سَمَح لك المُوجِّه import javafx.scene.paint.Color بكتابة التالي للتَّصْريح عن مُتَغيِّر: Color rectColor; يَقْتصِر دور المُوجِّه (directive)‏ import على السماح باِستخدَام الأسماء البسيطة للأصناف بدلًا من أسمائها الكاملة .، أي أنه لا يَستوِرد أي شيء فعليّ، فأنت ما زلت تستطيع الوصول إلى الصَنْف (class) بدون اِستخدَام ذلك المُوجِّه، فقط ستحتاج إلى تعيين اسم الصَنْف كاملًا. تَتَوفَّر طريقة مُختصرة لاستيراد (importing) جميع الأصناف الموجودة ضِمْن حزمة معينة. على سبيل المثال، اِستخدِم مُوجِّه import التالي بهدف استيراد جميع الأصناف (classes) الموجودة بحزمة java.util: import java.util.*; لاحِظ أنه في حين يَتطابَق محرف البدل (wildcard) * مع جميع الأصناف الموجودة ضِمْن حزمة معينة، فإنه لا يَتطابَق مع حزمها الفرعية (sub-packages)، أيّ أنك لا تستطيع استيراد جميع الحزم الفرعية (sub-packages) الموجودة ضِمْن حزمة javafx بمُجرَّد كتابة import javafx.*‎. لمّا كان اِستخدَام محرف البدل (wildcard) * بتَعْليمَة import يُتيح عددًا كبيرًا من أسماء الأصناف التي على الأرجح لن تُستخدَم، بل والتي ربما لا يَعَلم المبرمج عنها شيئًا، فإن بعض المبرمجين يُفضِّلون استيراد كل صَنْف سيَستخدِمونه فعليًا استيرادًا صريحًا وبصورة مُنفصلة. يَنصَح الكاتب باِستخدَام محرف البدل (wildcard) فقط مع الحزم (packages) الأكثر صلة بالتطبيق؛ بهدف استيراد جميع الأصناف (classes) الموجودة بها، أما في حالة اِستخدَام صَنْف واحد فقط أو اثنين من حزمة معينة، فلربما عندها من الأفضل اِستخدَام استيرادات (imports) فردية. على سبيل المثال، قد يَحتوِي برنامج يتعامل بصورة أساسية مع الشبكات على المُوجِّه import java.net.*;‎، بينما قد يَحتوِي برنامج آخر يقرأ الملفات ويكتبها على المُوجِّه import java.io.*;‎. لكن لاحِظ أنه في حالة بدأت باستيراد الكثير من الحزم بتلك الطريقة، فلابُدّ من الانتباه لأمر هام. قد تَحتوِي حزمتان مختلفتان على صَنْفين (classes) يَحمِل كلاهما نفس الاسم، فمثلًا تَحتوِي كُلًا من الحزمتين java.awt و java.util على صَنْف اسمه List. الآن، إذا استوردت كُلًا من java.awt.*‎ و java.util.*‎، فسيُصبِح الاسم البسيط للصَنْف List مُبهمًا، وبالتالي، إذا حاولت التَّصْريح (declare) عن مُتَغيِّر من النوع List، ستَحصُل على رسالة خطأ من المُصرِّف (compiler) بشأن وجود اسم صَنْف مُبْهَم. مع ذلك، ما زلت تستطيع اِستخدَام كِلا الصنفين بالبرنامج (program)، إما باِستخدَام الاسم الكامل للصَنْف مثل java.awt.List و java.util.List، أو باِستخدَام المُوجِّه import لاستيراد الأصناف المُفردة التي تحتاجها بدلًا من استيراد الحزم (packages) بالكامل. تُعدّ الحزمة java.lang أحد أهم الحزم الأساسية؛ لاحتوائها على بعض الأصناف الرئيسية، ولذلك تُستورَد جميع الأصناف الموجودة بتلك الحزمة أتوماتيكيًا بأيّ برنامج (program)، أيّ كما لو كان كل برنامج يبدأ بالتَعْليمَة import java.lang.*;‎. وهو في الواقع ما قد مَكَّنا سابقًا من اِستخدَام اسم الصَنْف String بدلًا من java.lang.String، واِستخدَام Math.sqrt()‎ بدلًا من java.lang.Math.sqrt()‎. ومع ذلك، يُمكِنك أيضًا اِستخدَام الصياغة الأطول من أسماء تلك الأصناف. تُستخدَم تَعْليمَة package لإنشاء حزم (packages) جديدة، والتي قد تَتضمَّن مجموعة من الأصناف (classes). كل ما عليك القيام به هو كتابة تلك التَعْليمَة ببداية ملفات الشيفرة المصدرية (source code) التي تَحتوِي على تعريف الأصناف المطلوب تَضْمِينها بتلك الحزمة. مثلًا، إذا أردت إنشاء حزمة اسمها utilities، اِستخدِم السطر التالي: package utilities; لابُدّ أن تُكْتَب تَعْليمَة package ببداية الملف، أيّ حتى قَبْل أيّ مُوجِّه import قد يَكُون موجودًا بذلك الملف. بالإضافة إلى ذلك، لابُدّ أن يوجد ذلك الملف بمجلد يَحمِل نفس اسم الحزمة، أي utilities بهذا المثال. وبالمثل، لابُدّ أن توجد ملفات الأصناف ضِمْن الحزم الفرعية (sub-package) بمجلدات فرعية. على سبيل المثال، ينبغي لملفات الأصناف الموجودة بحزمة اسمها utilities.net أن تكون موجودة بمجلد اسمه net الموجود بدوره بمجلد آخر اسمه utilities. يستطيع أي صَنْف داخل حزمة (package) معينة الوصول أتوماتيكيًا إلى جميع الأصناف (classes) الآخرى الموجودة بنفس الحزمة. بتعبير آخر، لا يحتاج صَنْف معين أن يَستورِد (import) الأصناف من نفس الحزمة (package) المُعرَّف بها. عادة ما يَلجأ المبرمجون لإنشاء حزم جديدة وذلك إِما بالمشروعات التي تُعرِّف عددًا كبيرًا من الأصناف؛ بهدف تنظيمها، أو عند إِنشائهم لصناديق أدوات (toolboxes)؛ لتوفير واجهة برمجة تطبيقات (APIs) لبعض الوظائف والميزات غير المُتوفِّرة بواجهة برمجة تطبيقات جافا القياسية (standard Java API). في الواقع، يَحظَى المبرمجون "من صَانِعي الأدوات" عادة بهَيْبة واحترام أكبر من مُبرمجي التطبيقات الذين يَستخدِمون تلك الأدوات. لاحظ أن غالبية الأصناف المَكْتوبة لهذا الكتاب غَيْر مُضمَّنة بأي حزمة، مع عدة استثناءات قليلة مثل الصَنْف TextIO بالحزمة textio. لأغراض هذا الكتاب، فإنك ستحتاج أن تدرك ماهية الحزم (packages)؛ حتى تَتَمكَّن من استيراد الصَنْف TextIO، وكذلك الأصناف الموجودة ضِمْن الحزم القياسية (standard packages). لاحِظ أن الحزم القياسية هي دائمًا مُتوفِّرة بجميع البرامج (programs) التي تَكتُبها، قد تَتَساءل، أين توجد تلك الأصناف القياسية (standard classes) بصورة فعليّة؟ يَعتمِد ذلك على إصدار الجافا المُستخدَم إلى حد كبير. مثلًا، بالإصدار ٨ من الجافا، فإنها تَكُون مُخزَّنة بملفات جافا أَرْشيفيّة (jar files/Java archive) تقع بالمجلد الفرعي lib الموجود بمجلد التثبيت الخاص ببيئة تَّنْفيذ الجافا (Java Runtime Environment). إن ملفات جافا الأَرْشيفيّة (jar file/Java archive) هي ببساطة ملفات بامتداد ‎.jar قد تَحتوِي على عدة أصناف. توجد غالبية الأصناف المُستخدَمة بالإصدار ٨ من الجافا بملف جافا أرشيفي (jar file) اسمه rt.jar. طرأت بعض التَغْيِيرات بالإصدار ٩ من الجافا، وهو ما سنُناقشه بالقسم الفرعي التالي. لاحِظ أن أيّ صَنْف بالنهاية لابُدّ وأن يقع ضِمْن حزمة (package)، حتى في حالة عدم تَحْدِيد الحزمة التي يُفْترَض أن يقع بها الصنف صراحةً، وفي تلك الحالات، يُوضَع الصَنْف تلقائيًا فيما يُعرَف باسم الحزمة الافتراضية (default package)، والتي ليس لها اسم. تقع تقريبًا كل الأمثلة التي ستراها بهذا الكتاب بالحزمة الافتراضية. الوحدات (modules) تُدعِّم الجافا منذ الإصدار ٩ ما يُعرَف باسم الوحدات (modules)، وهو ما تَسَبَّب بحُدوث بعض التَغْيِيرات على بنيتها ذات النطاقات الواسعة (large-scale structure). تُوفِّر الوحدات (modules) عمومًا مستوًى آخرًا من التَجْميع؛ حيث تَتضمَّن الوحدات مجموعة من الحزم، التي تَحتوِي على أصناف، والتي بدورها تَحتوِي على مُتَغيِّرات وتوابع (methods). ليس ضروريًا أن تقع الحزمة ضِمْن وحدة (module) حتى تُصبِح قابلة للاِستخدَام، ومع ذلك، فإن جميع الأصناف القياسية (standard classes) بكُلًا من جافا (Java) وجافا إف إكس (JavaFX) قد ضُمّنت داخل وحدات (modules). وَفَّرت الجافا الوحدات (modules) لعدة أسباب: أولًا، لتَحسِّين التَحكُّم بالوصول (access control)، وهو في الواقع أحد أهم الأسباب الرئيسية. قَبْل الوحدات، كان بإِمكانك اِستخدَام الأصناف العامة، أيّ تلك المُصرَّح عنها باِستخدَام المُبدِّل public، بأيّ مكان وداخل أيّ صَنْف ضِمْن أيّ حزمة، وبالمثل مُتَغيِّراته وتوابعه المُصرَّح عنها باِستخدَام المُبدِّل public. في المقابل، يَعنِي اِستخدَام المُبدِّل العام public مع صَنْف، مُعرَّف ضِمْن وحدة (module)، كَوْن ذلك الصَنْف عامًا public ضِمْن الوحدة (module) المُعرَّف بداخلها فقط. ومع ذلك، ما يزال بإمكان الوحدات تصدير (export) أي حزمة بشكل صريح، وبناءً عليه، ستُصبِح الأصناف العامة، أيّ تلك المُعرَّفة باِستخدَام المُبدِّل public، ضمن تلك الحزمة قابلة للوصول (accessible) مرة آخرى من أي مكان، بما في ذلك الوحدات (modules) الآخرى، وكذلك الأصناف التي ليست جزءًا من أي وحدة. يمكن حتى تَخْصيص الوحدات (modules) المطلوب تصدير الحزمة إليها، وهو ما يُوفِّر تَحكُّمًا بالوصول (access control) أكثر دقة. يَعنِي كل ما سبق أنه يُمكِننا الآن إنشاء حزم هي خاصة (private) بالأساس، أيّ أنها غَيْر مَرئية (invisible) من خارج الوحدة، ولكنها في نفس الوقت تُوفِّر خدمات (services) للحزم الآخرى داخل نفس الوحدة. يُمكِننا بذلك عدّ الوحدة نوعًا آخرًا من الصندوق الأسود (black box)، تَكُون فيه الحزم غَيْر المُصدَّرة (non-exported) جزءًا من تَّنْفيذه (implementation) الخفي. تُعدّ التركيبية (modularity) على هذا المُستوى الواسع من النطاق مهمة بحقّ، وبالأخص للتطبيقات ذات النطاقات الواسعة (large-scale applications). الدافع الآخر لتَوْفِير الوحدات (modules) هو الحجم الكلي لبيئة تَّنْفيذ الجافا القياسية (Java Runtime Environment)، وتُختصر إلى JRE. تَتضمَّن تلك البيئة جميع الأصناف القياسية (standard classes) على الرغم من أن التطبيقات (application) تَستخدِم عادةً جزءًا صغيرًا منها. تَسمَح التركيبية (Modularization) بإنشاء بيئات تَّنْفيذ جافا مُخصَّصة (custom JREs) أصغر؛ بحيث تحتوي فقط على الوحدات التي يحتاجها التطبيق. تَتضمَّن عُدة تطوير الجافا (Java Development Kit)، وتُختصر إلى JDK، الأمر jlink المُستخدَم لإنشاء بيئات تَّنْفيذ مُخصَّصة (custom runtimes)، والتي عادةً ما تَتضمَّن وحدات (modules) التطبيق ذاته بالإضافة إلى الوحدات القياسية (standard modules) المطلوبة لتَشْغِيل ذلك التطبيق (application). بعد ذلك، تُوزَّع (distribute) بيئات التَّنْفيذ تلك كتطبيق قائم بذاته (standalone)، والذي يُمكِن تَشْغِيله حتى بتلك الحواسيب التي لم تُثبَّت عليها عُدة تطوير الجافا (JDK). ولكن لاحِظ أنك ستحتاج إلى إنشاء إصدارات مختلفة من بيئة التَّنْفيذ المُخصَّصة (custom runtime) للمنصات المختلفة مثل الويندوز (Windows) والماك (Mac OS) ولينكس (Linux)، كما هو الحال مع عُدة تطوير الجافا (JDK) ذاتها. بالإضافة إلى ذلك، لن تُطبَق تحديثات الأمان (security updates) الصادرة لعُدة تطوير الجافا (JDK) أتوماتيكيًا على بيئات التَّنْفيذ المُخصَّصة (custom runtime)، ولذلك تقع مسئولية تحديثها على مُطوِّر التطبيق. عمومًا يُعدّ ذلك ميزة مفيدة جدًا للتطبيقات الكبيرة. منذ الإصدار ٩ من الجافا، تُخزَّن ملفات أصناف الوحدات القياسية (standard modules) المُصرَّفة داخل الملف modules، والموجود بالمجلد الفرعي lib الموجود بدوره بالمجلد الرئيسي لعُدة تطوير الجافا (JDK). صيغة ذلك الملف هي jimage، يُمكِنك التعامل معها باِستخدَام أداة سطر الأوامر jimage. في الواقع، عندما تُستخدَم أداة jlink لإنشاء بيئة تَّنْفيذ مُخصَّصة (custom runtime)، فإن جزءًا مما تقوم به هو إِنشاء ملف modules مُخصَّص يَحتوِي فقط على الوحدات (modules) المطلوبة لبيئة التَّنْفيذ (runtime) تلك. بفَحْص مجلد الإصدار ١٢ من عُدة تطوير الجافا (JDK) بحاسوب لينكس (Linux) الخاص بالكاتب، تَبيَّن أن الملف modules يَتضمَّن حوالي ٣٠١٩٩ صَنْف، ضِمْن ١٠٠٠ حزمة، ضِمْن ٧٠ وحدة، كما وصل حجمه إلى حوالي ١٣٠ ميجا بايت. يَحتوِي المجلد الرئيسي لعُدة تطوير الجافا (JDK) أيضًا على المجلد الفرعي jmods، والذي يَتضمَّن تلك الوحدات (modules) ولكن بصيغة آخرى، وعمومًا هو ليس مطلوبًا لتَصْرِيف البرامج وتَشْغِيلها، وغالبًا يَقْتصِر اِستخدَامه على الأداة jlink على حَدْ عِلم الكاتب. تَتضمَّن عُدة تطوير الجافا (JDK) مجموعة من الوحدات، من بينها الوحدتين java.base و java.desktop. تَحتوِي أولاهما على الحزم الأساسية مثل java.lang و java.util، بينما تَتضمَّن الثانية حزم (packages) خاصة بـ"أدوات تَحكُّم واجهة المُستخدَم الرسومية Swing ‏(Swing GUI toolkit)". في المقابل، تَتضمَّن منصة جافا إف إكس (JavaFX) كُلًا من الوحدات javafx.base و javafx.control و javafx.graphics بالإضافة إلى وحدات آخرى غير شائعة الاِستخدَام عمومًا. يُقسَّم تَوْثيق واجهة برمجة التطبيقات (API) للإصدارات التركيبية (modular) من الجافا إلى وحدات (modules)، مُقسَّمة بدورها إلى حزم (packages)، وأخيرًا إلى أصناف (classes)، وهو ما قد يَجعَل التَوْثيق (documentation) أصعب قليلًا في التَصفُّح بالموازنة مع الإصدارات الأقدم. مع ذلك تَتوفَّر مِيزَة بحث فعالة بالموقع الالكتروني للتَوْثيق. يُمكِنك تَصفُّح توثيق الإصدار ١١ من الجافا بالإضافة إلى توثيق الإصدار ١١ من جافا إف إكس (JavaFX). ليس ضروريًا أن يَقَع الصَنْف ضِمْن وحدة (module)، وفي تلك الحالة، فإنه ما يزال يستطيع اِستخدَام الحزم من الوحدات الاخرى، بشَّرْط أن تَكُون تلك الحزم قد صُدّرت (exported) بالوحدات المُعرَّفة داخلها. يستطيع المبرمج عمومًا اِستخدَام الأصناف الموجودة بعُدة تطوير الجافا (JDK) دون الحاجة للتفكير نهائيًا بالوحدات أو حتى مَعرِفة وجودها. يَنطبِق ذلك على برامج سطر الأوامر (command-line programs) بهذا الكتاب، أما برامج واجهة المُستخدِم الرسومية (GUI programs) التي تَستخدِم منصة جافا إف إكس (JavaFX)، فالأمور تختلف قليلًا منذ الإصدار ١١ من الجافا؛ وذلك لأن تلك المنصة قد حُذفَت من عُدة تطوير الجافا (JDK)، وأصبحت تُوزَّع بصورة مستقلة كمجموعة من الوحدات. لذلك، عند تَصْرِيف برنامج جافا إف إكس (JavaFX)، أو تَشْغِيله، ستحتاج، كما رأينا بالقسم ٢.٦، إلى تَخْصيص مسار الوحدة (module path)، والذي لابُدّ أن يَحتوِي على وحدات تلك المنصة، كما ستحتاج إلى تمرير قيمة للخيار ‎--add-modules. مُرِّرت ALL-MODULE-PATH كقيمة للخيار ‎--add-modules بالقسم ٢.٦؛ للسماح للبرنامج بالوصول إلى أي وحدات (modules) موجودة بمسار الوحدة (module path) المُمرَّر. بدلًا من ذلك، قد تُمرِّر قائمة بأسماء الوحدات المُستخدَمة فعليًا بالبرنامج فقط. تنبيه: لا يُغطِى هذا الكتاب موضوع الوحدات (modules) بصورة أكبر من مُجرَّد اِستخدَامها مع منصة جافا إف إكس (JavaFX)، بالإضافة إلى المعلومات الأساسية بهذا القسم. التوثيق بأداة Javadoc ينبغي عمومًا كتابة تَوْثيق (documentation) جيد لأيّ واجهة برمجة تطبيقات (API)؛ وذلك حتى يَتَمكَّن المبرمجين من اِستخدَامها بصورة فعالة. يَشيِع اِستخدَام نظام Javadoc لتَوْثيق غالبية واجهات برمجة تطبيقات جافا (Java APIs)، فمثلًا، يُستخدَم هذا النظام لتجهيز تَوْثيق حزم الجافا القياسية (standard packages)، كما يَنشُر غالبية المبرمجين تقريبًا تَوْثيقًا باِستخدَام نفس ذلك النظام لأي صندوق أدوات (toolbox) يُطوروه بالجافا. يُجهَز تَوْثيق Javadoc بالاعتماد على مجموعة من التعليقات (comments) الخاصة، والتي تُكتَب بملفات الشيفرة المصدرية. كما تَعَلم، تُكتَب أحد أنواع تعليقات الجافا ضِمْن الترميزين ‎/*‎ و ‎*/‎. بالمثل، تُكتَب تعليقات Javadoc بنفس الصياغة لكنها تبدأ بالترميز ‎/**‎‎ بدلًا من الترميز ‎/*‎. لقد تَعرَّضت بالفعل لتعليقات مَكْتوبة بتلك الصياغة بكثير من الأمثلة بهذا الكتاب. ينبغي أن تُوْضَع تعليقات Javadoc قَبْل البرنامج الفرعي المَعنِي بالتعليق مباشرة. لاحظ ضرورة اتباع تلك القاعدة عمومًا وبَغْض النظر عن العنصر المَعنِي بالتَوْثيق. تُستخدَم تعليقات Javadoc عمومًا مع البرامج الفرعية (subroutines)، والمُتَغيِّرات الأعضاء (member variables)، والأصناف (classes)، وفي جميع تلك الحالات، لابُدّ دائمًا أن يَسبِق تعليق Javadoc العنصر المَعنِي بالتعليق مباشرة. عندما يُصرِّف (compile) الحاسوب ملفات الشيفرة المصدرية، فإنه يتجاهل تعليقات Javadoc مثلما يتجاهل أي تعليق عادي آخر. تَتوفَّر الأداة javadoc، والتي تَقْرأ ملفات الشيفرة المصدرية، لتَستخرِج منها تعليقات Javadoc، ثم تُنشِئ مجموعة من صفحات الانترنت التي تَتضمَّن تلك التعليقات بصياغة متناسقة ومترابطة. لاحظ أن تلك الأداة تَستخرِج افتراضيًا المعلومات المُتعلِّقة بكُلًا من الأصناف العامة والبرامج الفرعية العامة والمُتَغيِّرات الأعضاء العامة فقط، أي تلك المُصرَّح عنها باِستخدَام المُبدِّل public، ومع ذلك فهي تَسمَح بإنشاء تَوْثيق للعناصر غير العامة (non-public) من خلال خيار خاص. إذا لم تَعثُر الأداة javadoc على أية تعليقات Javadoc لعنصر معين، فإنها تُنشِئ واحدًا افتراضيًا يَتكوَّن من مُجرد معلومات بسيطة عن ذلك العنصر، مثل اسم المُتَغيِّر العضو ونوعه في حالة كان العنصر مُتَغيِّر عضو، أو كُلًا من اسم البرنامج الفرعي، ونوع القيمة المُعادة منه وقائمة مُعامِلاته في حالة كان العنصر برنامجًا فرعيًا. تعدّ تلك المعلومات مُجرد معلومات صياغية (syntactic)، أما لإضافة معلومات دلالية (semantics) واقعية، فلابُدّ من كتابة تعليق Javadoc. كمثال، يُمكِنك فَحْص "توثيق Javadoc للصنف TextIO". اُنشأت صفحة التَوْثيق تلك باِستخدَام أداة javadoc مع ملف الشيفرة المصدري TextIO.java. إذا حَمَّلت نسخة الكتاب المتاحة عبر الإنترنت، ستَجِدْ ذلك التوثيق بالمجلد TextIO_Javadoc. يُعدّ استخدام الترميز * ببداية كل سطر ضِمْن تعليقات Javadoc أمرًا اختياريًا؛ حيث تَحذفه أداة javadoc على أية حال. بالإضافة إلى النص العادي، قد تَحتوِي تعليقات Javadoc على ترميزات (codes) خاصة، مثل أوامر HTML الترميزية (HTML mark-up commands)‏. تُستخدَم لغة HTML عمومًا لإنشاء صفحات الانترنت، ولمّا كانت تعليقات Javadoc مَعنيَّة بالظهور على تلك الصفحات، فإن أداة javadoc تَنسَخ أي أوامر HTML بالتعليقات إلى صفحات الانترنت التي تُنشئها. لن يتناول الكتاب أيّ شرح تفصيلي عن HTML، لكن، كمُجرَّد مثال، تستطيع مثلًا إضافة <p> للإشارة إلى بداية فقرة جديدة. في حالة غياب أوامر HTML، تتجاهل الأداة الأسطر الفارغة والفراغات (spaces) الإضافية الموجودة بالتعليق. انتبه أيضًا للمحرفين & و ‎<‎؛ لأن لهما معنًى خاصًا بلغة HTML، ولذا لا ينبغي اِستخدَامهما بتعليقات Javadoc لمعنى غير تلك المَعانِي، ولكن يُمكِن كتابتهما باِستخدَام ‎&amp;‎ و ‎&lt‎;‎ على التوالي. يُوفِّر نظام التوثيق Javadoc ما يُعرَف باسم الوُسوم التوثيقية (doc tags). تُكتَب تلك الوسوم ضِمْن تعليقات Javadoc، بحيث تُعالجها أداة javadoc بعدّها نوعًا من الأوامر الخاصة. يبدأ أيّ وَسم تَوْثيقي (doc tag) بالمحرف @ مَتبوعًا باسمه. سنتناول ٤ وسوم (tags) فقط، هي كالتالي: الوُسوم ‎@author و ‎@param و ‎@return و ‎@throws. يُستخدَم الوسم ‎@author فقط مع الأصناف، وينبغي أن يُتبَع باسم المؤلف. تُستخدَم الوسوم الثلاثة الاخرى بتعليقات Javadoc التي تستهدف البرامج الفرعية بهدف تَوْفِير معلومات عن مُعاملاتها، وقيمها المُعادة، والاعتراضات (exceptions) التي قد تبلِّغ عنها. لابُدّ أن تُوْضَع تلك الأوسمة بنهاية التعليق، أي بَعْد وصف البرنامج الفرعي نفسه. تُكتَب بالصيغ (syntax) التالية: @param <parameter-name> <description-of-parameter> @return <description-of-return-value> @throws <exception-class-name> <description-of-exception> يُمكِن أن تمتد الأوصاف و و إلى عدة أسطر؛ حيث ينتهي أي وصف إما ببداية الوَسْم التوثيقي (doc tag) التالي أو بنهاية تعليق Javadoc بالكامل. يُمكِنك اِستخدَام الوَسْم ‎@param لوصف كل مُعامِل (parameter) يَستقبِله البرنامج الفرعي، وكذلك الوَسْم ‎@throws بقدر ما تريد تَوْثيقه من أنواع الاعتراضات (exception) المختلفة. وأخيرًا الوَسْم ‎@return والذي يُفْترَض كتابته للبرامج الفرعية التي تُعيد قيمة فعلية لا void. لا يُشترَط عمومًا كتابة تلك الوسوم (tags) بترتيب معين. اُنظر المثال التالي والذي يَستخدِم وُسوم التَوْثيق (doc tag) الثلاثة: /** * يحسب هذا البرنامج الفرعي مساحة المستطيل بفرض استقباله * لكلا من طول وعرض المستطيل. * ينبغي أن يكون كلا من طول وعرض المستطيل الممررين قيمة موجبة * @param width طول أحد جوانب المستطيل * @param height طول الجانب الآخر من المستطيل * @return مساحة المستطيل * @throws IllegalArgumentException إذا كان عرض أو طول المستطيل قيمة سالبة */ public static double areaOfRectangle( double height, double width ) { if ( width < 0 || height < 0 ) throw new IllegalArgumentException("Sides must have positive length."); double area; area = width * height; return area; } حَاوِل أن تَستخدِم تعليقات Javadoc بالشيفرة الخاصة بك، حتى لو لَمْ تَكُن تَنوِي إنشاء صفحة انترنت للتوثيق (documentation)؛ لأنها تُعدّ الصيغة القياسية لكتابة التوثيقات، لذا ستَكُون مألوفة لغالبية مُبرمجي الجافا. أما إذا أردت إنشاء صفحة انترنت للتَوْثيق، فستحتاج إلى اِستخدَام أداة javadoc، وهي متاحة كأمر بعُدة تطوير الجافا (JDK) التي ناقشناها بالقسم ٢.٦. تستطيع عمومًا اِستخدَام أداة javadoc بواجهة سطر الأوامر (command line interface) بنفس الطريقة التي تَستخدِم بها أوامر مثل javac و java. لاحِظ أنه يُمكِن تطبيق توثيق Javadoc أيضًا داخل بيئات التطوير المتكاملة (integrated development environments)، تُعرَف اختصارًا باسم IDE، التي تحدثنا عنها بالقسم ٢.٦. لن نَتَعرَّض لأيّ من تلك التفاصيل هنا، حيث يُمكِنك ببساطة مراجعة توثيق بيئة البرمجة (programming environment) الخاصة بك. الاستيراد الساكن (static import) كنقطة أخيرة بهذا القسم، سنتناول امتدادًا للمُوجِّه (directive)‏ import. رأيت بالفعل كيف مَكَّنَك المُوجِّه import من الإشارة إلى صَنْف مثل java.util.Scanner باِستخدَام الاسم البسيط للصَنْف Scanner. لكنك ما زلت مُضطرًا لاِستخدَام الأسماء المُركَّبة للإشارة إلى المُتَغيِّرات الأعضاء الساكنة (static member variables) مثل System.out، والتوابع الساكنة (static methods) مثل Math.sqrt. في الواقع، تَتَوفَّر صياغة آخرى من المُوجِّه import، تَستورِد الأعضاء الساكنة (static members) الموجودة بصَنْف معين بنفس الطريقة التي يَستورَد بها المُوجِّه import الأصناف (classes) من حزمة (package). تُسمَى تلك الصياغة من المُوجِّه باسم الاستيراد الساكن (static import). فمثلًا، لاستيراد اسم عضو ساكن (static member) واحد من صَنْف، نَكتُب الصيغة (syntax) التالية : import static <package-name>.<class-name>.<static-member-name>; بالمثل، قد تُكتَب الصيغة التالية لاستيراد جميع الأعضاء الساكنة العامة (public static members) ضِمْن صَنْف معين: import static <package-name>.<class-name>.*; على سبيل المثال، إذا كَتَبَت المُوجِّه import التالي قَبْل تعريف صَنْف (class definition) معين: import static java.lang.System.out; فإنك تستطيع بَعْدها -ضِمْن ذلك الصَنْف- اِستخدَام الاسم البسيط out بدلًا من الاسم المُركَّب System.out، وكذلك كتابة out.println بدلًا من System.out.println. إذا كنت ستَستخدِم الصَنْف Math بكثرة ضِمْن صَنْف معين، فلربما قد تُفضِّل اِستِباق تعريف ذلك الصنف بالمُوجِّه import التالي: import static java.lang.Math.*; وهو ما سيَسمَح لك بكتابة sqrt بدلًا من Math.sqrt، وكتابة log بدلًا من Math.log، وأيضًا PI بدلًا من Math.PI، وغيره. يُمكِنك أيضًا استيراد الدالة getlnInt من الصنف TextIO باِستخدَام: import static textio.TextIO.getlnInt; تنبيه: يتَطلَّب مُوجِّه الاستيراد الساكن (static import directive) تَخْصيص اسم الحزمة حتى مع الأصناف المُعرَّفة بالحزمة القياسية java.lang، مما يَعنِي أنك لن تَكُون قادرًا على تَّنْفيذ أيّ استيراد ساكن (static import) من صَنْف مُعرَّف بالحزمة الافتراضية (default package)؛ لأن ليس لها اسم. ترجمة -بتصرّف- للقسم Section 6: APIs, Packages, Modules, and Javadoc من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

يُخْزَّن البرنامج الفرعي (subroutine) بذاكرة الحاسوب على هيئة سِلسِلة نصية طويلة مُكوَّنة من الرقمين صفر وواحد، ولذلك فإنه لا يَختلف كثيرًا عن البيانات (data)، مثل الأعداد الصحيحة والسَلاسِل النصية والمصفوفات، والتي تُخْزَّن أيضًا بنفس الطريقة. ربما اِعتدت التفكير بكُلًا من البرامج الفرعية والبيانات على أساس أنهما شيئان مختلفان تمامًا، ولكن في الواقع يَتعامَل الحاسوب مع البرنامج الفرعي على أساس أنه مجرد نوع آخر من البيانات. تَسمَح حتى بعض اللغات البرمجية بالتَعامُل مع البرامج الفرعية بنفس الطريقة التي يَتعامَل معها الحاسوب، وهو ما أُضيف إلى الجافا على هيئة تعبيرات لامدا (lambda expressions) منذ الإصدار ٨. أصبحت تعبيرات لامدا أكثر شيوعًا ببرامج الجافا، وهي مفيدة في العموم، ولكن تَبرُز أهميتها بصورة أكبر ببرمجة واجهات المُستخدِم الرُسومية (GUI)، كالتَعامُل مع "أدوات تَحكُّم واجهة المُستخدَم الرسومية JavaFX ‏(JavaFX GUI toolkit)"، وهو ما سنتناوله بالفصل السادس، كما سنَتَعرَّض لها مجددًا بنهاية الفصل الخامس، لذا يُمكِنك تَخطِّي هذا القسم إذا أردت إلى ذلك الحين. الدوال الكيانية (first-class functions) يُمكِننا كتابة دالة لحِسَاب قيمة مربع العدد، بحيث تَستقبِل ذلك العدد كمُعامِل صُّوري أو وهمي (dummy parameter)، كالتالي: static double square( double x ) { return x*x; } كالعادة، لابُدّ من تَخْصيص اسم لتلك الدالة، وفي تلك الحالة كان square، وعليه تُصبِح تلك الدالة جزءًا دائمًا من البرنامج (program)، وهو ما قد لا يَكُون مُلائمًا؛ بالأخص إذا كنت تَنوِي اِستخدَام الدالة مرة واحدة فقط. لامدا (lambda) هو أحد حروف الأبجدية الإغريقية (Greek alphabet)، والذي اِستخدَمه عالم الرياضيات ألونزو تشرتش (Alonzo Church) أثناء دراسته للدوال القابلة للحِسَاب (computable functions). على سبيل المثال، إذا كنا نُريد حِسَاب قيمة مربع عدد، وليكن x، فقد تَظُنّ أن الترميز x2 يُمثِل "دالة" تَحسِب مربع x، لكنه، في الواقع، ليس سوى تعبير (expression) يُمثِل "نتيجة" حِسَاب مربع x. قَدَّمَ ألونزو تشرتش (Alonzo Church) ترميز لامدا (lambda notation) والذي يُمكِن اِستخدَامه لتعريف دالة (function) بدون تَخْصيص اسم لها. بالتحديد اِستخدَم الترميز lambda(x).x2 (في الواقع يُستخدَم الحرف الإغريقي لامدا ذاته وليس الكلمة نفسها) للإشارة إلى "دالة x معطاة بواسطة x2". يُعدّ هذا الترميز دالة مجرَّدة (function literal)، أيّ تُمثِل قيمة من النوع "دالة (function)" بنفس الطريقة التي تُعدّ بها القيمة 42 عددًا صحيحًا مُجرَّدًا (integer literal) يُمثِل قيمة من النوع int. ينبغي أن تَدْفَعك الدوال المُجرَّدة (function literals) إلى التَفكير بالدوال (function) على أنها مُجرَّد نوع آخر من القيم، وعندما تَصِل إلى تلك المرحلة، فإنك ستَكُون قادرًا على تَطْبِيق نفس تلك الأشياء التي اعتدت إجرائها على القيم الآخرى على الدوال أيضًا، كإِسْناد دالة إلى مُتَغيِّر، أو تمرير دالة كمُعامِل (parameter) إلى برنامج فرعي (subroutine)، أو إعادة دالة كقيمة من برنامج فرعي، أو حتى إنشاء مصفوفة دوال (array of functions). تَسمَح بعض لغات البرمجة بالقيام بكل تلك الأشياء، ويُقال عندها أنها تُدعِّم "الدوال الكيانيَّة (first-class functions)" أو أنها تُعامِل الدوال بعدّها كائنات كيانيَّة (first-class objects). تُوفِّر لغة الجافا كل تلك الأشياء من خلال تعبيرات لامدا (lambda expressions)، والتي تَختلِف صيغتها عن الترميز الذي اِستخدَمه ألونزو تشرتش (Alonzo Church)، فهي الواقع، لا تَستخدِم حتى كلمة لامدا (lambda) على الرغم من مُسماها. تُكتَب دالة حِسَاب مربع العدد بتعبير لامدا (lambda expression) بلغة الجافا، كالتالي: x -> x*x يُنشِئ العَامِل ‎->‎ تعبير لامدا، بحيث تَقَع المُعامِلات الوهمية أو الصُّوريّة (dummy parameter) على يسار العَامِل، بينما يَقَع التعبير (expression) المسئول عن حِسَاب قيمة الدالة على يمينه. قد ترى تعبير لامدا بالأعلى مُمرَّرًا كمُعامِل فعليّ (actual parameter) إلى برنامج فرعي، أو مُسنَد إلى مُتَغيِّر، أو مُعاد من دالة. إذًا، هل الدوال بلغة الجافا كيانيَّة (first-class)؟ لا تَتَوفَّر إجابة واضحة على هذا السؤال، لأن لغة الجافا لا تُدعِّم بعض الأشياء الآخرى المُتوفِّرة ضِمْن لغات برمجية آخرى. فمثلًا، في حين تستطيع إِسْناد تعبير لامدا المُعرَّف بالأعلى إلى مُتَغيِّر اسمه sqr، فإنك لن تستطيع بَعْدها اِستخدَام ذلك المُتَغيِّر كما لو كان دالة فعليّة، أيّ لا تستطيع كتابة sqr(42)‎. لغة الجافا عمومًا هي لغة صارمة في تَحْدِيد النوع (strongly typed)، ولذلك لكي تَتَمكَّن من إِنشاء المُتَغيِّر sqr، فعليك التَّصْريح عنه أولًا وهو ما يَتضمَّن تَخْصيص نوعه، فيا تُرى ما هو ذلك النوع الذي يَتناسب مع قيمة هي عبارة عن دالة؟ تُوفِّر الجافا ما يُعرَف باسم واجهة نوع الدالة (functional interface) لهذا الغرض، وسنناقشها بَعْد قليل. ملاحظة أخيرة: على الرغم من ارتباط مصطلح الدالة (function) بتعبيرات لامدا (lambda expressions) بدلًا من مصطلحات مثل برنامج فرعي (subroutine) أو تابع (method)، فإنها في الواقع لا تَقْتصِر على تمثيل الدوال (functions)، وإنما يُمكِنها تمثيل أي برنامج فرعي (subroutines)، وبصورة عشوائية. واجهات نوع الدالة (functional interfaces) كي تَتَمكَّن من اِستخدَام برنامج فرعي (subroutine) معين، فلابُدّ أن تَعرِف كُلًا من اسمه، وعدد المُعامِلات (parameters) التي يَستقبِلها، وأنواعها، بالإضافة إلى نوع القيمة المُعادة (return type) من ذلك البرنامج الفرعي. تُوفِّر لغة الجافا ما يُعرَف باسم واجهات نوع الدالة (functional interface)، وهي أَشْبَه بالأصناف (class)، حيث تُعرَّف بملف امتداده هو ‎.java كأي صَنْف، وتَتضمَّن تلك المعلومات المذكورة بالأعلى عن برنامج فرعي وحيد. انظر المثال التالي: public interface FunctionR2R { double valueAt( double x ); } تُصرِّح الشيفرة بالأعلى عن واجهة نوع الدالة FunctionR2R، والموجودة بملف يَحمِل اسم FunctionR2R.java. تُصرِّح تلك الواجهة عن الدالة valueAt، والتي تَستقبِل مُعامِل وحيد من النوع double، وتُعيد قيمة من النوع double. تَفرِض قواعد الصيغة تَخْصيص اسم للمُعامِل -x بالأعلى- على الرغم من أنه في الواقع ليس ذا أهمية هنا، وهو ما قد يَكُون مزعجًا نوعًا ما. ها هو مثال آخر: public interface ArrayProcessor { void process( String[] array, int count ); } تَتضمَّن لغة الجافا الكثير من واجهات نوع الدالة القياسية (standard functional interfaces) بصورة افتراضية. تُعدّ واجهة نوع الدالة Runnable واحدة من أهم تلك الواجهات، وأبسطها، والمُعرَّفة كالتالي: public interface Runnable { public void run(); } سنَستخدِم واجهات نوع الدالة (functional interfaces) الثلاثة بالأعلى للأمثلة التالية بهذا القسم. تُوفِّر لغة الجافا أيضًا ما يُعرَف باسم الواجهات (Interfaces)، والتي هي في الواقع أعم وأشمل، وربما أكثر تعقيدًا من واجهات نوع الدالة (functional interfaces). سنتعلَّّم المزيد عنها بالقسم ٥.٧. سنُقصِر حديثنا بهذا القسم على واجهات نوع الدالة (functional interfaces)؛ لارتباطها بموضوعنا الرئيسي: تعبيرات لامدا (lambda expressions). يُعدّ اسم واجهة نوع الدالة نوعًا (type)، تمامًا كالأنواع String و double، وكأيّ نوع، فإنه يُمكِن اِستخدَامه للتَّصْريح عن المُتَغيِّرات، والمُعامِلات، وكذلك لتَخْصيص نوع القيمة المُعادة (return type) من الدوال، ويُمكِن إِسْناد تعبيرات لامدا (lambda expression) كقيم للمُتَغيِّرات من ذلك النوع. في الواقع، تَتضمَّن واجهة نوع الدالة (functional interface) قالبًا (template) لبرنامج فرعي وحيد، وينبغي لتعبير لامدا (lambda expression) المُسنَد أن يَكُون مُتطابِقًا مع ذلك القالب. تعبيرات لامدا (lambda Expressions) يُعدّ أي تعبير لامدا (lambda expression) تمثيلًا لبرنامج فرعي مجهول الاسم (anonymous subroutine)، أيّ لا يَمتلك اسمًا، ولكنه في المقابل، وكأيّ برنامج فرعي، لديه قائمة من المُعامِلات الصُّوريّة (formal parameter list)، بالإضافة إلى التعريف (definition) نفسه، ويُكتَب عمومًا بالصيغة (syntax) التالية: ( <parameter-list> ) -> { <statements> } كما هو الحال مع البرامج الفرعية العادية، يُمكِن لقائمة المُعامِلات -بالأعلى- أن تَكُون فارغة، أو قد تتكوَّن من تَّصْريح عن مُعامِل (parameter declaration) وحيد أو أكثر، بحيث يُفصَل بين كل تَّصْريح والذي يليه بفاصلة (comma)، وبحيث يَتكوَّن كل تَّصْريح من نوع المُعامِل متبوعًا باسمه. في الواقع، تُبسَّط عادة تلك الصيغة وفقًا لمجموعة من القواعد: أولًا: يُمكِن حَذْف أنواع المُعامِلات إذا كان استنباطها من السِّياق مُمكِنًا. على سبيل المثال، إذا كان هناك تعبير لامدا مُعرَّف على أنه من النوع FunctionR2R، فإن مُعامِل التعبير لابُدّ وأن يَكُون من النوع double، ولذلك فإنه، في تلك الحالة، ليس من الضروري تَخْصيص نوع المُعامِل ضِمْن تعبير اللامدا. ثانيًا، يُمكِن حَذْف الأقواس () حول قائمة المُعامِلات (parameter list) إذا كانت مُكوَّنة من مُعامِل وحيد غَيْر مُحدَّد النوع. ثالثًا، يُمكِن حَذْف الأقواس {} الموجودة على الجانب الأيمن من العَامِل ‎->‎ إذا كانت تَحتوِي على تَعْليمَة استدعاء برنامج فرعي (subroutine call) وحيدة. أخيرًا، إذا كان الجانب الأيمن من العَامِل ‎->‎ مكتوبًا بالصيغة { return <expression>;‎ }، فيُمكِن تبسيطها إلى التعبير وحَذْف أي شيء آخر. بفَرْض أننا نريد كتابة دالة لحِسَاب مربع القيم من النوع double، فإن نوع تلك الدالة هو من نفس نوع واجهة نوع الدالة FunctionR2R المُعرَّفة بالأعلى. الآن، إذا كان sqr مُتَغيِّرًا من النوع FunctionR2R، فإننا نستطيع أن نُسنِد تعبير لامدا (lambda expression) كقيمة لذلك المُتَغيِّر، ويُعدّ عندها ذلك التعبير تمثيلًا للدالة المطلوبة. يُمكِن القيام بذلك بأي من الصِيَغ التالية: sqr = (double x) -> { return x*x; }; sqr = (x) -> { return x*x; }; sqr = x -> { return x*x; }; sqr = x -> x*x; sqr = (double fred) -> fred*fred; sqr = (z) -> z*z; تُعرِّف تعبيرات لامدا (lambda expressions) الستة بالأعلى نفس الدالة بالضبط، وأُضيفت آخر تَعْليمَتين (statements) خصيصًا؛ للتأكيد على أن أسماء المُعامِلات غير مهمة، فهى بالنهاية مجرد مُعامِلات وهمية أو صُّوريّة (dummy parameters). لمّا كان المُصرِّف (compiler) على علم بكون المُتَغيِّر sqr من النوع FunctionR2R، ولأن النوع FunctionR2R يتطلَّب مُعامِلًا من النوع double، فقد تَمَكَّنا من حَذْف نوع المُعامِل double. يُمكِن اِستخدَام تعبيرات لامدا فقط ضِمْن السِّياقات التي يستطيع فيها المُصرِّف (compiler) استنباط نوعها، ولذلك لابُدّ من كتابة نوع المُعامِل إذا كان حَذْفه سيَتسبَّب بغموض نوع التعبير. لا يُعدّ المُتَغيِّر sqr -كما هو مُعرَّف بالأعلى- دالة (function) تمامًا، وإنما هو قيمة من النوع FunctionR2R، وبحسب ما هو مُخصَّص بتعريف الواجهة (interface definition)‏ FunctionR2R، فإن ذلك المُتَغيِّر لابُدّ وأن يَحتوِي على دالة تَحمِل اسم valueAt. يمكن استدعاء تلك الدالة من خلال اسمها الكامل sqr.valueAt، فمثلًا يُمكِن كتابة sqr.valueAt(42)‎ أو sqr.valueAt(x) + sqr.valueAt(y)‎. إذا كانت قائمة مُعامِلات تعبير لامدا مُكوَّنة من أكثر من مُعامِل واحد، فإن الأقواس () المُحيطة بقائمة المُعامِلات (parameters list) لم تَعُدْ اختيارية. اُنظر المثال التالي، والذي يَستخدِم واجهة نوع الدالة ArrayProcessor، كما يُبيِّن طريقة كتابة تعبير لامدا عندما يكون تعريفها مُتعدِّد الأسطر (multiline definition): ArrayProcessor concat; concat = (A,n) -> { // الأقواس هنا مطلوبة String str; str = ""; for (int i = 0; i < n; i++) str += A[i]; System.out.println(str); }; // الفاصلة المنقوطة هنا ليست جزءًا من تعبير لامدا // وإنما تشير إلى انتهاء تعليمة الإسناد String[] nums; nums = new String[4]; nums[0] = "One"; nums[1] = "Two"; nums[2] = "Three"; nums[3] = "Four"; for (int i = 1; i < nums.length; i++) { concat.process( nums, i ); } مما سينتج عنه الخَرْج التالي: One OneTwo OneTwoThree OneTwoThreeFour تُصبِح الأمور أكثر تشويقًا عند تمرير تعبير لامدا كمُعامِل فعليّ (actual parameter)، وهو في الواقع الاِستخدَام الأكثر شيوعًا لتعبيرات لامدا. افترض أن لدينا الدالة التالية مثلًا: /** * احسب قيمة التعبير‫ f(start) + f(start+1) + ... + f(end) * حيث‫ f عبارة عن دالة تُستقبل كمعامل * ‫قيمة المعامل end لابد أن تكون أكبر من أو تساوي start */ static double sum( FunctionR2R f, int start, int end ) { double total = 0; for (int n = start; n <= end; n++) { total = total + f.valueAt( n ); } return total; } لمّا كانت f من النوع FunctionR2R، فإن قيمة f عند n تُكتَب على الصورة f.valueAt(n)‎. يُمكِن تمرير تعبير لامدا (lambda expression) كقيمة للمُعامِل الأول عند استدعاء الدالة sum، كالتالي: System.out.print("The sum of n squared for n from 1 to 100 is "); System.out.println( sum( x -> x*x, 1, 100 ) ); System.out.print("The sum of 2 raised to the power n, for n from 1 to 10 is "); System.out.println( sum( num -> Math.pow(2,num), 1, 10 ) ); كمثال آخر، افترض أن لدينا برنامجًا فرعيًا (subroutine) ينبغي أن يُنفِّذ مُهِمّة (task) مُعطاة عدة مرات، يُمكِننا ببساطة تمرير تلك المُهِمّة كمُعامِل من النوع Runnable، كالتالي: static void doSeveralTimes( Runnable task, int repCount ) { for (int i = 0; i < repCount; i++) { task.run(); // نفذ المهمة } } نستطيع الآن طباعة السِلسِلة النصية "Hello World" عشر مرات باستدعاء التالي: doSeveralTimes( () -> System.out.println("Hello World"), 10 ); تَتَكوَّن قائمة مُعامِلات (parameter list) تعبيرات لامدا من النوع Runnable من زوج فارغ من الأقواس ()؛ وذلك لتتماشى مع البرنامج الفرعي المُصرَّح عنه ضِمْن واجهة نوع الدالة Runnable. اُنظر المثال التالي: doSeveralTimes( () -> { int count = 5 + (int)(21*Math.random()); for (int i = 1; i <= count; i++) { System.out.print(i + " "); } System.out.println(); }, 100); على الرغم من أن الشيفرة بالأعلى قد تبدو معقدة نوعًا ما، إلا أنها، في الواقع، مُكوَّنة من تَعْليمَة وحيدة هي تَعْليمَة استدعاء البرنامج الفرعي doSeveralTimes. يَتَكوَّن مُعامِل البرنامج الفرعي الأول من تعبير لامدا (lambda expression) قد امتد تعريفه إلى عدة أسطر، أما مُعامِله الثاني فهو القيمة ١٠٠، وتُنهِي الفاصلة المنقوطة (semicolon) بنهاية آخر سطر تَعْليمَة استدعاء البرنامج الفرعي (subroutine call). اطلعنا على عدة أمثلة تُسنَد فيها تعبيرات لامدا (lambda expression) إلى مُتَغيِّرات، وآخرى تُمرَّر فيها تعبيرات لامدا كمُعامِلات فعليّة (actual parameter). تَبَقَّى الآن أن نراها مُستخدَمة كقيمة مُعادة (return value) من دالة. اُنظر المثال التالي: static FunctionR2R makePowerFunction( int n ) { return x -> Math.pow(x,n); } وبالتالي، ستُعيد makePowerFunction(2)‎ قيمة من النوع FunctionR2R تَحسِب مربع قيمة المُعامِل المُمرَّر، بينما ستُعيد makePowerFunction(10)‎ قيمة من النوع FunctionR2R تَحسِب قيمة المُعامِل المُمرَّر مرفوعًا للأس ١٠. يُوضِح هذا المثال أيضًا أن تعبيرات لامدا (lambda expression) تستطيع اِستخدَام مُتَغيِّرات آخرى إلى جانب مُعامِلاتها، مثل n في المثال بالأعلى. (في الواقع هناك بعض القيود لتَحْدِيد متى يُمكِن القيام بذلك). مراجع التوابع (Method References) لنفْترِض أننا نريد كتابة تعبير لامدا (lambda expression) من النوع FunctionR2R، بحيث يُمثِل دالة تَحسِب الجذر التربيعي. نستطيع كتابته على الصورة x -> Math.sqrt(x)‎، ولكننا إذا دققنا النظر، سنَجِدْ أن تعبير لامدا، في تلك الحالة تحديدًا، ليس سوى مجرد مُغلِّف (wrapper) بسيط للدالة Math.sqrt الموجودة بالفعل. ولهذا تُوفِّر الجافا ما يُعرَف باسم مَراجِع التوابع (method reference)؛ لاِستخدَامها في الحالات المشابهة (تَذَكَر أن "التابع [method]" هو مجرد كلمة آخرى للإشارة إلى "البرنامج الفرعي [subroutine]" بلغة الجافا). نستطيع مثلًا اِستخدَام المَرجِع التابعي Math::sqrt، والذي يُعدّ اختصارًا لتعبير اللامدا المذكور سلفًا، أينما أَمْكَن اِستخدَام تعبير اللامدا المناظر، كتمريره مثلًا كمُعامِل للدالة sum المُعرَّفة بالأعلى، كالتالي: System.out.print("The sum of the square root of n for n from 1 to 100 is "); System.out.println( sum( Math::sqrt, 1, 100 ) ); فقط لو أَمْكَننا اِستخدَام الاسم Math.sqrt هنا بدلًا من الاستعانة بترميز (notation) جديد ::! في الواقع، الترميز Math.sqrt مُعرَّف بالفعل ضِمْن الصَنْف Math لكن للإشارة إلى مُتَغيِّر اسمه sqrt. يُمكِن عمومًا اِستخدَام مَراجِع التوابع (method reference) بدلًا من تعبيرات لامدا (lambda expression) التي يَقْتصِر دورها على اِستدعاء أحد التوابع الساكنة (static method) الموجودة مُسْبَّقًا. تُكتَب مَراجِع التوابع على الصورة التالية: <classname>::<method-name> لا يَقْتصِر هذا الترميز (notation) على التوابع الساكنة، أي تلك المُنتمية للأصناف (classes)، وإنما يَمْتَدّ إلى تلكم المُنتمية للكائنات (objects) كذلك. على سبيل المثال، إذا كان str متغير من النوع String، فإن str بطبيعة الحال سيَحتوِي على التابع str.length()‎، وفي هذه الحالة، يُمكِن اِستخدَام المَرجِع التابعي str::length كتعبير لامدا من واجهة نوع الدالة SupplyInt المُعرَّفة كالتالي: public interface SupplyInt { int get( ); } ترجمة -بتصرّف- للقسم Section 5: Lambda Expressions من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

يُطلَق على البرامج الفرعية (subroutine) التي تُعيد قيمة اسم "الدوال (function)"، والتي يُمكِنها أن تُعيد قيمة من نوع واحد مُحدَّد ضِمْن التعريف ويُسمى النوع المُعاد (return type) من الدالة. بإِمكَانك استدعاء الدوال (function call) في العموم بأيّ مكان يَتوقَّع فيه الحاسوب قيمة (value)، مثل الجانب الأيمن من تَعْليمَات الإِسْناد (assignment statement)، أو كمُعامِل فعليّ (actual parameter) بتَعْليمَات استدعاء البرامج الفرعية، أو كجُزء من تعبير (expression) أكبر. يُمكِن حتى اِستخدَام الدوال من النوع boolean، أي التي تُعيد قيمة من ذلك النوع، مَحل الشَّرْط (condition) ضِمْن تَعْليمَات مثل if و while و for و do..while. يُمكِن أيضًا اِستخدَام تَعْليمَة استدعاء دالة (function call)، كما لو كانت برنامجًا فرعيًا، أيّ كما لو أنها لا تُعيد قيمة. في تلك الحالة، يَتجاهَل الحاسوب القيمة المُعادة من البرنامج الفرعي، وهو ما يَكُون منطقيًا في بعض الأحيان. على سبيل المثال، تَقرأ الدالة TextIO.getln()‎ سَطْرًا مُدْخَلًا مِنْ قِبَل المُستخدِم وتُعيده كقيمة من النوع String. عادة، يُسنَد السَطْر المُعاد من تلك الدالة إلى مُتَغيِّر؛ لكي يُستخدَم لاحقًا، كما في التَعْليمَة name = TextIO.getln();‎. لكن، يُمكِن اِستخدَام تلك الدالة ضِمْن تَعْليمَة استدعاء برنامج فرعي على الصورة TextIO.getln();‎، والتي، كالعادة، ستَستمِر بقراءة مُدْخَلات المُستخدِم إلى أن تَصِل إلى محرف العودة إلى بداية السطر (carriage return). لمّا لم تُسنَد القيمة المُعادة من تلك الدالة إلى مُتَغيِّر، أو تُستخدَم ضِمْن تعبير (expression)، فإنها تُستبعَد ببساطة، لذا يَكُون تأثير استدعاء البرنامج الفرعي في تلك الحالة هو مجرد قراءة بعض المُدْخَلات واِستبعَادها، وهو الشيء الذي قد تَرغَب به في بعض الأحيان. تعليمة return بوصولك إلى هنا، فأنت قد تَعلَّمت طريقة استدعاء الدوال (functions) -التي تُعيد قيم فعليّة- مثل Math.sqrt()‎ و TextIO.getInt()‎، لكنك لَمْ تَكتُب أيّ دالة خاصة بك بَعْد. في الواقع، ستبدو كتابة الدوال أمرًا مألوفًا بالنسبة لك؛ فهي بالنهاية مُشابهة تمامًا لصيغة كتابة أيّ برنامج فرعي (subroutine) عادي باستثناء ضرورة اِستخدَام التَعْليمَة return؛ لتَخْصِيص القيمة التي سيُعيدها البرنامج الفرعي (return value). تُكتَب تَعْليمَة return بالصيغة (syntax) التالية: return <expression>; يُمكِن اِستخدَام تَعْليمَة return بالأعلى داخل تعريف الدوال فقط (function definition)، ولابُدّ لنوع التعبير المَكْتُوب بَعْد التَعْليمَة أن يَتماشى مع النوع المُعاد (return type) المُخصَّص ضِمْن تعريف الدالة، أيّ لابُدّ أن يؤول ذلك التعبير إلى قيمة هي من نوع يُمكِن إِسْناده -بواسطة تَعْليمَة إِسْناد (assignment)- إلى النوع المُعاد (return type) من الدالة والمُخصَّص بتعريفها (definition). عندما يُنفِّذ الحاسوب تَعْليمَة return، فإنه يَحسِب قيمة التعبير المُخصَّص، ثم يُنهِي تَّنْفيذ الدالة، وأخيرًا، يُعيد قيمة التعبير لتُصبِح القيمة المُعادة (return value) من الدالة. اُنظر تعريف الدالة التالي على سبيل المثال: static double pythagoras(double x, double y) { return Math.sqrt( x*x + y*y ); } بفَرْض تَّنْفيذ الحاسوب لتَعْليمَة إِسْناد تَتضمَّن تَعْليمَة استدعاء الدالة بالأعلى، مثل totalLength = 17 + pythagoras(12,5);‎، فإنه سيُحاوِل تَحْصِيل قيمة تَعْليمَة الاستدعاء pythagoras(12,5)‎، لذلك سيبدأ بإِسْناد قيم المُعامِلات الفعليّة (actual parameters) ‏المُمرَّرة، أيّ ١٢ و ٥، إلى المُعامِلات الصُّوريّة (formal parameters)‏ x و y بتعريف الدالة، ثم سينتقل إلى تَّنْفيذ مَتْن الدالة (function body)، وبالتالي سيضطرّ إلى تَحْصِيل قيمة التعبير Math.sqrt(12.0*12.0 + 5.0*5.0)‎ والتي تؤول إلى القيمة 13.0، ثم سيُعيد هذه القيمة لتَكُون القيمة المُعادة (return value) من الدالة، وعليه تُستبدَل القيمة 13.0 بتَعْليمَة استدعاء الدالة، فتصبح تَعْليمَة الإِسْناد وكأنها مَكْتُوبة على الصورة totalLength = 17+13.0. أخيرًا، تُضاف القيمة المُعادة (return value) إلى العدد 17 ثم تُخْزَن النتيجة 30.0 بالمُتَغيِّر totalLength. لاحظ أنه وبينما تُنفَّذ الدالة، فإنك قد تَتَمكَّن من تَحْصِيل القيمة المُفْترَض إعادتها منها، وفي تلك الحالة، تستطيع اِستخدَام تَعْليمَة return؛ لإعادة تلك القيمة مباشرة، ومِنْ ثَمَّ تَخَطِّي أية تَعْليمَات آخرى بمَتْن الدالة، دون الحاجة إلى الانتظار إلى نهاية المَتْن، أيّ أنه ليس من الضروري أن تَكُون تَعْليمَة return هي آخر تَعْليمَة بمَتْن الدالة، بل يُمكِن اِستخدَامها بأي مكان ضِمْن المَتْن. ولكن، لابُدّ دائمًا من إعادة قيمة ما من الدالة وذلك بجميع مسارات التَّنْفيذ المُحتمَلة التي قد تَتَّخذها الدالة. كما ذَكَرَنا مُسْبَّقًا، لابُدّ دائمًا من كتابة تَعْليمَة return مَتبوعة بتعبير (expression) ضِمْن تعريف أي دالة (function)؛ لأن الدوال دائمًا ما تُعيد قيمة. في المقابل، لا يُعدّ ذلك ضروريًا مع البرامج الفرعية من غير الدوال (non-function)، أي تلك التي تَستخدِم void ضِمْن تعريفها للتَّصْريح عن نوعها المُعاد، فهي في النهاية لا تُعيد قيمة، ومع ذلك يَظِلّ اِستخدَام تَعْليمَة return ضِمْن هذا السِّياق مُمكنًا، بحيث يَقْتصِر دورها على إنهاء تَّنْفيذ البرنامج الفرعي بمكان ما وسط المَتْن وإعادة التَحكُّم (return control) مرة آخرى إلى سَطْر الشيفرة المسئول عن استدعاء البرنامج الفرعي. تُكتَب تَعْليمَة return في تلك الحالة على الصورة return;‎ بدون تعبير (expression). بالإضافة إلى ما سبق، قد تُستخدَم تَعْليمَة return أيضًا داخل حَلْقة تَكْرار (loop) لإنهاء كُلًا من الحَلْقة (loop) والبرنامج الفرعي الحاضن لها. بالمثل، قد تُستخدَم بتَعْليمَة switch، للخروج من كُلًا من تَعْليمَة switch والبرنامج الفرعي الحاضن لها، أيّ ستَجِدْ أحيانًا تَعْليمَة return مُستخدَمة ضِمْن سِّياقات اعْتَدْت فيها استخدام تَعْليمَة break. أمثلة على الدوال (functions) تَعرَّضنا لمسألة حِسَاب قيم عناصر مُتتالية الأعداد"3N+1" عدة مرات بما في ذلك القسم السابق. يُمكِننا تعريف دالة (function) بسيطة جدًا، تَستقبِل قيمة العنصر الحالي بالمُتتالية، ثم تُعيد قيمة عنصر المتتالية التالي. اُنظر الشيفرة التالية: static int nextN(int currentN) { if (currentN % 2 == 1) // ‫إذا كان currentN فرديًا return 3*currentN + 1; // أعد تلك القيمة else return currentN / 2; // إذا لم يكن، أعد تلك القيمة } نُلاحِظ أن تعريف الدالة بالأعلى يَتضمَّن تَعْليمَتي return. ستُنفَّذ دائمًا تَعْليمَة return واحدة فقط بِغَضّ النظر عن عدد تلك التَعْليمَات المُستخدَمة ضِمْن التعريف. يُفضِّل بعض المبرمجين كتابة تَعْليمَة return وحيدة بنهاية الدالة، ويحاولوا القيام بذلك قدر الإمكان؛ خاصة وأن ذلك يُسهِل من العثور على تَعْليمَة return ضِمْن التعريف. فمثلًا، يُمكِننا إعادة كتابة الدالة nextN()‎ -المُعرَّفة بالأعلى- مرة آخرى على النحو التالي: static int nextN(int currentN) { int answer; // متغير يحمل القيمة المعادة من الدالة if (currentN % 2 == 1) // ‫إذا كان currentN فرديًا answer = 3*currentN+1; // أسند القيمة إلى المتغير else answer = currentN / 2; // إذا لم يكن، أسند القيمة إلى المتغير return answer; // لا تنسى أن تعيد المتغير } دَعْنَا الآن نَكتُب برنامجًا فرعيًا (subroutine) لحِسَاب قيم عناصر المُتتالية، لكن بالاعتماد على الدالة nextN هذه المرة. نظرًا لكَوْن الدالة nextN قصيرة نوعًا ما، فإن التَحْسِينات المُجراة على البرنامج الفرعي ليست ذا شأن بالموازنة مع نسخة البرنامج بالقسم ٤.٣. في المقابل، إذا كانت الدالة nextN()‎ طويلة لكَوْنها مثلًا تَحسِب عملية معقدة، فعندها سيَكُون من المنطقي إخفاء ذلك التعقيد بداخل دالة منفصلة: static void print3NSequence(int startingValue) { int N; // أحد عناصر المتتالية int count; // عدد عناصر المتتالية N = startingValue; // أول قيمة بالمتتالية count = 1; System.out.println("The 3N+1 sequence starting from " + N); System.out.println(); System.out.println(N); while (N > 1) { // ‫احسب قيمة عنصر المتتالية التالي باستدعاء الدالة nextN N = nextN( N ); count++; // أزد عدد عناصر المتتالية بمقدار الواحد System.out.println(N); // اطبع قيمة العنصر } System.out.println(); System.out.println("There were " + count + " terms in the sequence."); } اُنظر المثال التالي للدالة letterGrade، والتي تَستقبِل درجة عددية (numerical grade)، وتُحوِّلها إلى نظيرتها المحرفية (letter grade) بالاستعانة بمقياس درجات (grading scale) تقليدي: /** * أعد الدرجة المحرفية المناظرة للدرجة العددية الممررة للدالة كمعامل */ static char letterGrade(int numGrade) { if (numGrade >= 90) return 'A'; // 90 or above gets an A else if (numGrade >= 80) return 'B'; // 80 to 89 gets a B else if (numGrade >= 65) return 'C'; // 65 to 79 gets a C else if (numGrade >= 50) return 'D'; // 50 to 64 gets a D else return 'F'; } // ‫نهاية الدالة letterGrade تستطيع الدوال أن تُعيد قيم من أي نوع، فمثلًا، نوع القيمة المُعادة (return type) من الدالة letterGrade()‎ -بالأعلى- هو النوع char، أما الدالة المُعرَّفة بالمثال التالي، فإنها تُعيد قيمة (return value) من النوع boolean. اُنظر الشيفرة التالية، واحْرِصْ على قراءة التعليقات (comments)؛ لأنها تُوضِح بعض النقاط المثيرة للاهتمام: /** * تعيد هذه الدالة القيمة المنطقية‫ true إذا كان N عدد أولي. * ‫العدد الأولي هو عدد صحيح أكبر من العدد 1 * بشرط ألا يكون قابلًا للقسمة ‫إلا على نفسه وعلى الواحد. * Nإذا كان لدى‫ N أي قاسم D يتراوح بين الواحد والعدد * ‫فسيكون لديه قاسم يتراوح بين العدد 2 والجذر التربيعي للعدد N * ‫لذلك سوف نختبر قيم القواسم المحتملة بداية من العدد 2 * ‫وحتى الجذر التربيعي للعدد N */ static boolean isPrime(int N) { int divisor; // عدد يحتمل أن يكون قاسما للعدد if (N <= 1) return false; // العدد الأولي لابد أن يكون أكبر من الواحد int maxToTry; // أكبر قيمة قاسم محتمل ينبغي اختبارها // ‫ينبغي إجراء عملية التحويل بين الأنواع لأن Math.sqrt // ‫تعيد قيمة من النوع double maxToTry = (int)Math.sqrt(N); // ‫سنحاول قسمة‫ N على الأعداد من 2 ووصولا الى قيمة maxToTry // إذا لم يكن‫ N قابل للقسمة على أي عدد من تلك الأعداد // ‫سيكون N عددا اوليا for (divisor = 2; divisor <= maxToTry; divisor++) { if ( N % divisor == 0 ) // ‫إذا تمكن divisor من تقسم N return false; // ‫إذًا N لا يمكن أن يكون عددًا أوليًا // لا حاجة للاستمرار } // ‫إذا وصلنا إلى هنا، فإن N حتما هو عدد أولي // ‫لأنه إذا لم يكن أوليًا، ستكون الدالة بالفعل قد انتهت // ‫باستخدام تعليمة return الموجودة بالحلقة السابقة return true; // ‫نعم N هو عدد أولي } // ‫نهاية الدالة isPrime نَسْتَعْرِض بالشيفرة التالية دالة آخرى، والتي تَستقبِل مُعامِل (parameter) من النوع String، وتُعيد قيمة (return value) من نفس النوع String. تَعْكِس تلك الدالة ترتيب محارف السِلسِلة النصية المُمرَّرة، وتُعيد نسخة مَعْكوسة منها، فمثلًا، النسخة المَعْكوسة من السِلسِلة النصية "Hello World" هي "dlroW olleH". يُمكِن توصيف الخوارزمية (algorithm) المطلوبة لعَكْسَ سِلسِلة نصية str على النحو التالي: ابدأ بسِلسِلة نصية فارغة (empty string)، ثم أَضِف إلى نهايتها كل محرف (character) موجود بالسِلسِلة النصية str، بحيث تبدأ بالمحرف الأخير من السِلسِلة str، وتعود للوراء حتى تَصِل إلى المحرف الأول. اُنظر الشيفرة التالية: static String reverse(String str) { String copy; // النسخة المعكوسة // الموضع الحالي من السلسلة النصية الممرة // يأخذ القيم بداية من طول السلسلة وحتى صفر int i; copy = ""; // ابدأ بسلسلة نصية فارغة for ( i = str.length() - 1; i >= 0; i-- ) { // أضف المحرف الحالي إلي نهاية النسخة المعكوسة copy = copy + str.charAt(i); } return copy; } لاحِظ أن بعض السَلاسِل النصية لا تتغَيَّر سواء قُرأت طردًا (forwards) أو عكسًا (backwards)، أي سواء قرأت من اليسار إلى اليمين أو العَكْس. يُعرَف ذلك باسم السِّياق المُتَناظِر أو القلب المستو (palindrome)، والذي يُمكِنك اختبار حُدُوثه على سِلسِلة نصية معينة word بالاستعانة بالدالة المُعرَّفة بالأعلى وباِستخدَام الاختبار if (word.equals(reverse(word)))‎ تحديدًا. يقع كثير من المبتدئين، أثناء كتابتهم للدوال، بخطأ طباعة الإجابة بدلًا من إعادتها، وهو ما يُمثِل سوء فهم تام لماهية الدوال. إن مُهِمّة الدالة (function) ببساطة هو مجرد حِسَاب قيمة ما، ثم العودة مرة آخرى إلى سَطْر الشيفرة المسئول عن اِستدعاء الدالة، حيث ينبغي اِستخدَام القيمة المُعادة. قد يَطبَع ذلك السَطْر من الشيفرة تلك القيمة أو يُسنِدها إلى مُتَغيِّر أو يَستخدِمها ضِمْن تعبير (expression)، أو أي شيء آخر قد يَتطلَّبه البرنامج، المهم هنا هو أن تُدرِك أن أيًا كانت الطريقة التي سيُوظِّف بها المُستدعِي تلك القيمة المُعادة فهي بالنهاية أمر لا يَخُصّ الدالة. مسألة متتالية "3N+1" سنُحاوِل بالمثال الأخير من هذا القسم اِستخدَام الدالة nextN()‎ التي عَرَفناها بالأعلى لتَعْديل البرنامج المسئول عن حِسَاب قيم عناصر المتتالية "3N+1". أُضيفَت بعض التَعْديلات الآخرى أيضًا، مثل طباعة قيم عناصر المتتالية بأعمدة، بحيث يَحتوِي كل سَطْر على ٥ عناصر فقط، مما سيُحسِن من هيئة الخَرْج الناتج عن البرنامج. تستطيع القيام بذلك ببساطة عن طريق الاحتفاظ بعدد العناصر المَطبوعة بالسَطْر الحالي، وبدء سَطْر خَرْج جديد عند وصول قيمة ذلك العدد إلى القيمة ٥. نُسِق الخَرْج بحيث تُصطَفَّ العناصر بأعمدة مُرتَّبة: input textio.TextIO; /** * برنامج يحسب قيم عناصر المتتالية ‫3N+1 ويطبعها. تُحدد قيمة * أول عنصر بالمتتالية من قبل المستخدم، ثم تُطبع القيم بأعمدة * ‫بحيث يحتوي كل سطر على 5 عناصر فقط. * كما تطبع عدد عناصر المتتالية بالنهاية */ public class ThreeN2 { public static void main(String[] args) { System.out.println("This program will print out 3N+1 sequences"); System.out.println("for starting values that you specify."); System.out.println(); int K; // اقرأ مدخل المستخدم do { System.out.println("Enter a starting value;"); System.out.print("To end the program, enter 0: "); K = TextIO.getlnInt(); // اقرأ قيمة أول عنصر بالمتتالية if (K > 0) print3NSequence(K); // ‫اعد تكرار الحلقة إذا كان k أكبر من الصفر } while (K > 0); } // ‫نهاية main /** * يطبع‫ print3NSequence قيم المتتالية 3N+1 إلى الخرج القياسي، * بحيث يكون أول عنصر بالمتتالية هو قيمة المعامل الممررة * كما يطبع أيضًا عدد عناصر المتتالية * ‫قيمة المعامل startingValue الممررة ينبغي أن تكون عددًا صحيحا موجبا */ static void print3NSequence(int startingValue) { int N; // أحد عناصر المتتالية int count; // عدد العناصر حتى الآن int onLine; // عدد العناصر المطبوعة بالسطر الحالي N = startingValue; // ابدأ المتتالية بقيمة المعامل الممررة count = 1; // لدينا عنصر واحد بالمتتالية System.out.println("The 3N+1 sequence starting from " + N); System.out.println(); System.out.printf("%8d", N); onLine = 1; // هناك عدد مطبوع بالسطر الآن while (N > 1) { N = nextN(N); // احسب قيمة العنصر التالي count++; // أزد عناصر المتتالية بمقدار الواحد if (onLine == 5) { System.out.println(); // اطبع محرف العودة الى بداية السطر onLine = 0; // أعد ضبط عدد العناصر المطبوعة بالسطر } System.out.printf("%8d", N); // اطبع قيمة العنصر الحالي onLine++; // أزد قيمة عدد العنصر بالسطر بمقدار الواحد } System.out.println(); // انهي السطر الحالي من الخرج System.out.println(); // اطبع سطر فارغ System.out.println("There were " + count + " terms in the sequence."); } // نهاية print3NSequence /** * ‫تحسب الدالة nextN قيمة عنصر المتتالية التالي وتعيده * ‫بحيث تستقبل قيمة عنصر المتتالية الحالي كمعامل currentN */ static int nextN(int currentN) { if (currentN % 2 == 1) return 3 * currentN + 1; else return currentN / 2; } // ‫نهاية الدالة nextN } // ‫نهاية الصنف ThreeN2 ينبغي أن تَقْرأ هذا البرنامج بتأنِّي وأن تُحاوِل اِستيعاب طريقة عَمَله. ترجمة -بتصرّف- للقسم Section 4: Return Values من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

إذا كان البرنامج الفرعي (subroutine) عبارة عن صندوق أسود، فإن المُعامِلات (parameter) هي ببساطة طريقة لتمرير بعض المعلومات إليه من العالم الخارجي، لذا فإنها تُعدّ جزءًا من واجهة (interface) البرنامج الفرعي، وتَسمَح لك بتَخْصيص طريقة عمل البرنامج الفرعي للتَكيُف مع موقف محدد. على سبيل المثال، إذا نظرنا لمنظم الحرارة كصندوق أسود، تتلخَّص مُهِمّته في الحفاظ على درجة حرارة معينة، فإن ذلك المنظم لديه مُعامِل، هو القرص، والذي يُستخدَم لتَخْصيص درجة الحرارة المطلوبة. سيُنفِّذ منظم الحرارة دائمًا نفس المُهِمّة، أيّ الحفاظ على درجة حرارة ثابتة، لكن قيمة درجة الحرارة تلك يُمكِن تَخْصيصها من خلال القرص. استخدام المعاملات سنتَطَرَّق مجددًا لمسألة متتالية الأعداد "3N+1"، والتي قد تَعرَّضنا لها بالقسم الفرعي ٣.٢.٢. تُحسَّب قيم مُتتالية الأعداد "3N+1" وفقًا للقاعدة التالية: "إذا كان N عَدَدًا فرديًا، اِحسب حاصل ضربه في العَدَد ٣، ثُمَّ أَزِد قيمة حاصل الضرب بمقدار ١، أمَا إذا كان زوجيًا، اِحسب حاصل قِسمته على العَدَد ٢، بحيث تستمر بحِسَاب قيم عناصر مُتتالية الأعداد بنفس الطريقة حتى تُصبِح قيمة N مُساوِية للعَدَد ١. على سبيل المثال، إذا كانت قيمة N المبدئية تُساوِي ٣، سنَحصُل على مُتتالية الأعداد التالية: ٣، ١٠، ٥، ١٦، ٨، ٤، ٢، ١." اُكْتُب برنامجًا فرعيًا (subroutine) يَطبَع قيم مُتتالية الأعداد تلك. لاحِظ أن دور البرنامج هو طباعة متتالية الأعداد "3N+1" في العموم، أي أن القيم ذاتها التي سيَطبَعها لابُدّ وأن تعتمد على قيمة N المبدئية، ولهذا سنُمرِّر تلك القيمة كمُعامِل (parameter) للبرنامج الفرعي. يُمكِن كتابة البرنامج الفرعي كالتالي: static void print3NSequence(int startingValue) { int N; // أحد قيم عناصر المتتالية int count; // عدد عناصر المتتالية N = startingValue; // أول عنصر هو القيمة الممررة count = 1; // لدينا قيمة واحدة هي القيمة الممررة System.out.println("The 3N+1 sequence starting from " + N); System.out.println(); System.out.println(N); while (N > 1) { // ‫إذا كان N عدد فردي if (N % 2 == 1) N = 3 * N + 1; else N = N / 2; count++; // أزد عدد عناصر المتتالية بمقدار الواحد System.out.println(N); // اطبع العنصر } System.out.println(); System.out.println("There were " + count + " terms in the sequence."); } // ‫نهاية print3NSequence تَتكوَّن قائمة المعاملات (parameter list) -بتعريف البرنامج الفرعي بالأعلى- من المُعامِل int startingValue، مما يَعنِي أن ذلك البرنامج الفرعي سيَستقبِل مُعامِلًا (parameter) وحيدًا من النوع العَدَدَي الصحيح int، وسيَتَمكَّنْ من اِستخدَام اسم ذلك المُعامِل بداخل المَتْن، بنفس الطريقة التي يَستخدِم بها اسم أيّ مُتَغيِّر آخر. لاحِظ أننا لم نُسنِد أي قيمة للمُعامِل أثناء عملية التعريف ذاتها، فهو يَحصُل على قيمته المبدئية من مصدر خارجي أثناء عملية الاستدعاء، لذا لابُدّ للمُستدعِي أن يُمرِّر قيمة معينة لذلك المُعامِل ضِمْن تَعْليمَة الاستدعاء (subroutine call statement)، وعندها فقط ستُسنَد إلى startingValue قبل تَّنْفيذ المَتْن. مثلًا، عندما يُنفِّذ الحاسوب تَعْليمَة استدعاء البرنامج الفرعي print3NSequence(17);‎، فإنه يُسنِد أولًا القيمة ١٧ إلى startingValue، ثم يُنفِّذ بَعْدها التَعْليمَات الموجودة بمَتْن ذلك البرنامج، والتي تَطبَع قيم مُتتالية الأعداد "3N+1" بداية من العدد ١٧. وبصورة أعم، إذا كان K مُتَغيِّرًا من النوع العَدََدَي الصحيح int، يُمكِن اِستخدَام التَعْليمَة print3NSequence(K);‎ بهدف اِستدعاء البرنامج الفرعي، مما سيؤدي إلى إِسْناد قيمة المُتَغيِّر K إلى startingValue، ومِنْ ثَمَّ تَّنْفيذ مَتْن البرنامج الفرعي. يُمكِن اِستدعاء البرنامج الفرعي print3NSequence بواسطة أيّ برنامج فرعي -البرنامج main()‎ أو غيره- مُعرَّف ضِمْن نفس الصَنْف المُتَضمِّن لتعريف البرنامج الفرعي print3NSequence. فمثلًا، يَطبَع البرنامج main()‎ -بالمثال التالي- قيم عناصر المُتتالية "3N+1" أكثر من مرة وبقيم مبدئية مختلفة، والتي تُخصَّص من قِبَل المُستخدِم: public static void main(String[] args) { System.out.println("This program will print out 3N+1 sequences"); System.out.println("for starting values that you specify."); System.out.println(); int K; // اقرأ مدخل المستخدم do { System.out.println("Enter a starting value."); System.out.print("To end the program, enter 0: "); K = TextIO.getInt(); // اقرأ عنصر المتتالية الأول من المستخدم if (K > 0) // اطبع المتتالية print3NSequence(K); } while (K > 0); // ‫إستمر إذا كانت قيمة k أكبر من الصفر } // نهاية main تنبيه: لابُدّ أن يُعرَّف كُلًا من البرنامجين main و print3NSequence ضِمْن نفس الصَنْف؛ كي تتمكَّن من تَشْغِيل البرنامج بالأعلى. المعاملات الصورية (formal) والفعلية (actual) في الواقع، تُستخدَم كلمة "مُعامِل (parameter)" للإشارة إلى مفهومين، مُرتبطين نوعًا ما، لكنهما بالنهاية مختلفان. أولهما هو ذلك الذي نُشير إليه ضِمْن تعريفات البرامج الفرعية (definitions of subroutines)، مثل startingValue بالأعلى. والآخر هو ما نُشير إليه ضِمْن تَعْليمَات استدعاء البرامج الفرعية (subroutine call statements)، بحيث يُمرَّر إليها، مثل K بالتَعْليمَة print3NSequence(K);‎. يُطلَق على "المُعامِلات" من النوع الأول اسم المُعامِلات الصُّوريّة (formal parameters) أو المُعامِلات الوهمية (dummy parameters)، بينما يُطلَق على "المُعامِلات" من النوع الثاني اسم المُعامِلات الفعليّة (actual parameters) أو الوُسَطاء (arguments). عندما تَستدعِي برنامجًا فرعيًا، يُحصِّل الحاسوب قيم المُعامِلات الفعليّة بتَعْليمَة الاستدعاء، ثم يُسنِد تلك القيم إلى المُعامِلات الصُّوريّة المُصرَّح عنها بتعريف ذلك البرنامج الفرعي، وأخيرًا، يُنفِّذ مَتْن البرنامج الفرعي. المُعامِل الصُّوريّ (formal parameter) عبارة عن "اسم"، أو بتعبير آخر، مُعرِّف بسيط (simple identifier)، فهو في الواقع أشبه ما يَكُون بالمُتَغيِّر، وكأي مُتَغيِّر، لابُدّ أن يكون له نوع مثل int أو boolean أو String أو double[]‎. في المقابل، المُعامِل الفعلي (actual parameter) هو مجرد "قيمة" يُفْترَض اِسْنادها لمُتَغيِّر المُعامِل الصُّوريّ المُناظِر عند الاستدعاء الفعليّ للبرنامج الفرعي، لذا يُمكِن اِستخدَام أي تعبير (expression) طالما كان يَؤول إلى قيمة هي من نوع يمكن إِسْناده -بواسطة تَعْليمَة إِسْناد (assignment)- إلى نوع المُعامِل الصُّوريّ المُناظِر. فمثلًا، إذا كان لدينا مُعامِل صُّوريّ من النوع double، ونظرًا لإمكانية إِسْناد قيمة من النوع int إلى المُتَغيِّرات من النوع double، فإن قيمة المُعامِل الفعليّ المُمرَّرة لذلك المُعامِل الصُّوريّ يُمكِن أن تَكُون من النوع int. لاحِظ أنه من الضروري تَمرير مُعامِل فعليّ لكل مُعامِل صُّوريّ أثناء الاستدعاء الفعليّ للبرنامج الفرعي. اُنظر البرنامج الفرعي التالي كمثال: static void doTask(int N, double x, boolean test) { // تعليمات تنفيذ المهمة } تستطيع اِستدعاء البرنامج الفرعي بالأعلى باِستخدَام تَعْليمَة الاِستدعاء التالية: doTask(17, Math.sqrt(z+1), z >= 10); يُمكِن تَوصِيف ما يُنفِّذه الحاسوب -أثناء تَّنْفيذه لتَعْليمَة الاستدعاء بالأعلى- إلى تَعْليمَة الكُتلة (block statement) التالية: { int N; // خصص مساحة بالذاكرة للمعاملات الصورية double x; boolean test; // اسند القيمة 17 للمعامل الصوري الأول N = 17; // احسب قيمة التعبير واسندها للمعامل الصوري الثاني x = Math.sqrt(z+1); // احسب قيمة التعبير المنطقي واسندها للمعامل الصوري الثالث test = (z >= 10); // تعليمات تنفيذ المهمة } إلى جانب الاختلاف الجَلِيّ بحجم الشيفرة التي تَتَطلَّبها كِلا الطريقتين، هناك أيضًا اختلافات آخرى مُتعلقة بنِطاق (scope) المُتَغيِّرات، وكيفية التَعامُل في حالة وجود عدة مُتَغيِّرات أو مُعامِلات بنفس الاسم. قد تَكُون فكرة اِستخدَام مُعامِل (parameter) لتمرير بعض المعلومات إلى برنامج فرعي (subroutine) معين بديهية نوعًا ما، ولذلك فإن اِستدعاء التوابع الفرعية المُعرَّفة مُسْبَّقًا ليس بمشكلة، وهو ما يَختلِف تمامًا عن كتابة تعريف البرنامج الفرعي ذاته (subroutine definition)، والذي عادة ما يُرْبِك دَارسِي البرمجة المبتدئين، بالأخص ما يتعلق منها بكيفية عَمَل المُعامِلات. في الواقع، يَقع الكثيرون منهم في خطأ إِسْناد قيم إلى المُعامِلات الصُّوريّة (formal parameters) ببداية مَتْن البرنامج الفرعي، وهو ما يُمثِل سوء فهم تام لماهية مُعامِلات البرامج الفرعية؛ فعندما يُنفِّذ الحاسوب تَعْليمَة اِستدعاء برنامج فرعي معين، فإنه يُسنِد قيم المُعامِلات الفعليّة (actual parameters) المُمرَّرة بتَعْليمَة الاستدعاء إلى المُعامِلات الصُّوريّة، وذلك قَبْل البدء بتَّنْفيذ مَتْن البرنامج الفرعي، أيّ أنه حينما يبدأ الحاسوب بتَّنْفيذ ذلك المَتْن، تَكُون المُعامِلات الصُّوريّة قد هُيئت بالفعل بقيمها المبدئية المُمرَّرة، ولذلك لا معنى من بدء المَتْن بإِسْناد قيم إلى تلك المُعامِلات. تَذكَّر أن البرنامج الفرعي ليس مُستقلًا؛ فبالنهاية هو يُستدعَى بواسطة برنامج آخر (routine)، ولذا تَقع مسئولية تَوْفِير قيم مُعامِلاته على تَعْليمَة الاستدعاء، ومِنْ ثَمَّ على ذلك البرنامج المُستدعِي. التحميل الزائد (overloading) يَتَطلَّب استدعاء برنامج فرعي معين مَعرِفة بعض المعلومات عنه، والتي يُطلَق عليها اسم "بَصْمَة البرنامج الفرعي (subroutine's signature)". تَتَكوَّن تلك البَصْمَة من كُلًا من اسم البرنامج الفرعي، وعدد المُعامِلات الصُّوريّة (formal parameters) المُعرَّفة ضِمْن قائمة مُعامِلاته، بالإضافة إلى نوعها. على سبيل المثال، يُمكِنك كتابة بَصْمَة البرنامج الفرعي doTask المذكور بالأعلى كالتالي: doTask(int,double,boolean)‎. لاحِظ أن بَصْمَة البرنامج الفرعي لا تَتضمَّن أسماء المُعامِلات، وهو في الواقع أمر يَسهُل تبريره؛ فليس هناك أيّ نَفْع من مَعرِفة أسماء المُعامِلات الصُّوريّة إذا كان كل غرضك هو مجرد اِستخدَام ذلك البرنامج الفرعي، ولذلك لا تُعدّ أسماء المُعامِلات جزءًا من واجهة البرنامج الفرعي (subroutine's interface). تَسمَح لغة الجافا باِستخدَام نفس الاسم لأكثر من برنامج فرعي داخل نفس الصَنْف، بشَّرْط اختلاف البَصْمَة (signatures) الخاصة بهم، فيما يُعرَف باسم "التحميل الزائد (overloading)" لاسم البرنامج الفرعي؛ حيث أصبح ذلك الاسم يَمتلك عدة معاني مختلفة. لا يَخلِط الحاسوب بين تلك البرامج الفرعية التي تَحمِل نفس الاسم، ويَستطيع تَّمييز أي منها تَرغَب باستدعائه، وذلك بالاعتماد على عدد المُعامِلات الفعليّة المُمرَّرة ضِمْن تَعْليمَة الاستدعاء، وأنواع تلك المُعامِلات. في الواقع، يَستخدِم الكائن (object)‏ System.out التحميل الزائد (overloading)؛ حيث تَتَوفَّر له العديد من التوابع (methods) المختلفة، والتي تَحمِل جميعها الاسم println مع اختلاف بَصْمَاتها (signatures) بالتأكيد. اُنظر على سبيل المثال: println(int) println(double) println(char) println(boolean) println() يَعتمِد الحاسوب على نوع المُعامِل الفعليّ (actual parameter) المُمرَّر بتَعْليمَة الاستدعاء لمَعرِفة أي بَصْمَة من تلك البرامج الفرعية ترغب بتَّنْفيذها. فمثلًا، عند اِستخدَام التَعْليمَة System.out.println(17)‎، فإنه يَستدعِي البرنامج الفرعي ذو البَصْمَة println(int)‎، أما في حالة اِستخدَام التَعْليمَة System.out.println('A')‎، فإنه يَستدعِي البرنامج الفرعي ذو البَصْمَة println(char)‎. تُعدّ جميع البرامج الفرعية بالأعلى مرتبطة نوعًا ما من الناحية الدلالية، فجميعها يقوم بالطباعة، وهو ما يُبرِّر تسميتها جميعًا بنفس الاسم، ولكن فيما يتعلق بالحاسوب، فإن طباعة عدد صحيح من النوع int تختلف تمامًا عن طباعة محرف من النوع char، والتي بدورها تختلف عن طباعة قيمة منطقية من النوع boolean، وهو ما يُبرِّر تعريف برنامج فرعي منفصل لكُلًا من تلك العمليات المختلفة. لا يُعدّ نوع القيمة المُعادة من البرنامج الفرعي (return type) جزءًا من البَصْمَة، ولهذا لا يُسمَح بتعريف برنامجين فرعيين بصَنْف معين إذا كان لهما نفس الاسم والبَصْمَة (signature)، حتى مع اختلاف نوع القيمة المُعادة منهما. فمثلًا، سيُؤدي تعريف البرنامجين الفرعيين التاليين بنفس الصَنْف إلى حُدوث خطأ في بناء الجملة (syntax error): int getln() { ... } double getln() { ... } وفي الواقع، هذا هو السبب وراء عدم تسمية جميع البرامج الفرعية المُعرَّفة ضِمْن الصَنْف TextIO، والمُستخدَمة لقراءة الأنواع المختلفة، بنفس الاسم getln()‎، وإنما يُستخدَم اسم مختلف لكل نوع مثل getlnInt()‎ و getlnDouble()‎؛ لأن الصَنْف TextIO لا يُمكِن أن يَتَضمَّن أكثر من برنامج فرعي دون مُعامِلات، ويَحمِل نفس الاسم getln. أمثلة لبرامج فرعية تَتكوَّن البرمجة باستخدام البرامج الفرعية من شقّين، الأول هو تصميم البرنامج (program design)، أيّ تَقسِّيم مُهِمّة البرنامج (program) إلى مَهَامّ فرعية (subtasks) صغيرة بحيث يُسنَد كل منها إلى برنامج فرعي (subroutine)، أما الشقّ الآخر، فيَتعلَّق بعملية كتابة تعريف تلك البرامج الفرعية الصغيرة، والتي هي مسئولة عن تَّنْفيذ المَهَامّ الفرعية. سنقوم الآن بكتابة عدة أمثلة لبعض من تلك البرامج الفرعية الصغيرة، بينما سنُعود إلى مناقشة موضوع تصميم البرامج (program design) بالقسم ٤.٧. أول مثال هو كتابة برنامج فرعي يَستقبِل عددًا صحيحًا موجبًا كمُعامِل، ثم يَحسِب جميع قواسم (divisors) هذا العدد، ويَطبَعها. يُكتَب أيّ برنامج فرعي بالصيغة (syntax) التالية: <modifiers> <return-type> <subroutine-name> ( <parameter-list> ) { <statements> } تَتلخَّص كتابة أي برنامج فرعي (subroutine) في مَلْئ هذه الصيغة، لذا دَعْنَا نقوم بذلك لمسألة حِسَاب القواسم. أولًا، تَنُصّ المسألة على اِستقبال البرنامج الفرعي لمُعامِل (parameter) وحيد من النوع int، كما تُبيِّن المُهِمّة المطلوب تَّنْفيذها بواسطة التَعْليمَات المَكًتوبة بمَتْن ذلك البرنامج. ثانيًا، لمّا كان حديثنا في الوقت الراهن مقصورًا على البرامج الفرعية الساكنة (static subroutines)، فإننا سنَستخدِم المُبدِّل static بالتعريف. ثالثًا، قد نُضيف مُبدِّل وصول (access modifier) بالتعريف، مثل public أو private، ولكن نظرًا لعدم النَصّ بذلك صراحة ضِمْن نَّصّ المسألة، فلن نَستخدِم أيًا منهما. رابعًا، لم تَنُصّ المسألة على وجود أي قيمة مُعادة، ولذلك سيَكُون النوع المُعاد (return type) هو void. أخيرًا، لمّا لم تُحدِّد المسألة كُلًا من اسم البرنامج الفرعي (subroutine)، وأسماء المُعامِلات الصُّوريّة (formal parameter) صراحةً، فإننا سنَضَطرّ لاختيار تلك الأسماء بأنفسنا، ولذلك سيُستخدَم N كاسم للمُعامِل، و printDivisors كاسم للبرنامج الفرعي. اُنظر تعريف البرنامج الفرعي: static void printDivisors( int N ) { <statements> } ينبغي لنا الآن كتابة مجموعة التَعْليمَات التي ستُكوِّن مَتْن البرنامج (routine body)، وهو ليس أمرًا صعبًا. تَذكَّر فقط أن المُعامِل N سيَكُون لديه قيمة بالفعل ببداية تَّنْفيذ المَتْن. يُمكِن كتابة تَوصِيف الخوارزمية كالتالي: "لكل عدد يُحتمَل أن يَكُون قَاسِمًا D، أيّ بدايةً من الواحد ووصولًا للعَدَد N، إذا تَمكَّن العدد D من تَقسِّيم العَدَد N تَقسِّيمًا مُتعادلًا، اِطبَع قيمة D." تُصبح الخوارزمية كالتالي بعد ترجمتها إلى لغة الجافا: /** * اطبع قواسم‫ N * ‫بفرض أن N هو عدد صحيح موجب */ static void printDivisors( int N ) { int D; System.out.println("The divisors of " + N + " are:"); for ( D = 1; D <= N; D++ ) { if ( N % D == 0 ) // ‫إذا نجح D في تقسيم N تقسيما متعادلا System.out.println(D); } } يُمثِل التعليق (comment)، المُضاف قَبْل تعريف البرنامج الفرعي (subroutine definition)، ما يُعرَف باسم المواصفة الاصطلاحية للبرنامج (subroutine contract)، والمُكوَّنة من: بَيان هدف البرنامج الفرعي، بالإضافة إلى التَّصْريح عن أيّ اِفتراضات ينبغي مَعرفِتها قَبْل اِستخدَام ذلك البرنامج. مثلًا، في المثال بالأعلى، ذُكِر أن N ينبغي أن يَكُون عددًا صحيحًا موجبًا، ولذلك ينبغي لمُستدعِي البرنامج الفرعي التَأكُّد من تَوْفِية ذلك الفَرْض. لنَفْحَص مثالًا آخر، تَنُصّ المسألة على التالي: "اُكتب برنامجًا فرعيًا خاصًا private اسمه printRow، بحيث يَستقبِل ذلك البرنامج كُلًا من المُعامِلين: ch من النوع char، و N من النوع int. يَتلخَّص دور ذلك البرنامج بطباعة المحرف ch عدد N من المرات وذلك بسَطْر نصي مُنفصِل." بخلاف المسألة السابقة، نَصَّت هذه المسألة صراحةً على كُلًا من اسم البرنامج الفرعي وأسماء المُعامِلات، كما نَصَّت على ضرورة كَوْنه خاصًا، أيّ ينبغي اِستخدَام مُبدِّل الوصول private، ولذلك نحن مقيدين نوعًا ما فيما يتعلق بالسطر الأول من تعريف البرنامج الفرعي (subroutine definition). أخيرًا، مُهِمّة البرنامج بسيطة جدًا، ولذا يَسهُل كتابة مَتْن البرنامج الفرعي. اُنظر شيفرة البرنامج بالكامل: /** * ‫ اطبع المحرف `ch` عدد `N` من المرات وذلك بسَطْر نصي مُنفصِل * ‫إذا كان N أقل من أو يساوي الصفر، اطبع سطرًا فارغًا */ private static void printRow( char ch, int N ) { int i; for ( i = 1; i <= N; i++ ) { System.out.print( ch ); } System.out.println(); } لَمْ تُصَرِّح المواصفة الاصطلاحية (contract) للبرنامج بالأعلى عن وجود أية افتراضات فيما يَخُص المُعامِل N، ولكنها في المقابل أوْضَحَت طريقة استجابة البرنامج الفرعي لجميع الحالات المُمكِنة، بما فيها الحالة غَيْر المُتوقَّعة من كَوْن N <= 0. لنَفْحَص مثالًا آخر، ولكن في هذه المرة، سنُوضِح كيف يُمكِن لبرنامجين فرعيين أن يتفاعلا. تحديدًا، سنَكتُب برنامجًا فرعيًا يَستقبِل مُعامِلًا من النوع String، بحيث يَطبَع كل محرف بالسِلسِلة النصية (string) المُمرَّرة ٢٥ مرة وبسَطْر مُنفصِل. ينبغي أن تَستعين بالبرنامج الفرعي printRow()‎ الذي كتبناه للتو لطباعة ذلك الخَرْج. في هذا المثال، لمّا لم تُحدِّد المسألة كُلًا من اسم البرنامج الفرعي (subroutine)، وأسماء المُعامِلات الصُّوريّة (formal parameter) صراحةً، فإننا سنضطر لاختيار تلك الأسماء، ولذلك سيُستخدَم str كاسم للمُعامِل، وprintRowsFromString كاسم للبرنامج الفرعي. يُمكِن كتابة تَوصِيف الخوارزمية كالتالي: "لكل مَوْضِع i بالسِلسِلة النصية str، اِستدعِي البرنامج الفرعي printRow(str.charAt(i),25)‎؛ لطباعة سَطْر الخَرْج." تُصبِح الخوارزمية كالتالي بَعْد ترجمتها إلى لغة الجافا: /** * لكل محرف بالسلسلة النصية، اطبع سطر مكون من 25 نسخة من ذلك المحرف */ private static void printRowsFromString( String str ) { int i; for ( i = 0; i < str.length(); i++ ) { printRow( str.charAt(i), 25 ); } } نستطيع الآن استدعاء البرنامج الفرعي printRowsFromString المُعرَّف بالأعلى داخل البرنامج main()‎ كالتالي: public static void main(String[] args) { String inputLine; // السطر النصي المدخل من قبل المستخدم System.out.print("Enter a line of text: "); inputLine = TextIO.getln(); System.out.println(); printRowsFromString( inputLine ); } لاحِظ أنه من الضروري تَضْمِين تعريف البرامج الثلاثة main()‎ و printRowsFromString()‎ و printRow()‎ بنفس الصَنْف. على الرغم من كَوْن البرنامج بالأعلى عديم الفائدة نوعًا ما، لكنه على الأقل يُبيِّن طريقة اِستخدَام البرامج الفرعية. يُمكِنك الإطلاع على البرنامج كاملًا بالملف RowsOfChars.java. المصفوفات كمعامل بالإضافة إلى إمكانية تمرير المُعامِلات من الأنواع البسيطة (primitive types) إلى البرامج الفرعية، يُسمَح أيضًا بتمرير المُعامِلات من أنواع المصفوفة (array types)، ما يَعنِي تمرير مصفوفة كاملة من القيم (المُتَغيِّرات إذا شِئنا الدقة) من خلال مُعامِل وحيد. لنَكتُب، على سبيل المثال، برنامجًا فرعيًا يَستقبِل مُعامِلًا من نوع المصفوفة int[]‎؛ ثم يَطبَع جميع الأعداد الصحيحة الموجودة بها، بحيث يُفصَل بين كل عدد والذي يَليه فاصلة (comma)، وبحيث تُحاط جميع تلك الأعداد بزوج من الأقواس []، اُنظر تعريف البرنامج الفرعي: static void printValuesInList( int[] list ) { System.out.print('['); int i; for ( i = 0; i < list.length; i++ ) { if ( i > 0 ) System.out.print(','); System.out.print(list[i]); } System.out.println(']'); } لكي نَستدعِي البرنامج الفرعي بالأعلى، سنحتاج إلى مصفوفة فعليّة (actual). تُنشِئ الشيفرة التالية مصفوفة أعداد صحيحة (array of ints)، وتُمرِّرها كوسيط (argument) للبرنامج الفرعي: int[] numbers; numbers = new int[3]; numbers[0] = 42; numbers[1] = 17; numbers[2] = 256; printValuesInList( numbers ); سنَحصُل على الخَرْج [42,17,256]. وسطاء سطر الأوامر (command-line arguments) لمّا كان البرنامج (routine)‏ main يَستقبِل مُعامِل مصفوفة من النوع String[]‎، كان لزامًا على مُستدعِيه -أيّ النظام (system) في هذه الحالة- أن يُمرِّر مصفوفة سَلاسِل نصية (array of String) فعليّة (actual) كقيمة لذلك المُعامِل الصُّوريّ (formal parameter). لذا لابُدّ أن يَحصُل النظام على قيم السَلاسِل النصية بتلك المصفوفة بطريقة ما، فما الذي يعنيه ذلك؟ وكيف سيَتحصَّل النظام على تلك القيم؟ في الواقع، تَتَكوّن تلك القيم من وُسَطاء سطر الأوامر (command-line arguments)[*] المُمرَّرين إلى الأمر المُستخدَم لتَشْغِيل البرنامج، وبالتالي يُسنِد النظام قيم هؤلاء الوُسَطاء إلى مصفوفة سَلاسِل نصية (array of strings)، ثم يُمرِّرها إلى البرنامج main()‎. [*] يستطيع المُستخدِم عمومًا تَشْغِيل أحد البرامج من خلال كتابة أمر (command) معين بواجهة سَطْر الأوامر (command-line interface). يَتَكوّن الأمر عمومًا من اسم البرنامج المطلوب تَشْغِيله، ولكن يُمكِن أيضًا كتابة مُدْخَلات إضافية ضِمْن الأمر. تُسمَى تلك المُدْخَلات الإضافية باسم وُسَطاء سَطْر الأوامر (command-line arguments). فمثلًا، إذا كان اسم برنامج معين هو myProg، تستطيع تَشْغِيله باِستخدَام الأمر التالي: java myProg ولكن، في هذه الحالة، لا يوجد أي وُسَطاء (arguments)، في المقابل، تستطيع تمرير وسيط واحد أو أكثر باِستخدَام الأمر التالي: java myProg one two three في المثال بالأعلى، تُمثِل السَلاسِل النصية "one"، و "two"، و "three" قيم الوُسَطاء، ولذلك سيُسنِد النظام هذه السَلاسِل النصية إلى مصفوفة من النوع String[]‎، ثم يُمرِّرها كمُعامِل إلى البرنامج main()‎. على سبيل المثال، تَطبَع الشيفرة التالية قيمة أي وسيط (argument) أَدْخَله المُستخدِم: public class CLDemo { public static void main(String[] args) { System.out.println("You entered " + args.length + " command-line arguments"); if (args.length > 0) { System.out.println("They were:"); int i; for ( i = 0; i < args.length; i++ ) System.out.println(" " + args[i]); } } // ‫نهاية main } // ‫نهاية الصنف CLDemo إذا لم يُخصِّص المُستخدِم أي وسيط (arguments) بأمر تَشْغِيل البرنامج، فإن المُعامِل args سيَكُون عبارة عن مصفوفة فارغة، طولها (length) يُساوي الصفر. عمليًا، يُستخدَم وُسَطاء سَطْر الأوامر عادةً بهدف تمرير أسماء بعض الملفات إلى البرنامج. فمثلًا، يَنسَخ البرنامج التالي محتويات ملف نصي معين إلى ملف نصي آخر، ولذلك فإنه يَستخدِم الصَنْف TextIO ضِمْن حَلْقة تَكْرار، بحيث يَقْرأ سَطْرًا واحدًا من الملف الأصلي في كل مرة، ثم يَنسَخُه إلى الملف الآخر. يَستمِر في القيام بذلك حتى يَصِل إلى نهاية الملف، والتي يُستدَلّ عليها من القيمة المنطقية المُعادة من الدالة (function)‏ TextIO.eof()‎. input textio.TextIO; /** * يتطلب ذلك الأمر وسيطين، هما أسماء الملفات * الأول ينبغي أن يكون اسم ملف موجود * والثاني ينبغي أن يكون اسم الملف الذي سينسخ البرنامج إليه بيانات الملف الأول * سيقوم البرنامج بنسخ محتويات الملف الأول إلى الملف الثاني * تحذير: إذا كان الملف الثاني موجود عند تشغيل البرنامج، ستتم الكتابة على البيانات السابقة * يعمل هذا البرنامج مع الملفات النصية فقط */ public class CopyTextFile { public static void main( String[] args ) { if (args.length < 2 ) { System.out.println("Two command-line arguments are required!"); System.exit(1); } TextIO.readFile( args[0] ); // افتح الملف الأصلي بهدف القراءة TextIO.writeFile( args[1] ); // افتح الملف المراد النسخ إليه int lineCount; // عدد الأسطر المنسوخة lineCount = 0; while ( TextIO.eof() == false ) { // اقرأ سطر من الملف الأصلي وانسخه للملف الآخر String line; line = TextIO.getln(); TextIO.putln(line); lineCount++; } System.out.printf( "%d lines copied from %s to %s%n", lineCount, args[0], args[1] ); } } تُنفَّذ معظم البرامج حاليًا من خلال واجهة مُستخدِم رسومية (GUI environment)، ولذلك لم يَعُدْ وُسَطاء سَطْر الأمر (command-line arguments) بنفس ذات الأهمية في الوقت الحالي. مع ذلك ما يزال البرنامج بالأعلى مثالًا جيدًا لبيان كيفية اِستخدَام مُعامِلات المصفوفة (array parameters) على الأقل. التبليغ عن الاعتراضات (exceptions) ذَكَرَنا، منذ قليل، مصطلح المواصفة الاصطلاحية للبرنامج (subroutine contract)، والذي يُوضِح وظيفة البرنامج الفرعي في حالة تمرير قيم صالحة -وفقًا لما هو مُوضَّح بنفس المواصفة الاصطلاحية- لجميع المُعامِلات الخاصة به. تَتَبقَّى الحاجة إلى مَعرِفة كيفية تَصرُّف البرنامج الفرعي في حالة تمرير قيم غَيْر صالحة للمُعامِلات. تَعرَّضنا بالفعل لعدة أمثلة بالقسم ٣.٧، والتي تُبلِّغ فيها البرامج الفرعية عن اِعتراضات (throwing exceptions) في حالة تمرير قيم غَيْر صالحة، فمثلًا، تَنُصّ المواصفة الاصطلاحية للبرنامج الفرعي المَبنِى مُسْبَّقًا (built-in)‏ Double.parseDouble على ضرورة أن يَكُون المُعامِل المُمرَّر إليها عبارة عن تمثيل نصي (string representation) لعَدََدَ من النوع double. إذا كانت قيمة المُعامِل المُمرَّرة مُتماشية مع ذلك الشَّرْط، سيُحوِّل البرنامج الفرعي السِلسِلة النصية (string) المُمرَّرة إلى قيمتها العَدَدية المكافئة، أما إذا لم تَكُن مُتماشية معها، سيُبلِّغ البرنامج الفرعي عن اِعتراض (exception) من النوع NumberFormatException. تُبلِّغ الكثير من البرامج الفرعية عن اعتراض من النوع IllegalArgumentExceptions في حالة تمرير قيم غَيْر صالحة لمُعامِلاتها، وهو ما قد تَرغب في اتباعه بالبرامج الفرعية الخاصة بك. أيّ اعتراض (exception) هو بالنهاية عبارة عن كائن (object)، ستَضطرّ إلى إنشائه قَبْل التَبْليغ عنه باِستخدَام التَعْليمَة throw. سنتناول كيفية القيام بذلك تفصيليًا بالفصل الخامس، ولكن، إلى ذلك الحين، تستطيع اِستخدَام الصيغة (syntax) التالية لتَعْليمَة throw؛ للتَبْليغ عن اِعتراض من النوع IllegalArgumentException تحديدًا: throw new IllegalArgumentException( <error-message> ); تَتَكوّن رسالة الخطأ بالأعلى من سِلسِلة نصية (string) تَشرَح الخطأ المُكْتشَف بينما تُستخدَم new لإنشاء كائن الاعتراض (exception object). كل ما عليك القيام به هو فَحْص قيم المُعامِلات المُمرَّرة؛ لمَعرِفة ما إذا كانت صالحة أم لا، ثم التَبْليغ عن اعتراض باِستخدَام التَعْليمَة بالأعلى إذا لم تَكُن صالحة. على سبيل المثال، لابُدّ أن تَكُون قيمة المُعامِل المُمرَّرة إلى البرنامج الفرعي print3NSequence -المُعرَّف ببداية هذا القسم- عددًا صحيحًا موجبًا، لذلك يُمكِننا، في حالة انتهاك هذا الشَّرْط، تَعْدِيل تعريف البرنامج الفرعي (subroutine definition) بالصورة التالية؛ وذلك لكي نَتَمَكَّن من التَبْليغ عن الاِعتراض: static void print3NSequence(int startingValue) { if (startingValue <= 0) // إذا حدث انتهاك للمواصفة الاصطلاحية throw new IllegalArgumentException( "Starting value must be positive." ); // بقية البرنامج الفرعي مثلما بالأعلى إذا كانت القيمة المُمرَّرة إلى المُعامِل startingValue غَيْر صالحة، فستُنهِي تَعْليمَة throw بالأعلى البرنامج الفرعي فورًا بدون تَّنْفيذ بقية المَتْن، كما قد ينهار (crash) البرنامج بالكامل في حالة عدم اِلتقاط ذلك الاِعتراض (catching exception) بمكان آخر ضِمْن البرنامج باِستخدَام التَعْليمَة try..catch بحيث يُستدعَى البرنامج الفرعي print3NSequence داخل الجزء try، كما ناقشنا بالقسم ٣.٧. المتغيرات العامة (global) والمحلية (local) كملاحظة أخيرة بهذا القسم، يُمكِننا القول أننا نستطيع الآن اِستخدَام ثلاثة أنواع مختلفة من المُتَغيِّرات داخل أيّ برنامج فرعي، هي كالتالي: أولًا، المُتَغيِّرات المحليّة (local variables) والتي يُصرَّح عنها داخل البرنامج الفرعي. ثانيًا، أسماء المُعامِلات الصُّوريّة (formal parameter) ضِمْن تعريف البرنامج الفرعي. ثالثًا، المُتَغيِّرات الأعضاء الساكنة (static member variables)، والتي يُصرَّح عنها خارج البرنامج الفرعي. تُعدّ المُتَغيِّرات المحليّة (local variables) من صميم أعمال البرنامج الفرعي الداخلية، وليس لها أيّ اتصال مع ما هو خارج البرنامج الفرعي. تُمرِّر المُعامِلات الصُّوريّة (formal parameter) قيم خارجية إلى البرنامج الفرعي أثناء الاستدعاء، ولكنها مع ذلك تَتَصرَّف بطريقة مشابهة للمُتَغيِّرات المحليّة بمجرد بدء تَّنْفيذ البرنامج الفرعي. يَعنِي ذلك أنه في حالة حُدوث تَغْيِير بقيمة أحد المُعاملات الصُّوريّة (من النوع الأوَّليّ [primitive type] تحديدًا) أثناء تَّنْفيذ البرنامج الفرعي، فإن ذلك التَغْيِير لا يُؤثِر نهائيًا على بقية البرنامج. لاحِظ أنه في حالة كان المُعامِل الصُّوريّ عبارة عن مصفوفة أو كائن (object)، فإن الأمور تُصبِح أكثر تعقيدًا كما سنرى لاحقًا. أخيرًا، بخلاف المُتَغيِّرات المحليّة (local variables) المُعرَّفة داخل البرامج الفرعية، فإن المُتَغيِّرات العامة (global variables) تُعرَّف خارج أي برنامج فرعي، ولذا فإنها تُعدّ مستقلة عنها، كما أنها قابلة للاِستخدَام ضِمْن أجزاء عديدة من البرنامج (program). في الواقع، يُمكِن اِستخدَام المُتَغيِّر العام (global variable) بأيّ مكان داخل الصَنْف المُُعرَّف بداخله، بل يُمكِن استخدامه بأي صنف آخر طالما لم يُصرَّح عنه باِستخدَام المُبدِّل private. لاحظ أنه إذا حَدَثَ تغيير على مُتَغيِّر عام (global variable) داخل برنامج فرعي معين، فإن تأثير ذلك التغيير يمتد إلى ما هو أبعد من مجرد ذلك البرنامج الفرعي الذي أَحَدَث التغيير، وهو ما قد تعرضت له بالفعل بالمثال الأخير بالقسم السابق؛ حيث عَدَّلت إحدى البرامج الفرعية قيم المُتَغيِّرات العامة gamesPlayed و gamesWon، ثم طُبعت بواسطة برنامج فرعي آخر هو main()‎. إذا اِستخدَمت مُتَغيِّرًا عامًا (global variable) ضِمْن برنامج فرعي معين، فإن ذلك البرنامج الفرعي يُصبِح قادرًا على الاتصال مع بقية البرنامج (program) فيما يُشبه الاتصال السري (back-door communication)، ولهذا نستطيع القول أن المُتَغيِّرات العامة قد أصبحت بذلك جزءًا من واجهة البرنامج الفرعي (subroutine's interface). يُعدّ الاتصال السري عمومًا أقل وضوحًا وصراحةً من ذلك المُقام باستخدام المُعامِلات، ولهذا فإنه قد يَتَسبَّب بكسر القاعدة التي تَنُصّ على ضرورة كَوْن واجهة (interface) "الصندوق الاسود (black box)" صريحة وسهلة الفهم. قد يَدْفَعك ذلك إلى الظّنّ بأن اِستخدَام المُتَغيِّرات العامة داخل البرامج الفرعية أمر سيئ عمومًا، ولكن هذا غَيْر صحيح، فهناك على الأقل سببًا واحدًا جيدًا قد يَدْفَعك للقيام بذلك: مثلًا إذا فكرت بالصَنْف (class) بكَوْنه نوعًا من "الصندوق الاسود (black box)"، يُصبِح من المعقول تمامًا السماح للبرامج الفرعية الواقعة ضِمْن ذلك الصندوق بالاتصال سريًا مع بعضها البعض (back-door communication) خاصة إذا ساهم ذلك بتبسيط الصَنْف ككل من الخارج. لهذا يَنصَح الكاتب بعدم اتخاذ أيّ موقف عدائي مُطْلَق من اِستخدَام المُتَغيِّرات العامة (global variables) داخل البرامج الفرعية، فقط عليك أن تُفكِر مَلِيًّا قَبْل اِستخدَام مُتَغيِّر عام (global variable) داخل برنامج فرعي للتَأكُّد مما إذا كان ذلك ضروريًا. ترجمة -بتصرّف- للقسم Section 3: Parameters من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

تَسمَح بعض اللغات البرمجية -بل غالبيتها في الواقع- بتعريف البرامج الفرعية (subroutines) بصورة مستقلة خارج أي صَنْف، لكن تختلف لغة الجافا عنهم في تلك النقطة، حيث لابُدّ أن يُعرَّف أيّ برنامج فرعي (subroutine) بلغة الجافا ضِمْن صَنْف (class). الهدف من الصَنْف عمومًا هو تجميع البرامج الفرعية والمُتَغيِّرات المُرتبطة معًا ضِمْن وحدة واحدة. نظرًا لأن البرامج المكتوبة بلغة الجافا عادة ما تَستخدِم عددًا ضخمًا من البرامج الفرعية المَكْتوبة بواسطة مبرمجين مختلفين، فإن احتمالية الخلط بين أسمائها يَكُون كبيرًا، لذا حَرَص مُصمِّمي الجافا على وَضع تقييد حازم على الطرق التي يُمكِن بها تسمية الأشياء، ومن هنا كانت ضرورة تعريف البرامج الفرعية وتجميعها ضِمْن أصناف (classes) لها اسم وبالتبعية تجميع تلك الأصناف ضِمْن حزم (packages) لها اسم أيضًا كما سنرى لاحقًا. تُميز لغة الجافا بشكل واضح بين البرامج الفرعية الساكنة (static) وغَيْر الساكنة (non-static). يُمكِن لأي صَنْف أن يَتضمَّن كِلا النوعين، ولكن كيفية اِستخدَامهما مختلفة تمامًا. تُعدّ البرامج الفرعية الساكنة (static subroutine) عمومًا أسهل في الفهم، فببساطة أي برنامج فرعي ساكن هو عضو (member) ينتمي للصنف ذاته المُعرَّف بداخله. في المقابل، تعريف البرامج الفرعية غَيْر الساكنة (non-static subroutine) موجود فقط ضِمْن الصَنْف حتى تَتَمكَّن كائنات (objects) ذلك الصنف -عند إنشائها- من اِستخدَام تلك البرامج الفرعية، وتُصبِح عندها تلك البرامج أعضاء بتلك الكائنات (objects). يُمكِن تطبيق ذلك الاختلاف على المُتَغيِّرات (variables) الساكنة وغَيْر الساكنة بنفس الكيفية، بل وعلى أي شيء آخر قد يَقع ضمن تعريف الأصناف (class definition). سنتناول في هذا الفصل كُلًا من البرامج الفرعية الساكنة والمُتَغيِّرات الساكنة فقط، وسننتقل بالفصل التالي إلى البرمجة كائنية التوجه (object-oriented programming) وعندها سنستطيع مناقشة الأعضاء غَيْر الساكنة. عادة ما يُطلَق مصطلح "التابع (method)" على البرامج الفرعية (subroutines) المُعرَّفة ضِمْن صَنْف، وهو الاسم الذي يُفضِّله غالبية مبرمجي الجافا مع أن المصطلحان عمومًا مترادفان خاصة فيما يَتعلَّق بلغة الجافا. ستَجِدْ أيضًا البعض يَستخدِم مصطلحات آخرى للإشارة إلى البرامج الفرعية مثل "الإجراء (procedure)" أو "الدالة (function)". يُفضِّل الكاتب الاستمرار باِستخدَام المصطلح الأعم "البرنامج الفرعي (subroutine)" ضِمْن هذا الفصل للإشارة إلى البرامج الفرعية الساكنة على الأقل، ولكنه سيبدأ في اِستخدَام مصطلح "التابع (method)" من حين لآخر، كما أنه سيَستخدِم مصطلح "الدالة (function)" فقط للإشارة إلى البرامج الفرعية التي تَحسِب قيمة وتُعيدها مع أن بعض اللغات البرمجية الآخرى تَستخدِم ذلك المصطلح للإشارة إلى البرامج الفرعية (subroutines) بمفهومها الأعم. تعريف البرامج الفرعية ينبغي أن يُعرَّف (define) أيّ برنامج فرعي (subroutine)، تَنوِي اِستخدَامه، بمكان ما بالبرنامج، بحيث يَتضمَّن ذلك التعريف (subroutine definition) كُلًا من الآتي: اسم البرنامج الفرعي (subroutine name)، والمعلومات اللازمة لاستدعائه (subroutine call)، وأخيرًا، الشيفرة الفعليّة المطلوب تَّنْفيذها مع كل عملية استدعاء. يُكتَب تعريف البرنامج الفرعي (subroutine definition) بالجافا بالصياغة التالية: <modifiers> <return-type> <subroutine-name> ( <parameter-list> ) { <statements> } قد تكون الصيغة بالأعلى مألوفة بالنسبة لك؛ فقد تَعرَّضنا بالفعل خلال الفصول السابقة لبعض البرامج الفرعية، مثل البرنامج main()‎ المُعرَّف بأيّ برنامج، والبرنامج drawFrame()‎ ببرامج التحريكة (animation) بالقسم ٣.٩. ومع ذلك، لاِستيعاب ما تَعنيه تلك الصيغة تفصيليًا، سنحتاج إلى مُناقشتها باستفاضة، وهو ما سنفعله بغالبية هذا الفصل. أولًا، تُكوِّن التَعْليمَات -الواقعة بين القوسين المعقوصين {}- مَتْن البرنامج الفرعي (subroutine body)، وتُمثِل الجزء التَّنْفيذي (implementation) أو الداخلي "للصندوق الأسود (black box)" كما ذَكَرنا بالقسم السابق. يُنفِّذ الحاسوب تلك التَعْليمَات عند إجراء عملية اِستدعاء لذلك البرنامج (أو التابع [method]). لاحظ أن تلك التَعْليمَات قد تَتكوَّن من أي تَعْليمَة قد تَعرَّضنا لها خلال الفصلين الثاني والثالث. ثانيًا، تُكتَب المُبدِّلات ببداية التعريف، وهي عبارة عن كلمات تُستخدَم لضَبْط بعض خاصيات البرنامج الفرعي، مثل ما إذا كان ساكنًا (static) أم غير ساكن (non-static). تُوفِّر لغة الجافا عمومًا ستة مُبدِّلات (modifiers) يُمكنك اِستخدَامها، ولقد تَعرَّضنا لاثنين منها فقط حتى الآن، وهي المُبدِّل الساكن static، والمُبدِّل العام public. ثالثًا، يُستخدَم النوع المُعاد لتَخْصِيص نوع القيمة المُعادة من البرنامج الفرعي. تحديدًا، إذا كان البرنامج الفرعي بالأساس هو عبارة عن دالة (function) تَحسِب قيمة معينة، عندها قد تَستخدِم أي نوع، مثل String أو int أو حتى أنواع المصفوفة مثل double[]‎. أما إذا كان البرنامج الفرعي ليس بدالة، أيّ لا يُعيد قيمة، فعندها تُستخدَم القيمة الخاصة void، والتي تُشير إلى عدم وجود قيمة مُعادة، أيّ أنها إِما أن تَكُون فارغة (empty) أو غَيْر موجودة. سنتناول الدوال (functions)، والأنواع المُعادة (return types) تفصيليًا بالقسم ٤.٤. وأخيرًا، قائمة المُعامِلات الخاصة بالتابع (method). تُعدّ المُعامِلات جزءًا من وَاجهة البرنامج الفرعي (subroutine interface)، وتُمثِل المعلومات المُمرَّرة (passed) إليه من الخارج، والتي قد يَستخدِمها لحِسَاب بعض العمليات الداخلية الخاصة به. فمثلًا، بفَرْض وجود الصَنْف Television، والذي يَتضمَّن التابع changeChannel()‎. في تلك الحالة، يُفْترَض أن يُطرَح سؤالًا تلقائيًا عن رقم القناة التي تُريد من البرنامج الفرعي الانتقال إليها، وهنا يأتي دور المُعامِلات (parameter)؛ حيث يُمكِن اِستخدَام مُعامِل للإجابة على مثل هذا السؤال، ولمّا كان رقم القناة هو عدد صحيح، فسيَكُون نوع ذلك المُعامِل (parameter type) هو int، ولهذا يُمكِنك التَّصْريح (declaration) عن التابع changeChannel()‎ كالتالي: public void changeChannel(int channelNum) { ... } يُشير التَّصْريح بالأعلى إلى أن التابع changeChannel()‎ لديه مُعامِل يَحمِل اسم channelNum من النوع العددي الصحيح int. لاحظ أن قيمة المُعامِل channelNum غير مُتوفِّرة حتى الآن، وإنما تَتوفَّر عند عملية الاستدعاء الفعليّ للتابع الفرعي، على سبيل المثال: changeChannel(17);‎. قد تتكوَّن قائمة المُعامِلات (parameter list) -بتعريف البرنامج الفرعي- من تَّصْريح عن مُعامِل (parameter declaration) واحد أو أكثر، وذلك على الصورة ، بحيث يَتكوَّن كل تَّصْريح من مُعامِل وحيد، كما يُفصَل بين كل تَّصْريح والذي يليه باستخدام فاصلة (comma). على سبيل المثال، في حالة أردت التَّصْريح عن مُعامِلين من النوع double، فستضطر إلى كتابة double x, double y وليس double x, y. لاحِظ أن قائمة المُعامِلات قد تَكُون فارغة أيضًا. سنتناول المُعامِلات (parameters) تفصيليًا بالقسم التالي. ها هي التعريفات الخاصة ببعض البرامج الفرعية (subroutine definitions)، ولكن بدون الجزء التَّنْفيذي (implementation) منها، أي بدون التَعْليمَات الفعليّة التي تُعرِّف ما تُنفِّذه تلك البرامج الفرعية: public static void playGame() { // المبدلات هي‫ public و static // ‫النوع المعاد هو void // ‫اسم البرنامج الفرعي هو playGame // قائمة المعاملات فارغةً } int getNextN(int N) { // لا يوجد مبدلات // ‫النوع المعاد هو int // ‫اسم البرنامج الفرعي هو getNextN // ‫قائمة المعاملات تتضمن معامل اسمه N من النوع int } static boolean lessThan(double x, double y) { // ‫المبدلات هي static // ‫النوع المعاد هو boolean // ‫اسم البرنامج الفرعي هو lessThan // ‫قائمة المعاملات تتضمن معاملين x و y كلاهما من النوع double } بالمثال الثاني بالأعلى، لمّا كان تعريف التابع getNextN لا يَتضمَّن المُبدل static، فإنه يُعدّ بصورة افتراضية تابعًا غَيْر ساكن (non-static method)، ولذلك لن نَفْحصه بهذا الفصل! اُستخدِم المُبدل public بالمثال الأول، والذي يُشير إلى إِمكانية استدعاء التابع (method) من أي مكان بالبرنامج، حتى من خارج الصَنْف (class) الذي عُرِّف فيه هذا التابع. في المقابل، يَتوفَّر المُبدل private، والذي يُشير إلى إمكانية استدعاء التابع من داخل نفس الصَنْف فقط. يُطلَق على كُلًا من المُبدلين public و private مُحدِّدات الوصول أو مُبدِّلات الوصول (access specifiers/access modifier). يَتوفَّر مُبدل وصول (access modifier) أخير، هو protected، والذي ستتضح أهميته عندما ننتقل إلى البرمجة كائنية التَوجه (object-oriented programming) بالفصل الخامس. في حالة عدم تخصيص مُحدِّد وصول لتابع معين، فإنه، وبصورة افتراضية، يُصبِح قابلًا للاستدعاء من أيّ مكان بالحزمة (package) التي تَتضمَّن صَنْفه، ولكن ليس من خارج تلك الحزمة. سنُناقش الحزم (packages) خلال هذا الفصل، تحديدًا بالقسم ٤.٦. يَتَّبِع البرنامج main()‎، المُعرَّف بأي برنامج، نفس قواعد الصيغة (syntax rules) المُعتادة لأي برنامج فرعي: public static void main(String[] args) { ... } بفَحْص التعريف بالأعلى، تَجد أن المُبدلات المُستخدَمة هي public و static، أما النوع المُعاد فهو void، أما اسم البرنامج الفرعي فهو main، وأخيرًا، قائمة المعاملات هي String[] args، أيّ أن نوع المُعامِل المُمرَّر هو نوع المصفوفة String[]‎. إذا كنت قد قرأت الفصول السابقة، فلديك بالفعل الخبرة الكافية لكتابة الجزء التَّنْفيذي من البرنامج الفرعي (implementation of a subroutine). في هذا الفصل، سنتعلَّم كتابة التَعرِيف بالكامل بما في ذلك جزء الواجهة (interface). استدعاء البرامج الفرعية يُعدّ تعريف البرنامج الفرعي (subroutine definition) بمثابة إعلام للحاسوب بوجود ذلك البرنامج الفرعي وبالوظيفة التي يُؤديها، لكن يُرجئ التَّنْفيذ الفعليّ للبرنامج الفرعي إلى حين استدعائه (call). يَنطبِق ذلك حتى على البرنامج (routine)‏ main()‎، والذي يَستدعيه النظام (system) -لا أنت- عند تَّنْفيذه للبرنامج (program) ككل. تُستخدَم، مثلًا، تَعْليمَة استدعاء البرنامج الفرعي (subroutine call) التالية؛ لاستدعاء التابع playGame()‎ المذكور بالأعلى: playGame(); يُمكن عمومًا كتابة تَعْليمَة الاستدعاء بالأعلى بأيّ مكان داخل نفس الصَنْف (class) الذي عَرَّف التابع playGame()‎، سواء كان ذلك بالتابع‏ main()‎، أو بأيّ برنامج فرعي آخر. علاوة على ذلك، لمّا كان التابع playGame()‎ مُعرَّف باِستخدَام المُبدل public، وهو ما يَعنِي كَوْنه تابعًا عامًا، فإنه من الممكن لأيّ صَنْف آخر استدعائه أيضًا، ولكن ينبغي أن تُعلِم الحاسوب، في تلك الحالة، باسم التابع كاملًا أثناء الاستدعاء، أيّ بذكر الصَنْف الذي ينتمي إليه ذلك التابع. ولأن التابع playGame()‎ مُعرَّف باِستخدَام المُبدل static، وهو ما يَعنِي كَوْنه تابعًا ساكنًا، فإن اسمه الكامل يَتضمَّن اسم الصنف ذاته المُعرَّف بداخله. على سبيل المثال، إذا كان التابع playGame()‎ مُعرَّف بالصَنْف Poker، تُستخدَم التَعْليمَة التالية لاستدعائه من خارج هذا الصَنْف: Poker.playGame(); يُعلِم اسم الصَنْف -بالأعلى- الحاسوب بأيّ صَنْف ينبغي له أن يَجِد التابع. بالإضافة إلى ذلك، يُساعدنا وجود اسم الصَنْف أثناء الاستدعاء على التمييز بين التابع Poker.playGame()‎ وأي توابع اخرى لها نفس الاسم ومُعرَّفة بأصناف آخرى، مثل Roulette.playGame()‎ أو Blackjack.playGame()‎. تُكتَب عمومًا تَعْليمَة استدعاء أي برنامج فرعي ساكن static ‏(static subroutine call) بالجافا بالصيغة التالية إذا كان البرنامج الفرعي المُستدعَى مُعرَّفًا بنفس الصَنْف (class): <subroutine-name>(parameters); أو كالتالي إذا كان البرنامج الفرعي مُعرَّفًا بصَنْف آخر: <class-name>.<subroutine-name>(parameters); يَختلف ذلك عن التوابع غَيْر الساكنة (non-static methods) -سنتناولها لاحقًا-، والتي تنتمي إلى كائنات (objects) وليس أصناف (classes)، ولهذا يُستدعَى ذلك النوع من التوابع من خلال الكائنات (objects) ذاتها لا من خلال أسماء الأصناف. لاحظ أنه في حين يُمكِن لقائمة المُعامِلات (parameter list) أن تَكُون فارغة (empty)، كما هو الحال بالمثال playGame()‎، فإن كتابة الأقواس (parentheses) بتَعْليمَة الاستدعاء ما تزال ضرورية حتى مع كَوْن ما بينها فارغًا. أما في حالة تخصيص مُعامِل (parameter) أو أكثر بقائمة المُعامِلات (parameter list) بالتعريف الخاص ببرنامج فرعي ما (subroutine definition)، فينبغي عمومًا أن يَتطابَق عدد المُعامِلات المُمرَّرة أثناء استدعاء ذلك البرنامج الفرعي مع العَدَدَ المُخصَّص بذلك التعريف، كما لابُدّ بطبيعة الحال أن تَتطابَق أنواع تلك المُعامِلات المُمرَّرة بتَعْليمَة الاستدعاء مع نوعها المُناظِر بنفس ذلك التعريف. البرامج الفرعية بالبرامج سنُعطي الآن مثالًا عما قد يبدو عليه البرنامج (program) عند تَضمُّنه لبرنامج فرعي آخر غَيْر البرنامج main()‎. سنَكتُب تحديدًا برنامجًا للعبة تخمين، يَختار فيه الحاسوب عددًا عشوائيًا بين العددين ١ و ١٠٠، ثُمَّ يُحاول المُستخدِم تخمين ذلك العدد، ليُخبره الحاسوب بَعْدها عما إذا كان تخمينه أكبر أو أقل أو يُساوِي العَدَد الصحيح، وبحيث يَفوز المُستخدِم بالمباراة إذا تَمكَّن من تخمين العدد الصحيح خلال ٦ تخمينات كحد أقصى. أخيرًا، يَستطيع المُستخدِم اختيار الاستمرار بلعب مباراة إضافية بنهاية كل مباراة. لمّا كانت كل مباراة هي بالنهاية مُهِمّة مُترابطة مُفردة، كان بديهيًا كتابة برنامج فرعي playGame()‎ بهدف لعب مباراة تخمين واحدة مع المُستخدِم. سيَستخدِم البرنامج main()‎ حَلْقة تَكْرار (loop)، والتي ستَستدعِي ذلك البرنامج الفرعي مع كل مرة يختار فيها المُستخدِم الاستمرار بلعب مباراة إضافية. نحتاج الآن إلى تصميم البرنامج الفرعي playGame()‎ وكتابته، وفي الواقع، يُصمَّم أي برنامج فرعي بنفس طريقة تَصْميم البرنامج main()‎، أيّ نبدأ بكتابة توصيف للخوارزمية (algorithm)، ثم نُطبِق التَصْميم المُتدرج (stepwise refinement). اُنظر الخوارزمية التالية لبرنامج لعبة التخمين مكتوبًا بالشيفرة الوهمية: // اختر عددًا عشوائيًا Pick a random number // طالما لم تنته المباراة while the game is not over: // اقرأ تخمين المستخدم Get the user's guess // اخبر المستخدم عما إذا كان تخمينه صحيحًا أم أكبر أم أقل Tell the user whether the guess is high, low, or correct. يُعدّ الاختبار "طالما لم تنته المباراة" معقدًا نوعًا ما؛ وذلك لأن المباراة قد تنتهي لسببين: إما لأن تخمين المُستخدِم كان صحيحًا أو لوصوله للحد الأقصى من عدد التخمينات المُمكنة، أيّ ٦. أحد أسهل الطرائق للقيام بذلك هو اِستخدَام حَلْقة تَكْرار لا نهائية while (true)‎ تحتوي على تَعْليمَة break؛ بهدف إِنهاء الحَلْقة في الوقت المناسب. لاحِظ أننا سنحتاج إلى الاحتفاظ بعَدَد تخمينات المُستخدِم؛ حتى نَتمكَّن من إِنهاء المباراة في حالة وصول المُستخدِم للحد الأقصى من التخمينات. تُصبِح الخوارزمية كالتالي بعد إِجراء التعديلات: // أسند قيمة عشوائية بين 1 و 100 إلى المتغير computersNumber Let computersNumber be a random number between 1 and 100 // اضبط قيمة العداد المستخدم لعدّ عدد تخمينات المستخدم Let guessCount = 0 // استمر بتنفيذ الآتي while (true): // اقرأ تخمين المستخدم Get the user's guess // أزد قيمة العداد بمقدار الواحد Count the guess by adding 1 to guess count // إذا كان تخمين المستخدم صحيحًا if the user's guess equals computersNumber: // بلغ المستخدم بفوزه بالمباراة Tell the user he won // اخرج من الحلقة break out of the loop // إذا وصل العداد للحد الأقصى 6 if the number of guesses is 6: // بلغ المستخدم بخسارته للمباراة Tell the user he lost // اخرج من الحلقة break out of the loop // إذا كان كان تخمين المستخدم أقل من العدد if the user's guess is less than computersNumber: // بلغ المستخدم بكَوْن التخمين أقل من العدد Tell the user the guess was low // إذا كان كان تخمين المستخدم أعلى من العدد else if the user's guess is higher than computersNumber: // بلغ المستخدم بكَوْن التخمين أكبر من العدد Tell the user the guess was high يُستخدَم التعبير ‎(int)(100 * Math.random()) + 1 لاختيار عدد عشوائي يقع بين العددين ١ و ١٠٠. اُنظر الشيفرة التالية بلغة الجافا، والتي تَتضمَّن تعريف البرنامج playGame()‎ بعد التَّصْريح عن المُتَغيِّرات (variable declarations): static void playGame() { int computersNumber; // العدد العشوائي int usersGuess; // إحدى تخمينات المستخدم int guessCount; // عدد تخمينات المستخدم computersNumber = (int)(100 * Math.random()) + 1; guessCount = 0; System.out.println(); System.out.print("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // اقرأ تخمين المستخدم guessCount++; if (usersGuess == computersNumber) { System.out.println("You got it in " + guessCount + " guesses! My number was " + computersNumber); break; // انتهت المباراة بفوز المستخدم } if (guessCount == 6) { System.out.println("You didn't get the number in 6 guesses."); System.out.println("You lose. My number was " + computersNumber); break; // انتهت المباراة بخسارة المستخدم } // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد if (usersGuess < computersNumber) System.out.print("That's too low. Try again: "); else if (usersGuess > computersNumber) System.out.print("That's too high. Try again: "); } System.out.println(); } // end of playGame() الآن، وبعد انتهائنا من كتابة تعريف البرنامج الفرعي بالأعلى، فإننا سنحتاج إلى معرفة المكان الذي يُفْترَض أن نضع به هذا التعريف؟ ينبغي أن نضعه عمومًا ضِمْن نفس الصَنْف المُتضمِّن للبرنامج main()‎، ولكن ليس داخل البرنامج main ذاته؛ فمن غَيْر المسموح كتابة برنامج فرعي ضِمْن آخر (nested). لمّا كانت لغة الجافا لا تَشترِط أيّ ترتيب معين للبرامج الفرعية المُعرَّفة ضِمْن نفس الصَنْف، فيُمكِنك وضع تعريف playGame()‎ قَبْل البرنامج main()‎ أو بَعْده. لاحِظ أن البرنامج main()‎ سيَستدعِي البرنامج الفرعي playGame()‎، وهو ما يَعنِي مُجرد تَضمُّنه لتَعْليمَة استدعاء (call statement) لذلك البرنامج الفرعي، لا تَضمُّنه لتعريفها الكامل (definition). يتبقَّى لنا الآن كتابة البرنامج main، وهو ما قد تراه أمرًا بغاية السهولة خاصة مع رؤيتنا لكثير من الأمثلة المشابهة مُسْبَّقًا. سيبدو البرنامج كاملًا كالتالي مع مُراعاة إِمكانية إضافة المزيد من التعليقات (comments): import textio.TextIO; public class GuessingGame { public static void main(String[] args) { System.out.println("Let's play a game. I'll pick a number between"); System.out.println("1 and 100, and you try to guess it."); boolean playAgain; do { playGame(); // اِستدعي البرنامج الفرعي لإجراء مباراة System.out.print("Would you like to play again? "); playAgain = TextIO.getlnBoolean(); } while (playAgain); System.out.println("Thanks for playing. Goodbye."); } // ‫نهاية main static void playGame() { int computersNumber; // العدد العشوائي int usersGuess; // إحدى تخمينات المستخدم int guessCount; // عدد تخمينات المستخدم computersNumber = (int)(100 * Math.random()) + 1; guessCount = 0; System.out.println(); System.out.print("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // اقرأ تخمين المستخدم guessCount++; if (usersGuess == computersNumber) { System.out.println("You got it in " + guessCount + " guesses! My number was " + computersNumber); break; // انتهت المباراة بفوز المستخدم } if (guessCount == 6) { System.out.println("You didn't get the number in 6 guesses."); System.out.println("You lose. My number was " + computersNumber); break; // انتهت المباراة بخسارة المستخدم } // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد if (usersGuess < computersNumber) System.out.print("That's too low. Try again: "); else if (usersGuess > computersNumber) System.out.print("That's too high. Try again: "); } System.out.println(); } // ‫نهاية البرنامج الفرعي playGame } // ‫نهاية الصنف GuessingGame اِستغرِق الوقت الكافي لقراءة شيفرة البرنامج بالأعلى، وحَاول اِستيعاب طريقة عملها. رُبما تَكُون قد لاحَظت أن تَقسيم البرنامج إلى تابعين (methods) قد جَعل البرنامج عمومًا أسهل في القراءة، وربما حتى في الكتابة حتى مع كَوْنه بسيطًا، أما إذا لم تَلحَظ ذلك، فحاول إقناع نفسك به في الوقت الحالي. المتغيرات الأعضاء (Member Variables) قد تَتضمَّن الأصناف (classes) أعضاء (members) آخرى، غير البرامج الفرعية، كالمُتَغيِّرات (variables)، فيُمكِن لأي صَنْف التَّصْريح عن مُتَغيِّر ما (variable declaration)، ولا يُقصَد بذلك تلك المُتَغيِّرات المُعرَّفة داخل برنامج فرعي معين، والمَعروفة باسم المُتَغيِّرات المحليّة (local variable)، وإنما تلك المُعرَّفة بمكان يقع خارج أيّ برنامج فرعي ضِمْن الصَنْف. تُعرَف تلك المُتَغيِّرات باسم المُتَغيِّرات العامة (global variable) أو المُتَغيِّرات الأعضاء (member variables)؛ وذلك لكَوْنهم أعضاء (members) ضِمْن الصنف (class). مثلما هو الحال مع البرامج الفرعية، يُمكِن لأي مُتَغيِّر عضو (member variable) أن يُعرَّف بعدّه عضوًا ساكنًا (static) أو عضوًا غير ساكن (non-static). سنقتصر في هذا الفصل على الساكن منها. بدايةً، ينتمي أي مُتَغيِّر عضو، مُعرَّف باِستخدَام المُبدل static، إلى الصَنْف ذاته المُعرَّف بداخله -لا إلى كائنات ذلك الصَنْف-، فعندما يُحَمِّل مُفسر الجافا (Java interpreter) صَنْف معين، فإنه يُخصِّص مساحة بالذاكرة لكل مُتَغيِّر عضو ساكن ضِمْن ذلك الصَنْف. تُعدِّل أي تَعْليمَة إِسْناد (assignment) إلى واحد من تلك المُتَغيِّرات، وبغض النظر عن مكانها بالبرنامج، من محتوى نفس المساحة بالذاكرة، وكذلك يَلج (access) أي تعبير (expression) يَتضمَّن واحدًا من تلك المُتَغيِّرات، وبغض النظر عن مكانه بالبرنامج، إلى نفس المساحة بالذاكرة ويُعيد نفس القيمة، أيّ تتشارك البرامج الفرعية الساكنة المُعرَّفة بصَنْف ما قيم المُتَغيِّرات الأعضاء الساكنة المُعرَّفة ضِمْن نفس ذلك الصَنْف، فيُمكِن لبرنامج فرعي مُعين ضَبْط قيمة مُتَغيِّر عضو ساكن ما، بحيث يَستخدِمها برنامج فرعي آخر، وهو ما يَختلِف عن المُتَغيِّرات المحليّة المُعرَّفة (local variable) داخل أحد البرامج الفرعية؛ حيث تَتوفَّر فقط بينما يُنفَّذ ذلك البرنامج الفرعي، ثم لا يَعُدْ بالإمكان الوُلوج إليها (inaccessible) من خارج ذلك البرنامج الفرعي. تتشابه تَعْليمَة التَّصْريح (declaration) عن مُتَغيِّر عضو (member variable) مع تلك المَسئولة عن التَّصْريح عن أي مُتَغيِّر محليّ تقليدي باستثناء شيئين. الأول هو وقوع التَّصْريح عن المُتَغيِّر العضو بمكان خارج أي برنامج فرعي (مع ذلك ما يزال التَّصْريح ضِمْن الصَنْف نفسه)، والثاني هو إمكانية اِستخدَام المُبدلات (modifiers) مثل static و public و private ضِمْن التَّصْريح. يقتصر هذا الفصل على الأعضاء الساكنة فقط، ولهذا ستَتضمَّن أي تَعْليمَة تَّصْريح عن مُتَغيِّر عضو (member variable) المُبدل static، وربما قد يُستخدَم أيًا من المُبدلين public أو private. على سبيل المثال، انظر التالي: static String usersName; public static int numberOfPlayers; private static double velocity, time; إذا لم تَستخدِم المُبدل private ضِمْن تَعْليمَة التَّصْريح عن مُتَغيِّر عضو ساكن معين، فإنه يُعامَل افتراضيًا كعضو عام public، أي يُمكن الوُلوج إليه بأي مكان سواء من داخل الصَنْف المُعرَّف به أو من خارج ذلك الصنف. ولكن لاحِظ أنك ستحتاج إلى اِستخدَام مُعرِّف (identifier) مُركَّب على الصورة . عند محاولة الإشارة إليه من خارج الصَنْف. فمثلًا، يحتوي الصَنْف System على مُتَغيِّر عضو ساكن عام اسمه هو out، لذلك تستطيع الإشارة إلى ذلك المُتَغيِّر باِستخدَام System.out بأيّ صَنْف خاص بك. مثال آخر هو المُتَغيِّر العضو الساكن العام Math.PI بالصَنْف Math. مثال أخير، وبفَرْض أن لدينا الصَنْف Poker، والذي يُصَرِّح عن مُتَغيِّر عضو ساكن عام، وليَكُن numberOfPlayers، فإنه يُمكِن الإشارة إلى ذلك المُتَغيِّر داخل الصَنْف Poker ببساطة باِستخدَام numberOfPlayers، في المقابل، يُمكِن الإشارة إليه باِستخدَام Poker.numberOfPlayers من خارج الصَنْف. والآن، لنضيف عدة مُتَغيِّرات أعضاء ساكنة إلى الصَنْف GuessingGame الذي كتبناه مُسْبَّقًا بهذا القسم: أولًا، المُتَغيِّر العضو gamesPlayed بهدف الاحتفاظ بعَدَدَ المباريات التي لعبها المُستخدِم إجمالًا. ثانيًا، المُتَغيِّر العضو gamesWon بهدف الاحتفاظ بعَدَدَ المباريات التي كَسَبها المُستخدِم. يُصَرَّح عن تلك المُتغيرات كالتالي: static int gamesPlayed; static int gamesWon; ستَزداد قيمة المُتَغيِّر gamesPlayed بمقدار الواحد دائمًا مع كل عملية اِستدعاء للبرنامج playGame()‎، بينما ستَزداد قيمة المُتَغيِّر gamesWon بمقدار الواحد في حالة فوز المُستخدِم بالمباراة فقط، ثم تُطبَع قيمة المُتَغيِّرين بنهاية البرنامج main()‎. لمّا كان ضروريًا لكِلا البرنامجين الفرعيين playGame()‎ و main()‎ أن يَلجا إلى نفس قيمتي المُتَغيِّرين، فإنه يَستحِيل اِستخدَام المُتَغيِّرات المحليّة للقيام بنفس الشيء؛ ففي الواقع، يَقتصِر الولوج إلى قيمة مُتَغيِّر محليّ معين على برنامج فرعي وحيد، هو البرنامج الفرعي الذي عَرَّفه، وضِمْن نفس الاستدعاء؛ حيث تُسنَد قيمة جديدة للمُتَغيِّرات المحليّة (local variables) مع كل عملية استدعاء للبرنامج الفرعي الشامل لها، وهو ما يَختلِف عن المُتَغيِّرات العامة (global variables)، والتي تَحتفِظ بنفس قيمها بين كل استدعاء والاستدعاء الذي يَليه. تُهيَئ (initialized) المُتَغيِّرات الأعضاء تلقائيًا بقيم افتراضية بعد التَّصْريح عنها، وهو ما يَختلِف عن المُتَغيِّرات المحليّة ضِمْن البرامج الفرعية، والتي لابُدّ من إِسْناد قيمة لها صراحةً قَبْل اِستخدَامها. تلك القيم الافتراضية هي ذاتها القيم الافتراضية لعناصر المصفوفات، فتُسنَد القيمة صفر افتراضيًا إلى المُتَغيِّرات العددية، بينما تُسنَد القيمة false للمُتَغيِّرات من النوع boolean، في حين يُسنَد المحرف المقابل لقيمة ترميز اليونيكود (Unicode code)‏ ‎\u0000 للمُتَغيِّرات من النوع المحرفي char، أما القيمة الافتراضية المبدئية للكائنات (objects)، كالسَلاسِل النصية من النوع String، فهي القيمة الفارغة null. لمّا كان المُتَغيِّرين gamesPlayed و gamesWon من النوع int، فإنهما يُهيَئا أتوماتيكيًا إلى القيمة المبدئية صفر، وهو ما تَصادَف أن يَكُون القيمة المبدئية المناسبة لمُتَغيِّر يُنوَى اِستخدَامه كعَدَّاد (counter). مع ذلك، إذا لم تُناسبك القيمة المبدئية الافتراضية أو حتى إذا كنت تُريد مُجرد التَّصْريح عن نفس القيمة المبدئية لكن بصورة أكثر وضوحًا، فما يزال بإمكانك إِجراء عملية إِسْناد إلى أي من تلك المُتَغيِّرات ببداية البرنامج main()‎. اُنظر نسخة البرنامج GuessingGame.java بَعْد التعديل: import textio.TextIO; public class GuessingGame2 { static int gamesPlayed; // العدد الإجمالي للمباريات static int gamesWon; // عدد المباريات التي فاز فيها المستخدم public static void main(String[] args) { gamesPlayed = 0; gamesWon = 0; // لا فائدة فعلية من ذلك لأن الصفر هو القيمة الافتراضية System.out.println("Let's play a game. I'll pick a number between"); System.out.println("1 and 100, and you try to guess it."); boolean playAgain; do { playGame(); // استدع البرنامج الفرعي للعب مباراة System.out.print("Would you like to play again? "); playAgain = TextIO.getlnBoolean(); } while (playAgain); System.out.println(); System.out.println("You played " + gamesPlayed + " games,"); System.out.println("and you won " + gamesWon + " of those games."); System.out.println("Thanks for playing. Goodbye."); } // end of main() static void playGame() { int computersNumber; // العدد العشوائي int usersGuess; // إحدى تخمينات المستخدم int guessCount; // عدد تخمينات المستخدم gamesPlayed++; // أزد العدد الإجمالي للمباريات computersNumber = (int)(100 * Math.random()) + 1; guessCount = 0; System.out.println(); System.out.print("What is your first guess? "); while (true) { usersGuess = TextIO.getInt(); // اقرأ تخمين المستخدم guessCount++; if (usersGuess == computersNumber) { System.out.println("You got it in " + guessCount + " guesses! My number was " + computersNumber); gamesWon++; break; // انتهت المباراة بفوز المستخدم } if (guessCount == 6) { System.out.println("You didn't get the number in 6 guesses."); System.out.println("You lose. My number was " + computersNumber); break; // انتهت المباراة بخسارة المستخدم } // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد if (usersGuess < computersNumber) System.out.print("That's too low. Try again: "); else if (usersGuess > computersNumber) System.out.print("That's too high. Try again: "); } System.out.println(); } // ‫نهاية البرنامج الفرعي playGame } // ‫نهاية الصنف GuessingGame2 بالمناسبة، لم يُستخدَم أي من المُبدلين public و private مع البرامج الفرعية أو المُتَغيِّرات الساكنة static بالأعلى، فما الذي يَعنيه ذلك؟ في الواقع، إذا لم يُخصَّص أي مُبدل وصول (access modifier) لمُتَغيِّر عام (global variable) أو لبرنامج فرعي (subroutine)، فإنه يُصبِح قابلًا للوصول بأيّ مكان يقع ضِمْن حزمة (package) الصَنْف الحاضن له، ولكن ليس بأي حزم آخرى. تقع الأصناف التي لا تُصَرِّح عن وجودها ضِمْن حزمة معينة بالحزمة الافتراضية (default package)، لذا تستطيع جميع الأصناف ضِمْن الحزمة الافتراضية -وهو ما يَشمَل أغلبية الأصناف بهذا الكتاب- الوصول إلى كِلا المُتَغيِّرين gamesPlayed و gamesWon وكذلك استدعاء البرنامج الفرعي playGame()‎. مع ذلك، يُعدّ اِستخدَام المُبدل private أثناء التَّصْريح عن كُلًا من المُتَغيِّرات الأعضاء والبرامج الفرعية عمومًا واحدًا من الممارسات الجيدة إلا إذا كان هناك سببًا يَدعوك لمخالفة ذلك، كما يُفضَّل تَجَنُّب اِستخدَام الحزمة الافتراضية (default package). ترجمة -بتصرّف- للقسم Section 2: Static Subroutines and Static Variables من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

تستطيع عمومًا أن تقتطع مجموعة من التَعْليمَات (instructions) المسئولة عن إنجاز مُهِمّة واحدة مُحدَّدة، وتُضمِّنها معًا تحت اسم معين، ومِنْ ثَمَّ، تستطيع التَعامُل مع تلك المُهِمّة كوحدة واحدة مهما بَلغت درجة تعقيدها، يُطلق على تلك الوحدات اسم البرنامج الفرعي (subroutine). والآن، لَمْ يَعُدْ هناك أيّ داعي للقلق بشأن أيّ من تلك الخطوات التي قد يَكُون الحاسوب مضطرًا لتَّنْفيذها أثناء إنجازه لمُهِمّة معينة، وإنما تحتاج فقط لتَذَكُّر اسم البرنامج الفرعي (subroutine) الخاص بتلك المُهِمّة؛ لكي تتَمكَّنْ من استدعائه (call). تُعدّ البرامج الفرعية عمومًا أحد أهم الأدوات الأساسية لتبسيط المسائل المعقدة. في الواقع، البرامج الفرعية (subroutine) هي أشبه ما تَكُون بـ"صندوق أسود (black box)"؛ لا يُمكِنك رؤية ما بداخله، أو بتعبير أدق، لا ترغب برؤيته؛ لأنك إذا فعلت، فستكون مُضطرًا للتعامل مع ذلك الكم الهائل من التعقيد الذي يُفْترَض لذلك البرنامج الفرعي إخفائه بالأساس. على الجانب الآخر، لا يُمكِن أن يَقْتصِر ذلك الصندوق على عالمه الداخلي، وإلا سيكون عديم الفائدة، بل ينبغي له التَفاعُل مع العالم الخارجي، ولهذا فإنه يحتاج إلى ما يُشبه الواجهة (interface) التي تَسمَح بتَفاعُل ما بداخل الصندوق مع ما هو خارجه. على سبيل المثال، قد يُوفِّر صندوق أسود مادي عدة أزرار قابلة للضغط، أو قرص قابل للضبط، أو عدة فتحات لتمرير المعلومات جيْئةَ وذَهابًا. يحاول الصندوق عمومًا التخلص من التعقيد بإخفائه، ولذلك فإن القاعدة الأولى لأيّ صندوق أسود هي كالتالي: "ينبغي لواجهة (interface) أيّ صندوق أسود أن تَكُون مُبسَّطة، وسَهلة الفهم، ومُعرَّفة بصورة جيدة." هل توجد صناديق سوداء ضِمْن عالمنا الذي نعيش فيه؟ في الواقع، إنها تُحيط بك من كل جانب: تلفازك، وسيارتك، وهاتفك المحمول، وثلاجتك هي مجرد أمثلة قليلة. على سبيل المثال، تَتَكوَّن واجهة (interface) التلفاز من عدة عناصر هي مفتاحي التَشْغِيل والغَلْق، وجهاز التحكم -ولا تنس بالطبع وضع قابس الكهرباء-، والتي تستطيع من خلالها غَلْق التلفاز، وتَشْغِيله، أو تَغْيِير القناة، أو ضَبْط الصوت، وذلك بدون أيّ فهم لكيفية عَمَل تلك الأشياء. يَنْطَبِق نفس الشيء على هاتفك المحمول على الرغم من كَوْن واجهته أكثر تعقيدًا بعدّة مراحل. يُسمَى الجزء الداخلي من الصندوق الأسود بالتَّنْفيذ (implementation)، والذي قد يَتمثَل في صورة مجموعة الالكترونيات داخل عُدَّة التلفاز أو في صورة شيفرة البرنامج الفرعي الفعليّة المسئولة عن تَّنْفيذ مهمة البرنامج، وعليه تَكُون القاعدة الثانية لأيّ صندوق أسود كالتالي: "لا حاجة لمَعرِفة أيّ شيء عن الجزء التَّنْفيذي (implementation) الخاص بصندوق أسود لكي تَتَمكَّنْ من اِستخدَامه، وإنما يَكفيك مَعرِفة واجهته (interface)." تستطيع عمومًا إعادة كتابة الجزء التَّنْفيذي (implementation) لبرنامج فرعي معين طالما لم تتأثر واجهته بذلك التَغْيِير. على سبيل المثال، عندما تغَيَّرت عُدَّة التلفاز الداخلية من اعتمادها على الصمامات المُفْرغَة (vacuum tubes) إلى الترانزستور (Transistor)، لَمْ يَكُن هناك داعي لمَعرِفة أي شيء عن ذلك أو مَعرِفة حتى ما قد يَعنِيه، وبالمثل، يُمكِن إعادة كتابة الجزء الداخلي لأيّ برنامج فرعي؛ ربما بهدف كتابة شيفرة أكثر كفاءة، وذلك بدون إِحداث أي تَغْيِير على البرامج المُستخدِمة لذلك البرنامج الفرعي (subroutine). تَحَصُّلك على صندوق أسود يَعنِي بالضرورة أن شخصًا ما كان قد صمم تَّنْفيذه (implementation) وبناه، وفي الواقع، يَستفيد كُلًا من المُنفِّذ (implementor) والمُستخدِم من فكرة وجود صندوق أسود، فبالنهاية، يُمكِن اِستخدَام ذلك الصندوق بعَدََدَ لا محدود من المواضع المختلفة، والتي لا يحتاج المُنفِّذ (implementor) أن يَعلم عنها شيئًا، وإنما يَقْتصِر دوره على التأَكُّد من أن ذلك الصندوق يُنفِّذ مُهِمّته المُوكلة إليه تَّنْفيذًا صحيحًا، مع تَوْفِيره لواجهة (interface) سليمة تَسمَح للصندوق بالتَفاعُل مع العالم الخارجي. وعليه تَكُون القاعدة الثالثة لأيّ صندوق أسود كالتالي: "لا يحتاج مُنفِّذ صندوق أسود معين مَعرِفة أيّ شيء عن تلك الأنظمة الأكبر التي ربما قد تُوظِّف ذلك الصندوق داخلها." يُمكِن القول أن أيّ صندوق أسود يُقسِّم العالم إلى جزئين: الجزء الداخلي أو التَّنْفيذي (implementation) والجزء الخارجي، بحيث تَقع الواجهة (interface) على الحد الفاصل بينهما وتربطهما معًا. لاحِظ أن الواجهة (interface) ليست مجرد رابط مادي بين صندوق معين وعالمه الخارجي، وإنما تَتضمَّن أيضًا تَوصِيفًا (specification) لما يُنجزه الصندوق بالإضافة إلى تبيان واضح لطريقة اِستخدَام تلك الواجهة. فمثلًا، لا يكفي أن تقول أن التلفاز يُوفِّر مفتاح تَشْغِيل، وإنما لابُدّ من تَحْدِيد إمكانية اِستخدَام ذلك المفتاح لأغراض تَشْغِيل التلفاز وغَلْقه. دَعْنَا نُعيد صياغة ما تَعنيه الواجهة (interface) بمصطلحات علم الحاسوب (computer science). تَتَكوَّن واجهة أيّ برنامج فرعي (subroutine) من مُكوّنين رئيسيين، الأول هو تَوصِيف صياغي أو نَحوِي (syntactic specification)، والآخر تَوصِيف دلالي (semantic specification). يخبرك الأول بالكيفية التي يُسْتَدعى (call) بها ذلك البرنامج الفرعي، بينما يُحدِّد الثاني المُهِمّة (task) المُوكَلة لذلك البرنامج والتي يُفْترَض له إنجازها. لابدّ من مَعرِفة التوصيف الصياغي (syntactic specification) لبرنامج فرعي معين؛ وذلك لاستدعائه استدعاءً سليمًا، بينما لابُدّ من مَعرِفة توصيفه الدلالي (semantic specification)؛ وذلك لفهم الغرض منه، واِستخدَامه بطريقة فعالة. عادةً ما يُستخدَم مصطلح المواصفة الاصطلاحية للبرنامج الفرعي (contract of subroutine) للإشارة إلى مُكوّني الواجهة -الصياغي والدلالي- معًا. تقول المواصفة الاصطلاحية (contract) لأيّ برنامج فرعي: "ها هو ما ينبغي القيام به لإستدعائي، وها هو ما سأُنْجِزُه بالمقابل". ينبغي للتعليقات (comments) المكتوبة لبرنامج فرعي معين أن تُبرز مُواصفته الاصطلاحية بصورة واضحة، وهو في الواقع ما لا يَحدُث عمليًا، مما يُؤدي إلى انزعاج المبرمجين الذين قد يكونوا مُضطرّين لاِستخدَام ذلك البرنامج الفرعي. سأنتقل ببقية هذا الفصل من مجرد الحديث عن الفكرة العامة للصندوق الأسود والبرامج الفرعية إلى تفاصيل كتابة تلك البرامج بلغة الجافا وكيفية اِستخدَامها. ولكن حَاوِل دومًا اِستحضار تلك الأفكار والمبادئ العامة بذهنك؛ لأنها تُبرز الغرض الأساسي من وجود البرامج الفرعية، وتُرشدك لكيفية اِستخدَامها. سيَكُون ذلك أكثر وُضوحًا بوصولنا للقسم ٤.٧ حيث سنناقش البرامج الفرعية كأداة لتطوير البرامج. تَذكَّر دائمًا أن البرامج الفرعية (subroutines) ليست الصناديق السوداء الوحيدة بعالم البرمجة. على سبيل المثال، يُعدّ الصنف (class) صندوقًا أسودًا، يَتكوَّن من جزئين، أحدهما عام (public) يُمثِل واجهته (interface)، والآخر خاص (private) يُمثِل تَّنْفيذه (implementation) الخَفي. تَنْطَبِق مبادئ الصناديق السوداء عمومًا على كُلًا من الأصناف (classes) والبرامج الفرعية (subroutines). ترجمة -بتصرّف- للقسم Section 1: Black Boxes من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.