جوگیرساختن مخاطب برای خواندن تا ته

توی این فصل چنتا اصل خوب و شیک برای نحوه نوشتن کلاس هامون توی کد، اومده. اگر از طرفدارای پر و پا قرص برنامه نویسی شی گرا هستید و تا الان حس میکردید کلاس هاتون کلاس کاری مناسب رو نداشتن، این فصل مخصوص شماست !

فصل دهم – Classes

Encapsulation

به طور معمول استیل کار ما اینه که توی کلاس همه چیز رو پرایوت نگه داریم ولی خب خیلی نباید روش تعصب داشت. گاهی مجبوریم بعضی از توابع رو برای تست هاشون دسترسی بدیم . اوکیه.

Classes Should be Small

شاهد کول بازیای نویسنده هستیم همچنان:

قانون اول: کلاس ها باید کوچولو باشن

قانون دوم: کلاس ها باید کوچولوتر از قانون اول باشن حتی !

The Single Responsibility Principle

هر کلاس باید یک مسئولیت داشته باشه دلیلش هم اینه که فقط یک دلیل باید باعث بشه که کد کلاس عوض بشه

Cohesion

تعداد متغیرهای کلاس باید کم باشه و توابع کلاس نباید بیشتر از یکی دوتا ازین منغیر هارو تغیر بدن در طی طول عمر با برکتشون ! اینطوری تر تمیز تر و به قول عمو، منسجم تره .

Maintaining Cohesion Results in Many Small Classes

حالا کی به این نقطه میرسیم که کدامون منسجم و درست باشه ؟ وقتی کلاس های عریض و طویل رو بشکنیم به کلاس های کوچولو. وقتی کوچیک باشن هم تعداد متغیرها کمتر میشن و هم میشه توابعی نوشت که فقط یکی دوتا از متغیر هارو تغیر بده.

Organizing for change

در اکثر سیستم ها، متاسفانه تغییر زیاد اتفاق میفته چون نیازمندی عوض میشه و قاعدتا کد هم باید عوض بشه (لعنت) و این تغیرات ممکنه کاری کنن که صبح از خواب بیدار بشی ببینی دیگه هیچ چیز کار نمیکنه ( چه بد جایگاهی است ! )

حالا برای کمتر کردن این فجایع انسانی توصیه میشه که abstract classes, داشته باشیم و جزئیات رو ببریم توی پیاده سازی . اینطوری وقتی تغیری هم بوجود بیاد فقط توی اون پیاده سازی کلاس و توابعشه نه اون استخون بندی اصلی. اینطوری از گزند تغیرات ریشه ای که ریشه انسان رو میزنه در امانیم .