در این نوشته سعی شده است تا حد امکان به بیان ساده و شفاف توضیح داده شود که اصل Open Close چیست و برای درک بهتر آن، مثال ساده‌ای هم ارائه شده است. اصل Open Close یکی از اصول SOLID در شی‌گرایی به حساب می‌آید.

مقدمه ای برای شرح چیستی اصل Open Close

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

مشکل اینجاست که تعداد زیادی الگو وجود دارند و هر کسی هم عقیده‌اش در مورد اینکه چه الگویی تحت چه سناریویی باید استفاده شود متفاوت است. در بسیاری از اوقات، حتی پس از سال‌ها کار برنامه‌نویسی، کدهای نوشته شده همچنان نامرتب و به هم ریخته به نظر می‌رسند. گاهی ممکن است برنامه‌نویسان تصور کنند که زندگی در زمان کدنویسی به روش «رویه‌ای» (Procedural) خیلی آسان‌تر بود.

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

نیازمندی‌های جدید پشت سر هم اضافه می‌شوند و تصمیم‌هایی که ۶ ماه قبل گرفته شده‌اند، اکنون دیگر قابل استفاده نیستند. پس از سال‌ها یادگیری، همچنان نمی‌توان درک کرد که اصلاً چرا اینقدر به طراحی و دیزاین نرم‌افزار اهمیت داده می‌شود؟

چرا طراحی نرم افزار اهمیت زیادی دارد؟

دنیا به سرعت در حال تغییر است و نرخ تغییرات در آینده حتی سریع‌تر هم خواهد شد. هر تغییری که در نرم‌افزارها داده می‌شود، پیچیدگی‌های بیشتری را به کدبیس اضافه خواهد کرد و پیچیدگی بیشتر، سرعت برنامه‌نویس را در جهت معکوس سوق خواهد داد و باعث کندی پیشرفت خواهد شد. واقعیت امر همین است و هیچکس نمی‌تواند این حقیقت را تغییر دهد؛ تنها می‌توان آن را همان گونه که هست پذیرفت. پس چرا وقتی آنچه را امروز می‌نویسیم پس از چند ماه منسوخ می‌شود، اصلاً باید برای دیزاین نرم‌افزار اهمیت قائل شویم؟

زیرا هدف طراحی نرم‌افزار کاستن میزان تغییرات نیست، بلکه مقصود کاهش دادن هزینه تغییرات در آینده است.

چرا طراحی یک مسئله بهینه‌سازی است؟

برای اینکه بتوان توضیح بیشتری در خصوص جمله بالا (قبل از تیتر که بولد شده) ارائه داد، ابتدا لازم است انواع مختلف تغییراتی را درک کنیم که یک توسعه‌دهنده می‌تواند در نرم‌افزار اعمال کند. این انواع تغییرات ممکن، در ادامه فهرست شده‌اند:

1. تغییر به وسیله افزودن: این‌ها تغییراتی هستند که در طی آن‌ها اجزا یا کلاس‌های جدیدی اضافه می‌شوند.
2. تغییرات به وسیله ویرایش: این‌ها تغییراتی هستند که در آن‌ها اجزا یا کلاس‌های فعلی و موجود ویرایش می‌شوند.

حالا سوال این است که آیا می‌توان تاثیر این تغییرات را روی نرم‌افزار مشخص کرد؟

آیا می‌توان تاثیر این تغییرات را روی نرم‌افزار مشخص کرد؟

اگرچه همه تغییرات، خطر بروز نارسایی‌ها و اختلالاتی را برای سیستم خواهند داشت، تغییراتی که از نوع ویرایشی هستند، ریسک بیشتری دارند، چرا که می‌توانند پسرفت‌هایی را به همراه داشته باشند. منظور از پسرفت در اینجا «پسرفت نرم‌افزاری» (Software Regression) است.

