توی این فصل چنتا اصل خوب و شیک برای نحوه نوشتن کلاس هامون توی کد، اومده. اگر از طرفدارای پر و پا قرص برنامه نویسی شی گرا هستید و تا الان حس میکردید کلاس هاتون کلاس کاری مناسب رو نداشتن، این فصل مخصوص شماست !
به طور معمول استیل کار ما اینه که توی کلاس همه چیز رو پرایوت نگه داریم ولی خب خیلی نباید روش تعصب داشت. گاهی مجبوریم بعضی از توابع رو برای تست هاشون دسترسی بدیم . اوکیه.
شاهد کول بازیای نویسنده هستیم همچنان:
قانون اول: کلاس ها باید کوچولو باشن
قانون دوم: کلاس ها باید کوچولوتر از قانون اول باشن حتی !
هر کلاس باید یک مسئولیت داشته باشه دلیلش هم اینه که فقط یک دلیل باید باعث بشه که کد کلاس عوض بشه
تعداد متغیرهای کلاس باید کم باشه و توابع کلاس نباید بیشتر از یکی دوتا ازین منغیر هارو تغیر بدن در طی طول عمر با برکتشون ! اینطوری تر تمیز تر و به قول عمو، منسجم تره .
حالا کی به این نقطه میرسیم که کدامون منسجم و درست باشه ؟ وقتی کلاس های عریض و طویل رو بشکنیم به کلاس های کوچولو. وقتی کوچیک باشن هم تعداد متغیرها کمتر میشن و هم میشه توابعی نوشت که فقط یکی دوتا از متغیر هارو تغیر بده.
در اکثر سیستم ها، متاسفانه تغییر زیاد اتفاق میفته چون نیازمندی عوض میشه و قاعدتا کد هم باید عوض بشه (لعنت) و این تغیرات ممکنه کاری کنن که صبح از خواب بیدار بشی ببینی دیگه هیچ چیز کار نمیکنه ( چه بد جایگاهی است ! )
حالا برای کمتر کردن این فجایع انسانی توصیه میشه که abstract classes, داشته باشیم و جزئیات رو ببریم توی پیاده سازی . اینطوری وقتی تغیری هم بوجود بیاد فقط توی اون پیاده سازی کلاس و توابعشه نه اون استخون بندی اصلی. اینطوری از گزند تغیرات ریشه ای که ریشه انسان رو میزنه در امانیم .
وبسایت: https://mrbug.ir
اینستاگرام: https://www.instagram.com/mrbug_ir
توییتر: https://www.twitter.com/mrbug_ir
تلگرام: https://www.t.me/mrbug_ir
