كما ذَكَرَنا سابقًا، الأسماء هي أحد أركان البرمجة الأساسية. تَتَضمَّن مسألة التَّصْريح (declaring) عن الأسماء واِستخدَامها الكثير من التفاصيل التي تَجنَّبنا غالبيتها إلى الآن، ولكن حان وقت الكشف عن كثير من تلك التفاصيل. حاول التركيز عمومًا على محتوى القسمين الفرعيين "التهيئة أثناء التصريح" و "الثوابت المسماة (named constants)"؛ لأننا سنُعيد الإشارة إليهما باستمرار.

التهيئة (initialization) أثناء التصريح (declaration)

عندما نُصرِّح عن مُتَغيِّر ما (variable declaration)، يُخصِّص الحاسوب مساحة من الذاكرة لذلك المُتَغيِّر، والتي ينبغي تَهيئتها (initialize) مبدئيًا، بحيث يَتَضمَّن ذلك المُتَغيِّر قيمة معينة قَبْل أي مُحاولة لاِستخدَامه ضِمْن تعبير (expression). عادةً ما ترى تَعْليمَة التَّصْريح (declaration) عن مُتَغيِّر محليّ معين (local variable) مَتبوعة بتَعْليمَة إِسْناد (assignment statement) لغرض تهيئة ذلك المُتَغيِّر مبدئيًا (initialization). على سبيل المثال:

int count;    // ‫صرح عن المتغير count 
count = 0;    // ‫أسند القيمة 0 إلى المتغير count

في الواقع، تستطيع تَضْمِين التهيئة المبدئية (initialization) للمُتَغيِّر بنفس تَعْليمَة التصريح (declaration statement)، أيّ يُمكِن اختصار التَعْليمَتين بالأعلى إلى التَعْليمَة التالية:

int count = 0;  // ‫صرح عن المتغير count وأسند إليه القيمة 0

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

char firstInitial = 'D', secondInitial = 'E';

int x, y = 1;   // ‫صالح ولكن أسندت القيمة 1 إلى المتغير y فقط

int N = 3, M = N+2;  // ‫صالح، هُيأت القيمة N قبل استخدامها

لمّا كان المُتَغيِّر المُتحكِّم بحَلْقة معينة (loop control variable) غير مَعنِي بأي شيء يَقَع خارج تلك الحَلْقة عمومًا، كان من المنطقي التَّصْريح عنه ضِمْن ذلك الجزء من البرنامج الذي يَستخدِمُه فعليًا. ولهذا يَشيَع اِستخدَام التَعْليمَة المُختصرة بالأعلى ضِمْن حَلْقات التَكْرار for؛ حيث تُمكِّنك من التَّصْريح عن المُتَغيِّر المُتحكِّم بالحَلْقة، وتَهيئته مبدئيًا بمكان واحد ضِمْن الحَلْقة ذاتها. على سبيل المثال:

for ( int i = 0;  i < 10;  i++ ) {
   System.out.println(i);
}

الشيفرة بالأعلى هي بالأساس اختصار لما يَلي:

{
   int i;
   for ( i = 0;  i < 10;  i++ ) {
      System.out.println(i);
   }
}

أَضفنا زوجًا إضافيًا من الأقواس حول الحَلْقة -بالأعلى- للتأكيد على أن المُتَغيِّر i قد أصبح مُتَغيِّرًا محليًا (local) لتَعْليمَة الحَلْقة for، أيّ أنه لَمْ يَعُدْ موجودًا بعد انتهاء الحَلْقة.

يُمكِنك أيضًا إجراء التهيئة المبدئية (initialize) للمُتَغيِّرات الأعضاء (member variable) أثناء تَّصْريحك عنها (declare)، كما هو الحال مع المُتَغيِّرات المحليّة (local variable). فمثلًا:

public class Bank {
   private static double interestRate = 0.05;
   private static int maxWithdrawal = 200;
     .
     .  // المزيد من المتغيرات والبرامج الفرعية
     .
}

عندما يُحمِّل مُفسِّر الجافا (Java interpreter) صنفًا معينًا، فإنه يُنشِئ أي مُتَغيِّر عضو ساكن (static member variable) ضِمْن ذلك الصنف، ويُهيِئ قيمته المبدئية (initialization). لمّا كانت تَعْليمَات التَّصْريح (declaration statements) هي النوع الوحيد من التَعْليمَات التي يُمكِن كتابتها خارج أيّ برنامج فرعي (subroutine)، وعليه فإن تَعْليمَات الإِسْناد (assignment statements) غير ممكنة الكتابة خارجها، كان لزامًا تهيئة المُتَغيِّرات الأعضاء الساكنة أثناء التَّصْريح عنها -إذا أردنا القيام بالتهيئة-، فهو في تلك الحالة ليس مُجرَّد اختصار لتَعْليمَة تَّصْريح (declaration) مَتبوعة بتَعْليمَة إِسناد (assignment statement) مثلما هو الحال مع المُتَغيِّرات المحليّة. لاحِظ عدم إِمكانية القيام بالتالي:

public class Bank {
   private static double interestRate;
   // غير صالح! لا يمكن استخدام تعليمة إسناد خارج برنامج فرعي
   interestRate = 0.05;  
   .                     
   .
   .

لذلك، غالبًا ما يَحتوِي التَّصْريح عن مُتَغيِّر عضو (member variables) على قيمته المبدئية. وكما ذَكَرَنا سلفًا بالقسم الفرعي ٤.٢.٤، فإنه في حالة عدم تَخْصِيص قيمة مبدئية لمُتَغيِّر عضو معين (member variable)، تُسنَد إليه قيمة مبدئية افتراضية. على سبيل المثال، اِستخدَام التَعْليمَة static int count للتَّصْريح عن المُتَغيِّر العضو count هو مُكافِئ تمامًا للتَعْليمَة static int count = 0;‎.

نستطيع أيضًا تهيئة مُتَغيِّرات المصفوفة (array variables) مبدئيًا. ولمّا كانت المصفوفة عمومًا مُكوَّنة من عدة عناصر وليس مُجرَّد قيمة وحيدة، تُستخدَم قائمة من القيم، مَفصولة بفاصلة (comma)، ومُحاطة بزوج من الأقواس؛ لتهيئة (initialize) المُتَغيِّرات من ذلك النوع، كالتالي:

int[] smallPrimes = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29 };

تُنشِئ التَعْليمَة بالأعلى مصفوفة أعداد صحيحة (array of int)، وتَملؤها بالقيم ضِمْن القائمة. يُحدِّد عدد العناصر بالقائمة طول المصفوفة المُعرَّفة، أيّ أن طولها (length) -في المثال بالأعلى- يُساوِي ١٠.

تَقْتصِر صيغة (syntax) تهيئة المصفوفات -يُقصَد بذلك قائمة العناصر- على تَعْليمَات التَّصْريح (declaration statement)، أي بينما نُصرِّح عن مُتَغيِّر مصفوفة (array variable)، ولا يُمكِن اِستخدَامها ضِمْن تَعْليمَات الإِسْناد (assignment statements).

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

String[] nameList = new String[100];

ستَحتوِي جميع عناصر المصفوفة على القيمة الافتراضية في المثال بالأعلى.

التصريح عن المتغيرات باستخدام var

منذ الإصدار العاشر، تُوفِّر الجافا صيغة (syntax) جديدة للتَّصْريح عن المُتَغيِّرات، باستخدَام كلمة var، بشَّرْط تَخْصيص قيمة مبدئية ضِمْن تَعْليمَة التَّصْريح. تمتلك المُتَغيِّرات المُصرَّح عنها بتلك الطريقة نوعًا محدَّدًا، كأي مُتَغيِّر عادي آخر، ولكن بدلًا من تَحْديد ذلك النوع تحديدًا صريحًا، يعتمد مُصرِّف الجافا (Java compiler) على نوع القيمة المبدئية المُخصَّصة لتَحْديد نوع ذلك المُتَغيِّر. تَقْتصِر تلك الصيغة، مع ذلك، على المُتَغيِّرات المحليّة (local variables)، أي تلك المُصرَّح عنها ضِمْن برنامج فرعي (انظر القسم الفرعي ٤.٢.٤). اُنظر تَعْليمَة التَّصْريح التالية:

var interestRate = 0.05;

تُستخدَم التَعْليمَة بالأعلى لتعريف (define) مُتَغيِّر محليّ اسمه interestRate بقيمة مبدئية تُساوِي ٠,٠٥، ولمّا كانت القيمة المبدئية المُخصَّصة من النوع double، يَكُون نوع ذلك المُتَغيِّر هو double. بالمثل، للتَّصْريح عن مُتَغيِّر محليّ اسمه nameList من النوع String[]‎، يُمكِنك كتابة التالي:

var nameList = new String[100];

تستطيع أيضًا اِستخدَام كلمة var أثناء التَّصْريح عن المُتَغيِّر المُتحكِّم بالحَلْقة (loop control variable) ضِمْن الحَلْقة for، كالتالي:

for ( var i = 0;  i < 10;  i++ ) {
   System.out.println(i);
}

قد لا يبدو ذلك مفيدًا في الوقت الحالي، ولكنك ستُدرِك أهميته عندما نَتَعرَّض لما يُعرَف باسم الأنواع المُعمَّمة أو الأنواع المُحدَّدة بمعاملات نوع (parameterized types)، والتي تُعدّ أكثر تعقيدًا. سنتناول تلك الأنواع بكُلًا من القسم ٧.٢، والفصل العاشر.

الثوابت المسماة (named constants)

في بعض الأحيان، لا يَكُون هناك حاجة لتَعْديل قيمة المُتَغيِّر بَعْد تهيئتها مبدئيًا (initialize). على سبيل المثال، هُيَئ المُتَغيِّر interestRate بالأعلى، بحيث تَكُون قيمته المبدئية مُساوِية للقيمة ٠,٠٥. دَعْنَا نفْترِض أنه لا حاجة لتَعْديل تلك القيمة طوال فترة تَّنْفيذ البرنامج. في مثل تلك الحالات، قد يبدو المُتَغيِّر عديم الفائدة، ولهذا قد تَتَساءل، لماذا قد يُعرِّف (defining) المبرمج ذلك المُتَغيِّر من الأساس؟ في الواقع، يَلجأ المُبرمجين عادةً إلى تعريف تلك المُتَغيِّرات؛ بهدف إعطاء قيمة عددية معينة (٠,٠٥ في هذا المثال) اسمًا له مَغزى، فبخلاف ذلك، ستَكُون القيمة ٠,٠٥ بلا أي مَعنَى؛ فمن الأسهل عمومًا فِهم تَعْليمَة مثل principal += principal*interestRate;‎ بالمُوازنة مع principal += principal*0.05.

يُمكِن اِستخدَام المُبدِّل (modifier)‏ final أثناء التَّصْريح عن مُتَغيِّر معين (variable declaration)؛ للتَأكُّد من اِستحالة تَعْديل القيمة المُخزَّنة بذلك المُتَغيِّر بمجرد تَهيئتها (initialize). إذا صَرَّحت، مثلًا، عن المُتَغيِّر العضو interestRate باستخدام التَعْليمَة التالية:

public final static double interestRate = 0.05;

فسيَستحِيل تَعْديل قيمة ذلك المُتَغيِّر interestRate بأيّ مكان آخر داخل البرنامج، فإذا حَاوَلت، مثلًا، اِستخدَام تَعْليمَة إِسْناد لتَعْديل قيمته، فإن الحاسوب سيُبلِّغ عن وجود خطأ في بناء الجملة (syntax error) أثناء تَصْرِيف (compile) البرنامج. من المنطقي عمومًا اِستخدَام المُبدِّل final مع مُتَغيِّر عام (public) يُمثِل قيمة "مُعدل الفائدة"؛ فبينما يُريد بنك معين الإعلان عن قيمة "مُعدل الفائدة"، فإنه، وبكل تأكيد، لا يُريد أن يَسمَح لأشخاص عشوائية بتَعْديل قيمة "مُعدل الفائدة".

تَبرز أهمية المُبدِّل final عند اِستخدَامه مع المُتَغيِّرات الأعضاء، ولكنه مع ذلك، قابل للاِستخدَام مع كلا من المُتَغيِّرات المحليّة (local variables)، والمُعامِلات الصُّوريّة (formal parameters). يُطلَق مصطلح الثوابت المُسمَاة (named constants) على المُتَغيِّرات الأعضاء الساكنة (static member variable) المُصرَّح عنها باِستخدَام المُبدِّل final؛ لأن قيمتها تَظلّ تابثة طوال فترة تَّنْفيذ البرنامج. اِستخدَامك للثوابت المُسمَاة (named constants) قادر على تَحسِّين شيفرة البرامج بشكل كبير، وجَعْلها مَقروءة؛ فأنت بالنهاية تُعطِي أسماء ذات مَغزى للمقادير المُهمة بالبرنامج، ويُوصَى عمومًا بأن تَكُون تلك الأسماء مُكوَّنة بالكامل من حروف كبيرة (upper case letters)، بحيث يَفصِل محرف الشرطة السُفلية (underscore) بين الكلمات إذا ما لَزِم الأمر. على سبيل المثال، يُمكِن تعريف "مُعدَل الفائدة" كالتالي:

public final static double INTEREST_RATE = 0.05;

يَشيِع اِستخدَام نَمط التسمية بالأعلى عمومًا بأصناف الجافا القياسية (standard classes)، والتي تُعرِّف الكثير من الثوابت المُسمَاة. فمثلًا، تَعرَّضنا بالفعل للمُتَغيِّر Math.PI من النوع double المُعرَّف ضِمْن الصنف Math باِستخدَام المُبدِّلات public final static. بالمثل، يَحتوِي الصَنْف Color على مجموعة من الثوابت المُسمَاة (named constants) مثل: Color.RED و Color.YELLOW، والتي هي مُتَغيِّرات من النوع Color، مُعرَّفة باِستخدَام نفس مجموعة المُبدِّلات public final static.

تُعدّ ثوابت أنواع التعداد (enumerated type constants)، والتي تَعرَّضنا لها خلال القسم الفرعي ٢.٣.٣، مثالًا آخرًا للثوابت المُسمَاة. يُمكِننا تعريف تعداد من النوع Alignment كالتالي:

enum Alignment { LEFT, RIGHT, CENTER }

يُعرِّف ذلك التعداد كُلًا من الثوابت Alignment.LEFT و Alignment.RIGHT و Alignment.CENTER. تقنيًا، يُعدّ Alignment صنفًا (class)، وتُعدّ تلك الثوابت (constants) الثلاثة أعضاء ساكنة عامة ونهائية (public final static) ضِمْن ذلك الصَنْف. في الواقع، يُشبِه تعريف نوع التعداد (enumerated type) بالأعلى تعريف ثلاثة ثوابت من النوع int كالتالي:

public static final int ALIGNMENT_LEFT = 0;
public static final int ALIGNMENT_RIGHT = 1;
public static final int ALIGNMENT_CENTER = 2;

وفي الحقيقة، كانت تلك الطريقة هي الأسلوب المُتبَع قبل ظهور أنواع التعداد (enumerated types)، وما تزال في الواقع مُستخدَمة بكثير من الحالات. فبِتَوفُّر ثوابت الأعداد الصحيحة (integer constants) بالأعلى، تستطيع الآن ببساطة تعريف مُتَغيِّر من النوع int، وإِسْناد واحدة من تلك القيم الثلاثة ALIGNMENT_LEFT و ALIGNMENT_RIGHT و ALIGNMENT_CENTER له؛ بهدف تمثيل أنواع مختلفة من التعداد Alignment. مع ذلك هناك مشكلة، وهي عدم إِطلاع الحاسوب على نيتك باِستخدَام ذلك المُتَغيِّر لتمثيل قيمة من النوع Alignment، لذا فإنه لن يَعترِض إذا حاولت إِسْناد قيمة هي ليست ضِمْن تلك القيم الثلاثة الصالحة.

في المقابل، ومع ظهور أنواع التعداد (enumerated type)، فإنه إذا كان لديك مُتَغيِّر من نوع التعداد Alignment، فيُمكِنك فقط إِسْناد إحدى تلك القيم الثابتة المُدرجة بتعريف التعداد إليه، وأي محاولة لإِسْناد قيم آخرى غَيْر صالحة ستُعدّ بمثابة خطأ ببناء الجملة (syntax error) سيَكْتَشفها الحاسوب أثناء تَصْرِيف (compile) البرنامج. يُوفِّر ذلك نوعًا من الأمان الإضافي، وهو أحد أهم مميزات أنواع التعداد (enumerated types).

يُسهِل استخدام الثوابت المُسمَاة (named constants) من تَعْديل قيمة الثابت المُسمَى. بالطبع، لا يُقصَد بذلك تَعْديلها أثناء تَّنْفيذ البرنامج، وإنما بين تَّنْفيذ معين والذي يليه، أيّ تَعْديل القيمة داخل الشيفرة المصدرية ذاتها ثم إعادة تَصرِيف (recompile) البرنامج. لنُعيد التفكير بمثال "معدل الفائدة"، غالبًا ما ستَكُون قيمة "مُعدَل الفائدة" مُستخدَمة أكثر من مرة عبر شيفرة البرنامج. لنفْترِض أن البنك قد عَدَّل قيمة "معدل الفائدة"، وعليه ينبغي تَعْديلها بالبرنامج. إذا كانت القيمة ٠,٠٥ مُستخدَمة بشكل مُجرَّد ضِمْن الشيفرة، فسيَضطرّ المبرمج لتَعقُّب جميع الأماكن المُستخدِمة لتلك القيمة بحيث يُعدِّلها إلى القيمة الجديدة. يَصعُب القيام بذلك خصوصًا مع احتمالية اِستخدَام القيمة ٠,٠٥ داخل البرنامج لأهداف مختلفة غير "مُعدَل الفائدة"، بالإضافة إلى احتمالية اِستخدَام القيمة ٠,٠٢٥ مثلًا لتمثيل نصف قيمة "مُعدَل الفائدة". في المقابل، إذا كنا قد صَرَّحنا عن الثابت المُسمَى INTEREST_RATE ضِمْن البرنامج، واستخدَمناه بصورة مُتَّسقِة عبر شيفرة البرنامج بالكامل، فسنحتاج إلى تعديل سطر وحيد فقط هو سَطْر التهيئة المبدئية لذلك الثابت.

لنأخذ مثالًا آخر من القسم السابق، سنُعيد خلاله كتابة نسخة جديدة من البرنامج RandomMosaicWalk. ستَستخدِم تلك النسخة عدة ثوابت مُسمَاة (named constants) بهدف تمثيل كُلًا من عدد الصفوف، وعدد الأعمدة، وحجم كل مربع صغير بنافذة الصَنْف mosaic. سيُصرَّح عن تلك الثوابت (constants) الثلاثة كمُتَغيِّرات أعضاء ساكنة نهائية (final static member) كالتالي:

final static int ROWS = 20;        // عدد صفوف النافذة
final static int COLUMNS = 30;     // عدد أعمدة النافذة
final static int SQUARE_SIZE = 15; // حجم كل مربع بالنافذة

عُدِّل أيضًا باقي البرنامج بحرِص بحيث يتلائم مع الثوابت المُسمَاة (named constants) المُعرَّفة، فمثلًا، لفَتْح نافذة Mosaic بالنسخة الجديدة من البرنامج، يُمكِن استخدام التَعْليمَة التالية:

Mosaic.open(ROWS, COLUMNS, SQUARE_SIZE, SQUARE_SIZE);

ليس من السهل دومًا العُثور على جميع تلك الأماكن التي يُفْترَض بها اِستخدَام ثابت مُسمَى معين. لذا، انتبه! ففي حالة عدم اِستخدَامك لثابت مُسمَى معين بصورة مُتَّسقِة عبر شيفرة البرنامج بالكامل، فأنت تقريبًا قد أَفسدت الهدف الأساسي منه. لذلك يُنصَح عادة بتجربة البرنامج عدة مرات، بحيث تَستخدِم قيمة مختلفة للثابت المُسمَى (named constant) في كل مرة؛ لاِختبار كَوْنه يَعَمَل بصورة سليمة بجميع الحالات.

اُنظر النسخة الجديدة من البرنامج كاملة RandomMosaicWalk2 بالأسفل. لاحظ كيفية اِستخدَام الثابتين ROWS و COLUMNS داخل البرنامج randomMove()‎ عند تحريكه للتشويش (disturbance) من إحدى حواف النافذة mosaic إلى الحافة المضادة. لم تُضاف التعليقات (comments) لغرض تَوْفِير المساحة.

public class RandomMosaicWalk2 {

    final static int ROWS = 20;        // عدد الصفوف بالنافذة
    final static int COLUMNS = 30;     // عدد الأعمدة بالنافذة
    final static int SQUARE_SIZE = 15; // حجم كل مربع بالنافذة

    static int currentRow;    // رقم الصف المعرض للتشويش
    static int currentColumn; // رقم العمود المعرض للتشويش

    public static void main(String[] args) {
        Mosaic.open( ROWS, COLUMNS, SQUARE_SIZE, SQUARE_SIZE );
        fillWithRandomColors();
        currentRow = ROWS / 2;   // ابدأ بمنتصف النافذة
        currentColumn = COLUMNS / 2;
        while (true) {
            changeToRandomColor(currentRow, currentColumn);
            randomMove();
            Mosaic.delay(5);
        }
    }  // نهاية‫ main

    static void fillWithRandomColors() {
         for (int row=0; row < ROWS; row++) {
            for (int column=0; column < COLUMNS; column++) {
                changeToRandomColor(row, column);  
            }
         }
    }  // نهاية‫ fillWithRandomColors

    static void changeToRandomColor(int rowNum, int colNum) {
        // اختر قيم عشوائية تتراوح بين 0 و 255
        // لقيم الألوان الثلاثة (الأحمر، و الأزرق، والأخضر‫)
        // ‫بنظام الألوان RGB
         int red = (int)(256*Math.random());    
         int green = (int)(256*Math.random());  
         int blue = (int)(256*Math.random());   
         Mosaic.setColor(rowNum,colNum,red,green,blue);  
     }  // نهاية‫ changeToRandomColor

     static void randomMove() {
         // ‫اضبط القيمة عشوائيًا بحيث تتراوح من 0 وحتى 3
         int directionNum; 
         directionNum = (int)(4*Math.random());
         switch (directionNum) {
            case 0:  // تحرك للأعلى 
               currentRow--;
               if (currentRow < 0)
                  currentRow = ROWS - 1;
               break;
            case 1:  // تحرك لليمين
               currentColumn++;
               if (currentColumn >= COLUMNS)
                  currentColumn = 0;
               break; 
            case 2:  // تحرك للأسفل
               currentRow++;
               if (currentRow >= ROWS)
                  currentRow = 0;
               break;
            case 3:  // تحرك لليسار  
               currentColumn--;
               if (currentColumn < 0)
                  currentColumn = COLUMNS - 1;
               break; 
         }
     }  // ‫نهاية randomMove

} // نهاية الصنف‫ RandomMosaicWalk2

التسمية وقواعد النطاق (scope rules)

عندما نُصرِّح عن مُتَغيِّر ما (variable declaration)، يُخصِّص الحاسوب مساحة من الذاكرة لذلك المُتَغيِّر. بحيث تستطيع اِستخدَام اسم ذلك المُتَغيِّر ضِمْن جزء معين على الأقل من شيفرة البرنامج؛ بهدف الإشارة إلى تلك المساحة من الذاكرة أو إلى تلك البيانات المُخزَّنة بها. يُطلَق على ذلك الجزء من الشيفرة، والذي يَكُون فيه اسم المُتَغيِّر صالحًا للاِستخدَام، اسم نطاق المُتَغيِّر (scope of variable). بالمثل، يُمكِن الإشارة إلى نطاق كُلًا من أسماء البرامج الفرعية (subroutine) وأسماء المُعامِلات الصُّوريّة (formal parameter).

لنبدأ بالأعضاء الساكنة من البرامج الفرعية، والتي تُعدّ قواعد نطاقها (scope rule) بسيطة نوعًا ما. يَمتد نطاق (scope) أي برنامج فرعي ساكن إلى كامل الشيفرة المصدرية للصَنْف (class) المُعرَّف بداخله، أيّ يُمكِن استدعاء ذلك البرنامج الفرعي من أيّ مكان داخل الصنف، بما في ذلك تلك الأماكن الواقعة قَبْل تعريف (definition) البرنامج الفرعي. بل أنه حتى من المُمكن لبرنامج فرعي معين استدعاء ذاته، وهو ما يُعرَف باسم التَعاود أو الاستدعاء الذاتي (recursion)، وهو أحد المواضيع المتقدمة نسبيًا، وسنتناوله عمومًا بالقسم ٩.١. وأخيرًا، إذا لم يَكُن البرنامج الفرعي خاصًا (private)، فتستطيع حتى الوصول إليه من خارج الصَنْف المُعرَّف بداخله بشَّرْط اِستخدَام اسمه الكامل.

لننتقل الآن إلى الأعضاء الساكنة من المُتَغيِّرات، والتي تَملُك قواعد نطاق (scope rule) مشابهة بالإضافة إلى تعقيد واحد إضافي هو كالآتي. تستطيع عمومًا تعريف مُتَغيِّر محليّ (local variable) أو مُعامِل صُّوريّ (formal parameter) يَحمِل نفس اسم إحدى المُتَغيِّرات الأعضاء (member variable) ضِمْن الصَنْف، وفي تلك الحالة، يُعدّ المُتَغيِّر العضو مخفيًا ضِمْن نطاق المُتَغيِّر المحليّ أو المُعامِل الذي يَحمِل نفس الاسم. فعلى سبيل المثال، إذا كان لدينا الصَنْف Game كالتالي:

public class Game {

    static int count;  // متغير عضو

    static void playGame() {
        int count;  // متغير محلي
          .
          .   // ‫بعض التعليمات لتعريف playGame()
          .
    }

    .
    .   // المزيد من المتغيرات والبرامج الفرعية
    .

}  // ‫نهاية الصنف Game

يُشير الاسم count بالتَعْليمات المُؤلِّفة لمَتْن (body) البرنامج الفرعي playGame()‎ إلى المُتَغيِّر المحليّ (local variable). أما ببقية الصنف Game، فإنه سيُشيِر إلى المُتَغيِّر العضو (member variable)، بالطبع إذا لم يُخفَى باستخدام مُتَغيِّر محليّ آخر أو مُعامِلات تَحمِل نفس الاسم count. مع ذلك، ما يزال بإمكانك الإشارة إلى المُتَغيِّر العضو count بواسطة اسمه الكامل Game.count، والذي يُستخدَم، في العادة، خارج الصَنْف الذي عُرِّف به العضو، ولكن ليس هناك قاعدة تَمنع اِستخدَامه داخل الصنف. لهذا يُمكِن اِستخدَام الاسم الكامل Game.count داخل البرنامج الفرعي playGame()‎ للإشارة إلى المُتَغيِّر العضو بدلًا من المُتَغيِّر المحليّ. يُمكِننا الآن تلخيص قاعدة النطاق (scope rule) كالآتي: يَشمَل نطاق مُتَغيِّر عضو ساكن الصنف المُعرَّف بداخله بالكامل، وعندما يُصبِح الاسم البسيط (simple name) للمُتَغيِّر العضو مَخفيًا نتيجة تعريف مُتَغيِّر محليّ أو مُعامِل صُّوريّ يَحمِل نفس الاسم، يُصبِح من الضروري اِستخدَام الاسم الكامل على الصورة . للإشارة إلى المُتَغيِّر العضو. تُشبِه قواعد نطاق الأعضاء غير الساكنة (non-static) عمومًا تلك الخاصة بالأعضاء الساكنة، باستثناء أن الأولى لا يُمكِن اِستخدَامها بالبرامج الفرعية الساكنة (static subroutines)، كما سنرى لاحقًا.

أخيرًا، يَتَكوَّن نطاق المُعامِل الصُّوريّ (formal parameter) لبرنامج فرعي معين من الكُتلَة (block) المُؤلِّفة لمَتْن البرنامج الفرعي (subroutine body). في المقابل، يَمتَد نطاق المُتَغيِّر المحليّ (local variable) بدايةً من تَعْليمَة التَّصْريح (declaration statement) المسئولة عن تعريف ذلك المُتَغيِّر وحتى نهاية الكُتلَة (block) التي حَدَثَ خلالها ذلك التَّصْريح. كما أشرنا بالأعلى، تستطيع التَّصْريح عن المُتَغيِّر المُتحكِّم بحَلْقة (loop control variable)‏ for ضمن التعليمة ذاتها على الصورة for (int i=0; i < 10; i++)‎، ويُعدّ نطاق مثل هذا التَّصْريح (declaration) حالة خاصة: فهو صالح فقط ضِمْن تَعْليمَة for، ولا يَمتَد إلى بقية الكُتلَة المتضمنة للتَعْليمَة. لا يُسمَح عمومًا بإعادة تعريف (redefine) اسم المُعامِل الصُّوريّ أو المُتَغيِّر المحليّ ضِمْن نطاقه (scope)، حتى إذا كان ذلك داخل كُتلَة مُتداخِلة (nested block)، كالتالي:

void  badSub(int y) {
    int x;
    while (y > 0) {
       int x;  // ‫خطأ، لأن x مُعرَّفة بالفعل
         .
         .
         .
    }
 }

في الواقع، تَسمَح بعض اللغات بذلك، بحيث يُخفِي التَّصْريح عن x ضِمْن حَلْقة while التَّصْريح الأصلى، ولكن لا تَسمَح الجافا بذلك، حيث يُصبِح اسم المُتَغيِّر متاحًا للاِستخدَام مرة آخرى فقط بعد انتهاء تَّنْفيذ الكُتلَة (block) المُصرَّح عن المُتَغيِّر ضِمْنها. اُنظر على سبيل المثال:

void goodSub(int y) {
   while (y > 10) {
      int x;
        .
        .
        .
      // ينتهي نطاق‫ x هنا
   }
   while (y > 0) {
      int x;  // ‫صالح، فتَّصريح x السابق انتهت صلاحيته
       .
       .
       .
   }
}

هل تَتَسبَّب أسماء المُتَغيِّرات المحليّة (local variable) بإخفاء أسماء البرامج الفرعية (subroutine names)؟ لا يُمكِن حُدوث ذلك لسبب قد يبدو مفاجئًا. ببساطة، لمّا كانت أسماء البرامج الفرعية دومًا مَتبوعة بزوج من الأقواس (parenthesis)، والتي يُسْتحسَن التفكير بها على أساس أنها جزء من اسم البرنامج الفرعي، كأن تقول البرنامج الفرعي main()‎ وليس البرنامج الفرعي main، فإن الحاسوب عمومًا يُمكِنه دائمًا مَعرِفة ما إذا كان اسم معين يُشير إلى مُتَغيِّر أم إلى برنامج فرعي، لذا ليس ضروريًا أن تكون أسماء المُتَغيِّرات والبرامج الفرعية مختلفة من الأساس، حيث يُمكِنك ببساطة تعريف مُتَغيِّر اسمه count وبرنامج فرعي بنفس الاسم count ضِمْن نفس الصَنْف. كذلك لمّا كان الحاسوب قادرًا على مَعرِفة ما إذا كان اسم معين يُشير إلى اسم صَنْف أم لا وِفقًا لقواعد الصيغة (syntax)، فإنه حتى يُمكِن إعادة اِستخدَام أسماء الأصناف (classes) بهدف تسمية كلا من المُتَغيِّرات والبرامج الفرعية. اسم الصنف هو بالنهاية نوع، لذا يُمكِن اِستخدَام ذلك الاسم للتََّصْريح عن المُتَغيِّرات والمُعامِلات الصُّوريّة (formal parameters)، بالإضافة إلى تَخْصيص نوع القيمة المُعادة (return type) من دالة (function) معينة. يَعنِي ذلك أنك تستطيع التََّصْريح عن الدالة التالية ضِمْن صَنْف اسمه Insanity:

static  Insanity  Insanity( Insanity Insanity ) { ... }

يَستخدِم التََّصْريح -بالأعلى- الاسم Insanity ٤ مرات، تُشير الأولى إلى النوع المُعاد (return type) من الدالة، بينما تُشير الثانية إلى اسم تلك الدالة، والثالثة إلى نوع مُعاملها الصُّوريّ (formal parameter)، والرابعة إلى اسم ذلك المُعامِل. لكن تَذَكَّر! لا يُعدّ كل ما هو مُتاح فكرة جيدة بالضرورة.

ترجمة -بتصرّف- للقسم Section 8: The Truth About Declarations من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

قُدرتك على اِستيعاب طريقة عمل البرامج، وفهمها هو أمر جيد بلا شك، ولكنه يختلف تمامًا عن تَصميمها بحيث تُنفِّذ مُهِمّة معينة. لقد ناقشنا بالقسم ٣.٢ كيفية تَطْوير الخوارزميات بطريقة مَنهجية باستخدام أسلوب التصميم المُتدرج (stepwise refinement) والشيفرة الوهمية (pseudocode).

التصميم المُتدرج هو عملية تَقَع ضِمْن استراتيجيات التصميم من أعلى لأسفل (top-down)، أيّ لابُدّ عمومًا من وجود نقطة معينة تَتَوقَّف عندها عن عملية التحسِّين التدريجي لخوارزمية الشيفرة الوهمية (pseudocode algorithm)، وتُحوِّل عندها تلك الخوارزمية مباشرة إلى شيفرة برنامج فعليّة. بدون البرامج الفرعية (subroutines)، ستُمثِل تلك النقطة مستوًى بدائيًا جدًا من العمليات، كتَعْليمَات الإِسْناد (assignment statements)، وعمليات الدَخْل والخَرْج، أما في حالة تَوفُّر البرامج الفرعية المسئولة عن إنجاز بعض المَهَامّ (tasks) المُحدَّدة، فسيَكُون بإمكانك التَوقُّف عن التحسِّين بمجرد تعبيرك عن الخوارزمية بنفس المصطلحات التي تَستخدِمها البرامج الفرعية.

