چیکار کنیم که کدی که مینویسیم، خوانا باشه، یا اینکه بشه دوباره ازش استفاده کرد، یا اینکه اگه به مشکلی یا خطایی توش برخورد کردیم، راحت بشه دیباگش کرد یا حتی توسعه و گسترشش داد؟
اینا سوالایی هستن که هر برنامه نویس آینده نگری که دسخطش براش مهم باشه، کمابیش از ذهنش گذشتن .(صد البته اگر آینده نگر نباشه یا براش مهم نباشه که چیکار داره میکنه، کلا داستان متفاوتی داره).
وقتی صحبت از اصول و نقشه راه میشه، نامی که میدرخشه قطعا عمو باب هستش که با معماری تمیزش، خیلی جزئی، تو لایه های پیاده سازی، نکاتی رو ذکر ،ابداع و گرداوری کرده که اگه همچون منی پیاده نظام، فقط سعی کنم به سمتشون برم، برای خودم میتونم اندک آبرویی دست و پا کنم! دیگه ببین کی بوده خودش!!
از مجموعه اصولی که ایشون معرفی کرده، میشه گفت شاید معروف ترینش اصول SOLID باشن که در اصل برای الگوهای شیئ محور یا به قول معروف شیئ گرا (OOP) ارائه شدن. پنج اصلی که واقعا نشون دادن که اگه هر برنامه نویسی ازشون بهره ببره، نکاتی رو که در ابتدای نوشته بهشون اشاره کردم رو به دست میاره. پس با اجازه از رو دست بزرگای مجلس کپی میکنم و این اصول رو یکی یکی تشریح میکنم.
۱-اصل Single responsibility
نمیدونم دقیقا اگه بخوام معنی فارسی این اصطلاح رو ترجمه کنم، چی باید بگم؟ اما بیاین در این اسکوپ بهش بگیم " تک مسئولیتی " بودن. قطعا چیزی که مهمتر از عنوانه، معنی این اصله و این اصل به این معنیه که وقتی شما یه کلاس تعریف میکنین، این کلاس باید صرفا و تنها یک وظیفه داشته باشه. شنیدین که میگن " من یه قناری دارم روپایی میزنه " ... ؟ این دقیقا برعکس اون قضیه ست. در این اصل، قناری فقط باید آواز بخونه و نه کار دیگه. وقتی کار های متفاوتی به یه کلاس سپرده میشن، این کلاس جاهای مختلفی برای کار های مختلفی به کار گرفته میشه که خب عملا پیچیدگی ایجاد میکنه.
یه مجموعه تولیدی رو در نظر بگیرین، تکنیسینی که پشت دستگاه هست نباید در گیر زنجیره تامین، نظافت یا کارهای دیگه بشه. اینطوری میشه از این کارگاه، نظم و کیفیت تولید بالا رو انتظار داشت.
۲- اصل Open/Closed
در یک جمله کوتاه : بسته برای تغییر، باز برای توسعه.
حالا این یعنی چی؟ عرض میکنم. در این اصل گفته میشه اجزای یک برنامه، از کلاس و متد الی آخر، باید طوری تعریف و پرداخته بشن که در صورت نیاز، بشه توسعه شون داد و برای این توسعه، نیازی به تغییرشون نباشه. همون کارگاه رو درنظر بگیرین، ما یه وسیله داریم به اسم بلبرینگ. یه بلبرینگ با ساختارش و کاربردش بلبرینگه (در غیر اینصورت شاید اسم دیگه ای میگرفت، خدا عالمه!). ما میتونیم وسایل متعددی با استفاده از بلبرینگ و خاصیتش ایجاد کنیم. میتونیم اونو تو چرخ ماشین جا بدیم و یه ماشین رو باهاش تکمیل کنیم، میتونیم تو ساخت روتور یه ژنراتور ازش استفاده کنیم و اینطوری میشه یه قطعه از اون ژنراتور. ببینین، بلبرینگ همون بلبرینگه، نه ماهیتش و نه خاصیتش تغییر نکرده ولی یه جا میشه یه قطعه از اتومبیل و جای دیگه قطعه ی ژنراتور. پس بسته برای تغییر و باز برای توسعه :)
۳- اصل Liscov's substitution یا جایگزینی لیسوف
زیباست که بدونین (و من تا همین اواخر نمیدونستم) که لیسکوف در واقع یه سیبیل کلفت جامعه گریز نبوده و در اصل یه بانوی ملیح با پیرهن گل گلی به نام خانم باربارا لیسکوف هستن که اتفاقا به نظر خیلی هم مهربون میان. اینه که از رو اسم قضاوت نکنین. باری...
این اصل بیان میکنه که هر کلاس که از توسعه کلاس دیگری ایجاد شده، یعنی رابطه فرزند و والدی با کلاس دیگری داره، باید بتونه بدون مشکل به جای کلاس والدش به کار برده بشه. یه ماشین رو در نظر بگیرین. این ماشین قصه ما یه وسیله ی ایاب و ذهاب برای یه خانواده ست. پر خوش ذوق خانواده (که از قرار شبیه منه) میره و میل سوپاپ ماشین رو تعویض میکنه، هدرز میبنده و یه کیت مکش میزاره رو ماشین (قطعا ریمپش هم میکنه) . این ماشین الان قطعا یه ماشین مسابقه ست. یعنی کلاسی که از کلاس والد به اسم ماشین سدان خانوادگی ارث بری کرده. اما دلیلی نمیشه که نشه با همین ماشین کماکان ایاب و ذهاب های خانوادگی رو انجام داد. متوجه شدین دیگه ؟! اوکیه؟
۴- اصل Interface segregation
این اصل رو میشه گفت همون اصل اوله ولی برای اینترفیس ها. خلاصه ش میشه اینکه دوست عزیز! اینترفیسی تعریف نکن که اگر اطلاعات کاربر رو میخوای ازش میخونی،، اطلاعات هواشناسی ازش میخونی،، توش خاطرات مینویسی و نون سنگک هم میگیره. قشنگ و مرتب، بر اساس کاربرد جداشون کن. پیشاپیش ممنون.
۵ - اصل Dependency inversion
این اصل یه خورده مفهومیه، پس یادداشت کنین که حتما ازش تو امتحان سوال میاد.
خود اصل میگه که ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشن، بلکه هردو باید به ابسترکشن یا انتزاع وابسته باشن و همینطور در رابطه با وابستگی انتزاع به جزئیات هم همین طوره. انتزاع نباید به جزئیات وابسته باشه. این رابطه باید عکسش باشه و جزئیات بر اساس انتزاع شکل بگیرن.
خب بیاین این جملات قصار رو آدم فهم تر کنیم. ماژولهای سطح بالا تو برنامه، ماژولهایی هستن که منطق ها و لاجیک های پیچیده رو پیاده سازی میکنن. از طرف دیگه ماژول های سطح پایین، در واقع utility های سیستم رو پیاده سازی میکنن ( ابزار دیگه.. همون کارای خورده ریزه). حالا انتزاع چیه؟ انتزاع میشه رفتار.
اصل رو اینطوری توضیح میدم: رفتار بیزینسی که توی سیستم مدل میشه، میشه همون انتزاع یا ابسترکشن ما. مثلا ما یه سیستم داریم که یه مرسوله پستی رو برامون رهگیری میکنه. اینترفیسی که یه متد توش داره و اون متد خیلی راحت اسمش هست TrackMyPackage(packageCode) میشه انتزاع من از رهگیری. این یه رفتار و انتزاع انسانیه (محموله منو رهگیری کن).
الان این رفتار نه کاری به الگوریتم های پیچیده ی مسیریابی GPS داره (ماژول سطح بالا) و نه به اینکه تبدیلات لوکیشن با چه ابزاری انجام میشه(سطح پایین). اگر روزی روزگاری هم زیر پست پیاده سازیش کلا زیرو رو بشه و تغییر کنه، رفتار همینه، چون بیزینس من همینه. پس اگر رفتار رو مستقل از ماژولها و تکنولوژی ها مدل کنیم، در واقع این اصل رو رعایت کردیم. به همین خوشمزگی.
