دانستنی‌ها

مهارت هایی فراتر از قواعد برنامه نویسی (قسمت اول)

در [1] تعدادی از رویه های عملیاتی (practices) مفید برای برنامه نویسی به زبان جاوا ارائه شده اند. یکی از این رویه ها (Wisdom, not rules) به این موضوع پرداخته است که برنامه نویسان ماهر بر مبنای تجربه ای که کسب کرده اند برخی از قواعد برنامه نویسی (که در شروع یادگیری برنامه نویسی رعایت می کردند) را خردمندانه رعایت نمی کنند. به بیان دیگر، برنامه نویسان با تجربه دید کل نگر قوی تری دارند و قواعد برنامه نویسی را با سنجیدن جوانب مختلف اعمال می کنند و صرفاً پیش شرط های اعمال قواعد برنامه نویسی را در نظر نمی گیرند.

برخی از برنامه نویسان تجارب مفید برنامه نویسی را در قالب رویه های عملیاتی به اشتراک می گذارند. یکی از رویه های عملیاتی ارائه شده در [1] در ادامه ی این مطلب توضیح داده شده است. در مطالب ارسالی بعدی، برخی دیگر از رویه های عملیاتی توضیح داده خواهند شد.

 

رابطه ی وراثت را با دقت تعریف کنید: توجه داشته باشید که وراثت تنها مکانیزم استفاده ی مجدد (reuse) نیست و در صورتی که بین یک نمونه از زیر کلاس (subclass) و یک نمونه از فوق کلاس (superclass) رابطه ی “is-a” برقرار نباشد نمی توان رابطه ی وراثت را صرفاً برای استفاده ی مجدد به کار برد. به مثال ساده ی زیر دقت کنید [2]:

 

 

 

حالت اول:

class Fruit {

}

class Apple extends Fruit {

//…

}

حالت دوم:

class Apple {

}

class Fruit extends Apple {

//…

}

حالت سوم:

class Fruit {

}

class Apple {

private Fruit fruit = new Fruit();

//…

}

در این مثال، حالت دوم اشتباه است (از نظر منطق استفاده از رابطه ی وراثت و نه از نظر نحوی) زیرا از نظر منطق برنامه ی مورد نظر ما یک سیب نوعی میوه است و نه برعکس. در صورتی که وراثت تنها برای استفاده ی مجدد تعریف شده باشد نیز حالت سوم بر حالت اول ارجحیت دارد. در حالت سوم از رابطه ی ترکیب composition)) استفاده شده است؛ یعنی به جای تعریف رابطه ی وراثت، کلاس Apple از طریق یک شئ از نوع کلاس Fruit از سرویس هایی که کلاس Fruit ارائه می کند، استفاده می کند. از جمله دلایل ارجحیت حالت سوم به حالت اول می توان به این موارد اشاره کرد:

          در حالت سوم نیازی به تکامل همزمان دو کلاس نیست (تمام تغییرات کلاس Fruit به کلاس Apple منعکس نمی شوند).

          وابستگی بین دو کلاس خیلی کم تر است.

          حالت سوم انعطاف پذیرتر است چون در زمان اجرا با یک شئ کار می کند و در زمان ترجمه (compile) به صورت ایستا (static) تعریف نشده است.

 

منابع:

[1] http://www.javapractices.com

[2] http://www.javaworld.com

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا