نکات مهم برنامه نویسی

قوانین مهمی که برنامه نویس ها باید از آن تبعیت کنند.

اندازه کلاس را کوچک نگه دارید:

من تا کنون تعداد زیادی کلاس برخورد کرده ام که بسیار بزرگ بوده اند. اما متاسفانه این نمونه کلاس ها اصلا حوب نیستند. در ادامه دلیل این موضوع را یافتم. این کلاسها کارهای زیادی را انجام می دادند و این، اصل تک مسئولیته بودن  Single Responsibility Principle را در طراحی شی گرا (SOLID (Object Oriented Design نقض می کرد. 

اصل تک مسئولیته بودن (Single Responsibility Principle) بیان می کند که هر شی باید یک مسئولیت منحصر به فرد داشته باشد، و آن مسئولیت باید مطلقا توسط کلاس محصور شود. همه ی سرویس های شی باید تقریبا در محدوده آن مسئولیت باشد. و یا بر طبق تعریف مارتین Martin’s definition : "هرگز نباید بیشتر از یک دلیل برای تغییر دادن یک کلاس وجود داشته باشد".

راستی چرا جدا کردن دو مسئولیت در دو کلاس مجزا مهم است؟ به این خاطر که مسئولیت محور تغییر است. هنگامی که نیازها تغییر پیدا می کند، آن تغییر در واقع در اثر تغییر در مسئولیت میان کلاس ها است. اگر یک کلاس با بیش از یک مسئولیت در نظر گرفته شود، آنگاه مسئولیت ها با هم مرتبط می شوند. تغییر در یک مسئولیت ممکن است منجر به این شود که کلاس نتواند سایر مسئولیت ها و کارهایش را به درستی انجام دهد. این سبک جفت شدن مسئولیتها منجر به طراحی های شکننده ای می شود که به راحتی در برابر تغییرات ناخواسته آسیب پذیر هستند.

از کامنت های بی  اثر بپرهیزید

اجازه بدهید با کامنت بی اثر شروع کنیم. بر طبق نظر Robert C. Martin

کامنتی که کهنه، نامرتبط و نادرست باشد کامنت بی اثر است. کامنت ها با سرعت زیادی کهنه می شوند. بهتر است کامنتی که کهنه و بی اثر می شود ننویسیم. بهتر است هر چه سریعتر کامنت بی اثر را ویرایش کنیم و یا از شر آن راحت شویم. کامنت های بی اثر و کهنه جزیره هایی شناور از مسائل منحرف کننده و نامرتبط با کد می شوند.

جملاتی که در ادامه می آید موضوعی است که نقل صحبت برنامه نویس ها در مورد کامنت است. از نوشتن کامنت روی یک متد منحصر به فرد یا کلاس کوتاه بپرهیزید. به این دلیل که اکثر کامنت هایی که بنده تا کنون دیده ام در صدد بوده اند تا هدف کد را توصیف کنند. برخی از اوقات کامنت ها بی معنا هستند. برنامه نویس ها کامنت می نویسند تا خوانایی و معناداری کد را افزایش دهند. مطمئن شوید که کامنت های شما باعث ایجاد نویز نشود. بهتر است به جای اینکه کامنت بنویسید نام متد را در صورت امکان با معنا تر بنویسید، به این دلیل توصیه می کنم که نام متد موثرتر از کامنت است. اکثر کامنت ها چیزی جز نویز بی معنا نیستند. اجازه دهید کامنت های زیر را بررسی کنیم.

//ensure that we are not exporting
//deleted products
if(product.IsDeleted && !product.IsExported )
{
   ExportProducts = false;

}

// This is a for loop that prints the 1 million times
for (int i = 0; i < 1000000; i++)
{
    Console.WriteLine(i);
}

اگر به جای نوشتن کامنت برای یک متد، آن را مانند  ()CancelExportForDeletedProducts نامگذاری کنیم، چه اتفاقی می افتد؟ بنابراین، نام متد موثر تر از کامنت است. متدها اجرا می شوند و واقعی هستند. 

این برداشت به وجود نیاید که بنده تاکید دارم که پرهیز از کامنت در تمام اوقات یک باید است. بر طبق نظر کنت، کامنت را به صورت کلی برای توصیف این که کل داستان چه کاری انجام می دهد بگذارید نه این که روی تک تک متدها و حتی خطهای کد. اگر کامنت در صدد بود همه چیز را توصیف کند آنگاه اشتباه است. اگر شما با کدی که حجم زیادی کامنت دارد مواجه شدید، بدین معناست که اکثر کامنت ها در کد حاضر شده اند چون کد، کد خوبی نیست. برای اطلاعات بیشتر در این مورد می توانید کتابهای زیر را مطالعه فرمایید:

• Professional Refactoring in C# and ASP.NET by Danijel Arsenovski 
• "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, don Roberts

از نواحی غیر ضروری در کلاسهای خود اجتناب کنید.

نواحی یکی از ویژگی های ویژوال استودیو است که به شما اجازه می دهد که بلوکهایی از کد را در آن محصور کنید. این ناحیه می تواند متشکل از یک یا چند متد باشد. ناحیه باعث می شود که در فایلهای بزرگ راحت تر چرخ بزنیم. نواحی، زشتی کدهای زیاد را مخفی می کند و آن را تمیز می کند. اگر یک کلاس چیزهای زیادی را داشت، یادمان باشد که اصل تک مسئولیته بودن را نقض کرده است. بنابراین هروقت که خواستید یک ناحیه جدید را به کدتان اضافه کنید، یک گام عقب برگردید و از خودتان بپرسید که آیا این امکان وجود دارد که ناحیه را در یک کلاس مجزای دیگر بگذرایم.

• قبلی
• بعدی