رضوى العربي

الأعضاء
  • المساهمات

    65
  • تاريخ الانضمام

  • تاريخ آخر زيارة

السُّمعة بالموقع

14 جيدة

2 متابعين

  1. تَعرَّضنا بالقسم الفرعي 3.8.5 للمصفوفات ثنائية البعد (two-dimensional arrays)، ولكننا لم نَستخدِمها بالقدر الكافي منذ ذلك الحين. تَملُك المصفوفات ثنائية البعد نوعًا أيضًا مثل int[][]‎ أو String[][]‎ بزوجين من الأقواس المربعة. تُرتَّب عناصر المصفوفات ثنائية البعد ضِمْن مجموعة من الصفوف والأعمدة بحيث يُخصِّص العامل new كُلًا من عدد تلك الصفوف والأعمدة كالتالي: int[][] A; A = new int[3][4]; تُنشِئ تلك التَعليمَة مصفوفة ثنائية البعد مُكوَّنة من 12 عنصر مُرتَّبين ضِمْن 3 صفوف و 4 أعمدة. يَتَوفَّر أيضًا مُهيِئ (initializers) للمصفوفات ثنائية البعد. فمثلًا، تُنشِئ التَعْليمَة التالية مصفوفة 3x4: int[][] A = { { 1, 0, 12, -1 }, { 7, -3, 2, 5 }, { -5, -2, 2, -9 } }; يَتَكوَّن مُهيِئ المصفوفات ثنائية البعد من عدة صفوف مفصولة بفواصل (comma) ومُضمَّنة داخل أقواس. بالمثل، كل صف عبارة عن قائمة من القيم مفصولة بفواصل ومُضمَّنة داخل أقواس. إلى جانب ذلك، تَتَوفَّر قيم مُصنَّفة النوع (literals) لتَمثيِل المصفوفات ثنائية البعد لها نفس قواعد الصيغة (syntax)، ويُمكِن اِستخدَامها بأي مكان وليس فقط تَعْليمَات التّصرِيح (declarations). اُنظر المثال التالي: A = new int[][] { { 1, 0, 12, -1 }, { 7, -3, 2, 5 }, { -5, -2, 2, -9 } }; في الواقع، يُمكِنك أن تُطبِق نفس الأمر على المصفوفات ثلاثية البعد ورباعية البعد..إلخ، ولكنها غَيْر شائعة الاِستخدَام في العموم. حقيقة المصفوفات ثنائية البعد (two-dimensional arrays) قبل أن نتعمق أكثر من ذلك، هنالك مفاجأة صغيرة! لا تَملُك الجافا مصفوفات ثنائية البعد (two-dimensional arrays) بصورة فعلية. تَحتلّ العناصر بمصفوفة فعلية ثنائية البُعد مَواضِعًا مُتصِلة من الذاكرة، ولكن هذا ليس صحيحًا بالجافا. في الحقيقة، تَكشِف الصيغة (syntax) المُستخدَمة لتمثيل أنواع المصفوفة ذلك: بِفرض وجود النوع BaseType، ينبغي إذًا أن نَكُون قادرين على إنشاء النوع BaseType[]‎، وهو ما يَعنِي "مصفوفة من النوع BaseType". إذا اِستخدَمنا النوع int[]‎ ذاته كنوع أساسي للمصفوفة، فإننا نَحصُل على النوع int[][]‎ الذي يُمثِل "مصفوفة من النوع int[]‎" أو "مصفوفة من مصفوفة من النوع int ". بمصفوفة ثنائية البعد من النوع int[][]‎، تَكُون العناصر نفسها مُتْغيِّرات من النوع int[]‎. ولمّا كان أي مُتْغيِّر من النوع int[]‎ بدوره قادرًا على حَمْل مؤشر (pointer) إلى مصفوفة من النوع int. يُمكِننا إذًا أن نقول أن أي مصفوفة ثنائية البعد هي في الواقع عبارة عن مصفوفة من المؤشرات (pointers) بحيث يُشيِر كل مؤشر منها بدوره إلى مصفوفة أحادية البعد (one-dimensional array). تُمثِل المصفوفات أحادية البعد إذًا صفوفًا (rows) ضِمْن المصفوفة ثنائية البعد (two-dimensional). تُبيِّن الصورة التالية مصفوفة مُكوَّنة من 3 صفوف و 4 أعمدة: غالبًا ما نتجاهل تلك الحقيقة، ونُفكِر بالمصفوفة ثنائية البعد كما لو كانت شبكة (grid). ولكننا سنحتاج أحيانًا لأن نتذكَّر أن كل صف ضِمْن تلك الشبكة هو مصفوفة بحد ذاته. يُمكننا في الواقع أن نُشيِر إلى تلك المصفوفات باِستخدَام A[0]‎ و A[1]‎ و A[2]‎ أي أن كل صف هو قيمة من النوع int[]‎ يُمكِننا أن نُمرِّرها حتى إلى برنامج فرعي (subroutine) يَستقبِل مُعاملًا (parameter) من النوع int[]‎ على سبيل المثال. يترتَّب على التفكير بمصفوفة ثنائية البعد A على أنها مصفوفة من المصفوفات عدة نتائج: أولًا، يُساوِي A.length عدد الصفوف (rows) ضِمْن المصفوفة، وهو ما يَتضِح معناه عند التفكير بها بتلك الطريقة. ثانيًا، إذا كانت A تَملُك الشكل المعتاد للمصفوفات ثنائية البعد، فسيَكُون عدد الأعمدة بالمصفوفة A هو نفسه عدد العناصر بالصف الأول أي A[0].length. لاحِظ مع ذلك أنه لا توجد قاعدة تَنصّ على ضرورة أن تَكُون جميع الصفوف ضِمْن مصفوفة ثنائية البعد بنفس الطول حيث يُعدّ كل صف بمثابة مصفوفة مُنفصِلة أحادية البعد، ويُمكِن لها إذًا أن تَملٌك طولًا مختلفًا. في الواقع، قد يَكُون صف معين ضِمْن مصفوفة فارغًا (null). اُنظر التَعْليمَة التالية على سبيل المثال: A = new int[3][]; لا يَتَضمَّن التعريف السابق عددًا داخل الأقواس الثانية، ولهذا فإنه يُنشِئ مصفوفة مُكوَّنة من ثلاثة عناصر جميعها فارغة (null) أي أنه يُوفِّر مساحة لثلاثة صفوف (rows)، ولكنه لا يُنشِئ تلك الصفوف بشكل فعليّ. يُمكِنك أن تُنشِئ الصفوف A[0]‎ و A[1]‎ و A[2]‎ بشكل منفصل. كمثال آخر، لنُفكِر بمصفوفة مُتماثِلة M -المصفوفة المتماثلة (symmetric) عبارة عن مصفوفة ثنائية البعد يَتساوَى عدد صفوفها مع عدد أعمدتها كما تَتَساوَى قيم M[j]‎ و M[j]‎ لجميع قيم i و j-، نحتاج لتَخْزِين قيم M[j]‎ التي تُحقِّق الشَّرط i >= j أي يُمكِننا أن نُخزِّن البيانات بمصفوفة مُثلثة (triangular array) كالتالي: يُمكِننا أن نُنشِئ مصفوفة مثلثية (triangular array) إذا أنشأنا كل صف على حدى. تُنشِئ الشيفرة التالية مصفوفة مثلثية 7x7 من النوع double: double[][] matrix = new double[7][]; // لم ننشئ الصفوف بعد for (int i = 0; i < 7; i++) { // ‫انشئ الصف i بحيث يحتوي على i+1 من العناصر matrix[i] = new double[i+1]; } إذا أردنا أن نَجلب قيمة matrix بالمَوضِع (i,j)، وكان i < j، فإنه ينبغي أن نَجلب قيمة matrix[j]‎، ويَنطبِق الأمر نفسه على ضَبْط قيم تلك المصفوفة. تُعرِّف الشيفرة التالية صَنْفًا لتمثيل المصفوفات المُتماثِلة (symmetric matrices): public class SymmetricMatrix { private double[][] matrix; // مصفوفة مثلثية لحمل البيانات public SymmetricMatrix(int n) { matrix = new double[n][]; for (int i = 0; i < n; i++) matrix[i] = new double[i+1]; } public double get( int row, int col ) { if (row >= col) return matrix[row][col]; else return matrix[col][row]; } public void set( int row, int col, double value ) { if (row >= col) matrix[row][col] = value; else matrix[col][row] = value; } public int size() { return matrix.length; // يمثل عدد الصفوف } } // end class SymmetricMatrix يُمكِنك أن تجد تعريف الصَنْف بالأعلى داخل الملف SymmetricMatrix.java كما يَحتوِي الملف TestSymmetricMatrix.java على برنامج صغير لاختبار الصَنْف. بالمناسبة، لا تستطيع الدالة (function) القياسية Arrays.copyOf()‎ أن تُنشِئ نسخة كاملة من مصفوفة ثنائية البعد (2d array) ضِمْن خطوة واحدة، وإنما ينبغي أن تَفعَل ذلك لكل صف (row) ضِمْن المصفوفة على حدى. نستطيع إذًا كتابة الشيفرة التالية لنسخ مصفوفة ثنائية البعد من الأعداد الصحيحة: int[][] B = new int[A.length][]; // ‫B و A لديهم نفس عدد الصفوف for (int i = 0; i < A.length; i++) { B[i] = Arrays.copyOf(A[i], A[i].length)); // ‫انسخ الصف i } لعبة الحياة (Game of Life) كمثال آخر على معالجة المصفوفات ثنائية البعد، سنَفْحَص مثال مشهور آخر: لعبة الحياة (Game of Life) الذي اخترعها عالم الرياضيات جون هورتون كونواي (John Horton Conway) بعام 1970. لا تُعدّ لعبة الحياة (Game of Life) لعبة بحق، فهي تُمثِل آلة أوتوماتيكية ثنائية البعد. يَعنِي ذلك أنها مُكوَّنة من شبكة (grid) من الخلايا (cells) تَتَغيَّر محتوياتها بمرور الوقت وفقًا لقواعد محدَّدة. يُمكِن لأي خلية أن تَكُون بحالة من اثنين: "حية (alive)" أو "ميتة (dead)". سنَستخدِم مصفوفة ثنائية البعد لتَمثيِل تلك الشبكة بحيث يُمثِل كل عنصر بالمصفوفة حالة خلية واحدة ضِمْن الشبكة. ستُهيِئ اللعبة شبكة (grid) مبدئية بحيث تَكُون جميع خلاياها إما "حية" أو "ميتة". بَعْد ذلك، ستتطوَّر الشبكة وفقًا لسِلسِلة من الخطوات. ستُحدَّد حالة خلايا الشبكة بكل خطوة وفقًا لحالة خلاياها بالخطوة السابقة ووفقًا لعدد من القواعد البسيطة: ستَفحَص كل خلية بالشبكة الخلايا المجاورة لها (أفقيًا ورأسيًا وقطريًا)، وتَحسِب عدد الخلايا الحية ثم تُحدَّد حالة الخلية بالخطوة التالية وفقًا للقواعد التالية: في حالة كانت الخلية "حية" بالخطوة الحالية، وكانت أيضًا مُحاطَة بعدد 2 أو 3 خلايا حية، فإنها ستَبقَى حية بالخطوة التالية أما إذا لم تَكُن مُحاطَة بذلك العدد، فإنها ستموت. (أي تَموُت الخلية الحية نتيجة للوحدة إذا كانت مُحاطة بعدد أقل من خليتين حيتين أو نتيجة للازدحام إذا كانت مُحاطَة بأكثر من 3 خلايا حية). في حالة كانت الخلية "ميتة" بالخطوة الحالية، وكانت أيضًا مُحاطَة بثلاث خلايا حية، فإنها تتحوَّل لتُصبِح حية بالخطوة التالية أما إذا لم تَكُن مُحاطَة بذلك العدد، فإنها ستَبقَى ميتة. (أي يَنتُج عن وجود ثلاثة خلايا حية خلية حية جديدة). تُظهِر الصورة التالية شكل شبكة الخلايا قَبْل تطبيق قواعد اللعبة وبَعْدها. تُطبَق القواعد على كل خلية بالشبكة، وتُبيِّن الصورة كيفية تطبيقها على أربعة خلايا: تُعدّ لعبة الحياة (Game of Life) شيقة حيث تَعرِض الكثير من الأنماط المفاجئة (اُنظر بصفحة ويكيبيديا الخاصة باللعبة). نحن هنا مُهتمين فقط بكتابة برنامج لمحاكاة تلك اللعبة. يُمكِنك أن تَطلِع على شيفرة البرنامج بالكامل بالملف Life.java. تَظهَر رقعة الحياة كشبكة من المربعات بحيث تَكون المربعات الميتة سوداء اللون أما المربعات الحية فتَكُون بيضاء اللون. (سيَستخدِم البرنامج الصنف MosaicCanvas.java من القسم 4.7 لتَمثيِل تلك الشبكة، لذلك ستحتاج إلى إضافة ذلك الملف لتَصرِيف [compile] البرنامج وتَشْغِيله). يُمكِننا أن نملئ رقعة الحياة بخلايا حية وميتة عشوائيًا أو قد نَستخدِم الفأرة لضَبطها. يُوفِّر البرنامج الزر "Step" المسئول عن تحديد حالة الشبكة بَعْد خطوة واحدة فقط" بالإضافة إلى الزر "Start" المسئول عن تَشْغِيل تلك الخطوات بهيئة تحريكة (animation). سنَفْحَص العمليات المُتعلِقة بمعالجة المصفوفات (array processing) اللازمة لتّنفِيذ برنامج لعبة الحياة (Game of Life). أولًا، يُمكِن لأي خلية أن تَكُون حية أو ميتة، لذلك سنَستخدِم بطبيعة الحال مصفوفة ثنائية البعد من النوع boolean[][]‎ لتمثيل حالة جميع الخلايا، وليَكُن اسم تلك المصفوفة هو alive. ستُساوِي قيمة أي عنصر alive[r][c]‎ القيمة true إذا كانت الخلية برقم الصف r ورقم العمود c حية. سنَستخدِم أيضًا نفس قيمة الثابت GRID_SIZE لتمثيل عدد الصفوف والأعمدة بتلك المصفوفة. يُمكِننا إذًا أن نَستخدِم حَلْقة التَكْرار for المُتداخلة (nested) التالية لمَلْئ قيم تلك المصفوفة المُمثِلة لشبكة الحياة بقيم عشوائية: for (int r = 0; r < GRID_SIZE; r++) { for (int c = 0; c < GRID_SIZE; c++) { // ‫اضبط الخلية لتكون حية بنسبة احتمال تساوي 25% alive[r][c] = (Math.random() < 0.25); } } يُعيد التعبير Math.random() < 0.25 القيمة true أو false، والتي يُمكِننا أن نُسنِدها (assign) إلى عنصر مصفوفة من النوع boolean. سنَستخدِم تلك المصفوفة لضَبْط لون كل خلية بالشاشة. نظرًا لأننا سنَرسِم شبكة الخلايا على شاشة من الصَنْف MosaicCanvas، فإننا سنَستخدِم واجهة برمجة التطبيقات (ِAPI) الخاصة بذلك الصنف لضَبْط ألوانها. ونظرًا لأن الصَنْف MosaicCanvas هو المسئول عن الرسم الفعليّ، سيَكُون برنامج لعبة الحياة مسئولًا فقط عن ضَبْط الألوان باِستخدَام واجهة برمجة التطبيقات الخاصة بالصَنْف. سنُعرِّف ذلك بتابع اسمه showBoard()‎، والذي ينبغي أن يُستدعَى بكل مرة تَتَغيَّر فيها رقعة الحياة. سنَستخدِم مجددًا حَلْقة تَكْرار for مُتداخِلة لضَبْط لون كل مربع بالشبكة كالتالي: for (int r = 0; r < GRID_SIZE; r++) { for (int c = 0; c < GRID_SIZE; c++) { if (alive[r][c]) display.setColor(r,c,Color.WHITE); else display.setColor(r,c,null); // اعرض لون الخلفية بالأسود } } بالطبع، يُعدّ حساب الحالة الجديدة لشبكة الخلايا بَعْد تطبيق قواعد اللعبة على حالتها الحالية هو الجزء الأكثر تشويقًا من البرنامج. لمّا كانت القواعد ستُطبَق على كل خلية على حدى، فإننا سنحتاج إلى اِستخدَام حَلْقة تَكْرار for مُتداخِلة للمرور عبر جميع خلايا الشبكة، ولكن ستَكُون المعالجة أكثر تعقيدًا هذه المرة. لاحظ أنه لا يُمكِننا أن نُجرِي أي تغييرات على قيم المصفوفة أثناء معالجتها؛ لأننا سنحتاج إلى معرفة الحالة القديمة لخلية معينة أثناء معالجة خلاياها المجاورة. سيَستخدِم البرنامج مصفوفة آخرى للاحتفاظ بالحالة الجديدة أثناء المعالجة، وعندما ننتهي من معالجة جميع الخلايا ضِمْن الشبكة، يُمكننا أن نَستخدِم المصفوفة الجديدة بدلًا من القديمة. يُمكِننا كتابة الخوارزمية (algorithm) بالشيفرة الوهمية (pseudocode) كالتالي: let newboard be a new boolean[][] array for each row r: for each column c: Let N be the number of neighbors of cell (r,c) in the alive array if ((N is 3) or (N is 2 and alive[r][c])) newboard[r][c] = true; else newboard[r][c] = false; alive = newboard سيُشيِر alive عند انتهاء المعالجة إلى مصفوفة جديدة، وهو أمر لا ينبغي أن نقلق بشأنه طالما كانت محتويات المصفوفة الجديدة مُمثِلة للحالة الجديدة لشبكة الخلايا أما المصفوفة القديمة فسيُحرِّرها كانس المُهملات (garabage collector). قد لا يَكون اختبار ما إذا كان newboard[r][c]‎ مُتحقِقًا أم لا واضحًا بما فيه الكفاية، ولكنه يُنفِّذ القواعد بشكل سليم. سنحتاج أيضًا لحِسَاب عدد الخلايا المجاورة. إذا كان لدينا خلية بالصف r والعمود c، ولم تَكُن تلك الخلية واقعة على حافة الرقعة، فإن الخلايا المجاورة لتلك الخلية هي كالتالي: لاحِظ أن رقم الصف فوق الصف r يُساوِي r-1 أما الصف أسفله فهو r+1. يَنطبِق نفس الأمر على الأعمدة. ينبغي إذًا أن نَفْحَص القيم alive[r-1][c-1]‎ و alive[r-1][c]‎ و alive[r-1][c+1]‎ و alive[r][c-1]‎ و alive[r][c+1]‎ و alive[r+1][c-1]‎ و alive[r+1][c]‎ و alive[r+1][c+1]‎، ونَعِد منها تلكم المُحتوية على القيمة true. اِحرِص على فهم كيفية عمل فهارس المصفوفة. في المقابل، ستواجهنا مشكلة إذا كانت الخلية وَاقِعة على إحدى حواف الشبكة. في تلك الحالة، لا تَكُون بعض العناصر ضِمْن القائمة السابقة موجودة، وستَتَسبَّب محاولة الاشارة إليها إلى حدوث اِعترَاض (exception). لكي نَتَجنَّب حُدوث ذلك، ينبغي أن نُعامِل الخلايا الواقعة على الحواف بطريقة مختلفة. يُمكِننا مثلًا أن نَفْحَص ما إذا كان عنصر المصفوفة موجودًا قبل محاولة الإشارة إليه. في تلك الحالة، يُمكِننا مثلًا أن نَكْتُب شيفرة حساب عدد الخلايا المجاورة الحية كالتالي: if (r-1 >= 0 && c-1 >= 0 && alive[r-1][c-1]) N++; // ‫خلية بالموضع (r-1,c-1) موجودة وحية if (r-1 >= 0 && alive[r-1][c]) N++; // خلية بالموضع‫ (r-1,c) موجودة وحية if (r-1 >= 0 && c+1 <= GRID_SIZE && alive[r-1][c+1]) N++; // ‫خلية بالموضع (r-1,c+1) موجودة وحية // إلخ سنتجنَّب بذلك كل الاعتراضات (exceptions). اِستخدَمنا في الواقع حلًا آخر شائع الاِستخدَام بألعاب الحاسوب ثنائية البعد. سنَتَظاهَر كما لو أن الحافة اليسرى للرقعة مُرتبطِة بالحافة اليمنى وكما لو أن الحافة العلوية مُرتبطِة بالحافة السفلية. بالنسبة لخلية برقم الصف 0 على سبيل المثال، فإن الصف أعلاها هو الصف الأخير أي بالرقم GRID_SIZE-1. سنَستخدِم أيضًا مُتْغيِّرات لتمثيل المَواضِع above و below و left و right الخاصة بخلية معينة. اُنظر شيفرة التابع المسئولة عن حساب الحالة الجديدة للرقعة، والتي ستَجِد أنها أبسط كثيرًا: private void doFrame() { // احسب الحالة الجديدة لرقعة لعبة الحياة boolean[][] newboard = new boolean[GRID_SIZE][GRID_SIZE]; for ( int r = 0; r < GRID_SIZE; r++ ) { // ‫تعد الصفوف أعلى وأسفل الصف r int above, below; // ‫تعد الأعمدة على يمين ويسار العمود c int left, right; above = r > 0 ? r-1 : GRID_SIZE-1; // (for "?:" see Subsection 2.5.5) below = r < GRID_SIZE-1 ? r+1 : 0; for ( int c = 0; c < GRID_SIZE; c++ ) { left = c > 0 ? c-1 : GRID_SIZE-1; right = c < GRID_SIZE-1 ? c+1 : 0; int n = 0; // عدد الخلايا الحية المجاورة if (alive[above][left]) n++; if (alive[above][c]) n++; if (alive[above][right]) n++; if (alive[r][left]) n++; if (alive[r][right]) n++; if (alive[below][left]) n++; if (alive[below][c]) n++; if (alive[below][right]) n++; if (n == 3 || (alive[r][c] && n == 2)) newboard[r][c] = true; else newboard[r][c] = false; } } alive = newboard; } يُمكِنك الإطلاع على شيفرة البرنامج بالملف Life.java، وأن تُجرِبه. لا تنسى أنك ستحتاج إلى اِستخدَام الملف MosaicCanvas.java أيضًا. لعبة داما (Checkers) سنَفْحَص الآن مثالًا أكثر واقعية لاستخدام المصفوفات ثنائية البعد. يُعدّ هذا البرنامج هو الأطول حتى الآن حيث يَتَكوَّن من 745 سطر. يَسمَح ذلك البرنامج للمُستخدمين بلعب مباراة داما (checkers). تتكوَّن لعبة الداما من رقعة مُكوَّنة من 8 صفوف و8 أعمدة. سنعتمد على المثال الذي كتبناه بالقسم الفرعي 6.5.1. سنُسمِي اللاعبين بأسماء "أحمر" و "أسود" وفقًا للون قطع الداما الخاصة بهما. لن نشرح قواعد لعبة الداما هنا، ولربما تستطيع أن تتعلَّمها بينما تُجرِّب البرنامج. يستطيع اللاعب أن يَتحرَك بالنَقْر على القطعة التي يريد أن يُحرِكها ثُمَّ بالنَقْر على المربع الفارغ الذي يريد أن يَنقِل إليه تلك القطعة. سيَرسِم البرنامج بأي لحظة إطارًا حول المربعات التي يستطيع اللاعب أن يَنقُر عليها بلون أفتح قليلًا كنوع من المساعدة. على سبيل المثال، سيُحَاط المربع المُتضمِّن للقطعة التي اختارها المُستخدِم للحركة بإطار أصفر اللون بينما ستُحَاط القطع الآخرى التي بإمكانه تَحرِيكها بإطار أزرق سماوي. إذا كان المُستخدِم قد اختار قطعة بالفعل لتَحرِيكها، فستُحَاط جميع المربعات الفارغة التي يستطيع أن يُحرِك إليها تلك القطعة بإطار أخضر اللون. ستَتبِع اللعبة قاعدة تَنُص على أنه إذا كان اللاعب الحالي قادرًا على القفز (jump) على إحدى قطع الخصم، فإنه لابُدّ أن يَقفِز. عندما تُصبِح إحدى القطع "قطعة ملك" أي بَعْد وصولها إلى الحافة الأخرى من الرقعة، سيَرسِم البرنامج حرف "K" أبيض كبير على تلك القطعة. تَعرِض الصورة التالية لقطة شاشة مبكرة من اللعبة، والتي تُظهِر اللاعب الأسود وقد اختار القطعة الموجودة بالمربع ذو الإطار الأصفر للحركة. يستطيع اللاعب الآن أن يَنقُر على إحدى المربعات المُحاطَة بإطار أخضر لكي يُكمِل تلك الحركة أو قد يَنقُر على إحدى المربعات المُحاطَة بإطار أزرق سماوي ليختار قطعة آخرى لتَحرِيكها. سنَمُر عبر جزءًا من شيفرة ذلك المثال، ولكن يُمكِنك الاطلاع على الشيفرة بالكامل بالملف Checkers.java. قد يَكُون البرنامج طويلا ومعقدًا، ولكنه بقليل من الدراسة، ستَتَمكَّن من فهم جميع التقنيات المُستخدَمة به. يُعدّ البرنامج مثالًا جيدًا على البرمجة كائنية التوجه (object-oriented) المُعتمدِة على كُلًا من الأحداث (event-driven) والحالات (state-based). سنُخزِّن بيانات قطع الرقعة بمصفوفة ثنائية البعد (two-dimensional array). نظرًا لأن البرنامج مُعقَد نوعًا ما، سنُقسِّمه إلى عدة أصناف. إلى جانب الصَنْف الأساسي، سنُعرِّف بعض الأصناف المُتداخِلة (nested) الآخرى منها الصَنْف CheckersData المُستخدَم لمعالجة بيانات الرقعة. لا يُعدّ ذلك الصَنْف مسئولًا مباشرًا عن أي جزء من الرسوم (graphics) أو مُعالجة الأحداث (event-handling)، ولكنه يُوفِّر التوابع (methods) التي يُمكِننا أن نستدعيها بأصناف آخرى لأغراض معالجة الرسوم والأحداث (events). سنناقش ذلك الصَنْف قليلًا. يَحتوِي الصَنْف CheckersData على مُتْغيِّر نُسخة (instance variables) اسمه هو board من النوع int[][]‎‎. تُضبَط قيمة ذلك المُتْغيِّر إلى new int[8][8]‎ لتُمثِل شبكة 8x8 من الأعداد الصحيحة (integers). تُستخدَم ثوابت (constants) لتعريف القيم المُحتمَل تَخْزِينها بمربع برقعة شطرنج (checkboard): static final int EMPTY = 0, // يمثل مربعًا فارغًا RED = 1, // قطعة حمراء عادية RED_KING = 2, // قطعة ملك حمراء BLACK = 3, // قطعة سوداء عادية BLACK_KING = 4; // قطعة ملك سوداء سنَستخدِم أيضًا الثابتين RED و BLACK بالبرنامج لتَمثيِل لاعبي المباراة. عندما تبدأ المباراة، ستُضبَط قيم المصفوفة لتمثيل الحالة المبدئية للرقعة، وستبدو كالتالي: يُمكِن لأي قطعة سوداء عادية أن تتحرك لأسفل الشبكة فقط أي لابُدّ أن يكون رقم الصف للمربع الذي ستنتقل إليه أكبر من رقم الصف للمربع القادمة منه. بالمقابل، تستطيع أي قطعة حمراء عادية أن تَتَحرك لأعلى الشبكة فقط. يُمكِن للملوك بأي من اللونين الحركة بكلا الاتجاهين. لابُدّ أن ينتبه الصَنْف CheckersData لأي تَغييرات ينبغي إجراؤها على هياكل البيانات (data structures) عندما يُحرِك أحد اللاعبين قطعة معينة بالرقعة. في الواقع، يُعرِّف الصَنْف تابع النسخة makeMove()‎ المُخصَّص لذلك الغرض. عندما يُحرِك لاعب قطعة من مربع إلى آخر، سيُعدِّل التابع قيمة عنصرين ضِمْن المصفوفة. بالإضافة إلى ذلك، إذا كانت الحركة عبارة عن قفزة (jump)، ستُحذَف القطعة التي كانت موجودة بالمربع المقفوز إليه من الرقعة. يستطيع التابع أن يُحدِّد ما إذا كانت حركة معينة عبارة عن قفزة أم لا بِفْحَص ما إذا كان المربع الذي تَحرَكت إليه القطعة يَبعُد بمقدار صفين عن المربع الذي بدأت منه. إلى جانب ما سبق، تُصبِح القطعة الحمراء RED التي تتحرك إلى الصف 0 أو القطعة السوداء Black التي تتحرك إلى الصف 7 بمثابة قطعة ملك (king). سنَضَع جميع ما سبق ببرنامج فرعي (subroutine)، وبالتالي، لن يضطّر باقي البرنامج للقلق بشأن أي من تلك التفاصيل السابقة. يُمكِنه فقط أن يَستدعِي التابع makeMove()‎: void makeMove(int fromRow, int fromCol, int toRow, int toCol) { board[toRow][toCol] = board[fromRow][fromCol]; // حرك القطعة board[fromRow][fromCol] = EMPTY; // المربع الذي تحركت منه أصبح فارغًا if (fromRow - toRow == 2 || fromRow - toRow == -2) { // الحركة كانت قفزة لذلك احذف القطعة المقفوز إليها من الرقعة int jumpRow = (fromRow + toRow) / 2; // صف القطعة المقفوز إليها int jumpCol = (fromCol + toCol) / 2; // عمود القطعة المقفوز إليها board[jumpRow][jumpCol] = EMPTY; } if (toRow == 0 && board[toRow][toCol] == RED) board[toRow][toCol] = RED_KING; // تصبح القطعة الحمراء ملك if (toRow == 7 && board[toRow][toCol] == BLACK) board[toRow][toCol] = BLACK_KING; // تصبح القطعة السوداء ملك } // end makeMove() ينبغي أن يَسمَح الصَنْف CheckersData بالعثور على جميع الحركات الصالحة بالرقعة. سنستخدم كائنًا ينتمي للصَنْف التالي لتمثيل الحركة داخل لعبة داما: private static class CheckersMove { int fromRow, fromCol; // موضع القطعة المطلوب تحريكها int toRow, toCol; // المربع الذي انتقلت إليه القطعة CheckersMove(int r1, int c1, int r2, int c2) { // اضبط قيم متغيرات النسخة fromRow = r1; fromCol = c1; toRow = r2; toCol = c2; } boolean isJump() { // اختبر ما إذا كانت الحركة عبارة عن قفزة // بالقفزة، تتحرك القطعة مسافة صفين return (fromRow - toRow == 2 || fromRow - toRow == -2); } } // end class CheckersMove. يُعرِّف الصَنْف CheckersData تابع نسخة (instance method) للعثور على جميع الحركات المتاحة حاليًا لكل لاعب. يُعدّ ذلك التابع بمثابة دالة (function) تُعيِد مصفوفة من النوع CheckersMove[]‎ تحتوي على جميع الحركات المتاحة مُمثَلة بهيئة كائنات من النوع CheckersMove. يُمكِننا إذًا كتابة توصيف التابع كالتالي: CheckersMove[] getLegalMoves(int player) يُمكِننا كتابة خوارزمية التابع بالشيفرة الوهمية (pseudocode) كالتالي: // ابدأ بقائمة فارغة من الحركات Start with an empty list of moves // ابحث عن أي قفزات صالحة و أضفها إلى القائمة Find any legal jumps and add them to the list // إذا لم يكن هناك أي قفزات صالحة if there are no jumps: // ابحث عن الحركات العادية الأخرى و أضفها إلى القائمة Find any other legal moves and add them to the list // إذا كانت القائمة فارغة if the list is empty: return null else: return the list الآن، ما هو المقصود بالقائمة (list)؟ في الواقع، ينبغي أن نُعيد الحركات المسموح بها ضِمْن مصفوفة، ولكن لأن المصفوفات ثابتة الحجم، لا يُمكِننا أن نُنشِئها حتى نَعرِف عدد الحركات، وهو في الواقع ما لا يُمكِننا معرفته حتى نَصِل إلى نهاية التابع أي بَعْد أن نَكُون قد أنشأنا القائمة بالفعل! أحد الحلول إذًا هو اِستخدَام مصفوفة ديناميكية من النوع ArrayList بدلًا من مصفوفة عادية لكي تَحمِل الحركات بينما نَجِدها. يَستخدِم البرنامج بالأسفل كائنًا من النوع ArrayList<CheckersMove>‎ لكي يُمكِّن القائمة من حَمْل كائنات من الصَنْف CheckersMove فقط. بينما نُضيِف الحركات إلى تلك القائمة، سيزداد حجمها بما يتناسب مع عدد الحركات. يُمكِننا أن نُنشِئ المصفوفة المطلوبة ونَنسَخ البيانات إليها بنهاية التابع. اُنظر الشيفرة الوهمية التالية: // ‫أنشئ قائمة moves فارغة للحركات Let "moves" be an empty ArrayList<CheckersMove> // ابحث عن القفزات المسموح بها و أضفها إلى القائمة Find any legal jumps and add them to moves // إذا كان عدد الحركات ما يزال يساوي 0 if moves.size() is 0: // There are no legal jumps! // ابحث عن الحركات العادية الصالحة و أضفها إلى القائمة Find any other legal moves and add them to moves // إذا لم يكن عدد الحركات يساوي 0 if moves.size() is 0: // There are no legal moves at all! return null else: // ‫عرف مصفوفة moveArray من النوع CheckersMoves // ‫طولها يساوي moves.size() Let moveArray be an array of CheckersMoves of length moves.size() // ‫انسخ محتويات المصفوفة moves إلى moveArray Copy the contents of moves into moveArray return moveArray علينا الآن أن نُحدِّد الحركات والقفزات المسموح بها. تَتَوفَّر المعلومات التي نحتاج إليها بالمصفوفة board، ولكن يَلزَمنا بعض العمل لاِستخراجها. لابُدّ أن نَفْحَص جميع المواضع بالمصفوفة ونَعثُر على القطع التي تنتمي للاعب الحالي. بَعْد ذلك، ينبغي أن نَفْحَص المربعات التي يُمكِن لكل قطعة أن تنتقل إليها، ونُحدِّد ما إذا كانت تلك الحركة صالحة أم لا. إذا كنا نبحث عن القفزات المسموح بها، فينبغي أن نَفْحَص المربعات التي تَبعُد بمسافة صفين وعمودين من كل قطعة. يُمكِننا إذًا أن نُوسِّع سطر الخوارزمية "اِبحَث عن القفزات المسموح بها ثم أَضِفها إلى الحركات" كالتالي: // لكل صف بالرقعة For each row of the board: // لكل عمود بالرقعة For each column of the board: // إذا كانت إحدى قطع اللاعبين بذلك المكان if one of the player's pieces is at this location: // ‫إذا كان من الممكن القفز إلى الموضع row+2,column+2 if it is legal to jump to row + 2, column + 2 // ‫أضف تلك الحركة إلى moves add this move to moves // ‫إذا كان من الممكن القفز إلى الموضع row-2,column+2 if it is legal to jump to row - 2, column + 2 add this move to moves // ‫إذا كان من الممكن القفز إلى الموضع row+2,column-2 if it is legal to jump to row + 2, column - 2 add this move to moves // ‫إذا كان من الممكن القفز إلى الموضع row-2,column-2 if it is legal to jump to row - 2, column - 2 add this move to moves ينبغي أن نُوسِّع السطر "ابحث عن الحركات الصالحة الآخرى وأضفها إلى قائمة الحركات" بنفس الطريقة باستثناء أن علينا الآن فَحْص المربعات الأربعة التي تَبعُد مسافة صف واحد وعمود واحد من كل قطعة. لاحِظ أن اختبار ما إذا كان لاعب معين يستطيع أن يُحرِك قطعة من مربع معين إلى مربع آخر ليس بالأمر السهل. لابُدّ أن يَكُون المربع الذي ينتقل إليه اللاعب موجودًا بالرقعة، كما ينبغي أن يَكُون فارغًا. علاوة على ذلك، تستطيع القطع الحمراء والسوداء العادية أن تَتَحرَك باتجاه واحد. سنَستخدِم التابع (method) التالي لفْحَص ما إذا كان لاعب معين قادر على القيام بتحريك مربع: private boolean canMove(int player, int r1, int c1, int r2, int c2) { if (r2 < 0 || r2 >= 8 || c2 < 0 || c2 >= 8) return false; // ‫(r2,c2) خارج الرقعة if (board[r2][c2] != EMPTY) return false; // ‫(r2,c2) يحتوي بالفعل على قطعة if (player == RED) { if (board[r1][c1] == RED && r2 > r1) return false; // القطع الحمراء العادية يمكنها أن تتحرك للأسفل فقط return true; // الحركة صالحة } else { if (board[r1][c1] == BLACK && r2 < r1) return false; // القطع السوداء العادية يمكنها أن تتحرك للأعلى فقط return true; // الحركة صالحة } } // end canMove() يَستدعِى التابع getLegalMoves()‎ التابع canMove()‎ المُعرَّف بالأعلى ليَفْحَص ما إذا كانت حركة مُحتمَلة لقطعة معينة صالحة فعليًا أم لا. سنُعرِّف تابعًا مشابهًا لفَحْص ما إذا كانت قفزة (jump) معينة صالحة أم لا. في تلك الحالة، سنُمرِّر للتابع كُلًا من مربع القطعة والمربع الذي يُحتمَل أن تَنتقِل إليه وكذلك المربع الواقع بين هذين المربعين أي ذلك الذي سيَقفِز اللاعب فوقه. لابُدّ أن يَحتوِي المربع المقفوز إليه على إحدى قطع الخصم. يُمكننا تَوصِيف ذلك التابع كالتالي: private boolean canJump(int player, int r1, int c1, int r2, int c2, int r3, int c3) { . . . ينبغي الآن أن تَكُون قادرًا على فِهم شيفرة التابع getLegalMoves()‎ بالكامل. يَدمِج ذلك التابع عدة مواضيع معًا: المصفوفات أحادية البعد (one-dimensional) والمصفوفات الديناميكية ArrayLists والمصفوفات ثنائية البعد (two-dimensional): CheckersMove[] getLegalMoves(int player) { if (player != RED && player != BLACK) return null; // لن يحدث هذا ببرنامج سليم int playerKing; // The constant for a King belonging to the player. if (player == RED) playerKing = RED_KING; else playerKing = BLACK_KING; ArrayList<CheckersMove> moves = new ArrayList<CheckersMove>(); // ستخزن الحركة ضمن القائمة // تحقق من جميع القفزات الممكنة for (int row = 0; row < 8; row++) { for (int col = 0; col < 8; col++) { if (board[row][col] == player || board[row][col] == playerKing) { if (canJump(player, row, col, row+1, col+1, row+2, col+2)) moves.add(new CheckersMove(row, col, row+2, col+2)); if (canJump(player, row, col, row-1, col+1, row-2, col+2)) moves.add(new CheckersMove(row, col, row-2, col+2)); if (canJump(player, row, col, row+1, col-1, row+2, col-2)) moves.add(new CheckersMove(row, col, row+2, col-2)); if (canJump(player, row, col, row-1, col-1, row-2, col-2)) moves.add(new CheckersMove(row, col, row-2, col-2)); } } } // إذا وجدت أي قفزات ممكنة، فلابد أن يقفز اللاعب. لذلك لن نضيف أي // حركات عادية. أما إذا لم تجد أي قفزات، ابحث عن أي حركات عادية if (moves.size() == 0) { for (int row = 0; row < 8; row++) { for (int col = 0; col < 8; col++) { if (board[row][col] == player || board[row][col] == playerKing) { if (canMove(player,row,col,row+1,col+1)) moves.add(new CheckersMove(row,col,row+1,col+1)); if (canMove(player,row,col,row-1,col+1)) moves.add(new CheckersMove(row,col,row-1,col+1)); if (canMove(player,row,col,row+1,col-1)) moves.add(new CheckersMove(row,col,row+1,col-1)); if (canMove(player,row,col,row-1,col-1)) moves.add(new CheckersMove(row,col,row-1,col-1)); } } } } // إذا لم تجد أي حركات صالحة، أعد فراغا if (moves.size() == 0) return null; else { // انشئ مصفوفة وأضف إليها الحركات المسموح بها CheckersMove[] moveArray = new CheckersMove[moves.size()]; for (int i = 0; i < moves.size(); i++) moveArray[i] = moves.get(i); return moveArray; } } // end getLegalMoves يُعدّ برنامج الداما مُعقدًا نوعًا ما، ويحتاج إلى الكثير من التصميم الجيد لتَقْرِير الأصناف (classes) والكائنات (classes) المُستخدمَة، وكذلك لتَقرِير التوابع (methods) التي ينبغي كتابتها، وكذلك لتقرير الخوارزميات (algorithms) التي ينبغي لتلك التوابع اِستخدَامها. يُمكِنك الاطلاع على شيفرة البرنامج بالكامل بالملف Checkers.java. ترجمة -بتصرّف- للقسم Section 5: Two-dimensional Arrays من فصل Chapter 7: Arrays and ArrayLists من كتاب Introduction to Programming Using Java.
  2. تُعدّ عمليتي البحث (searching) والترتيب (sorting) أكثر الأساليب شيوعًا لمعالجة المصفوفات. يُشير البحث (searching) هنا إلى محاولة العثور على عنصر بمواصفات معينة ضِمْن مصفوفة بينما يُشير الترتيب (sorting) إلى إعادة ترتيب عناصر المصفوفة ترتيبًا تصاعديًا أو تنازليًا. عادةً ما يَعتمِد المقصود بالترتيب التصاعدي والتنازلي على السياق المُستخدَم به الترتيب. في الواقع، تُوفِّر الجافا تُوفِّر بعض التوابع المَبنية مُسْبَقّا (built-in methods) الخاصة بعمليات البحث والترتيب -كما رأينا بالقسم الفرعي 7.2.2-، ومع ذلك ينبغي أن تَكُون على اطلاع ومعرفة بالخوارزميات (algorithms) التي تَستخدِمها تلك التوابع. ولهذا، سنَتعلَّم بعضًا من تلك الخوارزميات بهذا القسم. عادةً ما يُناقَش البحث (searching) والترتيب (sorting) نظريًا باِستخدَام مصفوفة من الأعداد. ولكن من الناحية العملية، هناك أمور أكثر تشويقًا بكثير. فمثلًا، قد تَكُون المصفوفة عبارة عن قائمة بريدية بحيث يَكُون كل عنصر بها عبارة عن كائن (object) يَحتوِي على اسم وعنوان. إذا كان لدينا اسم شخص معين، يُمكِننا العثور على عنوانه، وهو ما يُعدّ مثالًا على عملية البحث (searching)؛ لأنك ببساطة تَبحَث عن كائن ضِمْن مصفوفة بالاعتماد على اسم الشخص. سيَكُون من المفيد أيضًا لو تَمَكَّنا من ترتيب المصفوفات وفقًا لمعيار معين مثل أن نُرتِّب المصفوفة السابقة بحيث تَكُون الأسماء مُرتَّبة ترتيبًا أبجديًا أو قد نُرتِّبها وفقًا للرقم البريدي. سنُعمِّم الآن المثال السابق إلى تصور مُجرَّد بعض الشئ: لنتخيل أن لدينا مصفوفة تَحتوِي على عدة كائنات (objects)، وأننا نرغب بالبحث داخل تلك المصفوفة أو نرغب بترتيبها بالاعتماد على احدى مُتْغيِّرات النُسخ (instance variables) المُعرَّفة بتلك الكائنات. سنلجأ إلى اِستخدَام بعض المصطلحات الشائعة بقواعد البيانات (databases). سنُطلِق اسم "تسجيل (record)" على كل كائن ضِمْن المصفوفة بينما سنُطلِق اسم "الحقول (fields)" على مُتْغيِّرات النُسخ المُعرَّفة بتلك الكائنات. نستطيع الآن أن نُعيِد صياغة مثال القائمة البريدية إلى ما يلي: يَتَكوَّن كل تسجيل (record) من اسم وعنوان. قد تَتَكوَّن حقول التسجيل من الاسم الأول والأخير والعنوان والمدينة والدولة والرقم البريدي. ينبغي أن نختار إحدى تلك الحقول لتُصبِح "مفتاحًا (key)" لكي نَتَمكَّن من إجراء عمليتي البحث والترتيب. وفقًا لهذا التصور، سيُمثِل البحث محاولة العثور على تسجيل بالمصفوفة بحيث يَحتوِي مفتاحه على قيمة معينة بينما سيُمثِل الترتيب (sorting) تَبديِل مواضع تسجيلات المصفوفة إلى أن تُصبِح مفاتيحها (keys) مُرتَّبة ترتيبًا تصاعديًا أو تنازليًا. البحث (Searching) هناك خوارزمية واضحة للبحث عن عنصر معين داخل مصفوفة: افحص كل عنصر بالمصفوفة بالترتيب، واختبر ما إذا كانت قيمة ذلك العنصر هي نفسها القيمة التي تبحث عنها. إذا كان كذلك، فقد انتهت عملية البحث إذًا. أما إذا لم تعثر عليه بعد فحص جميع عناصر المصفوفة، فهو إذًا غير موجود بها. يُمكننا كتابة برنامج فرعي لتنفيذ تلك الخوارزمية (algorithm) بسهولة. بفرض أن المصفوفة التي تريد البحث بها عبارة عن مصفوفة من النوع int[]‎، يبحث التابع (method) التالي عن قيمة عددية ضمن مصفوفة. سيعيد التابع فهرس (index) العنصر بالمصفوفة إذا عثر عليه بينما سيعيد -1 إذا لم يعثر عليه كإشارة أن العدد الصحيح غير موجود: static int find(int[] A, int N) { for (int index = 0; index < A.length; index++) { if ( A[index] == N ) // ‫عثرنا على N بهذا الفهرس return index; } // ‫إذا وصلنا إلى هنا، فإن N غير موجودة بأي مكان ضمن المصفوفة // أعد القيمة -1 return -1; } يُطلَق على طريقة البحث السابقة اسم البحث الخطي (linear search). إذا لم يَكُن لدينا أي معلومة عن كيفية ترتيب العناصر ضِمْن المصفوفة، فإنها تُمثِل الخيار الأفضل. في المقابل، إذا كنا على علم بكَوْن عناصر المصفوفة مُرتَّبة تصاعديًا أو تنازليًا، يُمكِننا إذًا أن نستغل تلك الحقيقة، ونَستخدِم خوارزميات أسرع. إذا كانت عناصر مصفوفة معينة مرتبة، يُقال عليها أنها "مصفوفة مرتبة (sorted)". يَستغرق ترتيب عناصر مصفوفة بعض الوقت بالطبع، ولكن إذا كانت المصفوفة مرتبة بالفعل، فيُمكننا إذًا أن نستغل تلك الحقيقة. يُعدّ البحث الثنائي (binary search) أحد الطرائق المُتاحة للبحث عن عنصر ضِمْن مصفوفة مُرتَّبة (sorted). على الرغم من أن تّنْفِيذه (implement) ليس سهلًا تمامًا، فإن فكرته بسيطة: إذا كنت تَبحَث عن عنصر ضِمْن قائمة مُرتَّبة، يُمكِنك أن تَستبعِد نُصف العناصر ضِمْن القائمة بِفَحْص عنصر واحد فقط. على سبيل المثال، لنَفْترِض أننا نبحث عن العدد 42 ضِمْن مصفوفة مُرتَّبة مُكوَّنة من 1000 عدد صحيح، ولنَفْترِض أن المصفوفة مُرتَّبة ترتيبًا تصاعديًا، ولنَفْترِض أننا فَحصَنا العنصر الموجود بالفهرس 500، ووجدنا أن قيمته تُساوِي 93. لمّا كان العدد 42 أقل من 93، ولمّا كانت العناصر بالمصفوفة مُرتَّبة ترتيبًا تصاعديًا، يُمكِننا إذًا أن نَستنتج أنه في حالة كان العدد 42 موجودًا بتلك المصفوفة من الأساس، فإنه لابُدّ وأنه يَقَع بمَوضِع فهرسه أقل من 500. يُمكِننا إذًا أن نَستبِعد جميع العناصر الموجودة بمَواضِع فهرسها أكبر من 500؛ فهي بالضرورة أكبر من أو تُساوِي 93. الخطوة التالية ببساطة هي فَحْص قيمة العنصر بالمَوْضِع 250. إذا كان العدد بذلك المَوْضِع يُساوِي -21 مثلًا، يُمكِننا إذًا أن نَستبعِد جميع العناصر قَبل المَوْضِع 250، ونُقصِر بحثنا على المَواضِع من 251 إلى 499. سيُقصِر الاختبار التالي بحثنا إلى 125 مَوضِع فقط ثُمَّ إلى 62. سيَتَبقَّى مَوضِع واحد فقط بعد 10 خطوات. تُعدّ تلك الطريقة أفضل كثيرًا من فَحْص كل عنصر ضِمْن المصفوفة. فمثلًا، إذا كانت المصفوفة تَحتوِي على مليون عنصر، ستَستغرِق خوارزمية البحث الثنائي 20 خطوة فقط للبحث بكامل المصفوفة. في العموم، يُساوِي عدد الخطوات اللازمة للبحث بأي مصفوفة لوغاريتم عدد العناصر بتلك المصفوفة بالنسبة للأساس 2. لكي نَتَمكَّن من تَحْوِيل خوارزمية البحث الثنائي (binary search) إلى برنامج فرعي (subroutine) يَبحَث عن عنصر N ضِمْن مصفوفة A، ينبغي أن نَحتفِظ بنطاق المَوْاضِع التي يُحتمَل أن تَحتوِي على N بحيث نَستبعِد منها تدريجيًا المزيد من الاحتمالات، ونُقلِّل من حجم النطاق. سنَفْحَص دائمًا العنصر الموجود بمنتصف النطاق. إذا كانت قيمته أكبر من N، يُمكِننا إذًا أن نَستبعِد النصف الثاني من النطاق أما إذا كانت قيمته أقل من N، يُمكِننا أن نَستبعِد النصف الأول. أما إذا كانت قيمته تُساوي N، فإن البحث يَكُون قد انتهى. إذا لم يَتبقَّى أية عناصر، فإن العدد N غَيْر موجود إذًا بالمصفوفة. اُنظر شيفرة البرنامج الفرعي (subroutine): /** * Precondition: A must be sorted into increasing order. * Postcondition: If N is in the array, then the return value, i, * satisfies A[i] == N. If N is not in the array, then the * return value is -1. */ static int binarySearch(int[] A, int N) { int lowestPossibleLoc = 0; int highestPossibleLoc = A.length - 1; while (highestPossibleLoc >= lowestPossibleLoc) { int middle = (lowestPossibleLoc + highestPossibleLoc) / 2; if (A[middle] == N) { // ‫عثرنا على N بهذا الفهرس return middle; } else if (A[middle] > N) { // ‫استبعد المواضع الأكبر من أو تساوي middle highestPossibleLoc = middle - 1; } else { // ‫استبعد المواضع الأقل من أو تساوي middle lowestPossibleLoc = middle + 1; } } // ‫إذا وصلنا إلى هنا فإن highestPossibleLoc < LowestPossibleLoc // ‫أي أن N غير موجود بالمصفوفة. // أعد القيمة -1 لكي تشير إلى عدم وجود‫ N بالمصفوفة return -1; } القوائم الارتباطية (Association Lists) تُعدّ القوائم الارتباطية (association lists) مثل القاموس (dictionary) واحدة من أشهر التطبيقات على البحث (searching). يَربُط القاموس (dictionary) مجموعة من التعريفات مع مجموعة من الكلمات. يُمكِنك مثلًا أن تَستخدِم كلمة معينة لمعرفة تَعرِيفها. قد تُفكِر بالقاموس على أنه قائمة من الأزواج (pairs) على الهيئة (w,d) حيث تُمثِل w كلمة معينة بينما d هي تعريف تلك الكلمة. بالمثل، تَتَكوَّن القوائم الارتباطية (association list) من قائمة من الأزواج (k,v) حيث تُمثِل k مفتاحًا (key) معينًا بينما تُمثِل v القيمة (value) المرتبطة بذلك المفتاح. لا يُمكِن لزوجين (pairs) ضِمْن قائمة معينة أن يَملُكا نفس قيمة المفتاح (key). عادةً ما نُطبِق عمليتين أساسيتين على القوائم الارتباطية: أولًا، إذا كان لديك مفتاح معين k، يُمكِنك أن تَجلُب القيمة v المُرتبِطة به إن وجدت. ثانيًا، يُمكِننا أن نُضيِف زوجًا جديدًا (k,v) إلى قائمة ارتباطية (association list). لاحِظ أنه في حالة إضافة زوج (pair) إلى قائمة، وكانت تلك القائمة تَحتوِي على زوج له نفس المفتاح، فإن القيمة الجديدة المضافة تَحلّ محلّ القديمة. يُطلق عادةً على تلك العمليتين اسم الجَلْب (get) والإضافة (put). يُشاع اِستخدَام القوائم الارتباطية (association lists) في العموم بعلوم الحاسوب (computer science). على سبيل المثال، لابُدّ أن يَحتفِظ المُصرِّف (compiler) بمَوضِع الذاكرة (memory location) الخاص بكل مُْتْغيِّر. يستطيع المُصرِّف إذًا أن يَستخدِم قائمة ارتباطية بحيث يُمثِل كل مفتاح (key) بها اسمًا لمُتْغيِّر بينما تُمثِل قيمة (value) ذلك المفتاح عنوانه بالذاكرة. مثال آخر هو القوائم البريدية إذا كان العنوان مَربُوطًا باسم ضِمْن تلك القائمة. فمثلًا، يَربُط دليل الهاتف كل اسم برقم هاتف. سنَفْحَص فيما يَلي نُسخة مُبسَطة من ذلك المثال. يُمكِننا أن نُمثِل عناصر دليل الهاتف بالقائمة الارتباطية (association list) بهيئة كائنات تنتمي إلى الصَنْف التالي: class PhoneEntry { String name; String phoneNum; } تَتَكوَّن البيانات الموجودة بدليل الهاتف من مصفوفة من النوع PhoneEntry[]‎ بالإضافة إلى مُتْغيِّر من النوع العددي الصحيح (integer) للاحتفاظ بعدد المُدْخَلات المُخزَّنة فعليًا بذلك الدليل. يُمكِننا أيضًا أن نَستخدِم تقنية المصفوفات الديناميكية (dynamic arrays) -اُنظر القسم الفرعي 7.2.4- لكي نَتجنَّب وَضْع حد أقصى عشوائي على عدد المُدْخَلات التي يُمكِن لدليل الهاتف أن يَحتوِيه أو قد نَستخدِم النوع ArrayList. ينبغي أن يَحتوِي الصَنْف PhoneDirectory على توابع نسخ (instance methods) لتّنْفِيذ (implement) كلًا من عمليتي الجَلْب (get) والإضافة (put). تُمثِل الشيفرة التالية تعريفًا (definition) بسيطًا لذلك الصَنْف: public class PhoneDirectory { private static class PhoneEntry { String name; // الاسم String number; // رقم الهاتف } private PhoneEntry[] data; // مصفوفة لحمل أزواج مكونة من أسماء وأرقام هاتف private int dataCount; // عدد الأزواج ضمن المصفوفة /** * Constructor creates an initially empty directory. */ public PhoneDirectory() { data = new PhoneEntry[1]; dataCount = 0; } private int find( String name ) { for (int i = 0; i < dataCount; i++) { if (data[i].name.equals(name)) return i; // الاسم موجود بالموضع‫ i } return -1; // الاسم غير موجود بالمصفوفة } /** * @return The phone number associated with the name; if the name does * not occur in the phone directory, then the return value is null. */ public String getNumber( String name ) { int position = find(name); if (position == -1) return null; // لا يوجد بيانات لذلك الاسم else return data[position].number; } public void putNumber( String name, String number ) { if (name == null || number == null) throw new IllegalArgumentException("name and number cannot be null"); int i = find(name); if (i >= 0) { // ‫الاسم موجود بالفعل بالموضع i بالمصفوفة // استبدل العدد الجديد بالعدد القديم بذلك الموضع data[i].number = number; } else { // أضف زوج جديد مكون من اسم وعدد إلى المصفوفة // إذا كانت المصفوفة ممتلئة، أنشئ مصفوفة جديدة أكبر if (dataCount == data.length) { data = Arrays.copyOf( data, 2*data.length ); } PhoneEntry newEntry = new PhoneEntry(); // أنشئ زوجا جديدا newEntry.name = name; newEntry.number = number; data[dataCount] = newEntry; // أضف الزوج الجديد إلى المصفوفة dataCount++; } } } // end class PhoneDirectory يُعرِّف الصَنْف تابع النسخة find()‎. يَستخدِم ذلك التابع أسلوب البحث الخطي (linear search) للعثور على مَوْضِع اسم معين بالمصفوفة المُكوَّنة من أزواج من الأسماء والأرقام. يَعتمِد كُلًا من التابعين getNumber()‎ و putNumber()‎ على التابع find()‎. لاحِظ أن التابع putNumber(name,number)‎ يَفحَص أولًا ما إذا كان الاسم موجودًا بدليل الهاتف أم لا. إذا كان موجودًا، فإنه فقط يُغيِّر الرقم المُرتبِط بذلك الاسم أما إذا لم يَكُن موجودًا، فإنه يُنشِئ مُدخلًا جديدًا ويُضيفه إلى المصفوفة. قد نُضيِف الكثير من التحسينات بالطبع على الصَنْف المعرَّف بالأعلى. فمثلًا، قد نَستخدِم البحث الثنائي (binary search) بالتابع getNumber()‎ بدلًا من البحث الخطي، ولكن يَتَطلَّب ذلك أن تَكُون الأسماء المُخزَّنة بقائمة المُدْخَلات مُرتَّبة ترتيبًا أبجديًا، وهو ليس أمرًا صعبًا كما ستَرَى بالقسم الفرعي التالي. عادةً ما يُطلَق اسم الخارطة (maps) على القوائم الارتباطية (association lists)، وتُوفِّر الجافا صَنْفًا قياسيًا ذو معاملات غَيْر محددة النوع (parameterized) اسمه هو Map كتنفيذ (implementation) لها. تستطيع أن تَستخدِم ذلك الصَنْف لكي تُنشِئ قوائمًا ارتباطية مُكوَّنة من مفاتيح (keys) وقيم (values) من أي نوع. يُعدّ ذلك التنفيذ (implementation) أكفأ بكثير من أي شيء قد تَفعَلُه باِستخدَام مصفوفات بسيطة. سنَتعرَّض بالفصل العاشر لذلك الصَنْف. الترتيب بالإدراج (Insertion Sort) اتضح لنا الآن الحاجة إلى ترتيب المصفوفات. في الواقع، تَتَوفَّر الكثير من الخوارزميات المُخصَّصة لذلك الغرض، منها خوارزمية الترتيب بالإدراج (insertion sort). تُعدّ تلك الخوارزمية واحدة من أسهل الطرائق لترتيب مصفوفة، كما يُمكِننا أن نُطبِقها للإبقاء على المصفوفة مُرتَّبة بينما نُضيِف إليها عناصر جديدة. لنَفْحَص المثال التالي أولًا: لنَفْترِض أن لدينا قائمة مُرتَّبة ونريد إضافة عنصر جديد إليها. إذا كنا نريد التأكُّد من أنها ستظلّ مُرتَّبة، ينبغي أن نُضيِف ذلك العنصر بمَوْضِعه الصحيح بحيث تأتي قبله جميع العناصر الأصغر بينما تَحِلّ بَعْده جميع العناصر الأكبر. يَعنِي ذلك تَحرِيك جميع العناصر الأكبر بمقدار خانة واحدة لترك مساحة للعنصر الجديد. static void insert(int[] A, int itemsInArray, int newItem) { int loc = itemsInArray - 1; // ابدأ من نهاية المصفوفة // ‫حرك العناصر الأكبر من newItem للأعلى بمقدار مسافة واحدة // وتوقف عندما تقابل عنصر أصغر أو عندما تصل إلى بداية المصفوفة while (loc >= 0 && A[loc] > newItem) { A[loc + 1] = A[loc]; // Bump item from A[loc] up to loc+1. loc = loc - 1; // انتقل إلى الموضع التالي } // ‫ضع newItem بآخر موضع فارغ A[loc + 1] = newItem; } يُمكِننا أن نَمِد ذلك إلى تابع للترتيب (sorting) بأخذ جميع العناصر الموجودة بمصفوفة غَيْر مُرتَّبة (unsorted) ثم اضافتها تدريجيًا واحدًا تلو الآخر إلى مصفوفة آخرى مع الإبقاء عليها مُرتَّبة. نستطيع أن نَستخدِم البرنامج insert بالأعلى أثناء كل عملية إدراج (insertion) لعنصر جديد. ملحوظة: بالخوارزمية الفعليّة، لا نأخُذ جميع العناصر من المصفوفة، ولكننا فقط نتذكَّر الأجزاء المُرتَّبة منها: static void insertionSort(int[] A) { // ‫رتب المصفوفة A ترتيبًا تصاعديا int itemsSorted; // عدد العناصر المُرتَّبة إلى الآن for (itemsSorted = 1; itemsSorted < A.length; itemsSorted++) { // ‫افترض أن العناصر A[0]‎ و A[1]‎ .. إلخ // ‫مرتبة بالفعل. أضف A[itemsSorted]‎ إلى الجزء المرتب من // القائمة int temp = A[itemsSorted]; // العنصر المطلوب إضافته int loc = itemsSorted - 1; // ابدأ بنهاية القائمة while (loc >= 0 && A[loc] > temp) { A[loc + 1] = A[loc]; // Bump item from A[loc] up to loc+1. loc = loc - 1; // Go on to next location. } // ‫ضع temp بآخر موضع فارغ A[loc + 1] = temp; } } تُوضِح الصورة التالية مرحلة واحدة من عملية الترتيب بالإدراج (insertion sort) حيث تُبيِّن ما يحدث أثناء تّنفِيذ تَكْرار واحد من الحلقة for بالأعلى بالتحديد عندما يَكُون عدد العناصر ضِمْن المصفوفة itemsSorted مُساوِيًا للقيمة 5: الترتيب الانتقائي (Selection Sort) تَستخدِم خوارزمية ترتيب (sorting) آخرى فكرة العُثور على أكبر عنصر ضِمْن القائمة، وتَحرِيكه إلى نهايتها حيث ينبغي أن يتواجد إذا كنا نريد ترتيبها ترتيبًا تصاعديًا. بمُجرَّد تَحرِيك أكبر عنصر بالقائمة إلى مَوْضِعه الصحيح، يُمكِننا أن نُطبِق نفس الفكرة على العناصر المُتبقَاة أي أن نَعثُر على العنصر الأكبر التالي، ونُحرِكه إلى المَوْضِع قبل الأخير، وهكذا. يُطلَق اسم "الترتيب الانتقائي (selection sort)" على تلك الخوارزمية (algorithm). يُمكِننا كتابتها كما يلي: static void selectionSort(int[] A) { // رتب المصفوفة A ترتيبا تصاعديا باستخدام الترتيب الانتقائي for (int lastPlace = A.length-1; lastPlace > 0; lastPlace--) { int maxLoc = 0; // موضع أكبر عنصر إلى الآن for (int j = 1; j <= lastPlace; j++) { if (A[j] > A[maxLoc]) { // ‫لأن A[j]‎ أكبر من أكبر قيمة رأيناها إلى الآن، فإن j هو // الموضع الجديد لأكبر قيمة وجدناها إلى الآن maxLoc = j; } } int temp = A[maxLoc]; // Swap largest item with A[lastPlace]. A[maxLoc] = A[lastPlace]; A[lastPlace] = temp; } // end of for loop } يَستخدِم الصَنْف Hand الذي كتبناه بالقسم الفرعي 5.4.1 نسخة مختلفة قليلًا من الترتيب الانتقائي (selection sort). يُعرِّف الصَنْف Hand مُتْغيِّرًا من النوع ArrayList<Card>‎ لتَمثيِل اليد (hand) يحتوي بطبيعة الحال على كائنات من النوع Card. يَحتوِي أي كائن من النوع Card على توابع النسخ getSuit()‎ و getValue()‎، والتي يُمكِننا أن نَستخدِمها لمَعرِفة كُلًا من قيمة ورقة اللعب ورمزها (suit). يُنشِئ التابع (method) المسئول عن عملية الترتيب (sorting) قائمة جديدة، بحيث يَختار ورق اللعب من القائمة القديمة تدريجيًا وبترتيب مُتصاعِد ثم يُحرِكها من القائمة القديمة إلى الجديدة. يَستخدِم التابع (method) القائمة الجديدة بالنهاية لتمثيل اليد بدلًا من القديمة. قد لا يَكُون ذلك هو الأسلوب الأكفأ لإنجاز الأمر، ولكن نظرًا لأن عدد ورق اللعب ضِمْن أي يد (hand) عادةً ما يَكون صغيرًا، فإنه لا يُمثِل مشكلة كبيرة. اُنظر شيفرة ترتيب (sorting) ورق اللعب: public void sortBySuit() { ArrayList<Card> newHand = new ArrayList<Card>(); while (hand.size() > 0) { int pos = 0; // موضع البطاقة الأقل Card c = hand.get(0); // البطاقة الأقل for (int i = 1; i < hand.size(); i++) { Card c1 = hand.get(i); if ( c1.getSuit() < c.getSuit() || (c1.getSuit() == c.getSuit() && c1.getValue() < c.getValue()) ) { pos = i; // Update the minimal card and location. c = c1; } } hand.remove(pos); // احذف ورقة اللعب من اليد الأصلية newHand.add(c); // أضف ورقة اللعب إلى اليد الجديدة } hand = newHand; } لاحِظ أن موازنة العناصر ضِمْن قائمة ليست دائمًا ببساطة اِستخدَام < كالمثال بالأعلى. في هذه الحالة، تُعدّ ورقة لعب معينة أصغر من ورقة لعب آخرى إذا كان رمز (suit) الأولى أقل من رمز الثانية أو أن يَكُونا متساويين بشرط أن تَكُون قيمة ورقة اللعب الثانية أقل من قيمة الأولى. يتأكَّد الجزء الثاني من الاختبار من ترتيب ورق اللعب بنفس الرمز ترتيبًا صحيحًا بحسب قيمته. يُمثِل ترتيب قائمة من النوع String مشكلة مشابهة؛ فالعامل < غَيْر مُعرَّف للسَلاسِل النصية. في المقابل، يُعرِّف الصنف String التابع compareTo. إذا كان str1 و str2 من النوع String، يُمكِننا كتابة ما يلي: str1.compareTo(str2) يُعيِد التابع السابق قيمة من النوع int تُساوِي 0 إذا كان str1 يُساوِي str2 أو قيمة أقل من 0 عندما يأتي str1 قبل str2 أو أكبر من 0 عندما يأتي str1 بَعْد str2. تستطيع مثلًا أن تختبر ما إذا كان str1 يَسبِق str2 أو يُساويه باِستخدَام الاختبار التالي: if ( str1.compareTo(str2) <= 0 ) يُقصَد بكلمات مثل "يَسبِق" أو "يَتبَع" -عند اِستخدَامها مع السَلاسِل النصية (string)- ترتيبها وفقًا للترتيب المعجمي (lexicographic ordering)، والذي يَعتمِد على قيمة اليونيكود (Unicode) للمحارف (characters) المُكوِّنة للسِلسِلة النصية (strings). يَختلِف الترتيب المعجمي (lexicographic ordering) عن الترتيب الأبجدي (alphabetical) حتى بالنسبة للكلمات المُكوَّنة من أحرف أبجدية فقط؛ لأن جميع الأحرف بحالتها الكبيرة (upper case) تَسبِق جميع الأحرف بحالتها الصغيرة (lower case). في المقابل، يُعدّ الترتيب الأبجدي والمعجمي للكلمات المُقتصِرة على 26 حرف بحالتها الصغيرة فقط أو الكبيرة فقط هو نفسه. يُحوِّل التابع str1.compareToIgnoreCase(str2)‎ أحرف سِلسِلتين نصيتين (strings) إلى الحالة الصغيرة (lowercsae) أولًا قبل موازنتهما. يتناسب كُلًا من الترتيب الانتقائي (selection sort) والترتيب بالادراج (insertion sort) مع المصفوفات الصغيرة المُكوَّنة من مئات قليلة من العناصر. أما بالنسبة للمصفوفات الكبيرة، فتَتَوفَّر خوارزميات آخرى أكثر تعقيدًا ولكنها أسرع بكثير. هذه الخوارزميات أسرع بكثير ربما بنفس الكيفية التي يُعدّ بها البحث الثنائي (binary search) أسرع من البحث الخطي (linear search). يَعتمِد التابع القياسي Arrays.sort على الخوارزميات السريعة. سنَتعرَّض لإحدى تلك الخوارزميات بالفصل التاسع. الترتيب العشوائي (unsorting) يُعدّ الترتيب العشوائي لعناصر مصفوفة مشكلة أقل شيوعًا ولكنها شيقة. قد نحتاجها مثلًا لخَلْط مجموعة ورق لعب ضِمْن برنامج. تَتًوفَّر خوارزمية شبيهة بالترتيب الانتقائي (selection sort)، فبدلًا من تَحرِيك أكبر عنصر بالمصفوفة إلى نهايتها، سنختار عنصرًا عشوائيًا ونُحرِكه إلى نهايتها. يَخلِط البرنامج الفرعي (subroutine) التالي عناصر مصفوفة من النوع int: /** * Postcondition: The items in A have been rearranged into a random order. */ static void shuffle(int[] A) { for (int lastPlace = A.length-1; lastPlace > 0; lastPlace--) { // ‫اختر موضعا عشوائيًا بين 0 و 1 و... حتى lastPlace int randLoc = (int)(Math.random()*(lastPlace+1)); // ‫بدل العناصر بالموضعين randLoc و lastPlace int temp = A[randLoc]; A[randLoc] = A[lastPlace]; A[lastPlace] = temp; } } ترجمة -بتصرّف- للقسم Section 4: Searching and Sorting من فصل Chapter 7: Arrays and ArrayLists من كتاب Introduction to Programming Using Java.
  3. يُمكِننا أن نُضمِّن نمط المصفوفة الديناميكية (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.
  4. تَعرَّضنا حتى الآن إلى بعض الأمثلة على معالجة المصفوفات في المقال السابق، ولكن غالبيتها كان مُجرد أمثلة بسيطة على معالجة عناصر مصفوفة من البداية إلى النهاية أو جَلْب عشوائي لقيمة عنصر ضِمْن مصفوفة. سنَفْحَص بهذا القسم وما يليه من أقسام بعضًا من الأمور الآخرى الأكثر تشويقًا. أمثلة على المعالجة لابُدّ أن تكون حريصًا فيما يتعلَّق بالفهارس من خارج نطاق المصفوفة. لنَفْترِض مثلًا أن 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.
  5. ناقشنا أساسيات المصفوفات (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.
  6. لقد ناقشنا حتى الآن الكثير من الجوانب الأساسية المُستخدَمة ببرمجة واجهات المُستخدِم الرسومية (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.
  7. تُعدّ المُكوِّنات (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.
  8. تَعلَّمنا خلال الأقسام السابقة كيف نَستخدِم سياقًا رُسوميًا (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.
  9. تعتمد برمجة واجهات المُستخدِم الرسومية (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.
  10. سنُناقش خلال هذا القسم بعضًا من الأصناف البسيطة المُستخدَمة لتَمثيِل كُلًا من الألوان والخطوط والصور، كما سنرى طريقة اِستخدَامها مع كائن السياق الرسومي 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.
  11. غالبية مُستخدمِي الحاسوب غَيْر مُعتَادون في العموم على برامج سطر الأوامر (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.
  12. تُعدّ الأصناف (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.
  13. تَسمَح بعض اللغات البرمجية كائنية التوجه (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.
  14. تُعدّ الأفكار الأساسية التي تَرتَكِز عليها البرمجة كائنية التوجه (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.
  15. تُستخدَم الأصناف (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.