يَعنِي ذلك أننا قد أضفنا عنصر، هو بالأساس يَتَّبِع أسلوب التصميم من أسفل لأعلى (bottom-up)، إلى استراتيجيات التصميم من أعلى لأسفل (top-down approach) الخاصة بالتصميم المُتدرج. بفَرْض وجود مشكلة معينة، تستطيع الآن البدء بكتابة بعض البرامج الفرعية (subroutines) المسئولة عن إنجاز بعض المَهَامّ المُتَعلِّقة بموضوع البرنامج، بحيث تُصبِح تلك البرامج بمثابة صندوق من الأدوات الجاهزة (toolbox) يُمكِنك دَمْجها إلى الخوارزمية أثناء تَطْويرها، أو حتى قد تستطيع شراء صندوق أدوات برمجي جاهز (software toolbox)، كُتب بواسطة شخص آخر، بحيث يَتَضمَّن ذلك الصندوق مجموعة من البرامج الفرعية، التي ستَكُون بمثابة صندوقًا أسودًا (black boxes)، يُمكِنك تَوظِّيفه ضِمْن المشروع الخاص بك.

بإمكانك حتى استخدام البرامج الفرعية مباشرة ضِمْن أساليب التصميم من أعلى لأسفل (top-down approach) الأكثر صرامة، بمعنى أنه وبينما تُحسِّن الخوارزمية بالطريقة المُعتادة، يُمكِنك أن تُعبر عن مُهِمّة فرعية (sub-task) معينة ضِمْن الخوارزمية بصورة استدعاء لبرنامج فرعي. يُصبِح تَطْوير ذلك البرنامج الفرعي عندها مشكلة مُستقلة تستطيع العمل عليها بشكل منفصل. لا يَتَعدَى اتباع تلك الطريقة أكثر من مُجرَّد تَقسِّيم للمشكلة الرئيسية إلى مشكلات صغيرة مُنفصلة، أيّ أنها ما تزال تَقَع ضِمْن استراتيجيات التصميم من أعلى لأسفل؛ لأن تحليلك للمشكلة هو الذي وَجَّهك لكتابة البرامج الفرعية. في المقابل، تَبدأ استراتيجيات التصميم من أسفل لأعلى (bottom-up approach) بكتابة البرامج الفرعية المُتَعلِّقة بموضوع البرنامج، أو الحصول عليها بطريقة ما، بحيث تَعَمَل تلك البرامج الفرعية بمثابة أساس أو قاعدة تُستخدَم لبناء حل للمشكلة الأساسية.

الشروط المسبقة (precondition) والشروط اللاحقة (postcondition)

تَعََمَل البرامج الفرعية (subroutines) عمومًا كلَبِنات أساسية (building blocks) ضِمْن البرنامج الأساسي، لذا لابُدّ أن تَكُون طريقة تَفْاعُلها مع ذلك البرنامج واضحة. تُحدِّد المواصفة الاصطلاحية (contract) لأيّ برنامج فرعي عمومًا طريقة التَفْاعُل تلك، وهو ما ناقشناه بالقسم ٤.١، ويُمكِن كتابتها باِستخدَام ما يُعرَف باسم الشروط المُسَبَّقة (precondition) واللاحقة (postcondition).

لابُدّ أن تَكُون الشروط المُسَبَّقة (precondition) لأي برنامج فرعي (subroutine) مُتحقِّقة عند استدعائه. على سبيل المثال، إحدى الشروط المُسَبَّقة (precondition) للدالة Math.sqrt(x)‎ المبنية مُسْبَّقًا (built-in function) يَتمثَل في ضرورة أن تَكُون القيمة المُمرَّرة للمُعامِل (parameter)‏ x أكبر من أو تُساوِي الصفر؛ لأنه لا يُمكِن بطبيعة الحال حِسَاب الجذر التربيعي لعدد سالب. عمومًا، يُمثِل الشَّرْط المُسَبَّق (precondition) بمواصفة اصطلاحية معينة إلزامًا على مُستدعِي (caller) البرنامج الفرعي، أيّ أنه في حالة استدعائك لبرنامج فرعي معين دون تَوْفِية شَّرْطه المُسَبَّق، فما من سبب يَدْفَعك لتَوقع إِنجازه للمُهِمّة بشكل ملائم، فلرُبما يَنهار البرنامج أو يَكتفِي بإعادة نتائج غير صحيحة؛ لأنك ببساطة لم تَلتزِم بجانبك من الاتفاق، ولهذا لا تَلوّمن إلا نفسك.

في المقابل، الشروط اللاحقة (postcondition) هي بمثابة الجانب الآخر من المواصفة الاصطلاحية (contract)، حيث تُمثِل إلزامًا على البرنامج الفرعي ذاته، أي بفَرْض اِستيفاء الشروط المُسَبَّقة (preconditions) لبرنامج فرعي معين، وعدم احتوائه على أية أخطاء برمجية (bugs)، فلابُدّ من تَحقُّق شروطه اللاحقة بعد الاستدعاء. على سبيل المثال، الشَّرْط اللاحق للدالة Math.sqrt(x)‎ يَتمثَل في ضرورة تَساوِي كُلًا من مربع القيمة المُعادة من تلك الدالة (function) وقيمة المُعامِل (parameter) المُمرَّرة عند استدعاء البرنامج الفرعي، وهو ما سيَكُون صحيحًا فقط في حالة استيفاء شَّرْطها المُسَبَّق بخصوص كَوْن قيمة المُعامِل أكبر من أو تُساوِي الصفر. مثال آخر هو البرنامج الفرعي System.out.print(x)‎ المَبنِي مُسْبَّقًا، والذي يَتَمثَل شَّرْطه اللاحق (postcondition) بطباعة قيمة مُعامِله (parameter) المُمرَّرة على الشاشة.

عادة ما تَضَع الشروط المُسَبَّقة (preconditions) لأي برنامج فرعي قيودًا على قيم مُعاملاته، مثل البرنامج الفرعي Math.sqrt(x)‎، لكن لا يَقْتصِر دورها في الواقع على ذلك. قد تُشيِر تلك الشروط أيضًا إلى المُتَغيِّرات العامة (global variables) المُستخدَمة بالبرنامج الفرعي، أو قد تُحدِّد الحالة (state) التي ينبغي أن يَكُون عليها البرنامج عند استدعاء البرنامج الفرعي، وهو ما يَكُون مفيدًا إذا كانت عملية استدعاء ذلك البرنامج صالحة فقط بأوقات معينة.

من الناحية الآخرى، يُحدِّد الشَّرْط اللاحق (postcondition) لأي برنامج فرعي مُهِمّته المُوكَلة إليه. فمثلًا، ينبغي أن يَتضمَّن الشَّرْط اللاحق لأي دالة (function) القيمة المُعادة منها.

تُوصَف البرامج الفرعية أحيانًا باِستخدَام تعليقات (comments)، والتي ينبغي أن تُحدِّد شروط ذلك البرنامج المُسَبَّقة (preconditions) واللاحقة (postconditions). عندما تَستخدِم برنامجًا فرعيًا (subroutine) مكتوب مُسْبَّقًا، ستُخبرك تلك الشروط بكيفية اِستخدَام البرنامج بالإضافة إلى تِبيان الغرض منه. في المقابل، عندما تَكْتُب برنامجًا فرعيًا، ستَمنَحك تلك الشروط توصيفًا دقيقًا عما هو مُتوقَّع من ذلك البرنامج. سنَتَعرَّض خلال القسمين الفرعيين التاليين لمثال بسيط، سنَستخدِم فيه التعليقات لهذا الغرض، وستَكُون مَكْتوبة بصياغة تعليقات Javadoc مع عَنونة كُلًا من الشروط المُسَبَّقة واللاحقة. يرى كثير من علماء الحاسوب ضرورة إضافة وُسوم تَوْثيق جديدة ‎@precondition و ‎@postcondition إلى نظام Javadoc لعَنونة الشروط المُسَبَّقة واللاحقة بشكل صريح، ولكن لَمْ يَحدُث ذلك حتى الآن.

مثال عن عملية التصميم

سنُصمِّم الآن برنامجًا بالاعتماد على البرامج الفرعية بصورة أساسية، بمعنى أننا سنَستخدِم بعض البرامج الفرعية (subroutines) التي سُبق كتابتها كلَبِنة أساسية (building block)، كما أننا سنُصمِّم بعض البرامج الفرعية الجديدة التي قد نحتاجها لإكمال المشروع. فيما يَتعلَّق بالبرامج المَكْتوبة مُسْبَّقًا، سنَستخدِم واجهة برمجة تطبيقات (API) تَحتوِي على صنفين (classes) -كان الكاتب قد كَتَبَهما-، الصَنْف الأول هو Mosaic.java والذي بدوره يَعتمِد على الصنف الثاني MosaicCanvas.java. لاحظ ضرورة تَوفِّير كُلًا من الصنفين Mosaic و MosaicCanvas أثناء تَصْرِيف (compile) البرنامج وتَشْغِيله، مما يَعنِي وجود الملفين Mosaic.java و MosaicCanvas.java -أو ملفات الصَنْفين بَعْد التَصْرِيف- بنفس مجلد الصَنْف المُعرِّف للبرنامج.

يَسمَح لك الصَنْف Mosaic بالتَعْامُل مع نافذة (window) مُكوَّنة من مجموعة من المستطيلات الصغيرة المُلوَّنة، والمُرَتَّبة بصورة صفوف وأعمدة، حيث يَتضمَّن أكثر من عضو برنامج فرعي ساكن (static member subroutines) يُمكِن اِستخدَامها لأغراض فَتْح النافذة، وغَلْقها، بالإضافة إلى التَلاعب بمُحتوياتها. يُوفِّر الصَنْف بطبيعة الحال صندوق أدوات (toolbox) أو واجهة برمجة تطبيقات (API) تَتضمَّن تلك المجموعة من البرامج (routines)، والتي نسْتَعْرِض بالأسفل بعضًا منها، مُوثَّقة باِستخدَام تعليقات Javadoc. تَذَكَّر أن تعليق Javadoc يَسبِق العنصر المَعنِي بذلك التعليق.

/**
 * ‫افتح نافذة mosaic على الشاشة
 * ‫ينبغي أن يُستدعى هذا التابع قبل أي تابع آخر ضمن الصنف Mosaic
 * سينتهي البرنامج عندما يغلق المستخدم النافذة
 * 
 * ‫الشرط المسبق: المعاملات rows و cols و h و w هي أعداد صحيحة موجبة
 *
 * ‫‫الشرط اللاحق: تفتح نافذة على الشاشة والتي يمكنها عرض صفوف وأعمدة
 * ‫من المستطيلات الملونة بحيث يكون عرض المستطيل يساوي w وطوله يساوي h
 * ‫كما أن عدد الصفوف هو قيمة المعامل الأول الممررة بينما عدد الأعمدة
 * هو قيمة المعامل الثاني. مبدئيًا، تكون جميع المستطيلات سوداء
 *
 * ‫ملحوظة: الصفوف مرقمة من 0 وحتى rows - 1 بينما الأعمدة مرقمة 
 * ‫من 0 وحتى cols - 1 
 */
public static void open(int rows, int cols, int h, int w)


    /**
     * ضبط لون أحد مربعات النافذة
     * 
     * ‫الشرط المسبق: لابد أن كون المعاملين row و col ضمن النطاق المسموح
     * ‫به لرقمي الصف والعمود، كما لابد أن تقع كلا من المعاملات r و g و b ‫بين العددين 0 و 255
     * الشرط اللاحق: سيضبط لون المربع المخصص عن طريق رقمي الصف والعمود
     * الممررين إلى اللون المحدد عبر المعاملات الثلاثة‫ r و g و b
     * بحيث تعطي هذه المعاملات قيم اللون الأحمر والأخضر والأخضر
     * بنظام‫ RGB للمربع، قمثلًا يعطي المعامل r قيمة اللون الأحمر بحيث
     * تشير القيمة 0 إلى انعدام اللون الأحمر بينما تشير القيمة 255 إلى أكبر قدر ممكن من اللون
     */
    public static void setColor(int row, int col, int r, int g, int b)


    /**
     * ‫جلب قيمة اللون الأحمر بنظام RGB لأحد المربعات
     * 
     * ‫الشرط المسبق: لابد أن يقع كُلا من المعاملين row و col ضمن النطاق المسموح به
     * ‫الشرط اللاحق: إعادة قيمة اللون الأحمر بنظام RGB للمربع المخصص
     * ‫كعدد صحيح يقع بين العددين 0 و 255
     */
    public static int getRed(int row, int col)


    /**
     * ‫تعمل بنفس طريقة الدالة  getRed
     */
    public static int getGreen(int row, int col)


    /**
     * ‫تعمل بنفس طريقة الدالة  getRed
     */
    public static int getBlue(int row, int col)


    /**
     * لإبطاء تنفيذ البرنامج عبر الانتظار قليلًا 
     * 
     * الشرط المسبق: لابد أن يكون المعامل‫ milliseconds عددا موجبا
     * ‫الشرط اللاحق: سيتوقف البرنامج مؤقتًا لمدة تساوي الزمن الممرر
     * بوحدة المللي ثانية
     */
    public static void delay(int milliseconds)

تَذَكَّر أن البرامج الفرعية -بالأعلى- هي أعضاء (members) ضِمْن الصَنْف Mosaic، ولهذا ينبغي أن تَتضمَّن أسماء تلك البرامج (routine) اسم الصَنْف ذاته عند اِستدعائها بمكان يَقَع خارج الصنف Mosaic. على سبيل المثال، اِستخدِم الاسم Mosaic.isOpen()‎ بدلًا من الاسم isOpen.

لا تُحدِّد تعليقات البرامج الفرعية -بالأعلى- ما سيَحدُث في حالة عدم استيفاء شروطها المُسَبَّقة (preconditions). على الرغم من أن البرامج الفرعية (subroutine)، في العموم، غير مُلزَمة فعليًا بما هو مَكْتوب ضِمْن مواصفاتها الاصطلاحية (contract)، فسيَكُون من الجيد مَعرِفة ما سيَحدُث في مثل تلك الحالات. على سبيل المثال، يُبلِّغ البرنامجين الفرعيين setColor()‎ أو getRed()‎ عن حُدوث اعتراض من النوع IllegalArgumentException في حالة عدم استيفاء شَّرْطهما المُسَبَّق: "ضرورة وقوع كلًا من row و col ضِمْن النِطاق المَسموح به لرَقمي الصف والعمود على الترتيب." تَسمَح مَعرِفتك لمثل تلك الحقيقة بكتابة برامج يُمكِنها التقاط (catch) ذلك الاعتراض (exception)، ومُعالجته، ولهذا سيَكُون من المفيد تَوْثيق (document) تلك المعلومة من خلال إضافة الوَسْم التوثيقي (doc tag)‏ ‎@throws‎ إلى تعليق Javadoc. تَتَبقَّى أسئلة آخرى عديدة تَتَعلَّق بكيفية تَصرُّف البرنامج الفرعي ضِمْن حالات معينة. على سبيل المثال، ماذا سيَحدُث إذا استدعينا البرنامج الفرعي Mosaic.open()‎ بينما هنالك نافذة مفتوحة بالفعل على الشاشة؟ في تلك الحالة، سيتجاهل البرنامج الفرعي عملية الاستدعاء الثانية. في الواقع، يَصعُب عادة إعداد تَوْثيق كامل على تلك الشاكلة، وأحيانًا ستحتاج إلى مُجرَّد تجربة حالة معينة لترى بنفسك كيفية تَصرُّفها، أو قد تَضطرّ أحيانًا للإطلاع على كامل الشيفرة المصدرية (source code) في حالة تَوفُّرها.

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

مع اعتمادنا على البرامج الفرعية (routines) ضِمْن الصنف Mosaic، نستطيع كتابة التَصوُّر المَبدئي للبرنامج كالتالي:

// ‫افتح نافذة Mosaic
Open a Mosaic window
// اِملئ النافذة بألوان عشوائية
Fill window with random colors
// تجول وغير لون المربعات عشوائيًا
Move around, changing squares at random

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

// ‫افتح نافذة Mosaic
Open a Mosaic window
// اِملئ النافذة بألوان عشوائية
Fill window with random colors
// اضبط المَوضع الحالي إلى المربع بمنتصف النافذة
Set the current position to the middle square in the window
// طالما كانت النافذة مفتوحة
As long as the mosaic window is open:
   // غير لون المربع بالمَوضع الحالي عشوائيًا
   Randomly change color of the square at the current position
   // حرك الموضع الحالي لأعلى أو لأسفل أو لليسار أو لليمين عشوائيًا
   Move current position up, down, left, or right, at random

سنَستخدِم مُتَغيِّرين من النوع الصحيح int هما currentRow و currentColumn؛ لتَمثيِل "المَوْضِع الحالي (current position)"، سيَحمِلان رقمي الصف (row number) والعمود (column number) للمربع الحالي الذي يُطبَق عليه التشويش (disturbance). لما كانت نافذة mosaic مُكوَّنة من ١٦ صف و ٢٠ عمود من المربعات، يُمكِننا تهيئة قيمة "المَوضِع الحالي" المَبدئية إلى منتصف النافذة عن طريق ضَبْط المُتَغيِّرين currentRow و currentColumn إلى القيمتين ٨ و ١٠ على الترتيب. سنَلجأ لاستخدام البرنامج الفرعي Mosaic.open()‎ لفَتْح النافذة، كما سنَكتُب برنامجين فرعيين (subroutines) إضافيين لإِنجاز مُهِمّتين ضِمْن حَلْقة التَكْرار while بحيث يَظلّ البرنامج main()‎ بسيطًا. نستطيع الآن تَحْوِيل الخوارزمية (algorithm) إلى الشيفرة التالية بلغة الجافا:

Mosaic.open(16,20,25,25)
fillWithRandomColors();
currentRow = 8;       // الصف الواقع بمنتصف النافذة
currentColumn = 10;   // العمود الواقع بمنتصف النافذة
while ( true ) { // ينتهي البرنامج عند غلق النافذة
    changeToRandomColor(currentRow, currentColumn);
    randomMove();      
}

سنُجرِي أيضًا تَعْديلًا إضافيًا، وهو إِبطاء التحريكة (animation) قليلًا، ولذلك سنُضِيف السطر Mosaic.delay(10);‎ إلى حَلْقة التَكْرار while.

انتهينا الآن من إِعداد البرنامج main()‎، لكننا نَحتاج لكتابة البرامج الفرعية fillWithRandomColors()‎ و changeToRandomColor(int,int)‎ و randomMove()‎ لنُكمِل البرنامج. تُعدّ عملية كتابة كل برنامج منها بمَثابة مُهِمّة صغيرة مُنفصلة. سنبدأ بالبرنامج الفرعي fillWithRandomColors()‎ والمَسئول عن ضمان تَحقُّق الشَّرْط اللاحق (postcondition) التالي: "سيَتغيَّر لون كل مربع بالنافذة عشوائيًا." يُمكِننا كتابة خوارزمية (algorithm) لإِنجاز تلك المُهِمّة بأسلوب الشيفرة الوهمية (pseudocode) كالتالي:

// لكل صف
For each row:
   // لكل عمود
   For each column:
         // غير لون المربع بذلك الصف والعمود إلى لون عشوائي
      set the square in that row and column to a random color

يُمكِن تَّنْفيذ (implement) السَطْرين "لكل صف"، و"لكل عمود" -بالأعلى- باِستخدَام حَلْقة التَكْرار for. أما بخصُوص السطر الأخير، فلقد قَررنا بالفعل كتابة البرنامج الفرعي changeToRandomColor(int,int)‎ المَسئول عن ضَبْط اللون. لاحِظ أن إِمكانية إعادة اِستخدَام برنامج فرعي معين بعدة مَواضِع يُعدّ أحد أهم مَكاسِب اِستخدَام البرامج الفرعية. يُمكِننا الآن كتابة البرنامج الفرعي fillWithRandomColors()‎ بلغة الجافا كالتالي:

static void fillWithRandomColors() {
    int row, column;
    for ( row = 0; row < 16; row++ )
        for ( column = 0; column < 20; column++ )
            changeToRandomColor(row,column);
}

سننتقل الآن إلى البرنامج الفرعي التالي changeToRandomColor(int,int)‎. يُوفِّر الصَنْف Mosaic بالفعل التابع (method)‏ Mosaic.setColor()‎، والمُستخدَم لتَغْيِير لون المربع.لمّا كنا نُريد لونًا عشوائيًا، فسنحتاج إلى اختيار قيم عشوائية لكل من r و g و b، والتي ينبغي أن تَكُون أعدادًا صحيحة (integers) مُتراوحة بين العددين ٠ و ٢٥٥، وفقًا للشَّرْط المُسَبَّق (precondition) للبرنامج الفرعي Mosaic.setColor()‎، ولهذا سنَستخدِم المُعادلة (int)(256*Math.random()‎) لاختيار مثل تلك الأعداد. بالتالي، يُمكِننا كتابة البرنامج الفرعي المُستخدَم لتَغْيِير اللون عشوائيًا كالتالي:

static void changeToRandomColor(int rowNum, int colNum) {
    int red = (int)(256*Math.random());
    int green = (int)(256*Math.random());  
    int blue = (int)(256*Math.random());
    Mosaic.setColor(rowNum,colNum,red,green,blue);  
}

وأخيرًا، يُمكِننا الانتقال إلى البرنامج الفرعي randomMove()‎، والمَسئول عن تحريك التشويش (disturbance) عشوائيًا، لأعلى، أو لأسفل، أو يسارًا، أو يمينًا. سنَستخدِم عددًا عشوائيًا يَتراوح بين القيمتين ٠ و ٣؛ لإجراء الاختيار ما بين الاتجاهات الأربعة، فمثلًا، عندما تَكُون قيمة العدد مُساوِية للصفر، سيَتحرَك التشويش باتجاه معين، أما إذا كانت قيمته مُساوِية للواحد، فسيَتحرَك باتجاه آخر، وهكذا. لمّا كنا نَستخدِم المُتَغيِّرين currentRow و currentColumn لتحديد المَوضِع الحالي للتشويش، فإن تحريك ذلك المَوضِع لأعلى يَعنِي بالضرورة إِنقاص قيمة المُتَغيِّر currentRow بمقدار الواحد. يَترك ذلك استفهامًا عما يُفْترَض حُدوثه عندما يَصِل المُتَغيِّر currentRow إلى القيمة -١؛ خُصوصًا وأن ذلك سيَتَسبَّب بإخفاء التشويش خارج النافذة، وهو ما سينتهك الشَّرْط المُسَبَّق (precondition) لكثير من البرامج الفرعية ضِمْن الصنف Mosaic، ولهذا سنُحرِك التشويش إلى الحافة المُضادة من النافذة من خلال ضَبْط قيمة المُتَغيِّر currentRow إلى ١٥ (تَذَكَّر أن النافذة مُكوَّنة من ١٦ صف مُرقَّمَين من ٠ وحتى ١٥). بدلًا من القفز إلى الحافة الآخرى، نستطيع أيضًا تَجاهُل تلك الحالة. يُمكِننا معالجة تحريك التشويش (disturbance) للاتجاهات الثلاثة الأخرى بنفس الطريقة، بحيث نستعين بتَعْليمَة switch لتَحْديد الاتجاه ذاته. اُنظر شيفرة البرنامج الفرعي randomMove()‎:

int directionNum;
directionNum = (int)(4*Math.random());
switch (directionNum) {
    case 0:  // تحرك لأعلى
        currentRow--;
        if (currentRow < 0)   // إذا أصبح الموضع الحالي خارج النافذة
            currentRow = 15;   // قم بتحريكه للحافة المضادة
        break;
    case 1:  // تحرك لليمين
        currentColumn++;
        if (currentColumn >= 20)
            currentColumn = 0;
        break; 
    case 2:  // تحرك لأسفل
        currentRow++;
        if (currentRow >= 16)
            currentRow = 0;
        break;
    case 3:  // تحرك لليسار
        currentColumn--;
        if (currentColumn < 0)
            currentColumn = 19;
        break; 
}

البرنامج

انتهينا الآن من كتابة جميع البرامج الفرعية، وتَبقَّى لنا تَجْميعها معًا بحيث نَحصُل على البرنامج كاملًا، بالإضافة إلى كتابة تعليقات Javadoc للصنف ذاته ولبرامجه الفرعية. لاحظ أننا قد عَرَّفنا المُتَغيِّرين currentRow و currentColumn كأعضاء ساكنة (static members) ضِمْن الصنف، وليس كمُتَغيِّرات محليّة (local)؛ وذلك لكَوْنهما مُستخدَمين ضِمْن أكثر من مُجرَّد برنامج فرعي (subroutines) واحد. تَتَوفَّر نسخة من الشيفرة المصدرية للبرنامج بالملف RandomMosaicWalk.java، وانتبه لكَوْنه يَعتمِد على كُلًا من الملفين Mosaic.java و MosaicCanvas.java.

/**
 * يفتح هذا البرنامج نافذة مليئة بالمربعات الملونة عشوائيًا
 * بحيث يتحرك نوع من "التشويش" عشوائيًا عبر الشاشة ويغير من 
 * لون أي مربع يواجهه بشكل عشوائي. يستمر البرنامج في العمل 
 * طالما كانت النافذة مفتوحة
 */
public class RandomMosaicWalk {

    static int currentRow;    // رقم الصف المعرض للتشويش
    static int currentColumn; // رقم العمود المعرض للتشويش

    /**
     * ‫يُنشيء برنامج main النافذة ويملؤها بألوان عشوائية
     * ثم يحرك التشويش بصورة عشوائية عبر النافذة طالما كانت مفتوحة
     */
    public static void main(String[] args) {
        Mosaic.open(16,20,25,25);
        fillWithRandomColors();
        currentRow = 8;   // ابدأ بمنتصف النافذة
        currentColumn = 10;
        while (true) {
            changeToRandomColor(currentRow, currentColumn);
            randomMove();
            Mosaic.delay(10);  // احذف هذا السطر لزيادة سرعة التحريكة
        }
    }  // نهاية main

    /**
     * يملأ النافذة بمربعات ملونة عشوائيا
     *
     * الشرط المسبق: لابد أن تكون النافذة مفتوحة
     * الشرط اللاحق: سيصبح كل مربع النافذة ملون بصورة عشوائية
     */
    static void fillWithRandomColors() {
        int row, column;
        for ( row=0; row < 16; row++ ) {
            for ( column=0; column < 20; column++ ) {
                changeToRandomColor(row, column);  
            }
        }
    }  // نهاية fillWithRandomColors

    /**
     * يغير من لون مربع معين بالنافذة عشوائيًا
     *
     * الشرط المسبق: لابد أن يقع رقمي الصف والعمود الممررين ضمن
     * النطاق المسموح به لأرقام الصف والعمود
     * الشرط اللاحق: سيتغير لون المربع المخصص بواسطة رقمي الصف والعمود
     *  
     * @param rowNum رقم الصف للمربع بحيث يبدأ عد الصفوف من الأعلى
     * @param colNum رقم الصف للمربع بحيث يبدأ عد الأعمدة من اليسار
     */
    static void changeToRandomColor(int rowNum, int colNum) {
        // اختر قيم عشوائية تتراوح بين 0 و 255
        // لقيم الألوان الثلاثة (الأحمر، والأزرق، والأخضر‫) ‫بنظام الألوان RGB

        int red = (int)(256*Math.random());    
        int green = (int)(256*Math.random());  
        int blue = (int)(256*Math.random());   
        Mosaic.setColor(rowNum,colNum,red,green,blue);  
    }  // ‫نهاية changeToRandomColor

    /**
     * يحرك التشويش عبر النافذة
     * 
     * الشرط المسبق: لابد أن تكون المتغيرات العامة‫ currentRow و 
     * ‫currentColumn ضمن النطاق المسموح به لرقمي الصف والعمود
     * الشرط اللاحق: يتغير رقمي الصف والعمود إلى أحد المواضع المجاورة 
     * سواء للأعلى أو للأسفل أو لليسار أو لليمين
     */
    static void randomMove() {
        int directionNum; 

        directionNum = (int)(4*Math.random());
        switch (directionNum) {
            case 0:  // move up 
                currentRow--;
                if (currentRow < 0)
                    currentRow = 15;
                break;
            case 1:  // move right
                currentColumn++;
                if (currentColumn >= 20)
                    currentColumn = 0;
                break; 
            case 2:  // move down
                currentRow ++;
                if (currentRow >= 16)
                    currentRow = 0;
                break;
            case 3:  // move left  
                currentColumn--;
                if (currentColumn < 0)
                    currentColumn = 19;
                break; 
        }
    }  // ‫نهاية randomMove

} // ‫نهاية الصنف RandomMosaicWalk

ترجمة -بتصرّف- للقسم Section 7: More on Program Design من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

كل تَطوُّر يَحدُث بواجهات المُستخدِم، يُقابله تَعقيد أكبر ينبغي على المبرمج التَعامُل معه، ففي حين تستطيع كتابة واجهة برنامج طرفية (console user interface) بواسطة عدد قليل من البرامج الفرعية (subroutines) البسيطة التي تقرأ ما يَكْتُبه المُستخدِم، وتَطبَع خَرْج البرنامج إلى الطرفية، فإن تطوير واجهات المُستخدِم الرسومية (graphical user interface) العصرية هو أمر أكثر تعقيدًا بمراحل عدة، خاصة مع كل هذا الكم الهائل من النوافذ، والأزرار، وشرائط التمرير، والقوائم، وصناديق الإِدْخَال النصية، وغيره، والتي أينعم تَمنَح المُستخدِم تجربة سهلة ومريحة، ولكنها في ذات الوقت تُجبر المبرمج على التَعامُل مع كمية هائلة من الاحتمالات والتعقيدات المتزايدة، والتي تَكُون بهيئة عدد ضخم من البرامج الفرعية المُخصَّصة فقط لأغراض إدارة واجهة المُستخدِم (user interface) ناهيك عن البرامج الفرعية الآخرى المُخصَّصة لغَيْر ذاك الغرض.

صناديق الأدوات (toolboxes)

اعتاد مبرمجي حاسوب ماكنتوش الأصلي (Macintosh) على التعامل مع "صندوق أدوات ماكنتوش (Macintosh Toolbox)"، والذي يَتكوَّن من أكثر من ألف برنامج فرعي (subroutines) مختلف؛ حيث تَتَوفَّر برامج لتَّنْفيذ جميع العمليات التي يُتوقَّع من الحاسوب القيام بها، فمثلًا، تَتَوفَّر تلك البرامج المُتعلقة بواجهة المُستخدِم (user interface) مثل فَتْح النوافذ (windows) وإِغلاقها، ورَسْم كُلًا من الأشكال الهندسية (geometric) والنصوص على تلك النوافذ، وإضافة الأزرار إليها، والاستجابة إلى ضغطات الفأرة على تلك النوافذ، وإضافة القوائم (menus)، والاستجابة لما يَختاره المُستخدِم منها. إلى جانب برامج واجهة المُستخدِم، تَتَوفَّر أيضًا برامج لفَتْح الملفات، وقراءة البيانات منها، وكذلك للاتصال الشبكي، ولإرسال الخَرْج إلى الطابعة، ولمُعالجة الاتصال بين البرامج. في المُقابل، يُوفِّر مايكروسوفت ويندوز (Microsoft Windows) مجموعة آخرى من البرامج الفرعية (subroutines) للمبرمجين، والتي تَختلِف نوعًا ما عن تلك المُستخدَمة بماكنتوش (Macintosh). علاوة على ذلك، يُوفِّر لينكس (Linux) للمبرمجين أكثر من صندوق أدوات لبرمجة واجهات المُستخدِم الرسومية (GUI toolboxes) يُمكِنهم الاختيار بينها.

أيّ مشروع برمجي هو بالنهاية خليط من كُلًا من الابتكار وإعادة الاِستخدَام. يبدأ المبرمج بمجموعة الأدوات البسيطة المَبْنِيَّة باللغة نفسها، كالمتغيرات، وتَعْليمَات الإِسْناد (assignment statements)، وتَعْليمَات التَفْرِيع if، وحَلْقات التَكْرار (loops). إلى جانب ذلك، فإنه قد يَستعِين بصناديق أدوات (toolboxes)، مَكْتوبة من قِبَل مُطوِّرين آخرين، والتي تَتضمَّن مجموعة من البرامج (routines) لتَّنْفيذ مَهَامّ معينة يَحتاجها المبرمج. إذا كانت تلك الأدوات مُصمَّمة تَصْمِيمًا جيدًا، فإنها تَكُون أَشْبه بصندوق أسود (black boxes)، لا يحتاج المبرمج أكثر من مُجرَّد استدعائها، دون مَعرِفة أية تفاصيل أو خطوات تُنفِّذها تلك الأداة لإنجاز المُهِمّة المُسنَدة إليها. كُل ما سبق يصُنَّف ضِمْن ذلك الجزء الخاص بإعادة الاِستخدَام، أما الجزء الآخر المُتَعلِّق بالابتكار، فيَتكوَّن من توظيف كل تلك الأدوات السابق ذِكرَها ضِمْن مشروع معين بهدف حل مشكلة معينة كمُعالجة النصوص، أو الاحتفاظ بالحسابات البنكية، أو مُعالجة الصور المُلتقَطة بواسطة مسبار فضاء، أو ألعاب الكمبيوتر، أو تَصفُّح الإنترنت، ..إلخ. يُطلَق على ذلك برمجة التطبيقات (applications programming).

صندوق الأدوات البرمجي (software toolbox) هو أَشْبه ما يَكُون بصندوق أسود، لابُدّ أن يَكُون مَصحُوبًا بواجهة (interface)، والتي تَتَكوَّن من توصيف لجميع البرامج (routines) المُعرَّفة بداخله، أيّ ذِكْر مُعامِلات (parameters) كل برنامج، والغرض منه. تُكوِّن تلك التوصيفات ما يُعرَف باسم واجهة برمجة التطبيقات (Application Programming Interface)، وتُختصَر إلى API، فمثلًا، تَحتوِي واجهة برمجة تطبيقات ماكنتوش (Macintosh API) على تَوصِيف لجميع البرامج (routines) المُتاحة "بصندوق أدوات ماكنتوش (Macintosh Toolbox)". عادةً ما تُصدر الشركات المُصنعة للأجهزة العتادية (hardware device) -مثل بطاقات الشبكة (network cards) المسئولة عن توصيل الحاسوب بشبكة معينة- واجهة برمجة تطبيقات (API) خاصة بذلك الجهاز، تَحتوِي على قائمة بالبرامج (routines) التي يُمكِن للمبرمجين استدعائها؛ للاتصال مع الجهاز والتَحكُّم به. علاوة على ذلك، يُوفِّر العلماء المُساهمين بكتابة البرامج المسئولة عن حِسَاب بعض العمليات المُعقدة نوعًا ما -مثل حلّ المعادلات التفاضلية (differential equations)- واجهة برمجة تطبيقات (API)، تَسمَح للآخرين باستدعاء تلك البرامج (routines) دون الحاجة إلى فهم تفاصيل تلك العمليات.

