آیا تا حالا پیش اومده که چند بار بیاید یه کد رو بنویسید؟ اگر پیش اومده کمربندهاتون رو ببندید که میخوایم بریم یه روش جدید برای بهینه کردن این داستان بهتون بگم.
خوب اسم این روش DRY هستش که کمکمون میکنه که به جایی این که بیشتر کد بزنیم عاقلانه تر کد بزنیم.
خوب همونطوری که توی کد بالا میبینید یه قسمتی از مراحل درست کردن چای و قهوه شبیه هم هستش.
مثل این که آب رو جوش میاریم و بعدش بهش شکر اضافه میکنیم و در آخر هم قهوه یا چای رو بهش اضافه میکنیم.
خوب این نمونه کد با استفاده از DRY هستش. خوب حالا ما اومدیم اینجا چی کار کردیم؟
اومدیم اون قسمت از لاجیک درست کردن چای و قهوه رو که یکی بودن و در دوجا تکرار شده بودن رو تبدیل کردیم به یه جا. یعنی الان توی یک قسمت از کد داریم آب جوش رو درست میکنیم و اگر نیاز به شکر بود بهش اضافه میکنیم و در قسمت های بعدی هم فقط چیز های که مشخص مربوط به درست کردن قهوه و چای هستش رو نوشتیم.
حالا مزیتش چیه ؟ یکیش اینه که هر وقت بخوایم لاجیک BoilWaterAndAddSugar رو تغییر بدیم سریع میریم توی اون قسمت و تغییرات رو اعمال میکنیم و این تغییرات از اون به بعد هم برای قهوه اعمال میشه و هم روی چای در صورتی که اگر همچنان از راه قبلی میرفتیم برای تغییر این لاجیک باید دو جا رو تغییر میدادیم
حالا مزیت دیگش اینه که اگر بعدا بخوایم دمنوش هم درست کنیم باز هم میتونیم از کد آب جوش استفاده کنیم.
In the context of C#, the DRY principle aims to avoid repetition by replacing duplicate logic or code snippets with shared methods or classes. It promotes creating reusable components so that future changes need to be implemented in only one place.
یکی از پایه و اساس DRY این هستش که از نوشتن کد تکراری پرهیز کنیم و همه اون لاجیک هایی که تکرار شونده هستند رو در یک جا مثل کلاس یا متد جمع کنیم. کامپوننت هایی بسازیم که اگر در آینده تغییر اتفاق افتاد بتونیم اون تغییرات رو فقط در یکجا اعمال کنیم.
حالا برای این که این موضوع رو بهتر درک کنیم بیاید خودمون رو توی شرایط بحرانی در نظر بگیریم که برای اتمام یه تسک به صورت ماراتونی کد زدیم تا فیچر رو برسونیم ولی بعد از اتمامش po میخواد که یه فیچر دیگه رو هم بهش اضافه کنیم حالا اگر از این روش DRY کدهامون رو ننوشته باشیم حالا باید دوباره شروع کنیم دوباره کد رو خوندن و تحلیل کردن که کجا چی کار کردیم و چه شد و چه شد ...
ولی با استفاده از DRY همه کد تر رو تمیزه ، نگهداری کد راحت تره ، راحت تر میتونیم بهش فیچر اضافه کنیم و خواناییش هم قطعا بیشتره .
یکی از مثال های دیگه رو که میزنن اینه که فرض کنید که دنبال یه کتاب توی یه کتابخونه ی خیلی بزرگ هستید طبیعتا وقتی که اون کتابخونه کتابهاش رو با توجه به موضوع طبقه بندی کرده راحت تر میتونید کتاب مورد نظرتون رو پیدا کنید.
حالا یه مورد دیگش اینه که میخوایم یه function بنویسیم که به ما یه گزارشی تحویل بده، حالا فرض کنید 2 تا گزارش داریم و برای هر کدومش نیاز داریم که اطلاعات رو از database بگیریم، حالا توی این مورد متوجه میشیم که اگر بخوایم 2 تا کد جدا بنویسیم برای دسترسی به دیتا بیس، کدمون بیشتر میشه، احتمال خطا بیشتره و ...
حالا برای پیاده سازی با روش DRY میتونیم فقط برای دسترسی پیدا کردن به دیتا بیس یه متد بنویسیم و لاجیک هر کدوم از پردازش و گزارش ها رو جدا بنویسی:
قبل و بعد از استفاده از روش DRY
ببینید در خیلی از موارد وقتی که ما شروع میکنیم به نوشتن یه برنامه اوایلش خیلی خوب و سر راست همه کد ها رو میزنیم و میریم جلو ولی وقتی که لاجیک برنامه پیچیده میشه و زیاد میشه مشکلات شروع میشن ولی با روش DRY میتونیم از این مشکلات جلوگیری کنیم.
میتونیم اینجوری به این روش نگاه کنیم که مثل قطعات لگو عمل میکنه که میتونیم با قطعات کوچک یه بنای خیلی بزرگ درست کنیم.
حالا یه مثال دیگه : فکر کنید میخوایم یه ماشین حساب درست کنیم
یه مورد دیگه اینه که DRY کمکمون میکنه که کد تکراری نزنیم، اینم مثالش :
Techniques to Avoid Code Repetition in C#
برای این که یک بار نخوایم یه کد رو بیشتر بزنیم و کد تکراری نزنیم بهترین دوست های ما فانکشن ها و متد ها هستن که کمکمون میکنن.
مورد بعدی استفاده کردن از Inheritance and Polymorphism
خوب Inheritance بهمون این امکان رو میده که یه کلاس بسازیم و بعدش بیایم از اون کلاس sub class بسازیم که همین کار باعث میشه که کد کمتری بزنیم.
Utilize Loop Structures
قسمت هایی از کد رو که میشه لوپ زد
خوب حالا با استفاده از این روش هایی که نوشتیم و تمرین کردنشون میتونیم یه کد خوب بنویسیم.
Pitfalls and Misunderstandings of DRY Principle in C#
قبل از این که بخوایم هر تیکه کدی که بیشتر از یه بار نوشته شده رو abstract و خلاصه کنیم یه سری مطالب رو باید بدونیم.
When Not to Use DRY Principle in C#
چه موقع هایی نباید از DRY استفاده کنیم؟
طبیعتا این همه نوشتیم که خیلی خوبه و عالی ولی یه جاهایی نباید ازش استفاده کنیم. اگر بخوایم دو مدل sort رو بر اساس نوع array انجام بدیم. میتونیم خیلی راحت فانشکن های هر کدومشون رو جدا بنویسیم و استفاده کنیم. خوب حالا توی این حالت استفاده از DRY باعث میشه که خوانایی کدمون کمتر بشه و پیچیدگیش بیشتر.
شاید اینجا به نظرتون اتفاقا کار خوبی کردیم که از DRY استفاده کردیم ولی در حقیقت با بزرگتر شدن و پیچیده تر شدن لاجیک شاید مجبور بشیم یه سری متد رو به عنوان پارامتر ارسال کنیم که همین کار هم باعث بدتر شدن کد میشه.
این رو باید یادمون باشه که ما از این روش استفاده میکنیم که کدمون بهتر و خوانا تر بشه اگر استفاده از این روش باعث بشه که کدمون پیچیده تر و ناخوانا تر بشه همون بهتره که از این روش استفاده نکنیم.