تشخیص رخداد این پسرفت‌ها می‌تواند بسیار دشوار باشد، زیرا به لحاظ نظری این پسرفت‌ها می‌توانند هر جایی در داخل کل سیستم وجود داشته باشند. برای جلوگیری از این مسئله، لازم است منابعی را به «تست پسرفت» (Regression Testing) اختصاص دهیم که البته فرایندی زمان‌بر است. به علاوه، چنین تغییراتی مستلزم این است که برنامه‌نویس درک مناسبی از تمام تفاوت‌های جزئی سیستم فعلی داشته باشد که این خودش چرخه توسعه نرم‌افزار را کندتر خواهد کرد.

تغییر به وسیله اضافه کردن اجزا به دلیل احتمال کمتر بروز پسرفت ریسک کمتری به همراه دارد. کاستی‌های رخ داده (اگر کاستی وجود داشته باشد) بیشتر به بخش جدیدی مربوط خواهد بود که به تازگی اضافه شده است. بنابراین، هزینه تست و دیباگ کردن در آینده کاهش خواهد یافت.

اصل Open Close چیست ؟

تا اینجا می‌توان به جمع‌بندی زیر رسید:

اگر نرم‌افزار را به گونه‌ای طراحی کنیم که به طور طبیعی تغییرات تنها به صورت افزودن اجزای جدید امکان‌پذیر شوند، می‌توان هزینه تغییرات را در آینده به میزان زیادی کاهش داد.

این ایده در واقع همان «اصل باز و بسته» یا «Open Closed Principle»‌ است که به صورت زیر بیان می‌شود:

امکان موجودیت‌های نرم‌افزاری برای توسعه و گسترش باید «باز» (آزاد) باشد، اما استقبال آن‌ها در قبال ویرایش و دستکاری، باید «بسته» (ممنوع) باشد.

چطور ممکن است نرم افزار همزمان هم باز و هم بسته باشد؟

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

رابرت مارتین، در خصوص اصل Open Close می‌گوید:

وقتی که تنها یک تغییر در برنامه منجر به بروز آبشاری از تغییرات در ماژول‌های وابسته می‌شود، آن برنامه خصلت‌های نامطلوبی را از خود نشان می‌دهد که با طراحی نامطلوب مرتبط هستند. در چنین شرایطی، برنامه آسیب‌پذیر، انعطاف‌ناپذیر، غیرقابل پیش‌بینی و غیرقابل استفاده مجدد می‌شود. اصل Open Close با این معضل مستقیماً وارد تقابل می‌شود. طبق اصل Open Close باید ماژول‌هایی طراحی شوند که هیچگاه تغییر نمی‌کنند. وقتی نیازمندی‌ها تغییر می‌کنند، رفتار و عملکرد چنین ماژول‌هایی را می‌توان به وسیله اضافه کردن کدهای جدید گسترش داد، نه اینکه بخواهیم کدهای قدیمی را تغییر دهیم که به درستی کار می‌کردند.

استفاده عملی از اصل Open Close چگونه است؟

تا اینجا نظریه نهفته در اصل Open Close مشخص شد. اما سوال این است که چگونه به صورت عملی می‌توان از اصل باز و بسته استفاده کرد؟ به بیان خلاصه باید گفت که کلید استفاده از این اصل، «انتزاع» است.

با استفاده از انتزاع، امکان ارائه مجموعه‌ای از رفتارها و خصوصیت‌های مطلوب به عنوان کدبیس فراهم می‌شود. همچنین خود رفتارها را می‌توان به صورت کلاس‌های مشتق شده ارائه داد. این متد به ما امکان می‌دهد تا به صورت تدریجی، کلاس‌های مشتق شده جدید اضافه کنیم تا بتوان به نیازمندی‌های در حال تغییر در آینده با کم‌ترین تغییرات در کدهای فعلی پاسخ داد.

مثالی برای درک بهتر اصل Open Close

مثلاً فرض می‌کنیم در حال ساخت بازی ماریو هستیم که در آن چند کاراکتر قابل استفاده در بازی وجود دارد. همچنین فرض می‌شود همه کاراکترهای بازی می‌توانند حمله کنند و پرش انجام دهند. یک راه برای کدنویسی چنین رفتاری به صورت زیر است:

 