لغة الجافا مُدعَّمة بواجهة برمجة التطبيقات القياسية (standard API)، والتي تَعرَّضنا لأجزاء منها بالفعل، مثل البرنامج الفرعي الرياضي Math.sqrt()‎، والصَنْف String، وما يَحتوِيه من برامج (routines)، بالإضافة إلى برامج طباعة الخَرْج System.out.print()‎. تَتضمَّن أيضًا تلك الواجهة برامج (routines) لبرمجة واجهات المُستخدِم الرسومية (graphical user interfaces)، وللاتصالات الشبكية (network communication)، ولقراءة الملفات وكتابتها، وغيرها. يَظُنّ البعض أن تلك البرامج (routines) هي جزء من لغة الجافا ذاتها، ولكنها في الواقع مُجرَّد برامج فرعية (subroutines) قد كُتبت وأُتيحت للاِستخدَام ببرامج (programs) الجافا.

ينبغي لأيّ واجهة برمجة تطبيقات جافا (Java API) العَمَل على جميع المنصات، وعندها يُعدّ برنامج (program) الجافا المَكْتوب وفقًا لتلك الواجهة مُستقلًا عن أيّ منصة (platform-independent)، أيّ أنه من المُمكِن تَشْغِيل نفس البرنامج (program) على منصات (platform) مُتعدِّدة، مثل ويندوز (Windows)، وماك (Mac OS)، ولينكس (Linux) وغيرها. ومع ذلك، لاحِظ أن الواجهة (interface) ذاتها هي التي تُعدّ مُستقلة عن المنصات (platform-independent)، أما تَّنْفيذ (implementation) تلك الواجهة فإنه قد يختلف من منصة لآخرى. فيما يتعلق بواجهة برمجة التطبيقات القياسية (standard API)، يَتضمَّن نظام الجافا (Java system) بأي حاسوب عمومًا تَّنْفيذًا (implementations) لجميع البرامج الموجودة بتلك الواجهة. عندما يَستدعِي برنامج جافا (Java program) واحدة من تلك البرامج القياسية (standard routines) ضِمْن الواجهة القياسية، فإن مُفسِّر الجافا (Java interpreter) -عند تَّنْفيذه للبرنامج (program)- يَسحَب تَّنْفيذ البرنامج المُستدعَى (routine implementation) المُتناسب مع المنصة (platform) الحالية، ثم يُنفِّذه. يَعنِي ذلك أنه بمُجرَّد تَعلُّمك لواجهة برمجة تطبيقات (API) واحدة، سيُصبِح بإمكانك استهداف مجموعة واسعة من المنصات، وهو ما يُعدّ ميزة قوية جدًا.

حزم الجافا القياسية (standard packages)

تُكتَب البرامج (routines) بواجهة برمجة التطبيقات القياسية (standard API) داخل أصناف (classes) كما هو الحال مع أي برنامج فرعي (subroutine). بالإضافة إلى ذلك، فإنه من المُمكِن تَجْميع الأصناف ضِمْن حزم (packages)، والتي تَعرَّضنا لها باختصار بالقسم الفرعي ٢.٦.٧؛ بهدف تنظيمها على نطاق أوسع (large-scale). يُمكِن أيضًا تَضْمِين الحزم (packages) داخل حزم آخرى لتحقيق مُستوى أعلى من التَجْميع. في الواقع، واجهة برمجة تطبيقات جافا القياسية (standard Java API) مُنفَّذة (implement) بالكامل ضِمْن عدة حزم، فمثلًا، تَحتوِي حزمة java على عدة حزم آخرى غَيْر مُتَعلِّقة بواجهة المُستخدِم الرسومية (non-GUI)، بالإضافة إلى احتوائها على أصناف AWT المُتَعَلِّقة بتلك الواجهات الرسومية. حزمة javax هي مثال آخر، وتَحتوِي على أصناف كثيرة، من ضِمْنها تلك الأصناف التي تَستخدِمها واجهة المُستخدِم الرسومية (GUI)‏ Swing. كذلك حزمة javafx والتي تَحتوِي على واجهة برمجة تطبيقات جافا إف إكس (JavaFX API) التي يَستخدِمها الكتاب لبرمجة واجهات المُستخدِم الرسومية (GUI)‏.

قد تَحتوِي أي حزمة (package) على أصناف أو حزم آخرى، وتُسمَى تلك الأخيرة باسم الحزم الفرعية (sub-package). تَتضمَّن كُلًا من الحزمتين java و javafx على حزم فرعية (sub-packages). فمثلًا، تَحتوِي الحزمة الفرعية util على تشكيلة من الأصناف، بما في ذلك الصَنْف Scanner الذي ناقشناه بالقسم الفرعي ٢.٤.٦، وهي في الواقع مُتضمَّنة داخل حزمة java، ولذا يَكُون اسمها الكامل هو java.util. مثال آخر هو الحزمة الفرعية java.io، والتي تُسهِل من عمليات الخَرْج والدَخْل (input/output). كذلك الحزمة الفرعية java.net، والتي تتعامل مع الاتصالات الشبكية. أخيرًا الحزمة الفرعية الأكثر بساطة java.lang، والتي تَحتوِي على الأصناف الأساسية مثل String و Math و Integer و Double.

اُنظر الصورة التالية والتي تَتضمَّن تمثيلًا رسوميًا (graphical representation) لمُستويات التَدَاخُل (nesting levels) بحزمة java، بما في ذلك حزمها الفرعية (sub-packages)، والأصناف الموجودة ضِمْن تلك الحزم الفرعية، بالإضافة إلى البرامج الفرعية (subroutines) الموجودة ضِمْن تلك الأصناف. لاحِظ أن هذا التمثيل الرسومي غَيْر كامل، فهو يَعرِض فقط عددًا قليلًا جدًا من العناصر الكثيرة الموجودة بكل عنصر.

]

بالمثل، تَحتوِي حزمة javafx على الحزمة الفرعية javafx.scene، والتي تَحتوِي بدورها على كُلًا من الحزمتين الفرعيتين javafx.scene.control و javafx.scene.paint. تَحتوِي أولاهما على أصناف (classes) لتمثيل مُكوِّنات واجهة المُستخدِم الرسومية (GUI components)، كالأزرار (buttons)، وصناديق الإِدْخال (input boxes)، بينما تَحتوِي الآخرى على الصَنْف Color، وأصناف آخرى لأغراض مَلْئ الأشكال (filling) وتَحْدِيد حوافها (stroking).

تَتضمَّن واجهة برمجة تطبيقات جافا القياسية (standard Java API) آلافًا من الأصناف مُجمَّعة ضِمْن مئات من الحزم. الكثير من تلك الأصناف هو، في الواقع، مُتخصِّص للغاية أو غَيْر مَعْروف، لذا لا داعي للإلمام بكامل واجهة برمجة تطبيقات جافا (Java API)، ولا حتى غالبيتها، فحتى خبراء المبرمجين ليسوا على دِرَايَة بكامل الواجهة. ستُواجه عشرات الأصناف (classes) أثناء دراستك لهذا الكتاب، وستَجِدْ أنهم كافيين تمامًا لكتابة تشكيلة واسعة من البرامج (programs). مع ذلك، يُمكِنك تَصفُّح توثيق واجهة برمجة التطبيقات (API) للإصدار ٨ من الجافا بالإضافة إلى توثيق واجهة برمجة تطبيقات جافا إف إكس (JavaFX) للإطلاع على ما هو مُتاح عمومًا.

يُناقِش القسم الفرعي "الوحدات (modules)" بالأسفل بعضًا من التَغْيِيرات التي طرأت بالإصدار ٩ من الجافا، كما ستَجِدْ روابط تَوْثيق (documentation) الإصدار ١١ من الجافا. لكن لاحِظ أن تَوْثيق الإصدار ٨ يُعدّ أكثر سهولة في الاِستخدَام فيما يَتعلَّق بدراسة هذا الكتاب.

استخدام الأصناف ضمن الحزم

تَتضمَّن الحزمة javafx.scene.paint الصَنْف Color، لذا فإن الاسم الكامل للصنف هو javafx.scene.paint.Color. ذلك الصَنْف، وكأي صنف، هو بالنهاية نوع، أيّ أنك تستطيع اِستخدَامه للتَّصْريح (declare) عن كلًا من المُتَغيِّرات، والمُعامِلات (parameters)، وكذلك لتَخْصيص نوع القيمة المعادة (return type) من دالة (function). إذا أردت اِستخدَام ذلك الصَنْف ضِمْن أحد البرامج (program) التي تقوم بكتابتها، فإن أحد الطرائق للقيام بذلك هو استخدام الاسم الكامل للصَنْف كاسم للنوع. مثلًا، إذا كنت تريد التَّصْريح عن مُتَغيِّر اسمه rectColor من النوع Color، تستطيع كتابة التالي:

javafx.scene.paint.Color  rectColor;

تُمثِل الشيفرة بالأعلى مُجرَّد تَّصْريح (declaration) عن مُتَغيِّر عادي على الصياغة ‎;‎. مع ذلك، فإن اِستخدَام الاسم الكامل للصَنْف هو حتمًا أمر مُتعب، وفي الواقع، نادرًا ما ستَجِدْ تلك الأسماء الكاملة مُستخدَمة بأيّ برنامج (program)؛ حيث تَسمَح الجافا بتَجَنُّب اِستخدَام الاسم الكامل للصَنْف، وفي المقابل، ستحتاج إلى اِستيراد (importing) ذلك الصَنْف أولًا. يُمكِنك استيراد الصَنْف بإضافة السَطْر التالي إلى بداية ملف الشيفرة المصدرية (source code):

import javafx.scene.paint.Color;

بذلك، تستطيع ببقية ذلك الملف كتابة الاسم البسيط (simple name) للصَنْف، أيّ Color، بدلًا من الاسم الكامل javafx.scene.paint.Color. لابُدّ أن يُكتَب سَطْر الاستيراد import ببداية الملف (بعد تَعْليمَة package في حالة وجودها)، وبحيث لا يَقَع سَطْر الاستيراد import ضِمْن أيّ صَنْف (class) مُعرَّف داخل الملف. يُسمِى البعض سَطْر الاستيراد import -بالأعلى- أحيانًا باسم التَعْليمَة (statement)، ولكن من الأنسب تَسميته بالمُوجِّه (directive)‏ import؛ لأنه ليس تَعْليمَة بالمعنى المُعتاد. والآن، سَمَح لك المُوجِّه import javafx.scene.paint.Color بكتابة التالي للتَّصْريح عن مُتَغيِّر:

Color  rectColor;

يَقْتصِر دور المُوجِّه (directive)‏ import على السماح باِستخدَام الأسماء البسيطة للأصناف بدلًا من أسمائها الكاملة .، أي أنه لا يَستوِرد أي شيء فعليّ، فأنت ما زلت تستطيع الوصول إلى الصَنْف (class) بدون اِستخدَام ذلك المُوجِّه، فقط ستحتاج إلى تعيين اسم الصَنْف كاملًا. تَتَوفَّر طريقة مُختصرة لاستيراد (importing) جميع الأصناف الموجودة ضِمْن حزمة معينة. على سبيل المثال، اِستخدِم مُوجِّه import التالي بهدف استيراد جميع الأصناف (classes) الموجودة بحزمة java.util:

import java.util.*;

لاحِظ أنه في حين يَتطابَق محرف البدل (wildcard) * مع جميع الأصناف الموجودة ضِمْن حزمة معينة، فإنه لا يَتطابَق مع حزمها الفرعية (sub-packages)، أيّ أنك لا تستطيع استيراد جميع الحزم الفرعية (sub-packages) الموجودة ضِمْن حزمة javafx بمُجرَّد كتابة import javafx.*‎.

لمّا كان اِستخدَام محرف البدل (wildcard) * بتَعْليمَة import يُتيح عددًا كبيرًا من أسماء الأصناف التي على الأرجح لن تُستخدَم، بل والتي ربما لا يَعَلم المبرمج عنها شيئًا، فإن بعض المبرمجين يُفضِّلون استيراد كل صَنْف سيَستخدِمونه فعليًا استيرادًا صريحًا وبصورة مُنفصلة. يَنصَح الكاتب باِستخدَام محرف البدل (wildcard) فقط مع الحزم (packages) الأكثر صلة بالتطبيق؛ بهدف استيراد جميع الأصناف (classes) الموجودة بها، أما في حالة اِستخدَام صَنْف واحد فقط أو اثنين من حزمة معينة، فلربما عندها من الأفضل اِستخدَام استيرادات (imports) فردية.

على سبيل المثال، قد يَحتوِي برنامج يتعامل بصورة أساسية مع الشبكات على المُوجِّه import java.net.*;‎، بينما قد يَحتوِي برنامج آخر يقرأ الملفات ويكتبها على المُوجِّه import java.io.*;‎. لكن لاحِظ أنه في حالة بدأت باستيراد الكثير من الحزم بتلك الطريقة، فلابُدّ من الانتباه لأمر هام. قد تَحتوِي حزمتان مختلفتان على صَنْفين (classes) يَحمِل كلاهما نفس الاسم، فمثلًا تَحتوِي كُلًا من الحزمتين java.awt و java.util على صَنْف اسمه List. الآن، إذا استوردت كُلًا من java.awt.*‎ و java.util.*‎، فسيُصبِح الاسم البسيط للصَنْف List مُبهمًا، وبالتالي، إذا حاولت التَّصْريح (declare) عن مُتَغيِّر من النوع List، ستَحصُل على رسالة خطأ من المُصرِّف (compiler) بشأن وجود اسم صَنْف مُبْهَم. مع ذلك، ما زلت تستطيع اِستخدَام كِلا الصنفين بالبرنامج (program)، إما باِستخدَام الاسم الكامل للصَنْف مثل java.awt.List و java.util.List، أو باِستخدَام المُوجِّه import لاستيراد الأصناف المُفردة التي تحتاجها بدلًا من استيراد الحزم (packages) بالكامل.

تُعدّ الحزمة java.lang أحد أهم الحزم الأساسية؛ لاحتوائها على بعض الأصناف الرئيسية، ولذلك تُستورَد جميع الأصناف الموجودة بتلك الحزمة أتوماتيكيًا بأيّ برنامج (program)، أيّ كما لو كان كل برنامج يبدأ بالتَعْليمَة import java.lang.*;‎. وهو في الواقع ما قد مَكَّنا سابقًا من اِستخدَام اسم الصَنْف String بدلًا من java.lang.String، واِستخدَام Math.sqrt()‎ بدلًا من java.lang.Math.sqrt()‎. ومع ذلك، يُمكِنك أيضًا اِستخدَام الصياغة الأطول من أسماء تلك الأصناف.

تُستخدَم تَعْليمَة package لإنشاء حزم (packages) جديدة، والتي قد تَتضمَّن مجموعة من الأصناف (classes). كل ما عليك القيام به هو كتابة تلك التَعْليمَة ببداية ملفات الشيفرة المصدرية (source code) التي تَحتوِي على تعريف الأصناف المطلوب تَضْمِينها بتلك الحزمة. مثلًا، إذا أردت إنشاء حزمة اسمها utilities، اِستخدِم السطر التالي:

package utilities;

لابُدّ أن تُكْتَب تَعْليمَة package ببداية الملف، أيّ حتى قَبْل أيّ مُوجِّه import قد يَكُون موجودًا بذلك الملف. بالإضافة إلى ذلك، لابُدّ أن يوجد ذلك الملف بمجلد يَحمِل نفس اسم الحزمة، أي utilities بهذا المثال. وبالمثل، لابُدّ أن توجد ملفات الأصناف ضِمْن الحزم الفرعية (sub-package) بمجلدات فرعية. على سبيل المثال، ينبغي لملفات الأصناف الموجودة بحزمة اسمها utilities.net أن تكون موجودة بمجلد اسمه net الموجود بدوره بمجلد آخر اسمه utilities. يستطيع أي صَنْف داخل حزمة (package) معينة الوصول أتوماتيكيًا إلى جميع الأصناف (classes) الآخرى الموجودة بنفس الحزمة. بتعبير آخر، لا يحتاج صَنْف معين أن يَستورِد (import) الأصناف من نفس الحزمة (package) المُعرَّف بها.

عادة ما يَلجأ المبرمجون لإنشاء حزم جديدة وذلك إِما بالمشروعات التي تُعرِّف عددًا كبيرًا من الأصناف؛ بهدف تنظيمها، أو عند إِنشائهم لصناديق أدوات (toolboxes)؛ لتوفير واجهة برمجة تطبيقات (APIs) لبعض الوظائف والميزات غير المُتوفِّرة بواجهة برمجة تطبيقات جافا القياسية (standard Java API). في الواقع، يَحظَى المبرمجون "من صَانِعي الأدوات" عادة بهَيْبة واحترام أكبر من مُبرمجي التطبيقات الذين يَستخدِمون تلك الأدوات.

لاحظ أن غالبية الأصناف المَكْتوبة لهذا الكتاب غَيْر مُضمَّنة بأي حزمة، مع عدة استثناءات قليلة مثل الصَنْف TextIO بالحزمة textio. لأغراض هذا الكتاب، فإنك ستحتاج أن تدرك ماهية الحزم (packages)؛ حتى تَتَمكَّن من استيراد الصَنْف TextIO، وكذلك الأصناف الموجودة ضِمْن الحزم القياسية (standard packages). لاحِظ أن الحزم القياسية هي دائمًا مُتوفِّرة بجميع البرامج (programs) التي تَكتُبها، قد تَتَساءل، أين توجد تلك الأصناف القياسية (standard classes) بصورة فعليّة؟ يَعتمِد ذلك على إصدار الجافا المُستخدَم إلى حد كبير. مثلًا، بالإصدار ٨ من الجافا، فإنها تَكُون مُخزَّنة بملفات جافا أَرْشيفيّة (jar files/Java archive) تقع بالمجلد الفرعي lib الموجود بمجلد التثبيت الخاص ببيئة تَّنْفيذ الجافا (Java Runtime Environment). إن ملفات جافا الأَرْشيفيّة (jar file/Java archive) هي ببساطة ملفات بامتداد ‎.jar قد تَحتوِي على عدة أصناف. توجد غالبية الأصناف المُستخدَمة بالإصدار ٨ من الجافا بملف جافا أرشيفي (jar file) اسمه rt.jar. طرأت بعض التَغْيِيرات بالإصدار ٩ من الجافا، وهو ما سنُناقشه بالقسم الفرعي التالي.

لاحِظ أن أيّ صَنْف بالنهاية لابُدّ وأن يقع ضِمْن حزمة (package)، حتى في حالة عدم تَحْدِيد الحزمة التي يُفْترَض أن يقع بها الصنف صراحةً، وفي تلك الحالات، يُوضَع الصَنْف تلقائيًا فيما يُعرَف باسم الحزمة الافتراضية (default package)، والتي ليس لها اسم. تقع تقريبًا كل الأمثلة التي ستراها بهذا الكتاب بالحزمة الافتراضية.

الوحدات (modules)

تُدعِّم الجافا منذ الإصدار ٩ ما يُعرَف باسم الوحدات (modules)، وهو ما تَسَبَّب بحُدوث بعض التَغْيِيرات على بنيتها ذات النطاقات الواسعة (large-scale structure). تُوفِّر الوحدات (modules) عمومًا مستوًى آخرًا من التَجْميع؛ حيث تَتضمَّن الوحدات مجموعة من الحزم، التي تَحتوِي على أصناف، والتي بدورها تَحتوِي على مُتَغيِّرات وتوابع (methods). ليس ضروريًا أن تقع الحزمة ضِمْن وحدة (module) حتى تُصبِح قابلة للاِستخدَام، ومع ذلك، فإن جميع الأصناف القياسية (standard classes) بكُلًا من جافا (Java) وجافا إف إكس (JavaFX) قد ضُمّنت داخل وحدات (modules).

وَفَّرت الجافا الوحدات (modules) لعدة أسباب: أولًا، لتَحسِّين التَحكُّم بالوصول (access control)، وهو في الواقع أحد أهم الأسباب الرئيسية. قَبْل الوحدات، كان بإِمكانك اِستخدَام الأصناف العامة، أيّ تلك المُصرَّح عنها باِستخدَام المُبدِّل public، بأيّ مكان وداخل أيّ صَنْف ضِمْن أيّ حزمة، وبالمثل مُتَغيِّراته وتوابعه المُصرَّح عنها باِستخدَام المُبدِّل public. في المقابل، يَعنِي اِستخدَام المُبدِّل العام public مع صَنْف، مُعرَّف ضِمْن وحدة (module)، كَوْن ذلك الصَنْف عامًا public ضِمْن الوحدة (module) المُعرَّف بداخلها فقط. ومع ذلك، ما يزال بإمكان الوحدات تصدير (export) أي حزمة بشكل صريح، وبناءً عليه، ستُصبِح الأصناف العامة، أيّ تلك المُعرَّفة باِستخدَام المُبدِّل public، ضمن تلك الحزمة قابلة للوصول (accessible) مرة آخرى من أي مكان، بما في ذلك الوحدات (modules) الآخرى، وكذلك الأصناف التي ليست جزءًا من أي وحدة. يمكن حتى تَخْصيص الوحدات (modules) المطلوب تصدير الحزمة إليها، وهو ما يُوفِّر تَحكُّمًا بالوصول (access control) أكثر دقة. يَعنِي كل ما سبق أنه يُمكِننا الآن إنشاء حزم هي خاصة (private) بالأساس، أيّ أنها غَيْر مَرئية (invisible) من خارج الوحدة، ولكنها في نفس الوقت تُوفِّر خدمات (services) للحزم الآخرى داخل نفس الوحدة. يُمكِننا بذلك عدّ الوحدة نوعًا آخرًا من الصندوق الأسود (black box)، تَكُون فيه الحزم غَيْر المُصدَّرة (non-exported) جزءًا من تَّنْفيذه (implementation) الخفي. تُعدّ التركيبية (modularity) على هذا المُستوى الواسع من النطاق مهمة بحقّ، وبالأخص للتطبيقات ذات النطاقات الواسعة (large-scale applications).

الدافع الآخر لتَوْفِير الوحدات (modules) هو الحجم الكلي لبيئة تَّنْفيذ الجافا القياسية (Java Runtime Environment)، وتُختصر إلى JRE. تَتضمَّن تلك البيئة جميع الأصناف القياسية (standard classes) على الرغم من أن التطبيقات (application) تَستخدِم عادةً جزءًا صغيرًا منها. تَسمَح التركيبية (Modularization) بإنشاء بيئات تَّنْفيذ جافا مُخصَّصة (custom JREs) أصغر؛ بحيث تحتوي فقط على الوحدات التي يحتاجها التطبيق. تَتضمَّن عُدة تطوير الجافا (Java Development Kit)، وتُختصر إلى JDK، الأمر jlink المُستخدَم لإنشاء بيئات تَّنْفيذ مُخصَّصة (custom runtimes)، والتي عادةً ما تَتضمَّن وحدات (modules) التطبيق ذاته بالإضافة إلى الوحدات القياسية (standard modules) المطلوبة لتَشْغِيل ذلك التطبيق (application). بعد ذلك، تُوزَّع (distribute) بيئات التَّنْفيذ تلك كتطبيق قائم بذاته (standalone)، والذي يُمكِن تَشْغِيله حتى بتلك الحواسيب التي لم تُثبَّت عليها عُدة تطوير الجافا (JDK). ولكن لاحِظ أنك ستحتاج إلى إنشاء إصدارات مختلفة من بيئة التَّنْفيذ المُخصَّصة (custom runtime) للمنصات المختلفة مثل الويندوز (Windows) والماك (Mac OS) ولينكس (Linux)، كما هو الحال مع عُدة تطوير الجافا (JDK) ذاتها. بالإضافة إلى ذلك، لن تُطبَق تحديثات الأمان (security updates) الصادرة لعُدة تطوير الجافا (JDK) أتوماتيكيًا على بيئات التَّنْفيذ المُخصَّصة (custom runtime)، ولذلك تقع مسئولية تحديثها على مُطوِّر التطبيق. عمومًا يُعدّ ذلك ميزة مفيدة جدًا للتطبيقات الكبيرة.

منذ الإصدار ٩ من الجافا، تُخزَّن ملفات أصناف الوحدات القياسية (standard modules) المُصرَّفة داخل الملف modules، والموجود بالمجلد الفرعي lib الموجود بدوره بالمجلد الرئيسي لعُدة تطوير الجافا (JDK). صيغة ذلك الملف هي jimage، يُمكِنك التعامل معها باِستخدَام أداة سطر الأوامر jimage. في الواقع، عندما تُستخدَم أداة jlink لإنشاء بيئة تَّنْفيذ مُخصَّصة (custom runtime)، فإن جزءًا مما تقوم به هو إِنشاء ملف modules مُخصَّص يَحتوِي فقط على الوحدات (modules) المطلوبة لبيئة التَّنْفيذ (runtime) تلك. بفَحْص مجلد الإصدار ١٢ من عُدة تطوير الجافا (JDK) بحاسوب لينكس (Linux) الخاص بالكاتب، تَبيَّن أن الملف modules يَتضمَّن حوالي ٣٠١٩٩ صَنْف، ضِمْن ١٠٠٠ حزمة، ضِمْن ٧٠ وحدة، كما وصل حجمه إلى حوالي ١٣٠ ميجا بايت. يَحتوِي المجلد الرئيسي لعُدة تطوير الجافا (JDK) أيضًا على المجلد الفرعي jmods، والذي يَتضمَّن تلك الوحدات (modules) ولكن بصيغة آخرى، وعمومًا هو ليس مطلوبًا لتَصْرِيف البرامج وتَشْغِيلها، وغالبًا يَقْتصِر اِستخدَامه على الأداة jlink على حَدْ عِلم الكاتب.

تَتضمَّن عُدة تطوير الجافا (JDK) مجموعة من الوحدات، من بينها الوحدتين java.base و java.desktop. تَحتوِي أولاهما على الحزم الأساسية مثل java.lang و java.util، بينما تَتضمَّن الثانية حزم (packages) خاصة بـ"أدوات تَحكُّم واجهة المُستخدَم الرسومية Swing ‏(Swing GUI toolkit)". في المقابل، تَتضمَّن منصة جافا إف إكس (JavaFX) كُلًا من الوحدات javafx.base و javafx.control و javafx.graphics بالإضافة إلى وحدات آخرى غير شائعة الاِستخدَام عمومًا. يُقسَّم تَوْثيق واجهة برمجة التطبيقات (API) للإصدارات التركيبية (modular) من الجافا إلى وحدات (modules)، مُقسَّمة بدورها إلى حزم (packages)، وأخيرًا إلى أصناف (classes)، وهو ما قد يَجعَل التَوْثيق (documentation) أصعب قليلًا في التَصفُّح بالموازنة مع الإصدارات الأقدم. مع ذلك تَتوفَّر مِيزَة بحث فعالة بالموقع الالكتروني للتَوْثيق. يُمكِنك تَصفُّح توثيق الإصدار ١١ من الجافا بالإضافة إلى توثيق الإصدار ١١ من جافا إف إكس (JavaFX).

ليس ضروريًا أن يَقَع الصَنْف ضِمْن وحدة (module)، وفي تلك الحالة، فإنه ما يزال يستطيع اِستخدَام الحزم من الوحدات الاخرى، بشَّرْط أن تَكُون تلك الحزم قد صُدّرت (exported) بالوحدات المُعرَّفة داخلها. يستطيع المبرمج عمومًا اِستخدَام الأصناف الموجودة بعُدة تطوير الجافا (JDK) دون الحاجة للتفكير نهائيًا بالوحدات أو حتى مَعرِفة وجودها. يَنطبِق ذلك على برامج سطر الأوامر (command-line programs) بهذا الكتاب، أما برامج واجهة المُستخدِم الرسومية (GUI programs) التي تَستخدِم منصة جافا إف إكس (JavaFX)، فالأمور تختلف قليلًا منذ الإصدار ١١ من الجافا؛ وذلك لأن تلك المنصة قد حُذفَت من عُدة تطوير الجافا (JDK)، وأصبحت تُوزَّع بصورة مستقلة كمجموعة من الوحدات. لذلك، عند تَصْرِيف برنامج جافا إف إكس (JavaFX)، أو تَشْغِيله، ستحتاج، كما رأينا بالقسم ٢.٦، إلى تَخْصيص مسار الوحدة (module path)، والذي لابُدّ أن يَحتوِي على وحدات تلك المنصة، كما ستحتاج إلى تمرير قيمة للخيار ‎--add-modules. مُرِّرت ALL-MODULE-PATH كقيمة للخيار ‎--add-modules بالقسم ٢.٦؛ للسماح للبرنامج بالوصول إلى أي وحدات (modules) موجودة بمسار الوحدة (module path) المُمرَّر. بدلًا من ذلك، قد تُمرِّر قائمة بأسماء الوحدات المُستخدَمة فعليًا بالبرنامج فقط.

تنبيه: لا يُغطِى هذا الكتاب موضوع الوحدات (modules) بصورة أكبر من مُجرَّد اِستخدَامها مع منصة جافا إف إكس (JavaFX)، بالإضافة إلى المعلومات الأساسية بهذا القسم.

التوثيق بأداة Javadoc

ينبغي عمومًا كتابة تَوْثيق (documentation) جيد لأيّ واجهة برمجة تطبيقات (API)؛ وذلك حتى يَتَمكَّن المبرمجين من اِستخدَامها بصورة فعالة. يَشيِع اِستخدَام نظام Javadoc لتَوْثيق غالبية واجهات برمجة تطبيقات جافا (Java APIs)، فمثلًا، يُستخدَم هذا النظام لتجهيز تَوْثيق حزم الجافا القياسية (standard packages)، كما يَنشُر غالبية المبرمجين تقريبًا تَوْثيقًا باِستخدَام نفس ذلك النظام لأي صندوق أدوات (toolbox) يُطوروه بالجافا.

