تا حالا به متد های private static فکر کردی؟

توی یه مقاله ی خیلی کوچولو میخوام این متد ها رو از دیدگاه Clean Code بررسی کنم!!!

همون طور که میدونی هر کلاس میتونه یه سری Field و همچنین یه سری Method داشته باشه. این ها به دو دسته تقسیم میشن:

• Instance Fields and Instance Methods
• Static Fields and Static Methods

همچنین میدونیم که Instance Field ها و Instance Method ها در سطح Object های ساخته شده از class قابل استفاده هستن و Static Field ها و Static Method ها در سطح خود class.

نکته ی مهم دیگه اینه که داخل یه Instance Method میتونیم از Static Method ها استفاده کنیم, ولی داخل Static Method ها نمیتونیم از Instance Method ها استفاده کنیم. (دلیلش هم کاملن واضحه)

خب این ها چیزایی بودن که از قبل میدونستیم و فقط مرورشون کردیم.

حالا وقتی از یه جنبه ی دیگه به یه کلاس نگاه میکنیم, دو نوع متد رو داخل کلاس میتونیم داشته باشیم:

• public
• private

متد های public یه جورایی Observable Behavior هستن و از بیرون قابل دسترسی هستن و متد های private هم, Implementation Detail هستن و از بیرون قابل دسترسی نیستن و فقط توسط متد های public خود کلاس استفاده میشن.

تا اینجا همه چی بدیهیات بود!!! درسته؟

حالا فرض کنیم که یه سری متد private داخل کلاسمون داریم. private بودنشون, نشون میده که Implementation Detail هستن. از طرفی این متد ها میتونن دو نوع باشن:

• static
• غیر static

شباهت اینا در چیه؟

شباهتشون اینه که هر دو private هستن. پس در نتیجه هر دو implementation Detail هستن و از بیرون قابل دسترسی نیستن و فقط توسط متد های public خود کلاس استفاده میشن.

تفاوت اینا در چیه؟

تفاوت شون اینه که یکی static هست و یکی دیگه غیر static!!!

خب؟

خب که خب!!!

اونی که غیر Static هست میتونه از Instance Field های کلاس استفاده کنه و اون ها رو تغییر بده و در نتیجه state کلاس رو تغییر بده.

ولی اونی که Static هست, در نقطه ی مقابل قرار داره و نمیتونه از Instance Field های کلاس استفاده کنه و touch شون کنه و در نتیحه نمیتونه state کلاس رو تغییر بده.

نتیجه

اگه متدهای private ای داخل کلاس داشتیم که هیچ کدوم از Instance Filed های کلاس رو touch نمیکردن, میتونیم اون ها رو static کنیم و از حالا به بعد اون متد ها private static باشن.

مزیت این کار چی میتونه باشه؟

خب از private بودنشون که متوجه میشیم که Implementation Detail هستن و همچنین از static بودنشون هم میفهمیم که هیچ کدوم از Instance Filed های کلاس رو touch نمکینن و از این رو وقتی با این متد ها روبرو میشیم, سریع میتونیم بفهمیم که داستان چیه و لازم نیست که داخلشون رو بگردیم و کدهای داخلش رو بخونیم تا متوجه بشیم که چه بلایی سر Instance Filed های کلاس میاره!!!

static کردن کار خوبی نیست!!!

از طرفی توی مغزمون کردن که static کردن کار خوبی نیست و مموری رو خراب میکنه!!!

ولی خیلی وقت ها و در عمل این اتفاق نیموفته.

به هر حال باید trade-off کنیم . اگه static کردن مشکل درست میکنه, این کار رو نکنیم. ما صد در صدی حرف نمیزنیم و نمیگیم که توی صد در صد موارد این کار رو بکن یا نکن. به هر حال انسانیم و میتونیم فکر کنیم و ببینیم که static کردن فلان متد مضره یا نه. چقدر برامون نفع داره (از جنبه ی clean شدن کد) و چقد ضرر داره (از جنبه ی performance) و سبک و سنگین کنیم.

در اکثر مواقع مشکل performance ای نمگیریم و clean شدن کد غلبه میکنه. ولی به هر روی باید فکر کنی!!!

به جای این کار باید یه اسم خوب برای متد انتخاب کنیم!!!

ممکنه یه نفر بگه به جای static کردن متد (private static) باید یه اسم خوب برای متد انتخاب کنیم و اون اسم همه چیز رو در مورد اینکه ایا متد Instance Field ها رو touch میکنه یا نه بهمون بگه.

درسته.

اسم خوب همیشه اولویته.

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

من منکر انتخاب اسم خوب نیستم, ولی خب به هر حال اینم (static کردن) یه روشیه دیگه. مگه نه؟

امیدوارم برات مفید بوده باشه.

تا یه مقاله ی کوچولو و یه نکته ی ریزه میزه دیگه خدانگهدار…