طراحی شی گرا چی میگه؟ - گام اول مقدمه

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

اگر نظر من رو بپرسید، نظر من اینه که تاوقتی لزوم استفاده از دیزاین پترن هارو در کدهاتون احساس نکنید یادگیری اونها بی فایدست. در واقع شما بعد از یه مدت به جایی می رسید که دغدغه شما از اینکه چطور یک فیچر رو پیاده سازی کنید به این میرسه که چطور این فیچر رو طوری پیاده سازی کنید که تست و maintenance اون راحت تر باشه و اگر قرار شد یه روزی کدهاتون رو یه بنده خدایی بشینه refactor کنه راحت تر باشه (در اصطلاح bad smell کمتری داشته باشین). خلاصه اینکه نشستن و خوندن این پترن ها به هیچ کاری نمیاد تا وقتی که احساس نیاز بهشون نکردید و حتی پیاده سازیشون باعث پیچیده تر شدن روند برنامه خواهد شد.

قبل از اینکه بریم سراغ اصل مطلب چندتا مبحث داریم که خیلی خلاصه وار بهشون اشاره می کنیم:

1. Rigidity: تغییر روی سیستم سخت و زمانبره
2. Fragility: وقتی تغییری روی یک بخشی از سیستم میدیم نگران عملکرد صحیح سایر بخش ها هستیم
3. Immobility: کدهامون رو نمیتونیم در مواقع لزوم درجاهای دیگه ایی از سیستم که نیاز داریم استفاده کنیم
4. Viscosity: تغییر در سیستم و اضافه کردن ویژگی های جدید انقدر دردسر داره که بیخیالش میشیم

Rigidity

برای اینکه از rigidity جلوگیری کنیم باید زمان build و test رو به حداقل برسونیم، یعنی با هرتغییر کوچک مجبور نباشیم تا کل سیستم رو دوباره rebuild وتست کنیم

نشونه های rigidity در کد:

1. کدهامون به صورت procedural نوشته شده اند. (۱- همه کدها داخل یک فایل هستن ۲- استفاده از if/else if/else های پشت سرهم)
2. عدم استفاده از Abstraction (توجه به اهمیت استفاده از inheritance و کاربرد interface ها)
3. عدم توجه به Encapsulation (کامپوننت ها و کلاس ها باید کمترین اطلاعات رو از همدیگه داشته باشن.)

نکته مهم: حواسمون باشه مفاهیم Abstraction شده رو بیش از حد برای سیستم customize نکنیم!

Fragility

اگر باهرتغییر در سیستم مجبورین بخش های دیگه رو هم تغییر بدید شما دچار fragility هستید.

چیکار کنیم دچار fragility نشیم؟ باید وابستگی بین کامپوننت های مختلف سیستم رو به حداقل برسونیم.

Immobility

چرا دچار immobility میشیم؟ توجه بیش از حد به جزئیات! (Over engineering نکنید آقا!!! شاید یه روزی یه فیچری لازم شد!)

اگر دید که ماژول ها یا متدهایی که کار یکسانی انجام میدند رو دوباره دارید پیاده سازی میکنید تبریک میگم ساختار شما دچار immobility شده. یادمون باشه که ماژول ها باید کمترین وابستگی رو به environment خودشون داشته باشند تا در اصطلاح reusability اون ها حفظ بشه و بتونیم در محیط های دیگه هم در صورت نیاز از اون ها استفاده کنیم.

Viscosity

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

افزایش پیچیدگی در سیستم، باعث سخت تر شدن پیشرفت و اضافه کردن قابلیت های جدید میشه در نتیجه برای اینکار راه های میانبری رو انتخاب می کنیم که خودشون باعث افزایش این پیچیدگی ها خواهند شد.
Robert C Martin

قسمت دوم : آشنایی با اصول Single Responsibility و Open-Closed