يُجهَز تَوْثيق Javadoc بالاعتماد على مجموعة من التعليقات (comments) الخاصة، والتي تُكتَب بملفات الشيفرة المصدرية. كما تَعَلم، تُكتَب أحد أنواع تعليقات الجافا ضِمْن الترميزين ‎/*‎ و ‎*/‎. بالمثل، تُكتَب تعليقات Javadoc بنفس الصياغة لكنها تبدأ بالترميز ‎/**‎‎ بدلًا من الترميز ‎/*‎. لقد تَعرَّضت بالفعل لتعليقات مَكْتوبة بتلك الصياغة بكثير من الأمثلة بهذا الكتاب.

ينبغي أن تُوْضَع تعليقات Javadoc قَبْل البرنامج الفرعي المَعنِي بالتعليق مباشرة. لاحظ ضرورة اتباع تلك القاعدة عمومًا وبَغْض النظر عن العنصر المَعنِي بالتَوْثيق. تُستخدَم تعليقات Javadoc عمومًا مع البرامج الفرعية (subroutines)، والمُتَغيِّرات الأعضاء (member variables)، والأصناف (classes)، وفي جميع تلك الحالات، لابُدّ دائمًا أن يَسبِق تعليق Javadoc العنصر المَعنِي بالتعليق مباشرة.

عندما يُصرِّف (compile) الحاسوب ملفات الشيفرة المصدرية، فإنه يتجاهل تعليقات Javadoc مثلما يتجاهل أي تعليق عادي آخر. تَتوفَّر الأداة javadoc، والتي تَقْرأ ملفات الشيفرة المصدرية، لتَستخرِج منها تعليقات Javadoc، ثم تُنشِئ مجموعة من صفحات الانترنت التي تَتضمَّن تلك التعليقات بصياغة متناسقة ومترابطة. لاحظ أن تلك الأداة تَستخرِج افتراضيًا المعلومات المُتعلِّقة بكُلًا من الأصناف العامة والبرامج الفرعية العامة والمُتَغيِّرات الأعضاء العامة فقط، أي تلك المُصرَّح عنها باِستخدَام المُبدِّل public، ومع ذلك فهي تَسمَح بإنشاء تَوْثيق للعناصر غير العامة (non-public) من خلال خيار خاص. إذا لم تَعثُر الأداة javadoc على أية تعليقات Javadoc لعنصر معين، فإنها تُنشِئ واحدًا افتراضيًا يَتكوَّن من مُجرد معلومات بسيطة عن ذلك العنصر، مثل اسم المُتَغيِّر العضو ونوعه في حالة كان العنصر مُتَغيِّر عضو، أو كُلًا من اسم البرنامج الفرعي، ونوع القيمة المُعادة منه وقائمة مُعامِلاته في حالة كان العنصر برنامجًا فرعيًا. تعدّ تلك المعلومات مُجرد معلومات صياغية (syntactic)، أما لإضافة معلومات دلالية (semantics) واقعية، فلابُدّ من كتابة تعليق Javadoc.

كمثال، يُمكِنك فَحْص "توثيق Javadoc للصنف TextIO". اُنشأت صفحة التَوْثيق تلك باِستخدَام أداة javadoc مع ملف الشيفرة المصدري TextIO.java. إذا حَمَّلت نسخة الكتاب المتاحة عبر الإنترنت، ستَجِدْ ذلك التوثيق بالمجلد TextIO_Javadoc.

يُعدّ استخدام الترميز * ببداية كل سطر ضِمْن تعليقات Javadoc أمرًا اختياريًا؛ حيث تَحذفه أداة javadoc على أية حال. بالإضافة إلى النص العادي، قد تَحتوِي تعليقات Javadoc على ترميزات (codes) خاصة، مثل أوامر HTML الترميزية (HTML mark-up commands)‏. تُستخدَم لغة HTML عمومًا لإنشاء صفحات الانترنت، ولمّا كانت تعليقات Javadoc مَعنيَّة بالظهور على تلك الصفحات، فإن أداة javadoc تَنسَخ أي أوامر HTML بالتعليقات إلى صفحات الانترنت التي تُنشئها. لن يتناول الكتاب أيّ شرح تفصيلي عن HTML، لكن، كمُجرَّد مثال، تستطيع مثلًا إضافة <p> للإشارة إلى بداية فقرة جديدة. في حالة غياب أوامر HTML، تتجاهل الأداة الأسطر الفارغة والفراغات (spaces) الإضافية الموجودة بالتعليق. انتبه أيضًا للمحرفين & و ‎<‎؛ لأن لهما معنًى خاصًا بلغة HTML، ولذا لا ينبغي اِستخدَامهما بتعليقات Javadoc لمعنى غير تلك المَعانِي، ولكن يُمكِن كتابتهما باِستخدَام ‎&‎ و ‎&lt‎;‎ على التوالي.

يُوفِّر نظام التوثيق Javadoc ما يُعرَف باسم الوُسوم التوثيقية (doc tags). تُكتَب تلك الوسوم ضِمْن تعليقات Javadoc، بحيث تُعالجها أداة javadoc بعدّها نوعًا من الأوامر الخاصة. يبدأ أيّ وَسم تَوْثيقي (doc tag) بالمحرف @ مَتبوعًا باسمه. سنتناول ٤ وسوم (tags) فقط، هي كالتالي: الوُسوم ‎@author و ‎@param و ‎@return و ‎@throws. يُستخدَم الوسم ‎@author فقط مع الأصناف، وينبغي أن يُتبَع باسم المؤلف. تُستخدَم الوسوم الثلاثة الاخرى بتعليقات Javadoc التي تستهدف البرامج الفرعية بهدف تَوْفِير معلومات عن مُعاملاتها، وقيمها المُعادة، والاعتراضات (exceptions) التي قد تبلِّغ عنها. لابُدّ أن تُوْضَع تلك الأوسمة بنهاية التعليق، أي بَعْد وصف البرنامج الفرعي نفسه. تُكتَب بالصيغ (syntax) التالية:

@param  <parameter-name>   <description-of-parameter>

@return  <description-of-return-value>

@throws  <exception-class-name>   <description-of-exception>

يُمكِن أن تمتد الأوصاف و و إلى عدة أسطر؛ حيث ينتهي أي وصف إما ببداية الوَسْم التوثيقي (doc tag) التالي أو بنهاية تعليق Javadoc بالكامل. يُمكِنك اِستخدَام الوَسْم ‎@param لوصف كل مُعامِل (parameter) يَستقبِله البرنامج الفرعي، وكذلك الوَسْم ‎@throws بقدر ما تريد تَوْثيقه من أنواع الاعتراضات (exception) المختلفة. وأخيرًا الوَسْم ‎@return والذي يُفْترَض كتابته للبرامج الفرعية التي تُعيد قيمة فعلية لا void. لا يُشترَط عمومًا كتابة تلك الوسوم (tags) بترتيب معين.

اُنظر المثال التالي والذي يَستخدِم وُسوم التَوْثيق (doc tag) الثلاثة:

/**
 * يحسب هذا البرنامج الفرعي مساحة المستطيل بفرض استقباله
 * لكلا من طول وعرض المستطيل. 
 * ينبغي أن يكون كلا من طول وعرض المستطيل الممررين قيمة موجبة
 * @param width طول أحد جوانب المستطيل 
 * @param height طول الجانب الآخر من المستطيل
 * @return مساحة المستطيل
 * @throws IllegalArgumentException إذا كان عرض أو طول المستطيل قيمة سالبة
 */
public static double areaOfRectangle( double height, double width ) {
    if ( width < 0  ||  height < 0 )
       throw new IllegalArgumentException("Sides must have positive length.");
    double area;
    area = width * height;
    return area; 
}

حَاوِل أن تَستخدِم تعليقات Javadoc بالشيفرة الخاصة بك، حتى لو لَمْ تَكُن تَنوِي إنشاء صفحة انترنت للتوثيق (documentation)؛ لأنها تُعدّ الصيغة القياسية لكتابة التوثيقات، لذا ستَكُون مألوفة لغالبية مُبرمجي الجافا.

أما إذا أردت إنشاء صفحة انترنت للتَوْثيق، فستحتاج إلى اِستخدَام أداة javadoc، وهي متاحة كأمر بعُدة تطوير الجافا (JDK) التي ناقشناها بالقسم ٢.٦. تستطيع عمومًا اِستخدَام أداة javadoc بواجهة سطر الأوامر (command line interface) بنفس الطريقة التي تَستخدِم بها أوامر مثل javac و java. لاحِظ أنه يُمكِن تطبيق توثيق Javadoc أيضًا داخل بيئات التطوير المتكاملة (integrated development environments)، تُعرَف اختصارًا باسم IDE، التي تحدثنا عنها بالقسم ٢.٦. لن نَتَعرَّض لأيّ من تلك التفاصيل هنا، حيث يُمكِنك ببساطة مراجعة توثيق بيئة البرمجة (programming environment) الخاصة بك.

الاستيراد الساكن (static import)

كنقطة أخيرة بهذا القسم، سنتناول امتدادًا للمُوجِّه (directive)‏ import. رأيت بالفعل كيف مَكَّنَك المُوجِّه import من الإشارة إلى صَنْف مثل java.util.Scanner باِستخدَام الاسم البسيط للصَنْف Scanner. لكنك ما زلت مُضطرًا لاِستخدَام الأسماء المُركَّبة للإشارة إلى المُتَغيِّرات الأعضاء الساكنة (static member variables) مثل System.out، والتوابع الساكنة (static methods) مثل Math.sqrt.

في الواقع، تَتَوفَّر صياغة آخرى من المُوجِّه import، تَستورِد الأعضاء الساكنة (static members) الموجودة بصَنْف معين بنفس الطريقة التي يَستورَد بها المُوجِّه import الأصناف (classes) من حزمة (package). تُسمَى تلك الصياغة من المُوجِّه باسم الاستيراد الساكن (static import). فمثلًا، لاستيراد اسم عضو ساكن (static member) واحد من صَنْف، نَكتُب الصيغة (syntax) التالية :

import static <package-name>.<class-name>.<static-member-name>;

بالمثل، قد تُكتَب الصيغة التالية لاستيراد جميع الأعضاء الساكنة العامة (public static members) ضِمْن صَنْف معين:

import static <package-name>.<class-name>.*;

على سبيل المثال، إذا كَتَبَت المُوجِّه import التالي قَبْل تعريف صَنْف (class definition) معين:

import static java.lang.System.out;

فإنك تستطيع بَعْدها -ضِمْن ذلك الصَنْف- اِستخدَام الاسم البسيط out بدلًا من الاسم المُركَّب System.out، وكذلك كتابة out.println بدلًا من System.out.println.

إذا كنت ستَستخدِم الصَنْف Math بكثرة ضِمْن صَنْف معين، فلربما قد تُفضِّل اِستِباق تعريف ذلك الصنف بالمُوجِّه import التالي:

import static java.lang.Math.*;

وهو ما سيَسمَح لك بكتابة sqrt بدلًا من Math.sqrt، وكتابة log بدلًا من Math.log، وأيضًا PI بدلًا من Math.PI، وغيره. يُمكِنك أيضًا استيراد الدالة getlnInt من الصنف TextIO باِستخدَام:

import static textio.TextIO.getlnInt;

تنبيه: يتَطلَّب مُوجِّه الاستيراد الساكن (static import directive) تَخْصيص اسم الحزمة حتى مع الأصناف المُعرَّفة بالحزمة القياسية java.lang، مما يَعنِي أنك لن تَكُون قادرًا على تَّنْفيذ أيّ استيراد ساكن (static import) من صَنْف مُعرَّف بالحزمة الافتراضية (default package)؛ لأن ليس لها اسم.

ترجمة -بتصرّف- للقسم Section 6: APIs, Packages, Modules, and Javadoc من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

يُخْزَّن البرنامج الفرعي (subroutine) بذاكرة الحاسوب على هيئة سِلسِلة نصية طويلة مُكوَّنة من الرقمين صفر وواحد، ولذلك فإنه لا يَختلف كثيرًا عن البيانات (data)، مثل الأعداد الصحيحة والسَلاسِل النصية والمصفوفات، والتي تُخْزَّن أيضًا بنفس الطريقة. ربما اِعتدت التفكير بكُلًا من البرامج الفرعية والبيانات على أساس أنهما شيئان مختلفان تمامًا، ولكن في الواقع يَتعامَل الحاسوب مع البرنامج الفرعي على أساس أنه مجرد نوع آخر من البيانات. تَسمَح حتى بعض اللغات البرمجية بالتَعامُل مع البرامج الفرعية بنفس الطريقة التي يَتعامَل معها الحاسوب، وهو ما أُضيف إلى الجافا على هيئة تعبيرات لامدا (lambda expressions) منذ الإصدار ٨.

أصبحت تعبيرات لامدا أكثر شيوعًا ببرامج الجافا، وهي مفيدة في العموم، ولكن تَبرُز أهميتها بصورة أكبر ببرمجة واجهات المُستخدِم الرُسومية (GUI)، كالتَعامُل مع "أدوات تَحكُّم واجهة المُستخدَم الرسومية JavaFX ‏(JavaFX GUI toolkit)"، وهو ما سنتناوله بالفصل السادس، كما سنَتَعرَّض لها مجددًا بنهاية الفصل الخامس، لذا يُمكِنك تَخطِّي هذا القسم إذا أردت إلى ذلك الحين.

الدوال الكيانية (first-class functions)

يُمكِننا كتابة دالة لحِسَاب قيمة مربع العدد، بحيث تَستقبِل ذلك العدد كمُعامِل صُّوري أو وهمي (dummy parameter)، كالتالي:

static double square( double x ) {
    return x*x;
}

كالعادة، لابُدّ من تَخْصيص اسم لتلك الدالة، وفي تلك الحالة كان square، وعليه تُصبِح تلك الدالة جزءًا دائمًا من البرنامج (program)، وهو ما قد لا يَكُون مُلائمًا؛ بالأخص إذا كنت تَنوِي اِستخدَام الدالة مرة واحدة فقط.

لامدا (lambda) هو أحد حروف الأبجدية الإغريقية (Greek alphabet)، والذي اِستخدَمه عالم الرياضيات ألونزو تشرتش (Alonzo Church) أثناء دراسته للدوال القابلة للحِسَاب (computable functions). على سبيل المثال، إذا كنا نُريد حِسَاب قيمة مربع عدد، وليكن x، فقد تَظُنّ أن الترميز x² يُمثِل "دالة" تَحسِب مربع x، لكنه، في الواقع، ليس سوى تعبير (expression) يُمثِل "نتيجة" حِسَاب مربع x. قَدَّمَ ألونزو تشرتش (Alonzo Church) ترميز لامدا (lambda notation) والذي يُمكِن اِستخدَامه لتعريف دالة (function) بدون تَخْصيص اسم لها. بالتحديد اِستخدَم الترميز lambda(x).x² (في الواقع يُستخدَم الحرف الإغريقي لامدا ذاته وليس الكلمة نفسها) للإشارة إلى "دالة x معطاة بواسطة x²". يُعدّ هذا الترميز دالة مجرَّدة (function literal)، أيّ تُمثِل قيمة من النوع "دالة (function)" بنفس الطريقة التي تُعدّ بها القيمة 42 عددًا صحيحًا مُجرَّدًا (integer literal) يُمثِل قيمة من النوع int.

ينبغي أن تَدْفَعك الدوال المُجرَّدة (function literals) إلى التَفكير بالدوال (function) على أنها مُجرَّد نوع آخر من القيم، وعندما تَصِل إلى تلك المرحلة، فإنك ستَكُون قادرًا على تَطْبِيق نفس تلك الأشياء التي اعتدت إجرائها على القيم الآخرى على الدوال أيضًا، كإِسْناد دالة إلى مُتَغيِّر، أو تمرير دالة كمُعامِل (parameter) إلى برنامج فرعي (subroutine)، أو إعادة دالة كقيمة من برنامج فرعي، أو حتى إنشاء مصفوفة دوال (array of functions). تَسمَح بعض لغات البرمجة بالقيام بكل تلك الأشياء، ويُقال عندها أنها تُدعِّم "الدوال الكيانيَّة (first-class functions)" أو أنها تُعامِل الدوال بعدّها كائنات كيانيَّة (first-class objects).

تُوفِّر لغة الجافا كل تلك الأشياء من خلال تعبيرات لامدا (lambda expressions)، والتي تَختلِف صيغتها عن الترميز الذي اِستخدَمه ألونزو تشرتش (Alonzo Church)، فهي الواقع، لا تَستخدِم حتى كلمة لامدا (lambda) على الرغم من مُسماها. تُكتَب دالة حِسَاب مربع العدد بتعبير لامدا (lambda expression) بلغة الجافا، كالتالي:

x  ->  x*x

يُنشِئ العَامِل ‎->‎ تعبير لامدا، بحيث تَقَع المُعامِلات الوهمية أو الصُّوريّة (dummy parameter) على يسار العَامِل، بينما يَقَع التعبير (expression) المسئول عن حِسَاب قيمة الدالة على يمينه. قد ترى تعبير لامدا بالأعلى مُمرَّرًا كمُعامِل فعليّ (actual parameter) إلى برنامج فرعي، أو مُسنَد إلى مُتَغيِّر، أو مُعاد من دالة.

إذًا، هل الدوال بلغة الجافا كيانيَّة (first-class)؟ لا تَتَوفَّر إجابة واضحة على هذا السؤال، لأن لغة الجافا لا تُدعِّم بعض الأشياء الآخرى المُتوفِّرة ضِمْن لغات برمجية آخرى. فمثلًا، في حين تستطيع إِسْناد تعبير لامدا المُعرَّف بالأعلى إلى مُتَغيِّر اسمه sqr، فإنك لن تستطيع بَعْدها اِستخدَام ذلك المُتَغيِّر كما لو كان دالة فعليّة، أيّ لا تستطيع كتابة sqr(42)‎. لغة الجافا عمومًا هي لغة صارمة في تَحْدِيد النوع (strongly typed)، ولذلك لكي تَتَمكَّن من إِنشاء المُتَغيِّر sqr، فعليك التَّصْريح عنه أولًا وهو ما يَتضمَّن تَخْصيص نوعه، فيا تُرى ما هو ذلك النوع الذي يَتناسب مع قيمة هي عبارة عن دالة؟ تُوفِّر الجافا ما يُعرَف باسم واجهة نوع الدالة (functional interface) لهذا الغرض، وسنناقشها بَعْد قليل.

ملاحظة أخيرة: على الرغم من ارتباط مصطلح الدالة (function) بتعبيرات لامدا (lambda expressions) بدلًا من مصطلحات مثل برنامج فرعي (subroutine) أو تابع (method)، فإنها في الواقع لا تَقْتصِر على تمثيل الدوال (functions)، وإنما يُمكِنها تمثيل أي برنامج فرعي (subroutines)، وبصورة عشوائية.

واجهات نوع الدالة (functional interfaces)

كي تَتَمكَّن من اِستخدَام برنامج فرعي (subroutine) معين، فلابُدّ أن تَعرِف كُلًا من اسمه، وعدد المُعامِلات (parameters) التي يَستقبِلها، وأنواعها، بالإضافة إلى نوع القيمة المُعادة (return type) من ذلك البرنامج الفرعي. تُوفِّر لغة الجافا ما يُعرَف باسم واجهات نوع الدالة (functional interface)، وهي أَشْبَه بالأصناف (class)، حيث تُعرَّف بملف امتداده هو ‎.java كأي صَنْف، وتَتضمَّن تلك المعلومات المذكورة بالأعلى عن برنامج فرعي وحيد. انظر المثال التالي:

public interface FunctionR2R {
    double valueAt( double x );
}

تُصرِّح الشيفرة بالأعلى عن واجهة نوع الدالة FunctionR2R، والموجودة بملف يَحمِل اسم FunctionR2R.java. تُصرِّح تلك الواجهة عن الدالة valueAt، والتي تَستقبِل مُعامِل وحيد من النوع double، وتُعيد قيمة من النوع double. تَفرِض قواعد الصيغة تَخْصيص اسم للمُعامِل -x بالأعلى- على الرغم من أنه في الواقع ليس ذا أهمية هنا، وهو ما قد يَكُون مزعجًا نوعًا ما. ها هو مثال آخر:

public interface ArrayProcessor {
    void process( String[] array, int count );
}

تَتضمَّن لغة الجافا الكثير من واجهات نوع الدالة القياسية (standard functional interfaces) بصورة افتراضية. تُعدّ واجهة نوع الدالة Runnable واحدة من أهم تلك الواجهات، وأبسطها، والمُعرَّفة كالتالي:

public interface Runnable {
    public void run();
}

سنَستخدِم واجهات نوع الدالة (functional interfaces) الثلاثة بالأعلى للأمثلة التالية بهذا القسم.

تُوفِّر لغة الجافا أيضًا ما يُعرَف باسم الواجهات (Interfaces)، والتي هي في الواقع أعم وأشمل، وربما أكثر تعقيدًا من واجهات نوع الدالة (functional interfaces). سنتعلَّّم المزيد عنها بالقسم ٥.٧. سنُقصِر حديثنا بهذا القسم على واجهات نوع الدالة (functional interfaces)؛ لارتباطها بموضوعنا الرئيسي: تعبيرات لامدا (lambda expressions).

يُعدّ اسم واجهة نوع الدالة نوعًا (type)، تمامًا كالأنواع String و double، وكأيّ نوع، فإنه يُمكِن اِستخدَامه للتَّصْريح عن المُتَغيِّرات، والمُعامِلات، وكذلك لتَخْصيص نوع القيمة المُعادة (return type) من الدوال، ويُمكِن إِسْناد تعبيرات لامدا (lambda expression) كقيم للمُتَغيِّرات من ذلك النوع. في الواقع، تَتضمَّن واجهة نوع الدالة (functional interface) قالبًا (template) لبرنامج فرعي وحيد، وينبغي لتعبير لامدا (lambda expression) المُسنَد أن يَكُون مُتطابِقًا مع ذلك القالب.

تعبيرات لامدا (lambda Expressions)

يُعدّ أي تعبير لامدا (lambda expression) تمثيلًا لبرنامج فرعي مجهول الاسم (anonymous subroutine)، أيّ لا يَمتلك اسمًا، ولكنه في المقابل، وكأيّ برنامج فرعي، لديه قائمة من المُعامِلات الصُّوريّة (formal parameter list)، بالإضافة إلى التعريف (definition) نفسه، ويُكتَب عمومًا بالصيغة (syntax) التالية:

( <parameter-list> )  ->  { <statements> }

كما هو الحال مع البرامج الفرعية العادية، يُمكِن لقائمة المُعامِلات -بالأعلى- أن تَكُون فارغة، أو قد تتكوَّن من تَّصْريح عن مُعامِل (parameter declaration) وحيد أو أكثر، بحيث يُفصَل بين كل تَّصْريح والذي يليه بفاصلة (comma)، وبحيث يَتكوَّن كل تَّصْريح من نوع المُعامِل متبوعًا باسمه. في الواقع، تُبسَّط عادة تلك الصيغة وفقًا لمجموعة من القواعد: أولًا: يُمكِن حَذْف أنواع المُعامِلات إذا كان استنباطها من السِّياق مُمكِنًا. على سبيل المثال، إذا كان هناك تعبير لامدا مُعرَّف على أنه من النوع FunctionR2R، فإن مُعامِل التعبير لابُدّ وأن يَكُون من النوع double، ولذلك فإنه، في تلك الحالة، ليس من الضروري تَخْصيص نوع المُعامِل ضِمْن تعبير اللامدا. ثانيًا، يُمكِن حَذْف الأقواس () حول قائمة المُعامِلات (parameter list) إذا كانت مُكوَّنة من مُعامِل وحيد غَيْر مُحدَّد النوع. ثالثًا، يُمكِن حَذْف الأقواس {} الموجودة على الجانب الأيمن من العَامِل ‎->‎ إذا كانت تَحتوِي على تَعْليمَة استدعاء برنامج فرعي (subroutine call) وحيدة. أخيرًا، إذا كان الجانب الأيمن من العَامِل ‎->‎ مكتوبًا بالصيغة { return <expression>;‎ }، فيُمكِن تبسيطها إلى التعبير وحَذْف أي شيء آخر.

بفَرْض أننا نريد كتابة دالة لحِسَاب مربع القيم من النوع double، فإن نوع تلك الدالة هو من نفس نوع واجهة نوع الدالة FunctionR2R المُعرَّفة بالأعلى. الآن، إذا كان sqr مُتَغيِّرًا من النوع FunctionR2R، فإننا نستطيع أن نُسنِد تعبير لامدا (lambda expression) كقيمة لذلك المُتَغيِّر، ويُعدّ عندها ذلك التعبير تمثيلًا للدالة المطلوبة. يُمكِن القيام بذلك بأي من الصِيَغ التالية:

sqr = (double x) -> { return x*x; };
sqr = (x) -> { return x*x; };
sqr = x -> { return x*x; };
sqr = x -> x*x;
sqr = (double fred) -> fred*fred;
sqr = (z) -> z*z;

تُعرِّف تعبيرات لامدا (lambda expressions) الستة بالأعلى نفس الدالة بالضبط، وأُضيفت آخر تَعْليمَتين (statements) خصيصًا؛ للتأكيد على أن أسماء المُعامِلات غير مهمة، فهى بالنهاية مجرد مُعامِلات وهمية أو صُّوريّة (dummy parameters). لمّا كان المُصرِّف (compiler) على علم بكون المُتَغيِّر sqr من النوع FunctionR2R، ولأن النوع FunctionR2R يتطلَّب مُعامِلًا من النوع double، فقد تَمَكَّنا من حَذْف نوع المُعامِل double. يُمكِن اِستخدَام تعبيرات لامدا فقط ضِمْن السِّياقات التي يستطيع فيها المُصرِّف (compiler) استنباط نوعها، ولذلك لابُدّ من كتابة نوع المُعامِل إذا كان حَذْفه سيَتسبَّب بغموض نوع التعبير.

لا يُعدّ المُتَغيِّر sqr -كما هو مُعرَّف بالأعلى- دالة (function) تمامًا، وإنما هو قيمة من النوع FunctionR2R، وبحسب ما هو مُخصَّص بتعريف الواجهة (interface definition)‏ FunctionR2R، فإن ذلك المُتَغيِّر لابُدّ وأن يَحتوِي على دالة تَحمِل اسم valueAt. يمكن استدعاء تلك الدالة من خلال اسمها الكامل sqr.valueAt، فمثلًا يُمكِن كتابة sqr.valueAt(42)‎ أو sqr.valueAt(x) + sqr.valueAt(y)‎.

إذا كانت قائمة مُعامِلات تعبير لامدا مُكوَّنة من أكثر من مُعامِل واحد، فإن الأقواس () المُحيطة بقائمة المُعامِلات (parameters list) لم تَعُدْ اختيارية. اُنظر المثال التالي، والذي يَستخدِم واجهة نوع الدالة ArrayProcessor، كما يُبيِّن طريقة كتابة تعبير لامدا عندما يكون تعريفها مُتعدِّد الأسطر (multiline definition):

ArrayProcessor concat;
concat = (A,n) -> { // الأقواس هنا مطلوبة
    String str;
    str = "";
    for (int i = 0; i < n; i++)
        str += A[i];
    System.out.println(str);
};  // الفاصلة المنقوطة هنا ليست جزءًا من تعبير لامدا
    // وإنما تشير إلى انتهاء تعليمة الإسناد

String[] nums;
nums = new String[4];
nums[0] = "One";
nums[1] = "Two";
nums[2] = "Three";
nums[3] = "Four";
for (int i = 1; i < nums.length; i++) {
   concat.process( nums, i );
}

مما سينتج عنه الخَرْج التالي:

One
OneTwo
OneTwoThree
OneTwoThreeFour

تُصبِح الأمور أكثر تشويقًا عند تمرير تعبير لامدا كمُعامِل فعليّ (actual parameter)، وهو في الواقع الاِستخدَام الأكثر شيوعًا لتعبيرات لامدا. افترض أن لدينا الدالة التالية مثلًا:

/** 
 * احسب قيمة التعبير‫ f(start) + f(start+1) + ... + f(end)
 * حيث‫ f عبارة عن دالة تُستقبل كمعامل
 * ‫قيمة المعامل end لابد أن تكون أكبر من أو تساوي start
 */
static double sum( FunctionR2R f, int start, int end ) {
    double total = 0;
    for (int n = start; n <= end; n++) {
        total = total + f.valueAt( n );
    }
    return total;
}

لمّا كانت f من النوع FunctionR2R، فإن قيمة f عند n تُكتَب على الصورة f.valueAt(n)‎. يُمكِن تمرير تعبير لامدا (lambda expression) كقيمة للمُعامِل الأول عند استدعاء الدالة sum، كالتالي:

System.out.print("The sum of n squared for n from 1 to 100 is ");
System.out.println( sum( x -> x*x, 1, 100 ) );
System.out.print("The sum of 2 raised to the power n, for n from 1 to 10 is ");
System.out.println( sum( num -> Math.pow(2,num), 1, 10 ) );

كمثال آخر، افترض أن لدينا برنامجًا فرعيًا (subroutine) ينبغي أن يُنفِّذ مُهِمّة (task) مُعطاة عدة مرات، يُمكِننا ببساطة تمرير تلك المُهِمّة كمُعامِل من النوع Runnable، كالتالي:

static void doSeveralTimes( Runnable task, int repCount ) {
    for (int i = 0; i < repCount; i++) {
        task.run();  // نفذ المهمة
    }
}

نستطيع الآن طباعة السِلسِلة النصية "Hello World" عشر مرات باستدعاء التالي:

doSeveralTimes( () -> System.out.println("Hello World"), 10 );

تَتَكوَّن قائمة مُعامِلات (parameter list) تعبيرات لامدا من النوع Runnable من زوج فارغ من الأقواس ()؛ وذلك لتتماشى مع البرنامج الفرعي المُصرَّح عنه ضِمْن واجهة نوع الدالة Runnable.

اُنظر المثال التالي:

doSeveralTimes( () -> { 
    int count = 5 + (int)(21*Math.random()); 
    for (int i = 1; i <= count; i++) { 
        System.out.print(i + " ");
    }
    System.out.println();
}, 100);

على الرغم من أن الشيفرة بالأعلى قد تبدو معقدة نوعًا ما، إلا أنها، في الواقع، مُكوَّنة من تَعْليمَة وحيدة هي تَعْليمَة استدعاء البرنامج الفرعي doSeveralTimes. يَتَكوَّن مُعامِل البرنامج الفرعي الأول من تعبير لامدا (lambda expression) قد امتد تعريفه إلى عدة أسطر، أما مُعامِله الثاني فهو القيمة ١٠٠، وتُنهِي الفاصلة المنقوطة (semicolon) بنهاية آخر سطر تَعْليمَة استدعاء البرنامج الفرعي (subroutine call).

اطلعنا على عدة أمثلة تُسنَد فيها تعبيرات لامدا (lambda expression) إلى مُتَغيِّرات، وآخرى تُمرَّر فيها تعبيرات لامدا كمُعامِلات فعليّة (actual parameter). تَبَقَّى الآن أن نراها مُستخدَمة كقيمة مُعادة (return value) من دالة. اُنظر المثال التالي:

static FunctionR2R makePowerFunction( int n ) {
   return x -> Math.pow(x,n);
}

وبالتالي، ستُعيد makePowerFunction(2)‎ قيمة من النوع FunctionR2R تَحسِب مربع قيمة المُعامِل المُمرَّر، بينما ستُعيد makePowerFunction(10)‎ قيمة من النوع FunctionR2R تَحسِب قيمة المُعامِل المُمرَّر مرفوعًا للأس ١٠. يُوضِح هذا المثال أيضًا أن تعبيرات لامدا (lambda expression) تستطيع اِستخدَام مُتَغيِّرات آخرى إلى جانب مُعامِلاتها، مثل n في المثال بالأعلى. (في الواقع هناك بعض القيود لتَحْدِيد متى يُمكِن القيام بذلك).

مراجع التوابع (Method References)

لنفْترِض أننا نريد كتابة تعبير لامدا (lambda expression) من النوع FunctionR2R، بحيث يُمثِل دالة تَحسِب الجذر التربيعي. نستطيع كتابته على الصورة x -> Math.sqrt(x)‎، ولكننا إذا دققنا النظر، سنَجِدْ أن تعبير لامدا، في تلك الحالة تحديدًا، ليس سوى مجرد مُغلِّف (wrapper) بسيط للدالة Math.sqrt الموجودة بالفعل. ولهذا تُوفِّر الجافا ما يُعرَف باسم مَراجِع التوابع (method reference)؛ لاِستخدَامها في الحالات المشابهة (تَذَكَر أن "التابع [method]" هو مجرد كلمة آخرى للإشارة إلى "البرنامج الفرعي [subroutine]" بلغة الجافا). نستطيع مثلًا اِستخدَام المَرجِع التابعي Math::sqrt، والذي يُعدّ اختصارًا لتعبير اللامدا المذكور سلفًا، أينما أَمْكَن اِستخدَام تعبير اللامدا المناظر، كتمريره مثلًا كمُعامِل للدالة sum المُعرَّفة بالأعلى، كالتالي:

System.out.print("The sum of the square root of n for n from 1 to 100 is ");
System.out.println( sum( Math::sqrt, 1, 100 ) );

فقط لو أَمْكَننا اِستخدَام الاسم Math.sqrt هنا بدلًا من الاستعانة بترميز (notation) جديد ::! في الواقع، الترميز Math.sqrt مُعرَّف بالفعل ضِمْن الصَنْف Math لكن للإشارة إلى مُتَغيِّر اسمه sqrt. يُمكِن عمومًا اِستخدَام مَراجِع التوابع (method reference) بدلًا من تعبيرات لامدا (lambda expression) التي يَقْتصِر دورها على اِستدعاء أحد التوابع الساكنة (static method) الموجودة مُسْبَّقًا. تُكتَب مَراجِع التوابع على الصورة التالية:

<classname>::<method-name>

لا يَقْتصِر هذا الترميز (notation) على التوابع الساكنة، أي تلك المُنتمية للأصناف (classes)، وإنما يَمْتَدّ إلى تلكم المُنتمية للكائنات (objects) كذلك. على سبيل المثال، إذا كان str متغير من النوع String، فإن str بطبيعة الحال سيَحتوِي على التابع str.length()‎، وفي هذه الحالة، يُمكِن اِستخدَام المَرجِع التابعي str::length كتعبير لامدا من واجهة نوع الدالة SupplyInt المُعرَّفة كالتالي:

public interface SupplyInt {
    int get( );
}

ترجمة -بتصرّف- للقسم Section 5: Lambda Expressions من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

يُطلَق على البرامج الفرعية (subroutine) التي تُعيد قيمة اسم "الدوال (function)"، والتي يُمكِنها أن تُعيد قيمة من نوع واحد مُحدَّد ضِمْن التعريف ويُسمى النوع المُعاد (return type) من الدالة. بإِمكَانك استدعاء الدوال (function call) في العموم بأيّ مكان يَتوقَّع فيه الحاسوب قيمة (value)، مثل الجانب الأيمن من تَعْليمَات الإِسْناد (assignment statement)، أو كمُعامِل فعليّ (actual parameter) بتَعْليمَات استدعاء البرامج الفرعية، أو كجُزء من تعبير (expression) أكبر. يُمكِن حتى اِستخدَام الدوال من النوع boolean، أي التي تُعيد قيمة من ذلك النوع، مَحل الشَّرْط (condition) ضِمْن تَعْليمَات مثل if و while و for و do..while.

يُمكِن أيضًا اِستخدَام تَعْليمَة استدعاء دالة (function call)، كما لو كانت برنامجًا فرعيًا، أيّ كما لو أنها لا تُعيد قيمة. في تلك الحالة، يَتجاهَل الحاسوب القيمة المُعادة من البرنامج الفرعي، وهو ما يَكُون منطقيًا في بعض الأحيان. على سبيل المثال، تَقرأ الدالة TextIO.getln()‎ سَطْرًا مُدْخَلًا مِنْ قِبَل المُستخدِم وتُعيده كقيمة من النوع String. عادة، يُسنَد السَطْر المُعاد من تلك الدالة إلى مُتَغيِّر؛ لكي يُستخدَم لاحقًا، كما في التَعْليمَة name = TextIO.getln();‎. لكن، يُمكِن اِستخدَام تلك الدالة ضِمْن تَعْليمَة استدعاء برنامج فرعي على الصورة TextIO.getln();‎، والتي، كالعادة، ستَستمِر بقراءة مُدْخَلات المُستخدِم إلى أن تَصِل إلى محرف العودة إلى بداية السطر (carriage return). لمّا لم تُسنَد القيمة المُعادة من تلك الدالة إلى مُتَغيِّر، أو تُستخدَم ضِمْن تعبير (expression)، فإنها تُستبعَد ببساطة، لذا يَكُون تأثير استدعاء البرنامج الفرعي في تلك الحالة هو مجرد قراءة بعض المُدْخَلات واِستبعَادها، وهو الشيء الذي قد تَرغَب به في بعض الأحيان.

تعليمة return

بوصولك إلى هنا، فأنت قد تَعلَّمت طريقة استدعاء الدوال (functions) -التي تُعيد قيم فعليّة- مثل Math.sqrt()‎ و TextIO.getInt()‎، لكنك لَمْ تَكتُب أيّ دالة خاصة بك بَعْد. في الواقع، ستبدو كتابة الدوال أمرًا مألوفًا بالنسبة لك؛ فهي بالنهاية مُشابهة تمامًا لصيغة كتابة أيّ برنامج فرعي (subroutine) عادي باستثناء ضرورة اِستخدَام التَعْليمَة return؛ لتَخْصِيص القيمة التي سيُعيدها البرنامج الفرعي (return value). تُكتَب تَعْليمَة return بالصيغة (syntax) التالية:

