طراحی نرم افزار خوب برای ایجاد سیستمهایی که قابل حفظ ، مقیاس پذیر و آسان برای درک هستند ضروری است. در اینجا پنج اصل اصلی طراحی نرم افزار ارائه شده است که هر توسعه دهنده باید بداند:
اصل مسئولیت واحد
اصل مسئولیت واحد بیان می کند که یک کلاس فقط باید یک دلیل برای تغییر داشته باشد. این بدان معنی است که یک کلاس فقط باید یک مسئولیت یا عملکرد داشته باشد. اگر یک کلاس مسئولیت های مختلفی داشته باشد ، می تواند منجر به اتصال تنگ شود و اصلاح یا گسترش کلاس را دشوار کند.
به عنوان مثال ، یک کلاس به نام “کاربر” را در نظر بگیرید که روش هایی برای تأیید اعتبار ، ذخیره داده ها و ورود به سیستم دارد. این کلاس مسئولیت های مختلفی دارد و حفظ آن دشوار است. درعوض ، شما می توانید این کلاس را به کلاس های جداگانه تقسیم کنید ، هرکدام با یک مسئولیت واحد مانند “معتبر” ، “DataStore” و “Logger”.
اصل بسته
اصل بسته بندی شده بیان می کند که یک کلاس باید برای پسوند باز باشد اما برای اصلاح بسته شده است. این بدان معنی است که شما باید بدون تغییر کد موجود آن ، عملکرد جدیدی را به یک کلاس اضافه کنید. این اصل به اطمینان حاصل می شود که تغییرات در یک کلاس عملکرد موجود را نمی شکند.
به عنوان مثال ، یک کلاس به نام “PaymentGateway” را در نظر بگیرید که از چندین روش پرداخت ، مانند کارت های اعتباری و پی پال پشتیبانی می کند. به جای اصلاح کلاس موجود برای اضافه کردن یک روش پرداخت جدید ، می توانید یک کلاس جدید ایجاد کنید که از کلاس “PaymentGateway” به ارث می برد و روش پرداخت جدید را اضافه می کند.
اصل تعویض لیسکوف
اصل جایگزینی Liskov بیان می کند که زیرگروه ها باید برای انواع پایه آنها قابل تعویض باشند. این بدان معنی است که هر کدی که از یک نوع پایه استفاده می کند ، باید بدون دانستن تفاوت ، بتواند با یک زیرگروه کار کند. این اصل به اطمینان حاصل می شود که از وراثت به درستی استفاده می شود و زیرگروه ها برای انواع پایه آنها قابل تعویض هستند.
به عنوان مثال ، کلاس به نام “وسیله نقلیه” و یک زیر کلاس به نام “ماشین” را در نظر بگیرید. کلاس “ماشین” باید برای کلاس “وسیله نقلیه” جایگزین شود ، به این معنی که هر کدی که از یک شیء “وسیله نقلیه” استفاده می کند باید بدون دانستن تفاوت ، بتواند با یک شی “ماشین” کار کند.
اصل تفکیک رابط
اصل تفکیک رابط بیان می کند که مشتریان نباید مجبور شوند به رابط هایی که از آنها استفاده نمی کنند وابسته باشند. این بدان معناست که یک کلاس نباید مجبور شود رابط کاربری را اجرا کند که روشهایی را که به آن احتیاج ندارد ، اجرا کند. در عوض ، رابط باید به رابط های کوچکتر و متمرکز تر که مخصوص نیازهای هر مشتری است ، تقسیم شود.
به عنوان مثال ، رابط کاربری به نام “قابل چاپ” را در نظر بگیرید که روش هایی برای چاپ ، اسکن و نمابر دارد. کلاس که فقط نیاز به چاپ اسناد دارد ، نباید مجبور به پیاده سازی رابط “قابل چاپ” شود ، که شامل روش هایی برای اسکن و نمابر است. در عوض ، رابط “قابل چاپ” می تواند به رابط های جداگانه مانند “قابل چاپ” ، “اسکن” و “فاکس” تقسیم شود.
اصل وارونگی وابستگی
اصل وارونگی وابستگی بیان می کند که ماژول های سطح بالا نباید به ماژول های سطح پایین بستگی داشته باشد ، اما هر دو باید به انتزاع بستگی داشته باشند. این بدان معنی است که یک ماژول سطح بالا نباید به یک ماژول سطح پایین خاص وصل شود ، بلکه در عوض باید به انتزاعی بستگی داشته باشد که رابط کار ماژول سطح پایین را مشخص کند.
به عنوان مثال ، یک کلاس به نام “logger” را در نظر بگیرید که به یک چارچوب ورود به سیستم خاص ، مانند log4j بستگی دارد. به جای اتصال محکم کلاس “logger” برای log4j ، می توانید انتزاعی مانند رابط “ورود به سیستم” را تعریف کنید که روش های ورود به سیستم را تعریف می کند. کلاس “logger” می تواند به رابط “ورود به سیستم” بستگی داشته باشد ، که می تواند توسط چارچوب های مختلف ورود به سیستم ، مانند Log4J یا Logback اجرا شود.
