در این مقاله میخواهیم ۲ دیدگاه متفاوت از Robert C Martin و Bertrand Meyer در خصوص اصل Open / Close را بررسی کنیم.
1- Reducing the amount of change(Robert C Martin)
2- Backward compatibility (Bertrand Meyer)
در ابتدا مختصری راجب اصل Open / Close صحبت کنیم. این اصل میگه:
<< ما باید بتوانیم رفتار یک کلاس را تغییر دهیم بدون اینکه سورس کد خود آن کلاس را تغییر بدهیم. >>
حالا به بررسی این ۲ دیدگاه بپردازیم. Robert C MArtin میفرمایند که ما باید Opne / Close را رعایت کنیم برای اینکه اون مقدار کدی که باید تغییر کند را کم کنیم.
فرض کنید در شکل بالا ما کلاسی داریم به اسم Strategy که قرار است برای مثال داده ای را به عنوان ورودی دریافت کند و روی این داده عملیاتی را انجام دهد و خروجی های متفاوت به ما بدهد. مثلا یکبار قرار است به صورت json، یکبار به صورت yml خروجی دهد. اگر قرار باشد به صورت xml هم خروجی داشته باشیم باید بیاییم کلاس Strategy را تغییر دهیم، یعنی یک متد به نام xml به کلاس Strategy اضافه کنیم. یعنی برای ایجاد رفتار جدید ما مجبور به دستکاری کلاس Strategy هستیم. این کار اصل Open / Close را نقض میکند. اگر این اصل رعایت نشود یک تغییر موجی ایجاد میشود یعنی ما برای اضافه کردن یک behavior باید کلاس های مختلف را تغییر دهیم و این تغییر به صورت موج در سورس کد و کلاس های ما تاثیر میگذارد.
دیدگاه دوم بیان میکند که برای مثال اگر ما نسخه ی جدیدی از packageمون را ارایه میدهیم نباید تغییرات جدید باعث break شدن سایر کدهامون بشه. فرض کنید یک پکیج برای payment نوشتید. در نسخه اول همه چیز به درستی کار میکند. اما به محض تغییرات جدید در نسخه دوم دیگر پکیج ما بصورت صحیح کار نمیکند و اصطلاحا break change کرده و تمام کسانی که از نسخه اول اپلیکیشن یا پکیج ما استفاده کردن با مشکل مواجه شده اند. یک نمونه دیگه Rest Api ها هستن. اگر با Rest Apiها کار کرده باشین دیدین که عملیات Version گذاری انجام میشود. این نوع پیاده سازی بر اساس دیدگاه دوم از Bertrand Meyer است. کسانی که دارند از Version1 استفاده میکنند را نمیتوانیم force کنیم که حتما نسخه اپلیکیشن را به روزرسانی کنند. پس باید Version1 به درستی کار خود را انجام دهد.
اما نکته مهمی که وجود دارد این است که موارد استفاده این دیدگاه ها کجاست؟!
به صورت کلی میتوان گفت دیدگاه اول (Robert C Martin) در نرم افزارهای Open Source کاربرد دارد. مثلا یک پکیجی برای laeravel توسعه داده شده و در اختیار Client قرار داده شده است. این نرم افزار باید قابلیت اضافه کردن یا تغییر رفتار (Behavior) بدون اینکه سورس کد یا کلاس های اون پکیج تغییر کند را داشته باشد. از دیدگاه دوم از Bertrand Meyer بیشتر در نرم افزارهای سازمانی استفاده میشود که به صورت تیمی روی نرم افزار کار میشود. در واقع کد من در جاهای مختلف توسط سایر اعضای تیم استفاده میشود. پس نباید تغییر به صورتی باشد که بقیه قسمت های برنامه تحت تاثیر قرار بگیرند و در عملکرد آن ها اختلال بوجود آورد.