return <expression>;

يُمكِن اِستخدَام تَعْليمَة return بالأعلى داخل تعريف الدوال فقط (function definition)، ولابُدّ لنوع التعبير المَكْتُوب بَعْد التَعْليمَة أن يَتماشى مع النوع المُعاد (return type) المُخصَّص ضِمْن تعريف الدالة، أيّ لابُدّ أن يؤول ذلك التعبير إلى قيمة هي من نوع يُمكِن إِسْناده -بواسطة تَعْليمَة إِسْناد (assignment)- إلى النوع المُعاد (return type) من الدالة والمُخصَّص بتعريفها (definition).

عندما يُنفِّذ الحاسوب تَعْليمَة return، فإنه يَحسِب قيمة التعبير المُخصَّص، ثم يُنهِي تَّنْفيذ الدالة، وأخيرًا، يُعيد قيمة التعبير لتُصبِح القيمة المُعادة (return value) من الدالة. اُنظر تعريف الدالة التالي على سبيل المثال:

static double pythagoras(double x, double y) {
    return  Math.sqrt( x*x + y*y );
}

بفَرْض تَّنْفيذ الحاسوب لتَعْليمَة إِسْناد تَتضمَّن تَعْليمَة استدعاء الدالة بالأعلى، مثل totalLength = 17 + pythagoras(12,5);‎، فإنه سيُحاوِل تَحْصِيل قيمة تَعْليمَة الاستدعاء pythagoras(12,5)‎، لذلك سيبدأ بإِسْناد قيم المُعامِلات الفعليّة (actual parameters) ‏المُمرَّرة، أيّ ١٢ و ٥، إلى المُعامِلات الصُّوريّة (formal parameters)‏ x و y بتعريف الدالة، ثم سينتقل إلى تَّنْفيذ مَتْن الدالة (function body)، وبالتالي سيضطرّ إلى تَحْصِيل قيمة التعبير Math.sqrt(12.0*12.0 + 5.0*5.0)‎ والتي تؤول إلى القيمة 13.0، ثم سيُعيد هذه القيمة لتَكُون القيمة المُعادة (return value) من الدالة، وعليه تُستبدَل القيمة 13.0 بتَعْليمَة استدعاء الدالة، فتصبح تَعْليمَة الإِسْناد وكأنها مَكْتُوبة على الصورة totalLength = 17+13.0. أخيرًا، تُضاف القيمة المُعادة (return value) إلى العدد 17 ثم تُخْزَن النتيجة 30.0 بالمُتَغيِّر totalLength.

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

كما ذَكَرَنا مُسْبَّقًا، لابُدّ دائمًا من كتابة تَعْليمَة return مَتبوعة بتعبير (expression) ضِمْن تعريف أي دالة (function)؛ لأن الدوال دائمًا ما تُعيد قيمة. في المقابل، لا يُعدّ ذلك ضروريًا مع البرامج الفرعية من غير الدوال (non-function)، أي تلك التي تَستخدِم void ضِمْن تعريفها للتَّصْريح عن نوعها المُعاد، فهي في النهاية لا تُعيد قيمة، ومع ذلك يَظِلّ اِستخدَام تَعْليمَة return ضِمْن هذا السِّياق مُمكنًا، بحيث يَقْتصِر دورها على إنهاء تَّنْفيذ البرنامج الفرعي بمكان ما وسط المَتْن وإعادة التَحكُّم (return control) مرة آخرى إلى سَطْر الشيفرة المسئول عن استدعاء البرنامج الفرعي. تُكتَب تَعْليمَة return في تلك الحالة على الصورة return;‎ بدون تعبير (expression).

بالإضافة إلى ما سبق، قد تُستخدَم تَعْليمَة return أيضًا داخل حَلْقة تَكْرار (loop) لإنهاء كُلًا من الحَلْقة (loop) والبرنامج الفرعي الحاضن لها. بالمثل، قد تُستخدَم بتَعْليمَة switch، للخروج من كُلًا من تَعْليمَة switch والبرنامج الفرعي الحاضن لها، أيّ ستَجِدْ أحيانًا تَعْليمَة return مُستخدَمة ضِمْن سِّياقات اعْتَدْت فيها استخدام تَعْليمَة break.

أمثلة على الدوال (functions)

تَعرَّضنا لمسألة حِسَاب قيم عناصر مُتتالية الأعداد"3N+1" عدة مرات بما في ذلك القسم السابق. يُمكِننا تعريف دالة (function) بسيطة جدًا، تَستقبِل قيمة العنصر الحالي بالمُتتالية، ثم تُعيد قيمة عنصر المتتالية التالي. اُنظر الشيفرة التالية:

static int nextN(int currentN) {
   if (currentN % 2 == 1)     // ‫إذا كان currentN فرديًا
      return 3*currentN + 1;  // أعد تلك القيمة
   else
      return currentN / 2;    // إذا لم يكن، أعد تلك القيمة
}

نُلاحِظ أن تعريف الدالة بالأعلى يَتضمَّن تَعْليمَتي return. ستُنفَّذ دائمًا تَعْليمَة return واحدة فقط بِغَضّ النظر عن عدد تلك التَعْليمَات المُستخدَمة ضِمْن التعريف. يُفضِّل بعض المبرمجين كتابة تَعْليمَة return وحيدة بنهاية الدالة، ويحاولوا القيام بذلك قدر الإمكان؛ خاصة وأن ذلك يُسهِل من العثور على تَعْليمَة return ضِمْن التعريف. فمثلًا، يُمكِننا إعادة كتابة الدالة nextN()‎ -المُعرَّفة بالأعلى- مرة آخرى على النحو التالي:

static int nextN(int currentN) {
    int answer;  // متغير يحمل القيمة المعادة من الدالة
    if (currentN % 2 == 1)    // ‫إذا كان currentN فرديًا
        answer = 3*currentN+1; // أسند القيمة إلى المتغير
    else
        answer = currentN / 2; // إذا لم يكن، أسند القيمة إلى المتغير
    return answer;   // لا تنسى أن تعيد المتغير
}

دَعْنَا الآن نَكتُب برنامجًا فرعيًا (subroutine) لحِسَاب قيم عناصر المُتتالية، لكن بالاعتماد على الدالة nextN هذه المرة. نظرًا لكَوْن الدالة nextN قصيرة نوعًا ما، فإن التَحْسِينات المُجراة على البرنامج الفرعي ليست ذا شأن بالموازنة مع نسخة البرنامج بالقسم ٤.٣. في المقابل، إذا كانت الدالة nextN()‎ طويلة لكَوْنها مثلًا تَحسِب عملية معقدة، فعندها سيَكُون من المنطقي إخفاء ذلك التعقيد بداخل دالة منفصلة:

static void print3NSequence(int startingValue) {

   int N;       // أحد عناصر المتتالية
   int count;   // عدد عناصر المتتالية

   N = startingValue;   // أول قيمة بالمتتالية
   count = 1;

   System.out.println("The 3N+1 sequence starting from " + N);
   System.out.println();
   System.out.println(N);  

   while (N > 1) {
       // ‫احسب قيمة عنصر المتتالية التالي باستدعاء الدالة nextN
       N = nextN( N );   
       count++;          // أزد عدد عناصر المتتالية بمقدار الواحد
       System.out.println(N);  // اطبع قيمة العنصر
   }

   System.out.println();
   System.out.println("There were " + count + " terms in the sequence.");

}

اُنظر المثال التالي للدالة letterGrade، والتي تَستقبِل درجة عددية (numerical grade)، وتُحوِّلها إلى نظيرتها المحرفية (letter grade) بالاستعانة بمقياس درجات (grading scale) تقليدي:

/**
 * أعد الدرجة المحرفية المناظرة للدرجة العددية الممررة للدالة كمعامل
 */
static char letterGrade(int numGrade) {
    if (numGrade >= 90)
        return 'A';   // 90 or above gets an A
    else if (numGrade >= 80)
        return 'B';   // 80 to 89 gets a B
    else if (numGrade >= 65)
        return 'C';   // 65 to 79 gets a C
    else if (numGrade >= 50)
        return 'D';   // 50 to 64 gets a D
    else
        return 'F';   

}  // ‫نهاية الدالة letterGrade

تستطيع الدوال أن تُعيد قيم من أي نوع، فمثلًا، نوع القيمة المُعادة (return type) من الدالة letterGrade()‎ -بالأعلى- هو النوع char، أما الدالة المُعرَّفة بالمثال التالي، فإنها تُعيد قيمة (return value) من النوع boolean. اُنظر الشيفرة التالية، واحْرِصْ على قراءة التعليقات (comments)؛ لأنها تُوضِح بعض النقاط المثيرة للاهتمام:

/**
 * تعيد هذه الدالة القيمة المنطقية‫ true إذا كان N عدد أولي.
 * ‫العدد الأولي هو عدد صحيح أكبر من العدد 1 
 * بشرط ألا يكون قابلًا للقسمة ‫إلا على  نفسه وعلى الواحد. 
 * Nإذا كان لدى‫ N أي قاسم D يتراوح بين الواحد والعدد  
 * ‫فسيكون لديه قاسم يتراوح بين العدد 2 والجذر التربيعي للعدد N 
 * ‫لذلك سوف نختبر قيم القواسم المحتملة بداية من العدد 2 
 * ‫وحتى الجذر التربيعي للعدد N
 */
static boolean isPrime(int N) {

    int divisor;  // عدد يحتمل أن يكون قاسما للعدد 

    if (N <= 1)
        return false;  // العدد الأولي لابد أن يكون أكبر من الواحد

    int maxToTry;  // أكبر قيمة قاسم محتمل ينبغي اختبارها

    // ‫ينبغي إجراء عملية التحويل بين الأنواع لأن Math.sqrt 
    // ‫تعيد قيمة من النوع double
    maxToTry = (int)Math.sqrt(N);

    // ‫سنحاول قسمة‫ N على الأعداد من 2 ووصولا الى قيمة maxToTry
    // إذا لم يكن‫ N قابل للقسمة على أي عدد من تلك الأعداد
    // ‫سيكون N عددا اوليا
    for (divisor = 2; divisor <= maxToTry; divisor++) {
        if ( N % divisor == 0 )  // ‫إذا تمكن divisor من تقسم N
            return false;         // ‫إذًا N لا يمكن أن يكون عددًا أوليًا
            // لا حاجة للاستمرار
    }

    // ‫إذا وصلنا إلى هنا، فإن N حتما هو عدد أولي
    // ‫لأنه إذا لم يكن أوليًا، ستكون الدالة بالفعل قد انتهت
    // ‫باستخدام تعليمة return الموجودة بالحلقة السابقة

    return true;  // ‫نعم N هو عدد أولي

}  // ‫نهاية الدالة isPrime

نَسْتَعْرِض بالشيفرة التالية دالة آخرى، والتي تَستقبِل مُعامِل (parameter) من النوع String، وتُعيد قيمة (return value) من نفس النوع String. تَعْكِس تلك الدالة ترتيب محارف السِلسِلة النصية المُمرَّرة، وتُعيد نسخة مَعْكوسة منها، فمثلًا، النسخة المَعْكوسة من السِلسِلة النصية "Hello World" هي "dlroW olleH". يُمكِن توصيف الخوارزمية (algorithm) المطلوبة لعَكْسَ سِلسِلة نصية str على النحو التالي: ابدأ بسِلسِلة نصية فارغة (empty string)، ثم أَضِف إلى نهايتها كل محرف (character) موجود بالسِلسِلة النصية str، بحيث تبدأ بالمحرف الأخير من السِلسِلة str، وتعود للوراء حتى تَصِل إلى المحرف الأول. اُنظر الشيفرة التالية:

static String reverse(String str) {
    String copy;  // النسخة المعكوسة
    // الموضع الحالي من السلسلة النصية الممرة
    // يأخذ القيم بداية من طول السلسلة وحتى صفر
    int i;        
    copy = "";    // ابدأ بسلسلة نصية فارغة
    for ( i = str.length() - 1;  i >= 0;  i-- ) {
        // أضف المحرف الحالي إلي نهاية النسخة المعكوسة
        copy = copy + str.charAt(i);  
    }
    return copy;
}

لاحِظ أن بعض السَلاسِل النصية لا تتغَيَّر سواء قُرأت طردًا (forwards) أو عكسًا (backwards)، أي سواء قرأت من اليسار إلى اليمين أو العَكْس. يُعرَف ذلك باسم السِّياق المُتَناظِر أو القلب المستو (palindrome)، والذي يُمكِنك اختبار حُدُوثه على سِلسِلة نصية معينة word بالاستعانة بالدالة المُعرَّفة بالأعلى وباِستخدَام الاختبار if (word.equals(reverse(word)))‎ تحديدًا.

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

مسألة متتالية "3N+1"

سنُحاوِل بالمثال الأخير من هذا القسم اِستخدَام الدالة nextN()‎ التي عَرَفناها بالأعلى لتَعْديل البرنامج المسئول عن حِسَاب قيم عناصر المتتالية "3N+1". أُضيفَت بعض التَعْديلات الآخرى أيضًا، مثل طباعة قيم عناصر المتتالية بأعمدة، بحيث يَحتوِي كل سَطْر على ٥ عناصر فقط، مما سيُحسِن من هيئة الخَرْج الناتج عن البرنامج. تستطيع القيام بذلك ببساطة عن طريق الاحتفاظ بعدد العناصر المَطبوعة بالسَطْر الحالي، وبدء سَطْر خَرْج جديد عند وصول قيمة ذلك العدد إلى القيمة ٥. نُسِق الخَرْج بحيث تُصطَفَّ العناصر بأعمدة مُرتَّبة:

input textio.TextIO;

/** 
 * برنامج يحسب قيم عناصر المتتالية ‫3N+1 ويطبعها. تُحدد قيمة 
 * أول عنصر بالمتتالية من قبل المستخدم، ثم تُطبع القيم بأعمدة 
 * ‫بحيث يحتوي كل سطر على 5 عناصر فقط.
 * كما تطبع عدد عناصر المتتالية بالنهاية
 */
public class ThreeN2 {


    public static void main(String[] args) {

        System.out.println("This program will print out 3N+1 sequences");
        System.out.println("for starting values that you specify.");
        System.out.println();

        int K;   // اقرأ مدخل المستخدم
        do {
            System.out.println("Enter a starting value;");
            System.out.print("To end the program, enter 0: ");
            K = TextIO.getlnInt();  // اقرأ قيمة أول عنصر بالمتتالية
            if (K > 0)              
                print3NSequence(K);
        // ‫اعد تكرار الحلقة إذا كان k أكبر من الصفر
        } while (K > 0);           

    } // ‫نهاية main


    /**
    * يطبع‫ print3NSequence قيم المتتالية 3N+1 إلى الخرج القياسي، 
    * بحيث يكون أول عنصر بالمتتالية هو قيمة المعامل الممررة
    * كما يطبع أيضًا عدد عناصر المتتالية
    * ‫قيمة المعامل startingValue الممررة ينبغي أن تكون عددًا صحيحا موجبا
    */
    static void print3NSequence(int startingValue) {

        int N;       // أحد عناصر المتتالية
        int count;   // عدد العناصر حتى الآن
        int onLine;  // عدد العناصر المطبوعة بالسطر الحالي

        N = startingValue;   // ابدأ المتتالية بقيمة المعامل الممررة
        count = 1;           // لدينا عنصر واحد بالمتتالية

        System.out.println("The 3N+1 sequence starting from " + N);
        System.out.println();
        System.out.printf("%8d", N); 
        onLine = 1;        // هناك عدد مطبوع بالسطر الآن

        while (N > 1) {
            N = nextN(N);  // احسب قيمة العنصر التالي
            count++;   // أزد عناصر المتتالية بمقدار الواحد
            if (onLine == 5) {  
                System.out.println();  // اطبع محرف العودة الى بداية السطر
                onLine = 0;      // أعد ضبط عدد العناصر المطبوعة بالسطر
            }
            System.out.printf("%8d", N);  // اطبع قيمة العنصر الحالي
            onLine++;   // أزد قيمة عدد العنصر بالسطر بمقدار الواحد
        }

        System.out.println();  // انهي السطر الحالي من الخرج
        System.out.println();  // اطبع سطر فارغ
        System.out.println("There were " + count + " terms in the sequence.");

    }  // نهاية print3NSequence


    /**
    * ‫تحسب الدالة nextN قيمة عنصر المتتالية التالي وتعيده
    * ‫بحيث تستقبل قيمة عنصر المتتالية الحالي كمعامل currentN
    */
    static int nextN(int currentN) {
        if (currentN % 2 == 1)
            return 3 * currentN + 1;
        else
            return currentN / 2;
    }  // ‫نهاية الدالة nextN


} // ‫نهاية الصنف ThreeN2

ينبغي أن تَقْرأ هذا البرنامج بتأنِّي وأن تُحاوِل اِستيعاب طريقة عَمَله.

ترجمة -بتصرّف- للقسم Section 4: Return Values من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

إذا كان البرنامج الفرعي (subroutine) عبارة عن صندوق أسود، فإن المُعامِلات (parameter) هي ببساطة طريقة لتمرير بعض المعلومات إليه من العالم الخارجي، لذا فإنها تُعدّ جزءًا من واجهة (interface) البرنامج الفرعي، وتَسمَح لك بتَخْصيص طريقة عمل البرنامج الفرعي للتَكيُف مع موقف محدد.

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

استخدام المعاملات

سنتَطَرَّق مجددًا لمسألة متتالية الأعداد "3N+1"، والتي قد تَعرَّضنا لها بالقسم الفرعي ٣.٢.٢. تُحسَّب قيم مُتتالية الأعداد "3N+1" وفقًا للقاعدة التالية:

"إذا كان N عَدَدًا فرديًا، اِحسب حاصل ضربه في العَدَد ٣، ثُمَّ أَزِد قيمة حاصل الضرب بمقدار ١، أمَا إذا كان زوجيًا، اِحسب حاصل قِسمته على العَدَد ٢، بحيث تستمر بحِسَاب قيم عناصر مُتتالية الأعداد بنفس الطريقة حتى تُصبِح قيمة N مُساوِية للعَدَد ١. على سبيل المثال، إذا كانت قيمة N المبدئية تُساوِي ٣، سنَحصُل على مُتتالية الأعداد التالية: ٣، ١٠، ٥، ١٦، ٨، ٤، ٢، ١."

اُكْتُب برنامجًا فرعيًا (subroutine) يَطبَع قيم مُتتالية الأعداد تلك. لاحِظ أن دور البرنامج هو طباعة متتالية الأعداد "3N+1" في العموم، أي أن القيم ذاتها التي سيَطبَعها لابُدّ وأن تعتمد على قيمة N المبدئية، ولهذا سنُمرِّر تلك القيمة كمُعامِل (parameter) للبرنامج الفرعي. يُمكِن كتابة البرنامج الفرعي كالتالي:

static void print3NSequence(int startingValue) {

    int N;      // أحد قيم عناصر المتتالية
    int count;  // عدد عناصر المتتالية

    N = startingValue;  // أول عنصر هو القيمة الممررة

    count = 1; // لدينا قيمة واحدة هي القيمة الممررة

    System.out.println("The 3N+1 sequence starting from " + N);
    System.out.println();
    System.out.println(N);  

    while (N > 1) {
        // ‫إذا كان N عدد فردي
        if (N % 2 == 1)     
            N = 3 * N + 1;
        else
            N = N / 2;
        count++;   // أزد عدد عناصر المتتالية بمقدار الواحد
        System.out.println(N);  // اطبع العنصر
    }

    System.out.println();
    System.out.println("There were " + count + " terms in the sequence.");

}  // ‫نهاية print3NSequence

تَتكوَّن قائمة المعاملات (parameter list) -بتعريف البرنامج الفرعي بالأعلى- من المُعامِل int startingValue، مما يَعنِي أن ذلك البرنامج الفرعي سيَستقبِل مُعامِلًا (parameter) وحيدًا من النوع العَدَدَي الصحيح int، وسيَتَمكَّنْ من اِستخدَام اسم ذلك المُعامِل بداخل المَتْن، بنفس الطريقة التي يَستخدِم بها اسم أيّ مُتَغيِّر آخر. لاحِظ أننا لم نُسنِد أي قيمة للمُعامِل أثناء عملية التعريف ذاتها، فهو يَحصُل على قيمته المبدئية من مصدر خارجي أثناء عملية الاستدعاء، لذا لابُدّ للمُستدعِي أن يُمرِّر قيمة معينة لذلك المُعامِل ضِمْن تَعْليمَة الاستدعاء (subroutine call statement)، وعندها فقط ستُسنَد إلى startingValue قبل تَّنْفيذ المَتْن. مثلًا، عندما يُنفِّذ الحاسوب تَعْليمَة استدعاء البرنامج الفرعي print3NSequence(17);‎، فإنه يُسنِد أولًا القيمة ١٧ إلى startingValue، ثم يُنفِّذ بَعْدها التَعْليمَات الموجودة بمَتْن ذلك البرنامج، والتي تَطبَع قيم مُتتالية الأعداد "3N+1" بداية من العدد ١٧. وبصورة أعم، إذا كان K مُتَغيِّرًا من النوع العَدََدَي الصحيح int، يُمكِن اِستخدَام التَعْليمَة print3NSequence(K);‎ بهدف اِستدعاء البرنامج الفرعي، مما سيؤدي إلى إِسْناد قيمة المُتَغيِّر K إلى startingValue، ومِنْ ثَمَّ تَّنْفيذ مَتْن البرنامج الفرعي.

يُمكِن اِستدعاء البرنامج الفرعي print3NSequence بواسطة أيّ برنامج فرعي -البرنامج main()‎ أو غيره- مُعرَّف ضِمْن نفس الصَنْف المُتَضمِّن لتعريف البرنامج الفرعي print3NSequence. فمثلًا، يَطبَع البرنامج main()‎ -بالمثال التالي- قيم عناصر المُتتالية "3N+1" أكثر من مرة وبقيم مبدئية مختلفة، والتي تُخصَّص من قِبَل المُستخدِم:

public static void main(String[] args) {
    System.out.println("This program will print out 3N+1 sequences");
    System.out.println("for starting values that you specify.");
    System.out.println();
    int K;  // اقرأ مدخل المستخدم
    do {
        System.out.println("Enter a starting value.");
        System.out.print("To end the program, enter 0: ");
        K = TextIO.getInt();  // اقرأ عنصر المتتالية الأول من المستخدم
        if (K > 0)   // اطبع المتتالية
            print3NSequence(K);
    } while (K > 0);   // ‫إستمر إذا كانت قيمة k أكبر من الصفر
} // نهاية main

تنبيه: لابُدّ أن يُعرَّف كُلًا من البرنامجين main و print3NSequence ضِمْن نفس الصَنْف؛ كي تتمكَّن من تَشْغِيل البرنامج بالأعلى.

المعاملات الصورية (formal) والفعلية (actual)

في الواقع، تُستخدَم كلمة "مُعامِل (parameter)" للإشارة إلى مفهومين، مُرتبطين نوعًا ما، لكنهما بالنهاية مختلفان. أولهما هو ذلك الذي نُشير إليه ضِمْن تعريفات البرامج الفرعية (definitions of subroutines)، مثل startingValue بالأعلى. والآخر هو ما نُشير إليه ضِمْن تَعْليمَات استدعاء البرامج الفرعية (subroutine call statements)، بحيث يُمرَّر إليها، مثل K بالتَعْليمَة print3NSequence(K);‎. يُطلَق على "المُعامِلات" من النوع الأول اسم المُعامِلات الصُّوريّة (formal parameters) أو المُعامِلات الوهمية (dummy parameters)، بينما يُطلَق على "المُعامِلات" من النوع الثاني اسم المُعامِلات الفعليّة (actual parameters) أو الوُسَطاء (arguments). عندما تَستدعِي برنامجًا فرعيًا، يُحصِّل الحاسوب قيم المُعامِلات الفعليّة بتَعْليمَة الاستدعاء، ثم يُسنِد تلك القيم إلى المُعامِلات الصُّوريّة المُصرَّح عنها بتعريف ذلك البرنامج الفرعي، وأخيرًا، يُنفِّذ مَتْن البرنامج الفرعي.

المُعامِل الصُّوريّ (formal parameter) عبارة عن "اسم"، أو بتعبير آخر، مُعرِّف بسيط (simple identifier)، فهو في الواقع أشبه ما يَكُون بالمُتَغيِّر، وكأي مُتَغيِّر، لابُدّ أن يكون له نوع مثل int أو boolean أو String أو double[]‎. في المقابل، المُعامِل الفعلي (actual parameter) هو مجرد "قيمة" يُفْترَض اِسْنادها لمُتَغيِّر المُعامِل الصُّوريّ المُناظِر عند الاستدعاء الفعليّ للبرنامج الفرعي، لذا يُمكِن اِستخدَام أي تعبير (expression) طالما كان يَؤول إلى قيمة هي من نوع يمكن إِسْناده -بواسطة تَعْليمَة إِسْناد (assignment)- إلى نوع المُعامِل الصُّوريّ المُناظِر. فمثلًا، إذا كان لدينا مُعامِل صُّوريّ من النوع double، ونظرًا لإمكانية إِسْناد قيمة من النوع int إلى المُتَغيِّرات من النوع double، فإن قيمة المُعامِل الفعليّ المُمرَّرة لذلك المُعامِل الصُّوريّ يُمكِن أن تَكُون من النوع int. لاحِظ أنه من الضروري تَمرير مُعامِل فعليّ لكل مُعامِل صُّوريّ أثناء الاستدعاء الفعليّ للبرنامج الفرعي. اُنظر البرنامج الفرعي التالي كمثال:

static void doTask(int N, double x, boolean test) {
    // تعليمات تنفيذ المهمة
}

تستطيع اِستدعاء البرنامج الفرعي بالأعلى باِستخدَام تَعْليمَة الاِستدعاء التالية:

doTask(17, Math.sqrt(z+1), z >= 10);

يُمكِن تَوصِيف ما يُنفِّذه الحاسوب -أثناء تَّنْفيذه لتَعْليمَة الاستدعاء بالأعلى- إلى تَعْليمَة الكُتلة (block statement) التالية:

{
    int N;       // خصص مساحة بالذاكرة للمعاملات الصورية
    double x;
    boolean test;
    // اسند القيمة 17 للمعامل الصوري الأول 
    N = 17;              
    // احسب قيمة التعبير واسندها للمعامل الصوري الثاني
    x = Math.sqrt(z+1);  
    // احسب قيمة التعبير المنطقي واسندها للمعامل الصوري الثالث
    test = (z >= 10);    
    // تعليمات تنفيذ المهمة
}

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

قد تَكُون فكرة اِستخدَام مُعامِل (parameter) لتمرير بعض المعلومات إلى برنامج فرعي (subroutine) معين بديهية نوعًا ما، ولذلك فإن اِستدعاء التوابع الفرعية المُعرَّفة مُسْبَّقًا ليس بمشكلة، وهو ما يَختلِف تمامًا عن كتابة تعريف البرنامج الفرعي ذاته (subroutine definition)، والذي عادة ما يُرْبِك دَارسِي البرمجة المبتدئين، بالأخص ما يتعلق منها بكيفية عَمَل المُعامِلات. في الواقع، يَقع الكثيرون منهم في خطأ إِسْناد قيم إلى المُعامِلات الصُّوريّة (formal parameters) ببداية مَتْن البرنامج الفرعي، وهو ما يُمثِل سوء فهم تام لماهية مُعامِلات البرامج الفرعية؛ فعندما يُنفِّذ الحاسوب تَعْليمَة اِستدعاء برنامج فرعي معين، فإنه يُسنِد قيم المُعامِلات الفعليّة (actual parameters) المُمرَّرة بتَعْليمَة الاستدعاء إلى المُعامِلات الصُّوريّة، وذلك قَبْل البدء بتَّنْفيذ مَتْن البرنامج الفرعي، أيّ أنه حينما يبدأ الحاسوب بتَّنْفيذ ذلك المَتْن، تَكُون المُعامِلات الصُّوريّة قد هُيئت بالفعل بقيمها المبدئية المُمرَّرة، ولذلك لا معنى من بدء المَتْن بإِسْناد قيم إلى تلك المُعامِلات. تَذكَّر أن البرنامج الفرعي ليس مُستقلًا؛ فبالنهاية هو يُستدعَى بواسطة برنامج آخر (routine)، ولذا تَقع مسئولية تَوْفِير قيم مُعامِلاته على تَعْليمَة الاستدعاء، ومِنْ ثَمَّ على ذلك البرنامج المُستدعِي.

التحميل الزائد (overloading)