باید توجه شود که اگر بخواهیم کاراکتر قابل بازی کردن دیگری را به بازی اضافه کنیم، نیاز است هر دو Method بالا را تغییر دهیم و ویرایش کنیم. به بیان دیگر، این متدها در خصوص تغییرات مورد نیاز در کاراکترهای قابل بازی کردن برای تغییر «بسته» نیستند. حال بیایید رویکرد دیگری را در نظر بگیریم:

 

این بار می‌توان به راحتی کاراکتر جدیدی را با کم‌ترین تغییرات و ویرایش‌ها در کدهای فعلی به برنامه اضافه کرد. بنابراین، در حالت دوم از اصل Open Close استفاده شده است و برنامه تا حد امکان در برابر تغییرات بسته است.

آیا می‌توان سیستمی تماماً بسته ساخت؟

خیر، نمی‌توان سیستمی کاملاً بسته ایجاد کرد. برای مثال (در ادامه مثال قبل) فرض می‌کنیم می‌خواهیم کاراکترهای بازی پرواز کنند. برای رسیدن به این قابلیت، ناچار خواهیم بود تمام کلاس‌های فعلی را در رویکرد دوم به‌روزرسانی کنیم، اما در رویکرد اول، تنها لازم است یک متد اضافه شود. یعنی ارث‌بری در قبال ارائه رفتارهای جدید به موجودیت‌های فعلی، «بسته» نیست.

به‌طور کلی، باز بودن و بسته بودن، عبارت‌هایی ضمنی هستند و هیچ وقت نمی‌توانند کامل باشند. بنابراین چون بسته بودن نمی‌تواند کامل باشد، باید استراتژیک باشد. یعنی، برنامه‌نویس باید انواع تغییرات لازم را انتخاب کند تا طراحی خود را برای آن‌ها ببندد. یک توسعه دهنده خردمند فردی است که به خوبی سیستم را می‌شناسد و برای محتمل‌ترین تغییرات، اصل Open Close را به کار می‌گیرد.

جمع‌بندی

اگر بخواهیم در این دنیای به سرعت در حال تغییر سیستمی انعطاف‌پذیر و مقاوم بسازیم، باید تغییر به وسیله افزودن را بر تغییر از طریق ویرایش ارجح بداریم. دلیلش این است:

• با این کار، احتمال ایجاد پسرفت نرم‌افزاری (Regression) کاهش می‌یابد.
• این رویکرد باعث می‌شود منابع کمتری برای توسعه، دیباگ کردن و تست نرم افزار مورد نیاز باشد.

این ایده به «اصل Open Close» معروف است، اصطلاحی که توسط «برتراند مایر» (Bertrand Meyer) بنیان گذاشته شد و رابرت مارتین هم آن را رواج داد. این اصل باعث می‌شود بتوان از قدرت انتزاع و ارث‌بری برای ایجاد سیستم‌هایی استفاده کرد که در برابر گسترش چراغ سبز نشان می‌دهند (باز هستند)، اما برای ویرایش انعطاف‌پذیری لازم را ندارند و به اصطلاح در برابر تغییر بسته هستند.

اگر این مطلب مفید بوده است، استفاده از دوره‌های آموزشی و مطالب زیر نیز پیشنهاد می‌شوند:

• مجموعه دوره‌های آموزش مهندسی کامپیوتر – نرم‌افزار
• دوره آموزش آشنایی با الگوهای طراحی در تولید نرم افزار با زبان سی شارپ C#‎
  
• مجموعه دوره‌های آموزش برنامه‌نویسی
• الگوهای طراحی نرم افزار در جاوا اسکریپت — از صفر تا صد
• MVC چیست ؟ — تشریح به زبان ساده + کاربرد در برنامه نویسی
• برنامه نویسی Kotlin — ایجاد الگوهای طراحی اندروید با کوتلین

منبع [+]