سلام
فرض کنید ما یک کلاس به شکل زیر در ورژن ۱.۰ برنامه داریم.
class ClassTest{
public function methodTest1(){
codeA;
codeB;
codeC;
codeD;
}
}
حالا در ورژن ۱.۱ طبق امکاناتی که از ما خواسته شده باید تغییراتی در متد های کلاس اعمال کنید که بتونیم امکانات جدید پیاده سازی کنیم
class ClassTest{
public function methodTest1(){
codeA;
codeH;
codeM;
codeC;
codeP;
}
}
این جا با تغییر متدهای کلاس ما عملا اصل دوم SOLID که میگه (open for extension closed for modification) زیر پا گذاشتیم
این جا باید چطوری نرم افزار توسعه بدیم طوریکه این قانون نقض نشده (سورس کد قبلی ویرایش نشه)
آیا دیزاین پترن decorator که functionality اضافه میکنه بدون اینکه کلاس تغییر بده راه حل این مشکل هست؟
بله حتما. مثلا تصور کنید یک کلاس قراره Notification ارسال کنه و این کلاس باید بتونه مثلا هم Email ارسال کنه و هم SMS و هم روش های ارسال دیگه. حالا اگر ما بیام توی این کلاس بگیم مثلا اگر Email بود این کد اجرا بشه و اگر SMS بود این کد اجرا بشه و .... خلاصه برای هر روش ارسال بیایم و کد به کلاس اضافه کنیم این دقیقا OCP رو نقض می کنه چون میایم و برای هر روش ارسال کلاس اصلی رو تغییر میدیم در حالی که مثلا با Strategy می تونیم هر روشی رو اضافه کنیم بدون اینکه کلاس اصلی رو تغییر بدیم.
سلام.هر متدی قراره یک logic رو پیاده سازی کنی و با تغییر اون logic این معنی رو نمیده که OCP نقض میشه الگوهایی مثل Decorator و Strategy می تونن نمونه های از اضافه کردن عملیات ها بدون تغییر کدهای کلاس باشن.
پس در چه حالتی قانون (open for extension closed for modification) تو توسعه نرم افزار نقض میشه؟
امکانش هست یک مثال بزنید
پس design patterns ها مشکلی حل می کنند که از قوانین SOLID سرچشمه میگره؟و این باعث افزایش توسعه پذیری نرم افراز میشه
چون اضافه کردن if در حالت عادی مشکل نیست مگر اینکه قانون دوم SOLID وجود نداشته باشه