يَتَطلَّب استدعاء برنامج فرعي معين مَعرِفة بعض المعلومات عنه، والتي يُطلَق عليها اسم "بَصْمَة البرنامج الفرعي (subroutine's signature)". تَتَكوَّن تلك البَصْمَة من كُلًا من اسم البرنامج الفرعي، وعدد المُعامِلات الصُّوريّة (formal parameters) المُعرَّفة ضِمْن قائمة مُعامِلاته، بالإضافة إلى نوعها. على سبيل المثال، يُمكِنك كتابة بَصْمَة البرنامج الفرعي doTask المذكور بالأعلى كالتالي: doTask(int,double,boolean)‎. لاحِظ أن بَصْمَة البرنامج الفرعي لا تَتضمَّن أسماء المُعامِلات، وهو في الواقع أمر يَسهُل تبريره؛ فليس هناك أيّ نَفْع من مَعرِفة أسماء المُعامِلات الصُّوريّة إذا كان كل غرضك هو مجرد اِستخدَام ذلك البرنامج الفرعي، ولذلك لا تُعدّ أسماء المُعامِلات جزءًا من واجهة البرنامج الفرعي (subroutine's interface).

تَسمَح لغة الجافا باِستخدَام نفس الاسم لأكثر من برنامج فرعي داخل نفس الصَنْف، بشَّرْط اختلاف البَصْمَة (signatures) الخاصة بهم، فيما يُعرَف باسم "التحميل الزائد (overloading)" لاسم البرنامج الفرعي؛ حيث أصبح ذلك الاسم يَمتلك عدة معاني مختلفة. لا يَخلِط الحاسوب بين تلك البرامج الفرعية التي تَحمِل نفس الاسم، ويَستطيع تَّمييز أي منها تَرغَب باستدعائه، وذلك بالاعتماد على عدد المُعامِلات الفعليّة المُمرَّرة ضِمْن تَعْليمَة الاستدعاء، وأنواع تلك المُعامِلات. في الواقع، يَستخدِم الكائن (object)‏ System.out التحميل الزائد (overloading)؛ حيث تَتَوفَّر له العديد من التوابع (methods) المختلفة، والتي تَحمِل جميعها الاسم println مع اختلاف بَصْمَاتها (signatures) بالتأكيد. اُنظر على سبيل المثال:

println(int)                   println(double)
println(char)                  println(boolean)
println()

يَعتمِد الحاسوب على نوع المُعامِل الفعليّ (actual parameter) المُمرَّر بتَعْليمَة الاستدعاء لمَعرِفة أي بَصْمَة من تلك البرامج الفرعية ترغب بتَّنْفيذها. فمثلًا، عند اِستخدَام التَعْليمَة System.out.println(17)‎، فإنه يَستدعِي البرنامج الفرعي ذو البَصْمَة println(int)‎، أما في حالة اِستخدَام التَعْليمَة System.out.println('A')‎، فإنه يَستدعِي البرنامج الفرعي ذو البَصْمَة println(char)‎. تُعدّ جميع البرامج الفرعية بالأعلى مرتبطة نوعًا ما من الناحية الدلالية، فجميعها يقوم بالطباعة، وهو ما يُبرِّر تسميتها جميعًا بنفس الاسم، ولكن فيما يتعلق بالحاسوب، فإن طباعة عدد صحيح من النوع int تختلف تمامًا عن طباعة محرف من النوع char، والتي بدورها تختلف عن طباعة قيمة منطقية من النوع boolean، وهو ما يُبرِّر تعريف برنامج فرعي منفصل لكُلًا من تلك العمليات المختلفة.

لا يُعدّ نوع القيمة المُعادة من البرنامج الفرعي (return type) جزءًا من البَصْمَة، ولهذا لا يُسمَح بتعريف برنامجين فرعيين بصَنْف معين إذا كان لهما نفس الاسم والبَصْمَة (signature)، حتى مع اختلاف نوع القيمة المُعادة منهما. فمثلًا، سيُؤدي تعريف البرنامجين الفرعيين التاليين بنفس الصَنْف إلى حُدوث خطأ في بناء الجملة (syntax error):

int    getln() { ... }
double getln() { ... }

وفي الواقع، هذا هو السبب وراء عدم تسمية جميع البرامج الفرعية المُعرَّفة ضِمْن الصَنْف TextIO، والمُستخدَمة لقراءة الأنواع المختلفة، بنفس الاسم getln()‎، وإنما يُستخدَم اسم مختلف لكل نوع مثل getlnInt()‎ و getlnDouble()‎؛ لأن الصَنْف TextIO لا يُمكِن أن يَتَضمَّن أكثر من برنامج فرعي دون مُعامِلات، ويَحمِل نفس الاسم getln.

أمثلة لبرامج فرعية

تَتكوَّن البرمجة باستخدام البرامج الفرعية من شقّين، الأول هو تصميم البرنامج (program design)، أيّ تَقسِّيم مُهِمّة البرنامج (program) إلى مَهَامّ فرعية (subtasks) صغيرة بحيث يُسنَد كل منها إلى برنامج فرعي (subroutine)، أما الشقّ الآخر، فيَتعلَّق بعملية كتابة تعريف تلك البرامج الفرعية الصغيرة، والتي هي مسئولة عن تَّنْفيذ المَهَامّ الفرعية. سنقوم الآن بكتابة عدة أمثلة لبعض من تلك البرامج الفرعية الصغيرة، بينما سنُعود إلى مناقشة موضوع تصميم البرامج (program design) بالقسم ٤.٧.

أول مثال هو كتابة برنامج فرعي يَستقبِل عددًا صحيحًا موجبًا كمُعامِل، ثم يَحسِب جميع قواسم (divisors) هذا العدد، ويَطبَعها. يُكتَب أيّ برنامج فرعي بالصيغة (syntax) التالية:

<modifiers>  <return-type>  <subroutine-name>  ( <parameter-list> ) {
    <statements>
}

تَتلخَّص كتابة أي برنامج فرعي (subroutine) في مَلْئ هذه الصيغة، لذا دَعْنَا نقوم بذلك لمسألة حِسَاب القواسم. أولًا، تَنُصّ المسألة على اِستقبال البرنامج الفرعي لمُعامِل (parameter) وحيد من النوع int، كما تُبيِّن المُهِمّة المطلوب تَّنْفيذها بواسطة التَعْليمَات المَكًتوبة بمَتْن ذلك البرنامج. ثانيًا، لمّا كان حديثنا في الوقت الراهن مقصورًا على البرامج الفرعية الساكنة (static subroutines)، فإننا سنَستخدِم المُبدِّل static بالتعريف. ثالثًا، قد نُضيف مُبدِّل وصول (access modifier) بالتعريف، مثل public أو private، ولكن نظرًا لعدم النَصّ بذلك صراحة ضِمْن نَّصّ المسألة، فلن نَستخدِم أيًا منهما. رابعًا، لم تَنُصّ المسألة على وجود أي قيمة مُعادة، ولذلك سيَكُون النوع المُعاد (return type) هو void. أخيرًا، لمّا لم تُحدِّد المسألة كُلًا من اسم البرنامج الفرعي (subroutine)، وأسماء المُعامِلات الصُّوريّة (formal parameter) صراحةً، فإننا سنَضَطرّ لاختيار تلك الأسماء بأنفسنا، ولذلك سيُستخدَم N كاسم للمُعامِل، و printDivisors كاسم للبرنامج الفرعي. اُنظر تعريف البرنامج الفرعي:

static void printDivisors( int N ) {
    <statements>
}

ينبغي لنا الآن كتابة مجموعة التَعْليمَات التي ستُكوِّن مَتْن البرنامج (routine body)، وهو ليس أمرًا صعبًا. تَذكَّر فقط أن المُعامِل N سيَكُون لديه قيمة بالفعل ببداية تَّنْفيذ المَتْن. يُمكِن كتابة تَوصِيف الخوارزمية كالتالي:

"لكل عدد يُحتمَل أن يَكُون قَاسِمًا D، أيّ بدايةً من الواحد ووصولًا للعَدَد N، إذا تَمكَّن العدد D من تَقسِّيم العَدَد N تَقسِّيمًا مُتعادلًا، اِطبَع قيمة D."

تُصبح الخوارزمية كالتالي بعد ترجمتها إلى لغة الجافا:

/**
 * اطبع قواسم‫ N
 * ‫بفرض أن N هو عدد صحيح موجب
 */
static void printDivisors( int N ) {
    int D;   
    System.out.println("The divisors of " + N + " are:");
    for ( D = 1; D <= N; D++ ) {
        if ( N % D == 0 )  // ‫إذا نجح D في تقسيم N تقسيما متعادلا
            System.out.println(D);
    }
}

يُمثِل التعليق (comment)، المُضاف قَبْل تعريف البرنامج الفرعي (subroutine definition)، ما يُعرَف باسم المواصفة الاصطلاحية للبرنامج (subroutine contract)، والمُكوَّنة من: بَيان هدف البرنامج الفرعي، بالإضافة إلى التَّصْريح عن أيّ اِفتراضات ينبغي مَعرفِتها قَبْل اِستخدَام ذلك البرنامج. مثلًا، في المثال بالأعلى، ذُكِر أن N ينبغي أن يَكُون عددًا صحيحًا موجبًا، ولذلك ينبغي لمُستدعِي البرنامج الفرعي التَأكُّد من تَوْفِية ذلك الفَرْض.

لنَفْحَص مثالًا آخر، تَنُصّ المسألة على التالي:

"اُكتب برنامجًا فرعيًا خاصًا private اسمه printRow، بحيث يَستقبِل ذلك البرنامج كُلًا من المُعامِلين: ch من النوع char، و N من النوع int. يَتلخَّص دور ذلك البرنامج بطباعة المحرف ch عدد N من المرات وذلك بسَطْر نصي مُنفصِل."

بخلاف المسألة السابقة، نَصَّت هذه المسألة صراحةً على كُلًا من اسم البرنامج الفرعي وأسماء المُعامِلات، كما نَصَّت على ضرورة كَوْنه خاصًا، أيّ ينبغي اِستخدَام مُبدِّل الوصول private، ولذلك نحن مقيدين نوعًا ما فيما يتعلق بالسطر الأول من تعريف البرنامج الفرعي (subroutine definition). أخيرًا، مُهِمّة البرنامج بسيطة جدًا، ولذا يَسهُل كتابة مَتْن البرنامج الفرعي. اُنظر شيفرة البرنامج بالكامل:

/**
 * ‫ اطبع المحرف `ch` عدد `N` من المرات وذلك بسَطْر نصي مُنفصِل
 * ‫إذا كان N أقل من أو يساوي الصفر، اطبع سطرًا فارغًا 
 */
private static void printRow( char ch, int N ) {
    int i;
    for ( i = 1; i <= N; i++ ) {
        System.out.print( ch );
    }
    System.out.println();
}

لَمْ تُصَرِّح المواصفة الاصطلاحية (contract) للبرنامج بالأعلى عن وجود أية افتراضات فيما يَخُص المُعامِل N، ولكنها في المقابل أوْضَحَت طريقة استجابة البرنامج الفرعي لجميع الحالات المُمكِنة، بما فيها الحالة غَيْر المُتوقَّعة من كَوْن N <= 0.

لنَفْحَص مثالًا آخر، ولكن في هذه المرة، سنُوضِح كيف يُمكِن لبرنامجين فرعيين أن يتفاعلا. تحديدًا، سنَكتُب برنامجًا فرعيًا يَستقبِل مُعامِلًا من النوع String، بحيث يَطبَع كل محرف بالسِلسِلة النصية (string) المُمرَّرة ٢٥ مرة وبسَطْر مُنفصِل. ينبغي أن تَستعين بالبرنامج الفرعي printRow()‎ الذي كتبناه للتو لطباعة ذلك الخَرْج.

في هذا المثال، لمّا لم تُحدِّد المسألة كُلًا من اسم البرنامج الفرعي (subroutine)، وأسماء المُعامِلات الصُّوريّة (formal parameter) صراحةً، فإننا سنضطر لاختيار تلك الأسماء، ولذلك سيُستخدَم str كاسم للمُعامِل، وprintRowsFromString كاسم للبرنامج الفرعي. يُمكِن كتابة تَوصِيف الخوارزمية كالتالي:

"لكل مَوْضِع i بالسِلسِلة النصية str، اِستدعِي البرنامج الفرعي printRow(str.charAt(i),25)‎؛ لطباعة سَطْر الخَرْج."

تُصبِح الخوارزمية كالتالي بَعْد ترجمتها إلى لغة الجافا:

/**
 * لكل محرف بالسلسلة النصية، اطبع سطر مكون من 25 نسخة من ذلك المحرف
 */
private static void printRowsFromString( String str ) {
    int i;  
    for ( i = 0; i < str.length(); i++ ) {
        printRow( str.charAt(i), 25 );
    }
}

نستطيع الآن استدعاء البرنامج الفرعي printRowsFromString المُعرَّف بالأعلى داخل البرنامج main()‎ كالتالي:

public static void main(String[] args) {
    String inputLine;  // السطر النصي المدخل من قبل المستخدم
    System.out.print("Enter a line of text: ");
    inputLine = TextIO.getln();
    System.out.println();
    printRowsFromString( inputLine );
}

لاحِظ أنه من الضروري تَضْمِين تعريف البرامج الثلاثة main()‎ و printRowsFromString()‎ و printRow()‎ بنفس الصَنْف. على الرغم من كَوْن البرنامج بالأعلى عديم الفائدة نوعًا ما، لكنه على الأقل يُبيِّن طريقة اِستخدَام البرامج الفرعية. يُمكِنك الإطلاع على البرنامج كاملًا بالملف RowsOfChars.java.

المصفوفات كمعامل

بالإضافة إلى إمكانية تمرير المُعامِلات من الأنواع البسيطة (primitive types) إلى البرامج الفرعية، يُسمَح أيضًا بتمرير المُعامِلات من أنواع المصفوفة (array types)، ما يَعنِي تمرير مصفوفة كاملة من القيم (المُتَغيِّرات إذا شِئنا الدقة) من خلال مُعامِل وحيد. لنَكتُب، على سبيل المثال، برنامجًا فرعيًا يَستقبِل مُعامِلًا من نوع المصفوفة int[]‎؛ ثم يَطبَع جميع الأعداد الصحيحة الموجودة بها، بحيث يُفصَل بين كل عدد والذي يَليه فاصلة (comma)، وبحيث تُحاط جميع تلك الأعداد بزوج من الأقواس []، اُنظر تعريف البرنامج الفرعي:

static void printValuesInList( int[] list ) {
    System.out.print('[');
    int i;
    for ( i = 0; i < list.length; i++ ) {
        if ( i > 0 )
            System.out.print(','); 
        System.out.print(list[i]);
    }
    System.out.println(']');
}

لكي نَستدعِي البرنامج الفرعي بالأعلى، سنحتاج إلى مصفوفة فعليّة (actual). تُنشِئ الشيفرة التالية مصفوفة أعداد صحيحة (array of ints)، وتُمرِّرها كوسيط (argument) للبرنامج الفرعي:

int[] numbers;
numbers = new int[3];
numbers[0] = 42;
numbers[1] = 17;
numbers[2] = 256;
printValuesInList( numbers );

سنَحصُل على الخَرْج [42,17,256].

وسطاء سطر الأوامر (command-line arguments)

لمّا كان البرنامج (routine)‏ main يَستقبِل مُعامِل مصفوفة من النوع String[]‎، كان لزامًا على مُستدعِيه -أيّ النظام (system) في هذه الحالة- أن يُمرِّر مصفوفة سَلاسِل نصية (array of String) فعليّة (actual) كقيمة لذلك المُعامِل الصُّوريّ (formal parameter). لذا لابُدّ أن يَحصُل النظام على قيم السَلاسِل النصية بتلك المصفوفة بطريقة ما، فما الذي يعنيه ذلك؟ وكيف سيَتحصَّل النظام على تلك القيم؟ في الواقع، تَتَكوّن تلك القيم من وُسَطاء سطر الأوامر (command-line arguments)[*] المُمرَّرين إلى الأمر المُستخدَم لتَشْغِيل البرنامج، وبالتالي يُسنِد النظام قيم هؤلاء الوُسَطاء إلى مصفوفة سَلاسِل نصية (array of strings)، ثم يُمرِّرها إلى البرنامج main()‎.

[*] يستطيع المُستخدِم عمومًا تَشْغِيل أحد البرامج من خلال كتابة أمر (command) معين بواجهة سَطْر الأوامر (command-line interface). يَتَكوّن الأمر عمومًا من اسم البرنامج المطلوب تَشْغِيله، ولكن يُمكِن أيضًا كتابة مُدْخَلات إضافية ضِمْن الأمر. تُسمَى تلك المُدْخَلات الإضافية باسم وُسَطاء سَطْر الأوامر (command-line arguments). فمثلًا، إذا كان اسم برنامج معين هو myProg، تستطيع تَشْغِيله باِستخدَام الأمر التالي:

java myProg

ولكن، في هذه الحالة، لا يوجد أي وُسَطاء (arguments)، في المقابل، تستطيع تمرير وسيط واحد أو أكثر باِستخدَام الأمر التالي:

java myProg one two three

في المثال بالأعلى، تُمثِل السَلاسِل النصية "one"، و "two"، و "three" قيم الوُسَطاء، ولذلك سيُسنِد النظام هذه السَلاسِل النصية إلى مصفوفة من النوع String[]‎، ثم يُمرِّرها كمُعامِل إلى البرنامج main()‎. على سبيل المثال، تَطبَع الشيفرة التالية قيمة أي وسيط (argument) أَدْخَله المُستخدِم:

public class CLDemo {

    public static void main(String[] args) {
        System.out.println("You entered " + args.length
                           + " command-line arguments");
        if (args.length > 0) {
            System.out.println("They were:");
            int i;
            for ( i = 0; i < args.length; i++ )
                System.out.println("   " + args[i]);
        }
    } // ‫نهاية main

} // ‫نهاية الصنف CLDemo

إذا لم يُخصِّص المُستخدِم أي وسيط (arguments) بأمر تَشْغِيل البرنامج، فإن المُعامِل args سيَكُون عبارة عن مصفوفة فارغة، طولها (length) يُساوي الصفر.

عمليًا، يُستخدَم وُسَطاء سَطْر الأوامر عادةً بهدف تمرير أسماء بعض الملفات إلى البرنامج. فمثلًا، يَنسَخ البرنامج التالي محتويات ملف نصي معين إلى ملف نصي آخر، ولذلك فإنه يَستخدِم الصَنْف TextIO ضِمْن حَلْقة تَكْرار، بحيث يَقْرأ سَطْرًا واحدًا من الملف الأصلي في كل مرة، ثم يَنسَخُه إلى الملف الآخر. يَستمِر في القيام بذلك حتى يَصِل إلى نهاية الملف، والتي يُستدَلّ عليها من القيمة المنطقية المُعادة من الدالة (function)‏ TextIO.eof()‎.

input textio.TextIO;
/** 
 * يتطلب ذلك الأمر وسيطين، هما أسماء الملفات
 * الأول ينبغي أن يكون اسم ملف موجود
 * والثاني ينبغي أن يكون اسم الملف الذي سينسخ البرنامج إليه بيانات الملف الأول
 * سيقوم البرنامج بنسخ محتويات الملف الأول إلى الملف الثاني
 * تحذير: إذا كان الملف الثاني موجود عند تشغيل البرنامج، ستتم الكتابة على البيانات السابقة
 * يعمل هذا البرنامج مع الملفات النصية فقط
 */
public class CopyTextFile {

    public static void main( String[] args ) {
        if (args.length < 2 ) {
            System.out.println("Two command-line arguments are required!");
            System.exit(1);
        }
        TextIO.readFile( args[0] );   // افتح الملف الأصلي بهدف القراءة
        TextIO.writeFile( args[1] );  // افتح الملف المراد النسخ إليه
        int lineCount;  // عدد الأسطر المنسوخة
        lineCount = 0;
        while ( TextIO.eof() == false ) {
            // اقرأ سطر من الملف الأصلي وانسخه للملف الآخر
            String line;
            line = TextIO.getln();
            TextIO.putln(line);
            lineCount++;
        }
        System.out.printf( "%d lines copied from %s to %s%n",
                          lineCount, args[0], args[1] );
    }

}

تُنفَّذ معظم البرامج حاليًا من خلال واجهة مُستخدِم رسومية (GUI environment)، ولذلك لم يَعُدْ وُسَطاء سَطْر الأمر (command-line arguments) بنفس ذات الأهمية في الوقت الحالي. مع ذلك ما يزال البرنامج بالأعلى مثالًا جيدًا لبيان كيفية اِستخدَام مُعامِلات المصفوفة (array parameters) على الأقل.

التبليغ عن الاعتراضات (exceptions)

ذَكَرَنا، منذ قليل، مصطلح المواصفة الاصطلاحية للبرنامج (subroutine contract)، والذي يُوضِح وظيفة البرنامج الفرعي في حالة تمرير قيم صالحة -وفقًا لما هو مُوضَّح بنفس المواصفة الاصطلاحية- لجميع المُعامِلات الخاصة به. تَتَبقَّى الحاجة إلى مَعرِفة كيفية تَصرُّف البرنامج الفرعي في حالة تمرير قيم غَيْر صالحة للمُعامِلات.

تَعرَّضنا بالفعل لعدة أمثلة بالقسم ٣.٧، والتي تُبلِّغ فيها البرامج الفرعية عن اِعتراضات (throwing exceptions) في حالة تمرير قيم غَيْر صالحة، فمثلًا، تَنُصّ المواصفة الاصطلاحية للبرنامج الفرعي المَبنِى مُسْبَّقًا (built-in)‏ Double.parseDouble على ضرورة أن يَكُون المُعامِل المُمرَّر إليها عبارة عن تمثيل نصي (string representation) لعَدََدَ من النوع double. إذا كانت قيمة المُعامِل المُمرَّرة مُتماشية مع ذلك الشَّرْط، سيُحوِّل البرنامج الفرعي السِلسِلة النصية (string) المُمرَّرة إلى قيمتها العَدَدية المكافئة، أما إذا لم تَكُن مُتماشية معها، سيُبلِّغ البرنامج الفرعي عن اِعتراض (exception) من النوع NumberFormatException.

تُبلِّغ الكثير من البرامج الفرعية عن اعتراض من النوع IllegalArgumentExceptions في حالة تمرير قيم غَيْر صالحة لمُعامِلاتها، وهو ما قد تَرغب في اتباعه بالبرامج الفرعية الخاصة بك. أيّ اعتراض (exception) هو بالنهاية عبارة عن كائن (object)، ستَضطرّ إلى إنشائه قَبْل التَبْليغ عنه باِستخدَام التَعْليمَة throw. سنتناول كيفية القيام بذلك تفصيليًا بالفصل الخامس، ولكن، إلى ذلك الحين، تستطيع اِستخدَام الصيغة (syntax) التالية لتَعْليمَة throw؛ للتَبْليغ عن اِعتراض من النوع IllegalArgumentException تحديدًا:

throw new  IllegalArgumentException( <error-message> );

تَتَكوّن رسالة الخطأ بالأعلى من سِلسِلة نصية (string) تَشرَح الخطأ المُكْتشَف بينما تُستخدَم new لإنشاء كائن الاعتراض (exception object). كل ما عليك القيام به هو فَحْص قيم المُعامِلات المُمرَّرة؛ لمَعرِفة ما إذا كانت صالحة أم لا، ثم التَبْليغ عن اعتراض باِستخدَام التَعْليمَة بالأعلى إذا لم تَكُن صالحة. على سبيل المثال، لابُدّ أن تَكُون قيمة المُعامِل المُمرَّرة إلى البرنامج الفرعي print3NSequence -المُعرَّف ببداية هذا القسم- عددًا صحيحًا موجبًا، لذلك يُمكِننا، في حالة انتهاك هذا الشَّرْط، تَعْدِيل تعريف البرنامج الفرعي (subroutine definition) بالصورة التالية؛ وذلك لكي نَتَمَكَّن من التَبْليغ عن الاِعتراض:

static void print3NSequence(int startingValue) {

    if (startingValue <= 0)  // إذا حدث انتهاك للمواصفة الاصطلاحية
        throw new IllegalArgumentException( "Starting value must be positive." );

    // بقية البرنامج الفرعي مثلما بالأعلى

إذا كانت القيمة المُمرَّرة إلى المُعامِل startingValue غَيْر صالحة، فستُنهِي تَعْليمَة throw بالأعلى البرنامج الفرعي فورًا بدون تَّنْفيذ بقية المَتْن، كما قد ينهار (crash) البرنامج بالكامل في حالة عدم اِلتقاط ذلك الاِعتراض (catching exception) بمكان آخر ضِمْن البرنامج باِستخدَام التَعْليمَة try..catch بحيث يُستدعَى البرنامج الفرعي print3NSequence داخل الجزء try، كما ناقشنا بالقسم ٣.٧.

المتغيرات العامة (global) والمحلية (local)

كملاحظة أخيرة بهذا القسم، يُمكِننا القول أننا نستطيع الآن اِستخدَام ثلاثة أنواع مختلفة من المُتَغيِّرات داخل أيّ برنامج فرعي، هي كالتالي: أولًا، المُتَغيِّرات المحليّة (local variables) والتي يُصرَّح عنها داخل البرنامج الفرعي. ثانيًا، أسماء المُعامِلات الصُّوريّة (formal parameter) ضِمْن تعريف البرنامج الفرعي. ثالثًا، المُتَغيِّرات الأعضاء الساكنة (static member variables)، والتي يُصرَّح عنها خارج البرنامج الفرعي.

تُعدّ المُتَغيِّرات المحليّة (local variables) من صميم أعمال البرنامج الفرعي الداخلية، وليس لها أيّ اتصال مع ما هو خارج البرنامج الفرعي.

تُمرِّر المُعامِلات الصُّوريّة (formal parameter) قيم خارجية إلى البرنامج الفرعي أثناء الاستدعاء، ولكنها مع ذلك تَتَصرَّف بطريقة مشابهة للمُتَغيِّرات المحليّة بمجرد بدء تَّنْفيذ البرنامج الفرعي. يَعنِي ذلك أنه في حالة حُدوث تَغْيِير بقيمة أحد المُعاملات الصُّوريّة (من النوع الأوَّليّ [primitive type] تحديدًا) أثناء تَّنْفيذ البرنامج الفرعي، فإن ذلك التَغْيِير لا يُؤثِر نهائيًا على بقية البرنامج. لاحِظ أنه في حالة كان المُعامِل الصُّوريّ عبارة عن مصفوفة أو كائن (object)، فإن الأمور تُصبِح أكثر تعقيدًا كما سنرى لاحقًا.

أخيرًا، بخلاف المُتَغيِّرات المحليّة (local variables) المُعرَّفة داخل البرامج الفرعية، فإن المُتَغيِّرات العامة (global variables) تُعرَّف خارج أي برنامج فرعي، ولذا فإنها تُعدّ مستقلة عنها، كما أنها قابلة للاِستخدَام ضِمْن أجزاء عديدة من البرنامج (program). في الواقع، يُمكِن اِستخدَام المُتَغيِّر العام (global variable) بأيّ مكان داخل الصَنْف المُُعرَّف بداخله، بل يُمكِن استخدامه بأي صنف آخر طالما لم يُصرَّح عنه باِستخدَام المُبدِّل private. لاحظ أنه إذا حَدَثَ تغيير على مُتَغيِّر عام (global variable) داخل برنامج فرعي معين، فإن تأثير ذلك التغيير يمتد إلى ما هو أبعد من مجرد ذلك البرنامج الفرعي الذي أَحَدَث التغيير، وهو ما قد تعرضت له بالفعل بالمثال الأخير بالقسم السابق؛ حيث عَدَّلت إحدى البرامج الفرعية قيم المُتَغيِّرات العامة gamesPlayed و gamesWon، ثم طُبعت بواسطة برنامج فرعي آخر هو main()‎.

إذا اِستخدَمت مُتَغيِّرًا عامًا (global variable) ضِمْن برنامج فرعي معين، فإن ذلك البرنامج الفرعي يُصبِح قادرًا على الاتصال مع بقية البرنامج (program) فيما يُشبه الاتصال السري (back-door communication)، ولهذا نستطيع القول أن المُتَغيِّرات العامة قد أصبحت بذلك جزءًا من واجهة البرنامج الفرعي (subroutine's interface). يُعدّ الاتصال السري عمومًا أقل وضوحًا وصراحةً من ذلك المُقام باستخدام المُعامِلات، ولهذا فإنه قد يَتَسبَّب بكسر القاعدة التي تَنُصّ على ضرورة كَوْن واجهة (interface) "الصندوق الاسود (black box)" صريحة وسهلة الفهم. قد يَدْفَعك ذلك إلى الظّنّ بأن اِستخدَام المُتَغيِّرات العامة داخل البرامج الفرعية أمر سيئ عمومًا، ولكن هذا غَيْر صحيح، فهناك على الأقل سببًا واحدًا جيدًا قد يَدْفَعك للقيام بذلك: مثلًا إذا فكرت بالصَنْف (class) بكَوْنه نوعًا من "الصندوق الاسود (black box)"، يُصبِح من المعقول تمامًا السماح للبرامج الفرعية الواقعة ضِمْن ذلك الصندوق بالاتصال سريًا مع بعضها البعض (back-door communication) خاصة إذا ساهم ذلك بتبسيط الصَنْف ككل من الخارج. لهذا يَنصَح الكاتب بعدم اتخاذ أيّ موقف عدائي مُطْلَق من اِستخدَام المُتَغيِّرات العامة (global variables) داخل البرامج الفرعية، فقط عليك أن تُفكِر مَلِيًّا قَبْل اِستخدَام مُتَغيِّر عام (global variable) داخل برنامج فرعي للتَأكُّد مما إذا كان ذلك ضروريًا.

ترجمة -بتصرّف- للقسم Section 3: Parameters من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

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

تُميز لغة الجافا بشكل واضح بين البرامج الفرعية الساكنة (static) وغَيْر الساكنة (non-static). يُمكِن لأي صَنْف أن يَتضمَّن كِلا النوعين، ولكن كيفية اِستخدَامهما مختلفة تمامًا. تُعدّ البرامج الفرعية الساكنة (static subroutine) عمومًا أسهل في الفهم، فببساطة أي برنامج فرعي ساكن هو عضو (member) ينتمي للصنف ذاته المُعرَّف بداخله. في المقابل، تعريف البرامج الفرعية غَيْر الساكنة (non-static subroutine) موجود فقط ضِمْن الصَنْف حتى تَتَمكَّن كائنات (objects) ذلك الصنف -عند إنشائها- من اِستخدَام تلك البرامج الفرعية، وتُصبِح عندها تلك البرامج أعضاء بتلك الكائنات (objects). يُمكِن تطبيق ذلك الاختلاف على المُتَغيِّرات (variables) الساكنة وغَيْر الساكنة بنفس الكيفية، بل وعلى أي شيء آخر قد يَقع ضمن تعريف الأصناف (class definition). سنتناول في هذا الفصل كُلًا من البرامج الفرعية الساكنة والمُتَغيِّرات الساكنة فقط، وسننتقل بالفصل التالي إلى البرمجة كائنية التوجه (object-oriented programming) وعندها سنستطيع مناقشة الأعضاء غَيْر الساكنة.

عادة ما يُطلَق مصطلح "التابع (method)" على البرامج الفرعية (subroutines) المُعرَّفة ضِمْن صَنْف، وهو الاسم الذي يُفضِّله غالبية مبرمجي الجافا مع أن المصطلحان عمومًا مترادفان خاصة فيما يَتعلَّق بلغة الجافا. ستَجِدْ أيضًا البعض يَستخدِم مصطلحات آخرى للإشارة إلى البرامج الفرعية مثل "الإجراء (procedure)" أو "الدالة (function)". يُفضِّل الكاتب الاستمرار باِستخدَام المصطلح الأعم "البرنامج الفرعي (subroutine)" ضِمْن هذا الفصل للإشارة إلى البرامج الفرعية الساكنة على الأقل، ولكنه سيبدأ في اِستخدَام مصطلح "التابع (method)" من حين لآخر، كما أنه سيَستخدِم مصطلح "الدالة (function)" فقط للإشارة إلى البرامج الفرعية التي تَحسِب قيمة وتُعيدها مع أن بعض اللغات البرمجية الآخرى تَستخدِم ذلك المصطلح للإشارة إلى البرامج الفرعية (subroutines) بمفهومها الأعم.

تعريف البرامج الفرعية

ينبغي أن يُعرَّف (define) أيّ برنامج فرعي (subroutine)، تَنوِي اِستخدَامه، بمكان ما بالبرنامج، بحيث يَتضمَّن ذلك التعريف (subroutine definition) كُلًا من الآتي: اسم البرنامج الفرعي (subroutine name)، والمعلومات اللازمة لاستدعائه (subroutine call)، وأخيرًا، الشيفرة الفعليّة المطلوب تَّنْفيذها مع كل عملية استدعاء. يُكتَب تعريف البرنامج الفرعي (subroutine definition) بالجافا بالصياغة التالية:

<modifiers>  <return-type>  <subroutine-name>  ( <parameter-list> ) {
    <statements>
}

قد تكون الصيغة بالأعلى مألوفة بالنسبة لك؛ فقد تَعرَّضنا بالفعل خلال الفصول السابقة لبعض البرامج الفرعية، مثل البرنامج main()‎ المُعرَّف بأيّ برنامج، والبرنامج drawFrame()‎ ببرامج التحريكة (animation) بالقسم ٣.٩. ومع ذلك، لاِستيعاب ما تَعنيه تلك الصيغة تفصيليًا، سنحتاج إلى مُناقشتها باستفاضة، وهو ما سنفعله بغالبية هذا الفصل.

أولًا، تُكوِّن التَعْليمَات -الواقعة بين القوسين المعقوصين {}- مَتْن البرنامج الفرعي (subroutine body)، وتُمثِل الجزء التَّنْفيذي (implementation) أو الداخلي "للصندوق الأسود (black box)" كما ذَكَرنا بالقسم السابق. يُنفِّذ الحاسوب تلك التَعْليمَات عند إجراء عملية اِستدعاء لذلك البرنامج (أو التابع [method]). لاحظ أن تلك التَعْليمَات قد تَتكوَّن من أي تَعْليمَة قد تَعرَّضنا لها خلال الفصلين الثاني والثالث.

ثانيًا، تُكتَب المُبدِّلات ببداية التعريف، وهي عبارة عن كلمات تُستخدَم لضَبْط بعض خاصيات البرنامج الفرعي، مثل ما إذا كان ساكنًا (static) أم غير ساكن (non-static). تُوفِّر لغة الجافا عمومًا ستة مُبدِّلات (modifiers) يُمكنك اِستخدَامها، ولقد تَعرَّضنا لاثنين منها فقط حتى الآن، وهي المُبدِّل الساكن static، والمُبدِّل العام public.

ثالثًا، يُستخدَم النوع المُعاد لتَخْصِيص نوع القيمة المُعادة من البرنامج الفرعي. تحديدًا، إذا كان البرنامج الفرعي بالأساس هو عبارة عن دالة (function) تَحسِب قيمة معينة، عندها قد تَستخدِم أي نوع، مثل String أو int أو حتى أنواع المصفوفة مثل double[]‎. أما إذا كان البرنامج الفرعي ليس بدالة، أيّ لا يُعيد قيمة، فعندها تُستخدَم القيمة الخاصة void، والتي تُشير إلى عدم وجود قيمة مُعادة، أيّ أنها إِما أن تَكُون فارغة (empty) أو غَيْر موجودة. سنتناول الدوال (functions)، والأنواع المُعادة (return types) تفصيليًا بالقسم ٤.٤.

وأخيرًا، قائمة المُعامِلات الخاصة بالتابع (method). تُعدّ المُعامِلات جزءًا من وَاجهة البرنامج الفرعي (subroutine interface)، وتُمثِل المعلومات المُمرَّرة (passed) إليه من الخارج، والتي قد يَستخدِمها لحِسَاب بعض العمليات الداخلية الخاصة به. فمثلًا، بفَرْض وجود الصَنْف Television، والذي يَتضمَّن التابع changeChannel()‎. في تلك الحالة، يُفْترَض أن يُطرَح سؤالًا تلقائيًا عن رقم القناة التي تُريد من البرنامج الفرعي الانتقال إليها، وهنا يأتي دور المُعامِلات (parameter)؛ حيث يُمكِن اِستخدَام مُعامِل للإجابة على مثل هذا السؤال، ولمّا كان رقم القناة هو عدد صحيح، فسيَكُون نوع ذلك المُعامِل (parameter type) هو int، ولهذا يُمكِنك التَّصْريح (declaration) عن التابع changeChannel()‎ كالتالي:

public void changeChannel(int channelNum) { ... }

يُشير التَّصْريح بالأعلى إلى أن التابع changeChannel()‎ لديه مُعامِل يَحمِل اسم channelNum من النوع العددي الصحيح int. لاحظ أن قيمة المُعامِل channelNum غير مُتوفِّرة حتى الآن، وإنما تَتوفَّر عند عملية الاستدعاء الفعليّ للتابع الفرعي، على سبيل المثال: changeChannel(17);‎.

قد تتكوَّن قائمة المُعامِلات (parameter list) -بتعريف البرنامج الفرعي- من تَّصْريح عن مُعامِل (parameter declaration) واحد أو أكثر، وذلك على الصورة ، بحيث يَتكوَّن كل تَّصْريح من مُعامِل وحيد، كما يُفصَل بين كل تَّصْريح والذي يليه باستخدام فاصلة (comma). على سبيل المثال، في حالة أردت التَّصْريح عن مُعامِلين من النوع double، فستضطر إلى كتابة double x, double y وليس double x, y. لاحِظ أن قائمة المُعامِلات قد تَكُون فارغة أيضًا.

سنتناول المُعامِلات (parameters) تفصيليًا بالقسم التالي.

ها هي التعريفات الخاصة ببعض البرامج الفرعية (subroutine definitions)، ولكن بدون الجزء التَّنْفيذي (implementation) منها، أي بدون التَعْليمَات الفعليّة التي تُعرِّف ما تُنفِّذه تلك البرامج الفرعية:

public static void playGame() {
    // المبدلات هي‫ public و static
    // ‫النوع المعاد هو void
    // ‫اسم البرنامج الفرعي هو playGame
    // قائمة المعاملات فارغةً
}

int getNextN(int N) {
    // لا يوجد مبدلات
    // ‫النوع المعاد هو int
    // ‫اسم البرنامج الفرعي هو getNextN
    // ‫قائمة المعاملات تتضمن معامل اسمه N من النوع int
}

static boolean lessThan(double x, double y) {
    // ‫المبدلات هي static
    // ‫النوع المعاد هو boolean
    // ‫اسم البرنامج الفرعي هو lessThan
    // ‫قائمة المعاملات تتضمن معاملين x و y كلاهما من النوع double
}

بالمثال الثاني بالأعلى، لمّا كان تعريف التابع getNextN لا يَتضمَّن المُبدل static، فإنه يُعدّ بصورة افتراضية تابعًا غَيْر ساكن (non-static method)، ولذلك لن نَفْحصه بهذا الفصل! اُستخدِم المُبدل public بالمثال الأول، والذي يُشير إلى إِمكانية استدعاء التابع (method) من أي مكان بالبرنامج، حتى من خارج الصَنْف (class) الذي عُرِّف فيه هذا التابع. في المقابل، يَتوفَّر المُبدل private، والذي يُشير إلى إمكانية استدعاء التابع من داخل نفس الصَنْف فقط. يُطلَق على كُلًا من المُبدلين public و private مُحدِّدات الوصول أو مُبدِّلات الوصول (access specifiers/access modifier). يَتوفَّر مُبدل وصول (access modifier) أخير، هو protected، والذي ستتضح أهميته عندما ننتقل إلى البرمجة كائنية التَوجه (object-oriented programming) بالفصل الخامس. في حالة عدم تخصيص مُحدِّد وصول لتابع معين، فإنه، وبصورة افتراضية، يُصبِح قابلًا للاستدعاء من أيّ مكان بالحزمة (package) التي تَتضمَّن صَنْفه، ولكن ليس من خارج تلك الحزمة. سنُناقش الحزم (packages) خلال هذا الفصل، تحديدًا بالقسم ٤.٦.

يَتَّبِع البرنامج main()‎، المُعرَّف بأي برنامج، نفس قواعد الصيغة (syntax rules) المُعتادة لأي برنامج فرعي:

public static void main(String[] args) { ... }

بفَحْص التعريف بالأعلى، تَجد أن المُبدلات المُستخدَمة هي public و static، أما النوع المُعاد فهو void، أما اسم البرنامج الفرعي فهو main، وأخيرًا، قائمة المعاملات هي String[] args، أيّ أن نوع المُعامِل المُمرَّر هو نوع المصفوفة String[]‎.

إذا كنت قد قرأت الفصول السابقة، فلديك بالفعل الخبرة الكافية لكتابة الجزء التَّنْفيذي من البرنامج الفرعي (implementation of a subroutine). في هذا الفصل، سنتعلَّم كتابة التَعرِيف بالكامل بما في ذلك جزء الواجهة (interface).

استدعاء البرامج الفرعية

يُعدّ تعريف البرنامج الفرعي (subroutine definition) بمثابة إعلام للحاسوب بوجود ذلك البرنامج الفرعي وبالوظيفة التي يُؤديها، لكن يُرجئ التَّنْفيذ الفعليّ للبرنامج الفرعي إلى حين استدعائه (call). يَنطبِق ذلك حتى على البرنامج (routine)‏ main()‎، والذي يَستدعيه النظام (system) -لا أنت- عند تَّنْفيذه للبرنامج (program) ككل. تُستخدَم، مثلًا، تَعْليمَة استدعاء البرنامج الفرعي (subroutine call) التالية؛ لاستدعاء التابع playGame()‎ المذكور بالأعلى:

playGame();

يُمكن عمومًا كتابة تَعْليمَة الاستدعاء بالأعلى بأيّ مكان داخل نفس الصَنْف (class) الذي عَرَّف التابع playGame()‎، سواء كان ذلك بالتابع‏ main()‎، أو بأيّ برنامج فرعي آخر. علاوة على ذلك، لمّا كان التابع playGame()‎ مُعرَّف باِستخدَام المُبدل public، وهو ما يَعنِي كَوْنه تابعًا عامًا، فإنه من الممكن لأيّ صَنْف آخر استدعائه أيضًا، ولكن ينبغي أن تُعلِم الحاسوب، في تلك الحالة، باسم التابع كاملًا أثناء الاستدعاء، أيّ بذكر الصَنْف الذي ينتمي إليه ذلك التابع. ولأن التابع playGame()‎ مُعرَّف باِستخدَام المُبدل static، وهو ما يَعنِي كَوْنه تابعًا ساكنًا، فإن اسمه الكامل يَتضمَّن اسم الصنف ذاته المُعرَّف بداخله. على سبيل المثال، إذا كان التابع playGame()‎ مُعرَّف بالصَنْف Poker، تُستخدَم التَعْليمَة التالية لاستدعائه من خارج هذا الصَنْف:

Poker.playGame();

يُعلِم اسم الصَنْف -بالأعلى- الحاسوب بأيّ صَنْف ينبغي له أن يَجِد التابع. بالإضافة إلى ذلك، يُساعدنا وجود اسم الصَنْف أثناء الاستدعاء على التمييز بين التابع Poker.playGame()‎ وأي توابع اخرى لها نفس الاسم ومُعرَّفة بأصناف آخرى، مثل Roulette.playGame()‎ أو Blackjack.playGame()‎.

تُكتَب عمومًا تَعْليمَة استدعاء أي برنامج فرعي ساكن static ‏(static subroutine call) بالجافا بالصيغة التالية إذا كان البرنامج الفرعي المُستدعَى مُعرَّفًا بنفس الصَنْف (class):

<subroutine-name>(parameters);

أو كالتالي إذا كان البرنامج الفرعي مُعرَّفًا بصَنْف آخر:

<class-name>.<subroutine-name>(parameters);

يَختلف ذلك عن التوابع غَيْر الساكنة (non-static methods) -سنتناولها لاحقًا-، والتي تنتمي إلى كائنات (objects) وليس أصناف (classes)، ولهذا يُستدعَى ذلك النوع من التوابع من خلال الكائنات (objects) ذاتها لا من خلال أسماء الأصناف.

لاحظ أنه في حين يُمكِن لقائمة المُعامِلات (parameter list) أن تَكُون فارغة (empty)، كما هو الحال بالمثال playGame()‎، فإن كتابة الأقواس (parentheses) بتَعْليمَة الاستدعاء ما تزال ضرورية حتى مع كَوْن ما بينها فارغًا. أما في حالة تخصيص مُعامِل (parameter) أو أكثر بقائمة المُعامِلات (parameter list) بالتعريف الخاص ببرنامج فرعي ما (subroutine definition)، فينبغي عمومًا أن يَتطابَق عدد المُعامِلات المُمرَّرة أثناء استدعاء ذلك البرنامج الفرعي مع العَدَدَ المُخصَّص بذلك التعريف، كما لابُدّ بطبيعة الحال أن تَتطابَق أنواع تلك المُعامِلات المُمرَّرة بتَعْليمَة الاستدعاء مع نوعها المُناظِر بنفس ذلك التعريف.

البرامج الفرعية بالبرامج

سنُعطي الآن مثالًا عما قد يبدو عليه البرنامج (program) عند تَضمُّنه لبرنامج فرعي آخر غَيْر البرنامج main()‎. سنَكتُب تحديدًا برنامجًا للعبة تخمين، يَختار فيه الحاسوب عددًا عشوائيًا بين العددين ١ و ١٠٠، ثُمَّ يُحاول المُستخدِم تخمين ذلك العدد، ليُخبره الحاسوب بَعْدها عما إذا كان تخمينه أكبر أو أقل أو يُساوِي العَدَد الصحيح، وبحيث يَفوز المُستخدِم بالمباراة إذا تَمكَّن من تخمين العدد الصحيح خلال ٦ تخمينات كحد أقصى. أخيرًا، يَستطيع المُستخدِم اختيار الاستمرار بلعب مباراة إضافية بنهاية كل مباراة.

لمّا كانت كل مباراة هي بالنهاية مُهِمّة مُترابطة مُفردة، كان بديهيًا كتابة برنامج فرعي playGame()‎ بهدف لعب مباراة تخمين واحدة مع المُستخدِم. سيَستخدِم البرنامج main()‎ حَلْقة تَكْرار (loop)، والتي ستَستدعِي ذلك البرنامج الفرعي مع كل مرة يختار فيها المُستخدِم الاستمرار بلعب مباراة إضافية. نحتاج الآن إلى تصميم البرنامج الفرعي playGame()‎ وكتابته، وفي الواقع، يُصمَّم أي برنامج فرعي بنفس طريقة تَصْميم البرنامج main()‎، أيّ نبدأ بكتابة توصيف للخوارزمية (algorithm)، ثم نُطبِق التَصْميم المُتدرج (stepwise refinement). اُنظر الخوارزمية التالية لبرنامج لعبة التخمين مكتوبًا بالشيفرة الوهمية:

// اختر عددًا عشوائيًا 
Pick a random number
// طالما لم تنته المباراة
while the game is not over:
    // اقرأ تخمين المستخدم
    Get the user's guess
    // اخبر المستخدم عما إذا كان تخمينه صحيحًا أم أكبر أم أقل
    Tell the user whether the guess is high, low, or correct.

يُعدّ الاختبار "طالما لم تنته المباراة" معقدًا نوعًا ما؛ وذلك لأن المباراة قد تنتهي لسببين: إما لأن تخمين المُستخدِم كان صحيحًا أو لوصوله للحد الأقصى من عدد التخمينات المُمكنة، أيّ ٦. أحد أسهل الطرائق للقيام بذلك هو اِستخدَام حَلْقة تَكْرار لا نهائية while (true)‎ تحتوي على تَعْليمَة break؛ بهدف إِنهاء الحَلْقة في الوقت المناسب. لاحِظ أننا سنحتاج إلى الاحتفاظ بعَدَد تخمينات المُستخدِم؛ حتى نَتمكَّن من إِنهاء المباراة في حالة وصول المُستخدِم للحد الأقصى من التخمينات. تُصبِح الخوارزمية كالتالي بعد إِجراء التعديلات:

// أسند قيمة عشوائية بين 1 و 100 إلى المتغير computersNumber
Let computersNumber be a random number between 1 and 100
// اضبط قيمة العداد المستخدم لعدّ عدد تخمينات المستخدم
Let guessCount = 0
// استمر بتنفيذ الآتي
while (true):
    // اقرأ تخمين المستخدم
    Get the user's guess
    // أزد قيمة العداد بمقدار الواحد
    Count the guess by adding 1 to guess count
    // إذا كان تخمين المستخدم صحيحًا
    if the user's guess equals computersNumber:
        // بلغ المستخدم بفوزه بالمباراة
        Tell the user he won
        // اخرج من الحلقة
        break out of the loop
    // إذا وصل العداد للحد الأقصى 6
    if the number of guesses is 6:
        // بلغ المستخدم بخسارته للمباراة
        Tell the user he lost
        // اخرج من الحلقة
        break out of the loop
    // إذا كان كان تخمين المستخدم أقل من العدد
    if the user's guess is less than computersNumber:
        // بلغ المستخدم بكَوْن التخمين أقل من العدد
        Tell the user the guess was low
    // إذا كان كان تخمين المستخدم أعلى من العدد
    else if the user's guess is higher than computersNumber:
        // بلغ المستخدم بكَوْن التخمين أكبر من العدد
        Tell the user the guess was high

يُستخدَم التعبير ‎(int)(100 * Math.random()) + 1 لاختيار عدد عشوائي يقع بين العددين ١ و ١٠٠. اُنظر الشيفرة التالية بلغة الجافا، والتي تَتضمَّن تعريف البرنامج playGame()‎ بعد التَّصْريح عن المُتَغيِّرات (variable declarations):

static void playGame() {
    int computersNumber; // العدد العشوائي
    int usersGuess;      // إحدى تخمينات المستخدم
    int guessCount;      // عدد تخمينات المستخدم
    computersNumber = (int)(100 * Math.random()) + 1;

    guessCount = 0;
    System.out.println();
    System.out.print("What is your first guess? ");
    while (true) {
        usersGuess = TextIO.getInt();  // اقرأ تخمين المستخدم
        guessCount++;
        if (usersGuess == computersNumber) {
            System.out.println("You got it in " + guessCount
                               + " guesses!  My number was " + computersNumber);
            break;  // انتهت المباراة بفوز المستخدم
        }
        if (guessCount == 6) {
            System.out.println("You didn't get the number in 6 guesses.");
            System.out.println("You lose.  My number was " + computersNumber);
            break;  // انتهت المباراة بخسارة المستخدم
        }
        // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد
        if (usersGuess < computersNumber)
            System.out.print("That's too low.  Try again: ");
        else if (usersGuess > computersNumber)
            System.out.print("That's too high.  Try again: ");
    }
    System.out.println();
} // end of playGame()

الآن، وبعد انتهائنا من كتابة تعريف البرنامج الفرعي بالأعلى، فإننا سنحتاج إلى معرفة المكان الذي يُفْترَض أن نضع به هذا التعريف؟ ينبغي أن نضعه عمومًا ضِمْن نفس الصَنْف المُتضمِّن للبرنامج main()‎، ولكن ليس داخل البرنامج main ذاته؛ فمن غَيْر المسموح كتابة برنامج فرعي ضِمْن آخر (nested). لمّا كانت لغة الجافا لا تَشترِط أيّ ترتيب معين للبرامج الفرعية المُعرَّفة ضِمْن نفس الصَنْف، فيُمكِنك وضع تعريف playGame()‎ قَبْل البرنامج main()‎ أو بَعْده. لاحِظ أن البرنامج main()‎ سيَستدعِي البرنامج الفرعي playGame()‎، وهو ما يَعنِي مُجرد تَضمُّنه لتَعْليمَة استدعاء (call statement) لذلك البرنامج الفرعي، لا تَضمُّنه لتعريفها الكامل (definition). يتبقَّى لنا الآن كتابة البرنامج main، وهو ما قد تراه أمرًا بغاية السهولة خاصة مع رؤيتنا لكثير من الأمثلة المشابهة مُسْبَّقًا.

سيبدو البرنامج كاملًا كالتالي مع مُراعاة إِمكانية إضافة المزيد من التعليقات (comments):

import textio.TextIO;

public class GuessingGame {

    public static void main(String[] args) {
        System.out.println("Let's play a game.  I'll pick a number between");
        System.out.println("1 and 100, and you try to guess it.");
        boolean playAgain;
        do {
            playGame();  // اِستدعي البرنامج الفرعي لإجراء مباراة    
            System.out.print("Would you like to play again? ");
            playAgain = TextIO.getlnBoolean();
        } while (playAgain);
        System.out.println("Thanks for playing.  Goodbye.");
    } // ‫نهاية main 

    static void playGame() {
        int computersNumber; // العدد العشوائي
        int usersGuess;      // إحدى تخمينات المستخدم
        int guessCount;      // عدد تخمينات المستخدم

        computersNumber = (int)(100 * Math.random()) + 1;

        guessCount = 0;
        System.out.println();
        System.out.print("What is your first guess? ");
        while (true) {
            usersGuess = TextIO.getInt();  // اقرأ تخمين المستخدم
            guessCount++;
            if (usersGuess == computersNumber) {
                System.out.println("You got it in " + guessCount
                                   + " guesses!  My number was " + computersNumber);
                break;  // انتهت المباراة بفوز المستخدم
            }
            if (guessCount == 6) {
                System.out.println("You didn't get the number in 6 guesses.");
                System.out.println("You lose.  My number was " + computersNumber);
                break;  // انتهت المباراة بخسارة المستخدم
            }
            // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد
            if (usersGuess < computersNumber)
                System.out.print("That's too low.  Try again: ");
            else if (usersGuess > computersNumber)
                System.out.print("That's too high.  Try again: ");
        }
        System.out.println();
    } // ‫نهاية البرنامج الفرعي playGame

} // ‫نهاية الصنف GuessingGame

اِستغرِق الوقت الكافي لقراءة شيفرة البرنامج بالأعلى، وحَاول اِستيعاب طريقة عملها. رُبما تَكُون قد لاحَظت أن تَقسيم البرنامج إلى تابعين (methods) قد جَعل البرنامج عمومًا أسهل في القراءة، وربما حتى في الكتابة حتى مع كَوْنه بسيطًا، أما إذا لم تَلحَظ ذلك، فحاول إقناع نفسك به في الوقت الحالي.

المتغيرات الأعضاء (Member Variables)

قد تَتضمَّن الأصناف (classes) أعضاء (members) آخرى، غير البرامج الفرعية، كالمُتَغيِّرات (variables)، فيُمكِن لأي صَنْف التَّصْريح عن مُتَغيِّر ما (variable declaration)، ولا يُقصَد بذلك تلك المُتَغيِّرات المُعرَّفة داخل برنامج فرعي معين، والمَعروفة باسم المُتَغيِّرات المحليّة (local variable)، وإنما تلك المُعرَّفة بمكان يقع خارج أيّ برنامج فرعي ضِمْن الصَنْف. تُعرَف تلك المُتَغيِّرات باسم المُتَغيِّرات العامة (global variable) أو المُتَغيِّرات الأعضاء (member variables)؛ وذلك لكَوْنهم أعضاء (members) ضِمْن الصنف (class).

مثلما هو الحال مع البرامج الفرعية، يُمكِن لأي مُتَغيِّر عضو (member variable) أن يُعرَّف بعدّه عضوًا ساكنًا (static) أو عضوًا غير ساكن (non-static). سنقتصر في هذا الفصل على الساكن منها. بدايةً، ينتمي أي مُتَغيِّر عضو، مُعرَّف باِستخدَام المُبدل static، إلى الصَنْف ذاته المُعرَّف بداخله -لا إلى كائنات ذلك الصَنْف-، فعندما يُحَمِّل مُفسر الجافا (Java interpreter) صَنْف معين، فإنه يُخصِّص مساحة بالذاكرة لكل مُتَغيِّر عضو ساكن ضِمْن ذلك الصَنْف. تُعدِّل أي تَعْليمَة إِسْناد (assignment) إلى واحد من تلك المُتَغيِّرات، وبغض النظر عن مكانها بالبرنامج، من محتوى نفس المساحة بالذاكرة، وكذلك يَلج (access) أي تعبير (expression) يَتضمَّن واحدًا من تلك المُتَغيِّرات، وبغض النظر عن مكانه بالبرنامج، إلى نفس المساحة بالذاكرة ويُعيد نفس القيمة، أيّ تتشارك البرامج الفرعية الساكنة المُعرَّفة بصَنْف ما قيم المُتَغيِّرات الأعضاء الساكنة المُعرَّفة ضِمْن نفس ذلك الصَنْف، فيُمكِن لبرنامج فرعي مُعين ضَبْط قيمة مُتَغيِّر عضو ساكن ما، بحيث يَستخدِمها برنامج فرعي آخر، وهو ما يَختلِف عن المُتَغيِّرات المحليّة المُعرَّفة (local variable) داخل أحد البرامج الفرعية؛ حيث تَتوفَّر فقط بينما يُنفَّذ ذلك البرنامج الفرعي، ثم لا يَعُدْ بالإمكان الوُلوج إليها (inaccessible) من خارج ذلك البرنامج الفرعي.

تتشابه تَعْليمَة التَّصْريح (declaration) عن مُتَغيِّر عضو (member variable) مع تلك المَسئولة عن التَّصْريح عن أي مُتَغيِّر محليّ تقليدي باستثناء شيئين. الأول هو وقوع التَّصْريح عن المُتَغيِّر العضو بمكان خارج أي برنامج فرعي (مع ذلك ما يزال التَّصْريح ضِمْن الصَنْف نفسه)، والثاني هو إمكانية اِستخدَام المُبدلات (modifiers) مثل static و public و private ضِمْن التَّصْريح. يقتصر هذا الفصل على الأعضاء الساكنة فقط، ولهذا ستَتضمَّن أي تَعْليمَة تَّصْريح عن مُتَغيِّر عضو (member variable) المُبدل static، وربما قد يُستخدَم أيًا من المُبدلين public أو private. على سبيل المثال، انظر التالي:

static String usersName;
public static int numberOfPlayers;
private static double velocity, time;

إذا لم تَستخدِم المُبدل private ضِمْن تَعْليمَة التَّصْريح عن مُتَغيِّر عضو ساكن معين، فإنه يُعامَل افتراضيًا كعضو عام public، أي يُمكن الوُلوج إليه بأي مكان سواء من داخل الصَنْف المُعرَّف به أو من خارج ذلك الصنف. ولكن لاحِظ أنك ستحتاج إلى اِستخدَام مُعرِّف (identifier) مُركَّب على الصورة . عند محاولة الإشارة إليه من خارج الصَنْف. فمثلًا، يحتوي الصَنْف System على مُتَغيِّر عضو ساكن عام اسمه هو out، لذلك تستطيع الإشارة إلى ذلك المُتَغيِّر باِستخدَام System.out بأيّ صَنْف خاص بك. مثال آخر هو المُتَغيِّر العضو الساكن العام Math.PI بالصَنْف Math. مثال أخير، وبفَرْض أن لدينا الصَنْف Poker، والذي يُصَرِّح عن مُتَغيِّر عضو ساكن عام، وليَكُن numberOfPlayers، فإنه يُمكِن الإشارة إلى ذلك المُتَغيِّر داخل الصَنْف Poker ببساطة باِستخدَام numberOfPlayers، في المقابل، يُمكِن الإشارة إليه باِستخدَام Poker.numberOfPlayers من خارج الصَنْف.

والآن، لنضيف عدة مُتَغيِّرات أعضاء ساكنة إلى الصَنْف GuessingGame الذي كتبناه مُسْبَّقًا بهذا القسم: أولًا، المُتَغيِّر العضو gamesPlayed بهدف الاحتفاظ بعَدَدَ المباريات التي لعبها المُستخدِم إجمالًا. ثانيًا، المُتَغيِّر العضو gamesWon بهدف الاحتفاظ بعَدَدَ المباريات التي كَسَبها المُستخدِم. يُصَرَّح عن تلك المُتغيرات كالتالي:

static int gamesPlayed;
static int gamesWon;

ستَزداد قيمة المُتَغيِّر gamesPlayed بمقدار الواحد دائمًا مع كل عملية اِستدعاء للبرنامج playGame()‎، بينما ستَزداد قيمة المُتَغيِّر gamesWon بمقدار الواحد في حالة فوز المُستخدِم بالمباراة فقط، ثم تُطبَع قيمة المُتَغيِّرين بنهاية البرنامج main()‎. لمّا كان ضروريًا لكِلا البرنامجين الفرعيين playGame()‎ و main()‎ أن يَلجا إلى نفس قيمتي المُتَغيِّرين، فإنه يَستحِيل اِستخدَام المُتَغيِّرات المحليّة للقيام بنفس الشيء؛ ففي الواقع، يَقتصِر الولوج إلى قيمة مُتَغيِّر محليّ معين على برنامج فرعي وحيد، هو البرنامج الفرعي الذي عَرَّفه، وضِمْن نفس الاستدعاء؛ حيث تُسنَد قيمة جديدة للمُتَغيِّرات المحليّة (local variables) مع كل عملية استدعاء للبرنامج الفرعي الشامل لها، وهو ما يَختلِف عن المُتَغيِّرات العامة (global variables)، والتي تَحتفِظ بنفس قيمها بين كل استدعاء والاستدعاء الذي يَليه.

تُهيَئ (initialized) المُتَغيِّرات الأعضاء تلقائيًا بقيم افتراضية بعد التَّصْريح عنها، وهو ما يَختلِف عن المُتَغيِّرات المحليّة ضِمْن البرامج الفرعية، والتي لابُدّ من إِسْناد قيمة لها صراحةً قَبْل اِستخدَامها. تلك القيم الافتراضية هي ذاتها القيم الافتراضية لعناصر المصفوفات، فتُسنَد القيمة صفر افتراضيًا إلى المُتَغيِّرات العددية، بينما تُسنَد القيمة false للمُتَغيِّرات من النوع boolean، في حين يُسنَد المحرف المقابل لقيمة ترميز اليونيكود (Unicode code)‏ ‎\u0000 للمُتَغيِّرات من النوع المحرفي char، أما القيمة الافتراضية المبدئية للكائنات (objects)، كالسَلاسِل النصية من النوع String، فهي القيمة الفارغة null.

لمّا كان المُتَغيِّرين gamesPlayed و gamesWon من النوع int، فإنهما يُهيَئا أتوماتيكيًا إلى القيمة المبدئية صفر، وهو ما تَصادَف أن يَكُون القيمة المبدئية المناسبة لمُتَغيِّر يُنوَى اِستخدَامه كعَدَّاد (counter). مع ذلك، إذا لم تُناسبك القيمة المبدئية الافتراضية أو حتى إذا كنت تُريد مُجرد التَّصْريح عن نفس القيمة المبدئية لكن بصورة أكثر وضوحًا، فما يزال بإمكانك إِجراء عملية إِسْناد إلى أي من تلك المُتَغيِّرات ببداية البرنامج main()‎.

اُنظر نسخة البرنامج GuessingGame.java بَعْد التعديل:

import textio.TextIO;

public class GuessingGame2 {

    static int gamesPlayed;   // العدد الإجمالي للمباريات
    static int gamesWon;      // عدد المباريات التي فاز فيها المستخدم

    public static void main(String[] args) {
       gamesPlayed = 0;
       gamesWon = 0;  // لا فائدة فعلية من ذلك لأن الصفر هو القيمة الافتراضية
       System.out.println("Let's play a game.  I'll pick a number between");
       System.out.println("1 and 100, and you try to guess it.");
       boolean playAgain;
       do {
          playGame();  // استدع البرنامج الفرعي للعب مباراة
          System.out.print("Would you like to play again? ");
          playAgain = TextIO.getlnBoolean();
       } while (playAgain);
       System.out.println();
       System.out.println("You played " + gamesPlayed + " games,");
       System.out.println("and you won " + gamesWon + " of those games.");
       System.out.println("Thanks for playing.  Goodbye.");
    } // end of main()            

    static void playGame() {
        int computersNumber; // العدد العشوائي
        int usersGuess;      // إحدى تخمينات المستخدم
        int guessCount;      // عدد تخمينات المستخدم

        gamesPlayed++;  // أزد العدد الإجمالي للمباريات
        computersNumber = (int)(100 * Math.random()) + 1;

        guessCount = 0;
        System.out.println();
        System.out.print("What is your first guess? ");
        while (true) {
           usersGuess = TextIO.getInt();  // اقرأ تخمين المستخدم
           guessCount++;
           if (usersGuess == computersNumber) {
              System.out.println("You got it in " + guessCount
                      + " guesses!  My number was " + computersNumber);
              gamesWon++; 
              break;  // انتهت المباراة بفوز المستخدم
           }
           if (guessCount == 6) {
              System.out.println("You didn't get the number in 6 guesses.");
              System.out.println("You lose.  My number was " + computersNumber);
               break;  // انتهت المباراة بخسارة المستخدم
           }
           // بلغ المستخدم عما إذا كان تخمينه أكبر أم أصغر من العدد
           if (usersGuess < computersNumber)
              System.out.print("That's too low.  Try again: ");
           else if (usersGuess > computersNumber)
              System.out.print("That's too high.  Try again: ");
        }
        System.out.println();
    } // ‫نهاية البرنامج الفرعي playGame

} // ‫نهاية الصنف GuessingGame2

بالمناسبة، لم يُستخدَم أي من المُبدلين public و private مع البرامج الفرعية أو المُتَغيِّرات الساكنة static بالأعلى، فما الذي يَعنيه ذلك؟ في الواقع، إذا لم يُخصَّص أي مُبدل وصول (access modifier) لمُتَغيِّر عام (global variable) أو لبرنامج فرعي (subroutine)، فإنه يُصبِح قابلًا للوصول بأيّ مكان يقع ضِمْن حزمة (package) الصَنْف الحاضن له، ولكن ليس بأي حزم آخرى. تقع الأصناف التي لا تُصَرِّح عن وجودها ضِمْن حزمة معينة بالحزمة الافتراضية (default package)، لذا تستطيع جميع الأصناف ضِمْن الحزمة الافتراضية -وهو ما يَشمَل أغلبية الأصناف بهذا الكتاب- الوصول إلى كِلا المُتَغيِّرين gamesPlayed و gamesWon وكذلك استدعاء البرنامج الفرعي playGame()‎. مع ذلك، يُعدّ اِستخدَام المُبدل private أثناء التَّصْريح عن كُلًا من المُتَغيِّرات الأعضاء والبرامج الفرعية عمومًا واحدًا من الممارسات الجيدة إلا إذا كان هناك سببًا يَدعوك لمخالفة ذلك، كما يُفضَّل تَجَنُّب اِستخدَام الحزمة الافتراضية (default package).

ترجمة -بتصرّف- للقسم Section 2: Static Subroutines and Static Variables من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

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

في الواقع، البرامج الفرعية (subroutine) هي أشبه ما تَكُون بـ"صندوق أسود (black box)"؛ لا يُمكِنك رؤية ما بداخله، أو بتعبير أدق، لا ترغب برؤيته؛ لأنك إذا فعلت، فستكون مُضطرًا للتعامل مع ذلك الكم الهائل من التعقيد الذي يُفْترَض لذلك البرنامج الفرعي إخفائه بالأساس. على الجانب الآخر، لا يُمكِن أن يَقْتصِر ذلك الصندوق على عالمه الداخلي، وإلا سيكون عديم الفائدة، بل ينبغي له التَفاعُل مع العالم الخارجي، ولهذا فإنه يحتاج إلى ما يُشبه الواجهة (interface) التي تَسمَح بتَفاعُل ما بداخل الصندوق مع ما هو خارجه. على سبيل المثال، قد يُوفِّر صندوق أسود مادي عدة أزرار قابلة للضغط، أو قرص قابل للضبط، أو عدة فتحات لتمرير المعلومات جيْئةَ وذَهابًا. يحاول الصندوق عمومًا التخلص من التعقيد بإخفائه، ولذلك فإن القاعدة الأولى لأيّ صندوق أسود هي كالتالي: "ينبغي لواجهة (interface) أيّ صندوق أسود أن تَكُون مُبسَّطة، وسَهلة الفهم، ومُعرَّفة بصورة جيدة."

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

يُسمَى الجزء الداخلي من الصندوق الأسود بالتَّنْفيذ (implementation)، والذي قد يَتمثَل في صورة مجموعة الالكترونيات داخل عُدَّة التلفاز أو في صورة شيفرة البرنامج الفرعي الفعليّة المسئولة عن تَّنْفيذ مهمة البرنامج، وعليه تَكُون القاعدة الثانية لأيّ صندوق أسود كالتالي: "لا حاجة لمَعرِفة أيّ شيء عن الجزء التَّنْفيذي (implementation) الخاص بصندوق أسود لكي تَتَمكَّنْ من اِستخدَامه، وإنما يَكفيك مَعرِفة واجهته (interface)."

تستطيع عمومًا إعادة كتابة الجزء التَّنْفيذي (implementation) لبرنامج فرعي معين طالما لم تتأثر واجهته بذلك التَغْيِير. على سبيل المثال، عندما تغَيَّرت عُدَّة التلفاز الداخلية من اعتمادها على الصمامات المُفْرغَة (vacuum tubes) إلى الترانزستور (Transistor)، لَمْ يَكُن هناك داعي لمَعرِفة أي شيء عن ذلك أو مَعرِفة حتى ما قد يَعنِيه، وبالمثل، يُمكِن إعادة كتابة الجزء الداخلي لأيّ برنامج فرعي؛ ربما بهدف كتابة شيفرة أكثر كفاءة، وذلك بدون إِحداث أي تَغْيِير على البرامج المُستخدِمة لذلك البرنامج الفرعي (subroutine).

تَحَصُّلك على صندوق أسود يَعنِي بالضرورة أن شخصًا ما كان قد صمم تَّنْفيذه (implementation) وبناه، وفي الواقع، يَستفيد كُلًا من المُنفِّذ (implementor) والمُستخدِم من فكرة وجود صندوق أسود، فبالنهاية، يُمكِن اِستخدَام ذلك الصندوق بعَدََدَ لا محدود من المواضع المختلفة، والتي لا يحتاج المُنفِّذ (implementor) أن يَعلم عنها شيئًا، وإنما يَقْتصِر دوره على التأَكُّد من أن ذلك الصندوق يُنفِّذ مُهِمّته المُوكلة إليه تَّنْفيذًا صحيحًا، مع تَوْفِيره لواجهة (interface) سليمة تَسمَح للصندوق بالتَفاعُل مع العالم الخارجي. وعليه تَكُون القاعدة الثالثة لأيّ صندوق أسود كالتالي: "لا يحتاج مُنفِّذ صندوق أسود معين مَعرِفة أيّ شيء عن تلك الأنظمة الأكبر التي ربما قد تُوظِّف ذلك الصندوق داخلها."

يُمكِن القول أن أيّ صندوق أسود يُقسِّم العالم إلى جزئين: الجزء الداخلي أو التَّنْفيذي (implementation) والجزء الخارجي، بحيث تَقع الواجهة (interface) على الحد الفاصل بينهما وتربطهما معًا.

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

دَعْنَا نُعيد صياغة ما تَعنيه الواجهة (interface) بمصطلحات علم الحاسوب (computer science). تَتَكوَّن واجهة أيّ برنامج فرعي (subroutine) من مُكوّنين رئيسيين، الأول هو تَوصِيف صياغي أو نَحوِي (syntactic specification)، والآخر تَوصِيف دلالي (semantic specification). يخبرك الأول بالكيفية التي يُسْتَدعى (call) بها ذلك البرنامج الفرعي، بينما يُحدِّد الثاني المُهِمّة (task) المُوكَلة لذلك البرنامج والتي يُفْترَض له إنجازها. لابدّ من مَعرِفة التوصيف الصياغي (syntactic specification) لبرنامج فرعي معين؛ وذلك لاستدعائه استدعاءً سليمًا، بينما لابُدّ من مَعرِفة توصيفه الدلالي (semantic specification)؛ وذلك لفهم الغرض منه، واِستخدَامه بطريقة فعالة. عادةً ما يُستخدَم مصطلح المواصفة الاصطلاحية للبرنامج الفرعي (contract of subroutine) للإشارة إلى مُكوّني الواجهة -الصياغي والدلالي- معًا.

تقول المواصفة الاصطلاحية (contract) لأيّ برنامج فرعي: "ها هو ما ينبغي القيام به لإستدعائي، وها هو ما سأُنْجِزُه بالمقابل". ينبغي للتعليقات (comments) المكتوبة لبرنامج فرعي معين أن تُبرز مُواصفته الاصطلاحية بصورة واضحة، وهو في الواقع ما لا يَحدُث عمليًا، مما يُؤدي إلى انزعاج المبرمجين الذين قد يكونوا مُضطرّين لاِستخدَام ذلك البرنامج الفرعي.

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

تَذكَّر دائمًا أن البرامج الفرعية (subroutines) ليست الصناديق السوداء الوحيدة بعالم البرمجة. على سبيل المثال، يُعدّ الصنف (class) صندوقًا أسودًا، يَتكوَّن من جزئين، أحدهما عام (public) يُمثِل واجهته (interface)، والآخر خاص (private) يُمثِل تَّنْفيذه (implementation) الخَفي. تَنْطَبِق مبادئ الصناديق السوداء عمومًا على كُلًا من الأصناف (classes) والبرامج الفرعية (subroutines).

ترجمة -بتصرّف- للقسم Section 1: Black Boxes من فصل Chapter 4: Programming in the Large I: Subroutines من كتاب Introduction to Programming Using Java.

لقد تَعلَّمت، على مدار الفصلين السابقين، نوعية البرمجة المُستخدَمة أثناء كتابة برنامج فرعي وحيد (subroutine)، فيما أطلقنا عليه اسم "البرمجة في نطاق ضيق". سنُركز أكثر خلال الفصول المُتبقّية من الكتاب على بناء البرامج ضِمْن نطاق أوسع، ولكن ما يزال ما تَعلَّمته حتى الآن هو البذرة الأساسية والضرورية لكل ما ستَتَعرَّض له فيما بَعْد.

سنرى، في هذا القسم، كيف يُمكِن تطبيق ما قد تَعلَّمته خلال الفصول السابقة ضِمْن سياق برمجة واجهات المُستخدِم الرسومية (graphical user interface)، والتي تُعرَف اختصارًا باسم GUI، وهو سِّياق مُختلف نوعًا ما عما اعتدته من برامج الطرفيّة النصية. ستَعتمِد برمجة الواجهات الرسومية (GUI) سواء التي سنَتَعرَّض لها خلال هذا القسم أو خلال بقية الكتاب على منصة JavaFX، والتي تَضُمّ مجموعة من الأصناف (classes) المُستخدَمة لكتابة هذه النوعية من البرامج، أيّ أن جميع الأصناف (classes) المذكورة بهذا القسم هي جزء من منصة JavaFX، وبالتالي يَنبغي أن تقوم باستيرادها (import) إلى البرنامج حتى تَتَمكَّن من اِستخدَامها. اُنظر القسم ٢.٦ لمزيد من المعلومات عن تَصرِّيف (compiling) البرامج المُستخدِمة لمنصة JavaFX وكيفية تَشْغِيلها.

عند تَشْغِيل برامج واجهات المُستخدِم الرسومية (GUI)، ستُفتَح نافذة واحدة (window) أو أكثر على شاشة الحاسوب الخاصة بك. يُمكِنك، كمبرمج، التَحكُّم الكامل بما يَظهر على تلك النافذة، وكذلك بالكيفية التي يُمكِن للمُستخدِم التَفاعُل (interact) بها مع النافذة. سنَفْحَص خلال هذا القسم أمثلة بسيطة مثل طباعة بعض الأشكال البسيطة كالخطوط والمستطيلات على النافذة بدون أي تَفاعُل من المُستخدِم، فالنقطة المُهمّة، في الوقت الحالي، هو أن تتعرَّف على الطريقة التي تُستخدَم بها أساليب "البرمجة في نطاق ضيق" ضِمْن سياقات اخرى غَيْر برامج الطرفية المُعتمدة على النصوص، وسترى بنفسك أنه يمكن تطبيق نفس تلك الأساليب لكتابة أيّ برنامج فرعي (subroutine) وليس فقط البرنامج main.

رسم الأشكال

ستحتاج إلى أن تَكُون على دراية ببعض المفاهيم كالبكسل (pixels)، وأنظمة الإِحداثيَّات (coordinate systems)؛ كي يتَسَنَّى لك فهم الرسومات الحاسوبية (computer graphics)، ولذلك سنمر على بعض المفاهيم الأساسية سريعًا.

تتكون عامةً شاشة الحاسوب (computer screen) من مربعات صغيرة تُسمى البكسل (pixels)، مُرَتَّبة بصورة صفوف وعواميد، بدقة تَصِل عادةً إلى ١٠٠ بكسل لكل بُوصَة (pixels per inch). تَحتوِي الكثير من الشاشات حاليًا على عدد أكبر بكثير من البكسلات المَلْموسة (physical pixels) لكل بُوصَة، لدرجة أنه مِنْ المُحتمَل لبكسل منصة JavaFX أن يُشير إلى بكسل مَلْموس (physical pixel) بمثل هذه الشاشات عالية الدقة (high-resolution)، ولكنه على الأرجح يُشيِر إلى بكسل مَنطقي (logical pixel)، والتي هي وَحدة قياس تُعادِل ٠.٠١ بوصة تقريبًا.

لمّا كان باستطاعة الحاسوب التَحكُّم بلون البكسل، فإنه، في الواقع، يَرسِم (drawing) الأشكال عن طريق تَغْيِير ألوان البكسلات المُفردة (individual pixels). كل بكسل له زوج من الإِحداثيَّات (coordinates)، يُشار إليها عادة باسم الإِحداثيّ x والإِحداثيّ y، وتُستخدَم لتَحْدِيد المَوْضِع الأفقي (horizontal) والرأسي (vertical) للبكسل على الترتيب. عند الرسم بمساحة مستطيلية الشكل على الشاشة، تَكُون إِحداثيَّات البكسل بالرُكْن العُلوِي الأيسر (upper left corner) هي (٠،٠)، وبحيث تزداد قيمة الإِحداثيّ x من اليسار إلى اليمين، بينما تزداد قيمة الإِحداثيّ y من الأعلى إلى الأسفل. يُستخدَم البكسل لتَحْدِيد الأشكال وتَعرَيفها، فعلى سبيل المثال، يُعرَّف أيّ مستطيل من خلال الإِحداثيّ x والإِحداثيّ y بالرُكْن العُلوِي الأيسر للمستطيل، بالإضافة إلى كُلًا من عَرْضه (width)، وارتفاعه (height) بوَحدة البكسل.

تَعرَض مساحة الرسم (drawing area) بالصورة التالية نطاق كلًا من الإِحداثيَّات x و y، ويُمثِل العَرْض والارتفاع بها حجم مساحة الرسم بوَحدة البكسل:

بفَرْض أن مساحة الرسم (drawing area) -بالأعلى- مُكوَّنة من ٨٠٠*٥٠٠ بكسل، سيكون المستطيل، الواقع بالجزء العُلوِي الأيسر من الصورة، تقريبًا بعَرْض ٢٠٠ بكسل وارتفاع ١٥٠ بكسل، كما يَقع الرُكْن العُلوِي الأيسر (upper left corner) للمستطيل بالإِحداثيَّات (٥٠،٥٠) تقريبيًا.

يَتمّ الرسم بلغة الجافا باِستخدَام كائن سِّياق رُسومي (graphics context) من النوع GraphicsContext. يَشتمِل هذا الكائن على بعض البرامج الفرعية (subroutines)، مثل برامج (routines) لرسم الأشكال البسيطة كالخطوط، والمستطيلات، والأشكال البيضاوية، والنصوص. (عندما يَظهر النص على الشاشة، يَرسِم الحاسوب حروف النص مثلما يَرسِم أيّ أشكال آخرى). بالإضافة إلى ذلك، يَشتمِل كائن السِّياق الرُسومي (graphics context) أيضًا على مجموعة من البيانات (data)، مثل نوع الخط المُختار حاليًا للرَسْم ولونه. (يُحدِّد نوع الخط كلًا من حجم وشكل الحروف). تَشتمِل بيانات كائن السِّياق أيضًا على سطح رسم (drawing surface)، وهو ما يَتمّ الرسم عليه، وفي حالتنا، سيكون سطح الرسم هو مساحة مُحتوَى النافذة بدون الحواف (border) وشريط العنوان (title bar)، ولكن تَتوفَّر أسطح رَسْم مختلفة يمكن الرَسْم عليها أيضًا.

تُوفِّر منصة JavaFX طريقتين لرسم الأشكال: إِمّا بمَلْئ الشكل (filling) أو بتَحْدِيد حوافه (stroking). مَلْئ الشكل (filling) هو ضَبْط لون كل بكسل بداخله، أمَا تَحْدِيد حواف الشكل (stroking) فهو ضَبْط لون البكسلات الواقعة بحوافه (border)، وهو ما يُشبه عملية سَحب قلم على طول حواف الشكل، وفي هذه الحالة، تُعدّ صفات القلم -كحجمه (width/size) أو ما إذا كان يَستخدِم خط صلب (solid line) أو مُتقطِّع (dashed line)- خاصيات (properties) ضِمْن كائن السِّياق الرُسومي (graphics context). يُخصِّص كائن السِّياق الرُسومي أيضًا لونين مُنفصلين، أحدهما لمَلْئ الأشكال (filling)، والآخر لتَحْدِيد حوافها (stroking). لاحظ اقتصار بعض الأشكال -كالخطوط- على طريقة تَحْدِيد الحواف فقط.

يُستخدَم مُتَغيِّر من النوع GraphicsContext لتَمثيِل السِّياق الرُسومي (graphics context)، ويَحمِل هذا المُتَغيِّر عادةً الاسم g. ليس هذا ضروريًا بالطبع، حيث يَتوقَف اسمه بالنهاية على المُبرمج. نَعرِض هنا بعض البرامج الفرعية (subroutines) المُتوفرة ضِمْن كائن السِّياق الرُسومي g. لاحظ أن كل قيم المُعامِلات العددية هي من النوع double:

• البرنامج الفرعي g.setFill(c)‎: يَضبُط اللون المُستخدَم لمَلْئ الأشكال (filling)، حيث المُعامِل c هو كائن من الصَنْف Color. تَتوفَّر الكثير من الثوابت (constants) المُمثِلة للألوان القياسية (standard colors)، والتي يُمكِن اِستخدَامها كمُعامِل لهذا البرنامج الفرعي. تتراوح الألوان القياسية من الألوان الشائعة مثل Color.BLACK و Color.WHITE و Color.RED و Color.GREEN و Color.BLUE و Color.YELLOW، إلى بعض الألوان الغريبة مثل Color.CORNFLOWERBLUE. (يُمكِنك أيضًا إِنشاء ألوان جديدة مُخصَّصة). على سبيل المثال، إذا أردت مَلْئ الأشكال باللون الأحمر، فإنك ستَستدعِي البرنامج الفرعي g.setFill(Color.RED);‎. لاحظ أن اللون المُخصَّص أثناء الاستدعاء سيُستخدَم لجميع عمليات المَلْئ التالية وحتى الاستدعاء التالي لنفس البرنامج الفرعي، أما الأشكال المَرسومة مُسْبَّقًا فلا تتأثر بهذا التَغْيِير.

• البرنامج الفرعي g.setStroke(c)‎: يَضبُط اللون المُستخدَم لتَحْدِيد حواف الأشكال (stroking)، ويَعمَل بصورة مشابهة للبرنامج الفرعي g.setFill.

• البرنامج الفرعي g.setLineWidth(w)‎: يَضبُط حجم القلم المُستخدَم خلال عمليات تَحْدِيد الحواف التالية (stroking). لاحظ أن المُعامِل w يَستخدِم وَحدة البكسل.

• البرنامج الفرعي g.strokeLine(x1,y1,x2,y2)‎: يَرسِم خطًا مُمتدًا من إِحداثيَّات نقطة البداية (x1,y1) وحتى إِحداثيَّات نقطة النهاية (x2,y2). يُرسَم الخط باللون الأسود وبحجم ١ بكسل افتراضيًا، ومع ذلك، يُمكِنك تَخْصِيص كلًا منهما باستدعاء g.setStroke()‎ و g.setLineWidth()‎ على الترتيب.

• البرنامج الفرعي g.strokeRect(x,y,w,h)‎: يَرسِم الحواف الخارجية (stroking) لمستطيل مع جوانبه الأفقية والرأسية، بحيث يَبعُد الرُكْن العُلوِي الأيسر (top-left corner) لهذا المستطيل مسافة قدرها x بوَحدة البكسل عن الحافة اليسرى لمساحة الرسم (drawing area)، ومسافة قدرها y بوَحدة البكسل عن حافتها العُلوِية. يُحدِّد كلًا من المُعامِلين w و h عَرْض المستطيل الأفقي وارتفاعه الرأسي بوَحدة البكسل على الترتيب. يُمكِن ضَبْط لون الخط المُستخدَم وحجمه باستدعاء g.setStroke()‎ و g.setLineWidth()‎ على الترتيب.

• البرنامج الفرعي g.fillRect(x,y,w,h)‎: يَعمَل بصورة مشابهة للبرنامج الفرعي g.strokeRect()‎ باستثناء أنه يَملْئ المستطيل (filling) بدلًا من رسم حوافه الخارجية (stroking). اِستدعي g.setFill لضَبْط اللون المُستخدَم.

• البرنامج الفرعي g.strokeOval(x,y,w,h)‎: يَرسِم الحواف الخارجية لشكل بيضاوي. يُرسَم الشكل البيضاوي بحيث يَقع ضِمْن المستطيل الذي كان سيُرسَم في حالة استدعاء g.strokeRect(x,y,w,h)‎ بنفس قيم المُعامِلات. لاحِظ أنه يُمكِنك اِستخدَام نفس القيمة لكُلًا من المُعامِلين w و h لرسم حواف دائرة.

• البرنامج الفرعي g.fillOval(x,y,w,h)‎: يَعمَل بصورة مشابهة للبرنامج الفرعي g.strokeOval()‎ باستثناء أنه يَملْئ الشكل البيضاوي بدلًا من رَسْم حوافه الخارجية.

تُعدّ هذه البرامج الفرعية كافية لرَسْم بعض الصور باِستخدَام الجافا. لنبدأ بشئ بسيط مثل رَسْم عشرة خطوط متوازية، كالتالي:

نحتاج أولًا لمجموعة افتراضات هي كالتالي: سيكون طول الخطوط حوالي ٢٠٠ بكسل، والمسافة بين كل خط والخط الذي يَليه حوالي ١٠ بكسل، وأخيرًا، سنفْترِض أن نقطة بداية (start) أول خط تقع بالإِحداثيَّات (١٠٠،٥٠). الآن، كل ما نحتاج إليه لرَسْم خط هو استدعاء البرنامج الفرعي g.strokeLine(x1,y1,x2,y2)‎ بقيم مُعامِلات مناسبة. نلاحِظ أن نقطة البداية (start) لجميع الخطوط لها نفس قيمة الإِحداثيّ x ‏(x-coordinate) وتُساوِي ١٠٠، ومِنْ ثَمَّ، سنَستخدِم قيمة ثابتة تُساوِي ١٠٠ كقيمة للمُعامِل x1. لمّا كانت جميع الخطوط بطول ٢٠٠ بكسل، فإننا سنَستخدِم قيمة ثابتة تُساوِي ٣٠٠ كقيمة للمُعامِل x2. في المقابل، تَختلف إِحداثيَّات y ‏(y-coordinates) بكل خط عن الخط الذي يَليه، ولكن يُمكِننا أن نرى أن قيمة الإِحداثيّ y بنقطتي البداية (start) والنهاية (end) لكل خط منها هو نفسه، وعليه، سنَستخدِم مُتَغيِّر وحيد لكُلًا من قيمتي y1 و y2، هو المُتَغيِّر y. الآن، أصبح أمر الاستدعاء لرَسْم أحد الخيوط كالتالي g.strokeLine(100,y,300,y)‎. اِفْترَضنا قبلًا أن قيمة المُتَغيِّر y لأول خط هي ٥٠، ثم ستزداد تلك القيمة بمقدار ١٠ مع كل انتقال للخط التالي، مما يَعنِي أننا سنحتاج إلى التأكد من أن قيمة y تأخذ القيمة الصحيحة من متتالية الأعداد. يُمكِننا اِستخدَام حَلْقة تَكْرار for، كالتالي:

int y;   // ‫إحداثي y للخط
int i;   // المتغير المتحكم بالحلقة
y = 50;  // ‫تبدأ y بالقيمة 50 لأول خط
for ( i = 1; i <= 10; i++ ) {
    g.strokeLine( 100, y, 300, y );
    y = y + 10;  // ‫أزد y بمقدار 10 قبل رسم الخط التالي
}

نستطيع أيضًا اِستخدَام المُتَغيِّر y ذاته كمُتحكِّم بالحَلْقة (loop control variable). لاحِظ أن قيمة y للخط الأخير هي ١٤٠. انظر الشيفرة التالية:

int y;
for ( y = 50; y <= 140; y = y + 10 )
    g.strokeLine( 100, y, 300, y );

إذا أردت تلوين الخطوط باللون الأزرق، اِستدعي البرنامج الفرعي g.setStroke(Color.BLUE)‎ قبل رَسْمها، حيث سيُستخدَم اللون الأسود افتراضيًا إذا قُمت برَسْمها دون ضَبْط اللون. أما إذا أردت أن يَكُون حجم تلك الخطوط ٣ بكسل، اِستدعي البرنامج الفرعي g.setLineWidth(3)‎ قَبْل رَسْمها.

لننتقل إلى مثال أكثر تعقيدًا، فمثلًا، لنَرسِم عددًا كبيرًا من الدوائر بشكل عشوائي سواء فيما يَخُص مَوْضِعها (position) أو لونها. لمّا كنا على علم بعدد قليل من الألوان المُتوفرة، فإننا سنختار عشوائيًا واحدًا من الألوان التالية : الأحمر، والأخضر، والأزرق، والأصفر. سنستعمل تَعْليمَة switch بسيطة للاختيار، وذلك بطريقة شبيهة للمثال بالقسم الفرعي ٣.٦.٤:

switch ( (int)(4*Math.random()) ) {
    case 0:
        g.setFill( Color.RED );
        break;
    case 1:
        g.setFill( Color.GREEN );
        break;
    case 2:
        g.setFill( Color.BLUE );
        break;
    case 3:
        g.setFill( Color.YELLOW );
        break;
}

لمّا كنا نريد للدوائر أن تكون عشوائية التَموْضع، فسنحتاج إلى اختيار مركز الدوائر (center of circles) بصورة عشوائية. بفَرْض أن عَرْض مساحة الرسم (drawing area) وارتفاعها مُعطيين من خلال المُتَغيِّرين width و height على الترتيب، فسينبغي للمَوْضِع الأفقي (horizontal position) للمركز أن يكون قيمة عشوائية تتراوح من القيمة ٠ وحتى width-1. بالمثل، يَنبغي للمَوْضِع الرأسي (vertical position) لمركز الدائرة أن يَكُون قيمة عشوائية تتراوح من القيمة ٠ وحتى height-1. أخيرًا، ما زِلنا بحاجة لتَحْدِيد حجم الدائرة. سنكتفي، في هذا المثال، باِستخدَام نصف قطر (radius) ثابت لجميع الدوائر مُساوِي للقيمة ٥٠ بكسل. تُرسَم الدائرة باِستخدَام التَعْليمَة g.fillOval(x,y,w,h)‎، لكن، في الواقع، لا يُمثِل المُعامِلان x و y، بهذا الأمر (command)، إِحداثيَّات مركز الدائرة؛ وإنما إِحداثيَّات الرُكْن العُلوِي الأيسر (upper left corner) للمستطيل المرسوم حول الدائرة، ولهذا سنحتاج إلى تَحرِيك مركز الدائرة بمسافة قدرها يُساوِي نصف قطر الدائرة أي ٥٠ بكسل؛ وذلك للحصول على قيم x و y المُناظِرة. في المقابل، يُمثِل المُعامِلان w و h عَرْض وارتفاع المستطيل على الترتيب، واللذين ستكون قيمتهما مُساوِية لضعف نصف قطر الدائرة أي ١٠٠ بكسل بهذا المثال. تُراعِي الشيفرة التالية جميع النقاط المذكورة بالأعلى، وتُستخدَم لرَسْم دائرة عشوائية واحدة:

centerX = (int)(width*Math.random());
centerY = (int)(height*Math.random());
g.fillOval( centerX - 50, centerY - 50, 100, 100 );

لاحِظ أن الشيفرة بالأعلى تُستدَعى بَعْد استدعاء الشيفرة المسئولة عن ضَبْط اللون. تبدو الصورة عامةً بشكل أفضل بَعْد تَحْدِيد حافة الدائرة (border) باللون الأسود (stroking)، ولذلك أضيفت الشيفرة التالية:

g.setStroke( Color.BLACK );
g.strokeOval( centerX - 50, centerY - 50, 100, 100 );

وأخيرًا، للحصول على عدد كبير من الدوائر، ضُمِّنت الشيفرة بالأعلى داخل حَلْقة تَكْرار for، ونُفِّذت ٥٠٠ مرة، فكانت الرسمة الناتجة عن البرنامج كالتالي:

الرسم داخل برنامج

كما تعلم، لا يُمكِن لأيّ شيفرة بلغة الجافا أن تكون مُستقلة بذاتها، فلابُدّ لها أن تُكتَب ضِمْن برنامج فرعي (subroutine)، والذي بدوره يَكُون مُعرَّفًا داخل صَنْف (class)، ولهذا تَعرِض الشيفرة التالية التَعرِيف الكامل لبرنامج فرعي (subroutine definition)، والذي يُستخدَم لرَسْم الصورة من المثال السابق :

public void drawPicture(GraphicsContext g, int width, int height) {

    g.setFill(Color.WHITE);
    g.fillRect(0, 0, width, height); // املأ لون الخلفية بالأبيض

    // As an example, draw a large number of colored disks.
    // To get a different picture, erase this code, and substitute your own. 

    int centerX;     // ‫احداثي x لمركز القرص
    int centerY;     // ‫احداثي y لمركز القرص
    int colorChoice; // قيمة اللون العشوائي
    int count;       // المتغير التحكم بالحلقة

    for (count = 0; count < 500; count++) {

        centerX = (int)(width*Math.random());
        centerY = (int)(height*Math.random());

        colorChoice = (int)(4*Math.random());
        switch (colorChoice) {
            case 0:
                g.setFill(Color.RED);
                break;
            case 1:
                g.setFill(Color.GREEN);
                break;
            case 2:
                g.setFill(Color.BLUE);
                break;
            case 3:
                g.setFill(Color.YELLOW);
                break;
        }

        g.fillOval( centerX - 50, centerY - 50, 100, 100 );
        g.setStroke(Color.BLACK);
        g.strokeOval( centerX - 50, centerY - 50, 100, 100 );
    }

} // ‫نهاية drawPicture()

هذه هي المرة الأولى التي تَتعرَّض فيها لتَعرِيف برنامج فرعي (subroutine definition) -إلى جانب main()‎-. سنتناول هذا الموضوع تفصيليًا بالفصل التالي، ولكن سنَمر عليه سريعًا هنا، يُتيِح السَطْر الأول من التَعرِيف الولوج لبعض القيم التي يَحتاجها البرنامج الفرعي، وهي السِّياق الرُسومي g، وكلًا من عَرْض وارتفاع مساحة الرسم width و height. يَستقبِل البرنامج الفرعي هذه القيم من مصدر خارجي، ويستطيع اِستخدَامها. ما يَهمّ هنا هو أن تُدرِك أنه لكي تَرِسم شيئًا (يَقصِد الكاتب أن هذا هو هدف البرنامج الفرعي، فاِسم البرنامج الفرعي هو drawPicture)، فستحتاج فقط إلى كتابة مُحتوَى البرنامج الفرعي، مثلما تَكتُب مُحتوَى البرنامج main()‎ عند كتابة برنامج (الهدف من main()‎).

يَنبغي لتَعرِيف البرنامج الفرعي (subroutine definition) أن يَكُون بالصَنْف (class) الذي يُعرِّف البرنامج، وهو في هذه الحالة الصَنْف SimpleGraphicsStarter. شَّغِل البرنامج -مُتاح بالكامل بالملف SimpleGraphicsStarter.java- لترى الرَسمة، كما يُمكِنك اِستخدَام هذا البرنامج كنقطة بداية لرَسْم الصور الخاصة بك.

لاحِظ أنك لن تَفهم كل الشيفرة المكتوبة بالبرنامج، لكن ما يزال بإمكانك التَعديل عليها، فلا حاجة إلى فهم الشيفرة بأكملها، كل ما قد يَعَنيك هو الشيفرة الموجودة بالبرنامج الفرعي drawPicture()‎. اِحذف تلك الشيفرة، وضَعْ مكانها شيفرة الرسوم خاصتك، وستَتمكَّن بعدها من عَرْض رسوماتك.

بالمناسبة، قد تُلاحِظ أن الكلمة static مُستخدَمة بتَعرِيف البرنامج الفرعي main()‎، بعكس البرنامج الفرعي drawPicture()‎، الذي لا يَستخدِمها، وهو ما يَعنِي أن البرنامج الفرعي drawPicture()‎ موجود بكائن (object) وليس بصَنْف (class). تُعدّ البرامج الفرعية التي تَستخدِم الكلمة static بتَعرِيفعها ساكنة (static)، أما التي لا تَستخدِمها فتُعدّ غَيْر ساكنة (non-static). الفرق بينهما مُهِمّ، ولكنه ليس بالأمر الذي يَنبغي أن تَقْلَق حِياله في الوقت الحاضر؛ حيث سنتناوله تفصيليًا بالفصل الخامس على أية حال.

التحريكة (Animation)

يَعتمِد التَحرِيك الحاسوبي (computer animation) على متتالية من الصور المُنفصلة، يُطلَق على كُل منها اسم الإطار (frame). تُعرَض هذه الصور بشكل سريع واحدة تلو الآخرى، فإذا كان التَغْيِير بين كل صورة والصورة التي تَليها طفيفًا، ستبدو متتالية الصور وكأنها تَحرِيكة مُستمرة (continuous animation). يُمكِنك اِستخدَام المثال التوضيحي بالملف SimpleAnimationStarter.java كنقطة بداية، حيث يَحتوِي على البرنامج الفرعي drawFrame()‎ المَسؤول عن رَسْم إطار (frame) وحيد ضِمْن تَحرِيكة (animation)، بالإضافة إلى ذلك، يُنفَّذ البرنامج الفرعي drawFrame()‎ أتوماتيكيًا حوالي ٦٠ مرة بالثانية، مما يَضمَن استمرار عَرْض الأُطُر (frames)، أيّ أنك تستطيع إِنشاء تَحرِيكة (animation) بمُجرَّد إضافة الشيفرة إلى هذا البرنامج الفرعي. تستطيع تمييز المرة الحالية من التَّنْفيذ من خلال مُتَغيِّرين إضافيين -إلى جانب السِّياق الرُسومي وكُلًا من عَرْض وارتفاع مساحة الرسم- يَستقبِلهما البرنامج الفرعي، وهما frameNumber و elapsedSeconds؛ حيث يأخذ المُتَغيِّر frameNumber القيم ٠، ١، ٢، ٣، .. والتي تَزداد بمقدار الواحد مع كل اِستدعاء للبرنامج الفرعي، أمَا قيمة المُتَغيِّر elapsedSeconds فتُشيِر إلى عدد الثواني التي مَرَّت على تَّنْفيذ التَحرِيكة حتى الآن. إجمالًا، تَستطيع رَسْم صورة مختلفة في كل مرة يُستدَعى فيها البرنامج الفرعي (subroutine) بالاعتماد على قيمة أيًا من هذين المُتَغيِّرين.

سنَرسِم بالمثال التالي مجموعة من المستطيلات المُتداخِلة (nested rectangles)، والتي ستنكمش باتجاه مركز الرَسْمة، مما سيُعطِي انطباعًا زائفًا بوجود حركة لا نهائية (infinite motion). تَعرِض الصورة التالية إِطارًا واحدًا من التَحرِيكة (animation):

لنُفكر كيف يُمكِن رَسْم مثل هذه الصورة. عامةً، يُمكِن اِستخدَام حَلْقة التَكْرار while لرَسْم المستطيلات، بحيث تبدأ أولًا برَسْم المستطيل الخارجي، ثُمَّ تنتقل إلى الداخل وهكذا. يَنبغي الآن أن نُفكر بالمُتَغيِّرات التي سنحتاج إليها خلال حَلْقة التَكْرار (loop)، وكذلك بالطريقة التي ستَتغَيَّر بها قيم تلك المُتَغيِّرات من تَكْرار (iteration) معين إلى التَكْرار الذي يليه. ستساعدنا الملاحظات التالية على مَعرِفة تلك المُتَغيِّرات، أولًا، مع كل تَكْرار، يكون المستطيل المرسوم أصغر منه في المرة السابقة، كما أنه يَتحرك للداخل قليلًا. يتركز عامةً الفارق بين أيّ مستطيلين على حجمهما وإِحداثيَّات (coordinates) رُكْنيهما اليساريين العُلوِيين (upper left corners)، ولهذا سنحتاج، أولًا، إلى مُتَغيِّرين لتَمثيِل كلًا من عَرْض المستطيل وارتفاعه، وهما المُتَغيِّران rectWidth و rectHeight على الترتيب. أما بالنسبة لإِحداثيَّات الرُكْن الأيسر العُلوِي x و y، فيُمكِن تَمثيِل كليهما بمُتَغيِّر وحيد للمستطيل الواحد، هو المُتَغيِّر inset؛ لأن قيمتهما مُتساوِية؛ حيث يَبعُد أيّ مستطيل عن حافتي مساحة الرسم (drawing area) بنفس مقدار المسافة. نُلاحِظ أنه مع كل تَكْرار، تَنقُص قيمة كلًا من عَرْض المستطيل rectWidth وارتفاعه rectHeight، بينما تزداد المسافة inset التي يَبعُدها المستطيل عن الحافتين. أخيرًا، تنتهي حَلْقة التَكْرار while عندما يُصبِح عَرْض المستطيل أو ارتفاعه أقل من أو يُساوِي الصفر. اُنظر خوارزمية رَسْم إِطار (frame) وحيد:

// املأ مساحة الرسم باللون الأبيض
Fill the drawing area with white
// ‫اضبط قيمة inset المبدئية للمستطيل الأول الخارجي
Set the amount of inset for the first rectangle
// اضبط قيمة عرض وارتفاع المستطيل الأول الخارجي
Set the width and height for the first rectangle
// اضبط اللون المستخدم لتحديد الحواف إلى اللون الأسود
Set the stroke color to black
// طالما كان العرض والارتفاع أكبر من الصفر
while the width and height are both greater than zero:
    // ‫ارسم مستطيل باستخدام البرنامج الفرعي g.strokeRect
    draw a rectangle (using the g.strokeRect subroutine)
    // ‫أزد قيمة inset حتى ينتقل المستطيل التالي إلى الداخل
    increase the inset (to move the next rectangle over and down)
    // ‫انقص عرض وارتفاع المستطيل التالي حتى يصبح المستطيل التالي أصغر
    decrease the width and height (to make the next rectangle smaller)

ضُبطَت هذه النسخة من البرنامج بحيث يَبعُد كل مستطيل مسافة قدرها ١٥ بكسل عن المستطيل المُحيِط به، ولهذا فإن قيمة المُتَغيِّر inset تَزداد بمقدار ١٥ بكسل مع كل تَكْرار. في المقابل، يَتقَلص المستطيل حوالي ١٥ بكسل يمينًا ويسارًا، أيّ يَنقُص عَرْض المستطيل بمقدار ٣٠ بكسل. وبالمثل، يَنقُص ارتفاعه بمقدار ٣٠ بكسل مع كل تَكْرار ضِمْن الحلقة.

يَسهُل إعادة كتابة الخوارزمية بلغة الجافا، لكن تتبقَى فقط حاجتنا إلى معرفة القيم المبدئية للمُتَغيِّرات inset و width و height لأول مستطيل-(المستطيل الخارجي). لحساب ذلك، سنُفكر في حقيقة كَوْن الصورة متحركة (animated)، أي يَعتمِد ما نَرسِمه بطريقة ما على رقم الإِطار (frame number) الحالي. لمّا كان الرُكْن الأيسر العُلوِي (top-left corner) للمستطيل الخارجي يتحرك للأسفل وللداخل من أيّ إِطار إلى الإِطار الذي يَليه، فإن قيمة المُتَغيِّر inset المبدئية تزداد مع كل إِطار. قد تُفكر إذًا بضَبْط قيمة المُتَغيِّر inset المبدئية إلى القيمة ٠ بالإِطار رقم ٠، وإلى القيمة ١ بالإطار رقم ١ وهكذا. للأسف، لن يكون هذا صالحًا إلى الأبد؛ فعندما تَصِل التحريكة للإِطار ١٥، يَنبغِي أن يَظهر مستطيل خارجي جديد بمساحة الرَسْم (drawing area)، هو في الواقع ليس جديدًا، وإنما أُعيد فقط ضَبْط قيمة المُتَغيِّر inset المبدئية إلى القيمة ٠. إجمالًا، يَنبغِي لقيمة المُتَغيِّر inset أن تأخذ القيم ٠، ١، ٢، ٣،… حتى تَصِل إلى القيمة ١٤، لتُعاد الكَرَّة من جديد، وهو ما يُمكِن إنجازه باِستخدَام الشيفرة التالية:

inset = frameNumber % 15;

لاحِظ أن المستطيل يَملأ مساحة الرسم باستثناء حافة (border) تُحيِط به، عَرْضها يُساوِي قيمة المُتَغيِّر inset، أي بعبارة آخرى، عَرْض المستطيل هو عَرْض مساحة الرسم مطروحًا منه ضعف قيمة المُتَغيِّر inset، وبالمثل لارتفاعه. انظر شيفرة البرنامج الفرعي drawFrame()‎ كاملة بالأسفل والمسئولة عن تَحرِيك المستطيل:

public void drawFrame(GraphicsContext g, int frameNumber, 
                      double elapsedSeconds, int width, int height) {

    g.setFill(Color.WHITE);
    g.fillRect(0,0,width,height);  // املأ مساحة الرسم باللون الأبيض

    // المسافة بين بين المستطيل الخارجي ومساحة الرسم
    double inset; 

    double rectWidth, rectHeight;   // عرض وطول أحد المستطيلات

    // اضبط اللون المستخدم لرسم حواف المستطيل
    g.setStroke(Color.BLACK);  

    // إضافة القيمة 0.5 هو أسلوب للحصول على صورة أكثر وضوحًا
    inset = frameNumber % 15 + 0.5;  

    rectWidth = width - 2*inset;
    rectHeight = height - 2*inset;

    while (rectWidth >= 0 && rectHeight >= 0) {
        g.strokeRect(inset, inset, rectWidth, rectHeight);
        inset += 15;       // تبعد المستطيلات عن بعضها بمقدار 15 بكسل
        rectWidth -= 30;
        rectHeight -= 30;
    }

}