آشنایی با قوانین پنج گانه ی SOLID


آشنایی با قوانین پنج گانه ی SOLID


SOLID دربرگیرنده ی اصولی در برنامه نویسی شیء گرایی است که در اوایل سال 2000 توسط مهندسی به نام Robert Martin که تحت عنوان Uncle Bob یا «عمو باب» شناخته می‌شود ابداع شد. وقتی این اصول به درستی در کنار یکدیگر به کار گرفته شوند، این امکان را به برنامه نویس یا توسعه‌دهنده می‌دهند تا با سهولت بیشتری به توسعه ی نرم افزارهای خود بپردازد. علاوه بر این، به کارگیری اصول SOLID این امکان را به برنامه نویسان خواهد داد تا با رویکردی چابک به توسعه ی نرم افزارهای خود پرداخته، از مرتکب شدن اشتباهات کوچک جلوگیری کنند و در صورت نیاز هم به سادگی اقدام به بازنویسی کدهای خود کنند (در فصل آینده، با مفهوم برنامه نویسی به سبک Agile (اجایل یا چابک) بیشتر آشنا خواهیم شد.) حال ممکن است این سؤال برای شما پیش بیاید که SOLID مخفف چه اصطلاحاتی است که در ادامه به تشریح تک تک اجزای تشکیل‌دهنده ی این اصطلاح خواهیم پرداخت:

S: Single Responsibility
O: Open / Closed
L: Liskov Substitution
I: Interface Segregation
D: Dependency Inversion

Single Responsibility
این اصل که به طور خلاصه SRP نیز خوانده می شود، حاکی از آن است که یک کلاس می بایست صرفاً یک وظیفه بیشتر نداشته باشد که در این صورت، کلاس‌ها فقط و فقط به خاطر ایجاد تغییر در وظیفه‌ای که انجام می‌دهند دستخوش تغییر خواهند شد نه چیز دیگر! کلاس‌ها می‌توانند Behavior های مختلفی داشته باشند اما تمامی آن‌ها می بایست مربوط به یک حوزه بوده و مربوط به هم باشند. با محترم شمردن چنین قانونی، برنامه نویسان دیگر قادر نخواهند بود تا کلاس‌های اصطلاحاً «همه فن حریف!» درست کنند.

Open-closed
کلاس‌هایی که ما در شیء گرایی ایجاد می‌کنیم می بایست برای توسعه یافتن قابلیت‌هایشان اصطلاحاً Open باشند یا «دست برنامه نویس برای توسعه ی کلاس باز باشد» اما اگر برنامه نویس خواست تا تغییری در کلاس ایجاد کند، چنین امکان می بایست Closed یا «بسته» باشد. فرض کنیم نرم افزاری نوشته‌ایم که دارای چندین کلاس است. متدهای داخل کلاس‌ها همگی به خوبی کار می‌کنند و نیازهای برنامه ی ما را مرتفع می سازند. حال به جایی رسیده‌ایم که نیاز داریم قابلیت‌های جدید به برنامه ی خود بیفزاییم. بر اساس این قانون، دست برنامه نویس برای تغییر -یا بهتر بگوییم افزودن چیزهایی به کلاس مد نظرش- باز است اما این در حالی است که این قابلیت‌های جدید می بایست در قالب افزودن کدهای جدید صورت پذیرد نه تغییر دادن کدهای قبلی!

برای روشن‌تر شدن این مسأله مثالی می زنیم. پیش از این با مفهوم وراثت در برنامه نویسی آشنا شدیم. فرض کنیم کلاسی داریم تحت عنوان BankAccount که دو کلاس دیگر تحت عناوین SavingAccount و InverstmentAccount از آن ارث بری می کنند. حال قصد داریم کلاس جدید تحت عنوان CurrentAccount ایجاد کنیم که از BankAccount ارث بری می‌کند اما این کلاس جدید دارای یکسری قابلیت‌هایی است که در کلاس والد دیده نشده است. در چنین شرایطی، ما به جای آن که قابلیت‌های مد نظر جدید را به کلاس والد بیفزاییم، نیاز خود را از طریق افزودن قابلیت‌های جدید در همان کلاس فرزند عملی می کنیم. در چنین شرایطی، ما هرگز دست به تغییر کدهای موجود نزده و قانون Open / Closed را هم به رسمیت شناخته ایم. به عبارت دیگر، کلاس برای توسعه باز است اما برای تغییر بسته!

Liskov Substitution
این اصل هم مرتبط با مبحث وراثت در برنامه نویسی است. این قانون می‌گوید که کلاس‌های فرزند می بایست آنقدر کامل و جامع از کلاس والد خود ارث بری کرده باشند که به سادگی بتوان همان رفتاری که با کلاس والد می کنیم را با کلاس‌های فرزند نیز داشته باشیم. به عبارتی، کلاس‌های فرزند می بایست قابلیت جایگزینی کلاس‌های والد را داشته باشند. اگر شما در شرایطی قرار گرفتید که با خود گفتید کلاس فرزند برنامه ی من می‌تواند تمامی کارهای کلاس والدش را انجام دهد به جزء فلان مورد، اینجا است که این اصل از SOLID را نقض کرده اید!

Interface Segregation
بر اساس این قانون، چندین اینترفیس تک منظوره به مراتب بهتر است از یک اینترفیس چند منظوره! است. پیش از این هم گفتیم که اینترفیس ها کلاس‌هایی هستند که هیچ کار خاصی انجام نمی‌دهند فقط مشخص می‌کنند که یک کلاس از چه قابلیت‌هایی حتماً می بایست برخوردار باشد. اگر ما یک اینترفیس چند منظوره ی بزرگ داشته باشیم و سایر کلاس‌های ما از آن اصطلاحاً implements کنند،‌ در چنین صورتی ممکن است برخی خصوصیات، متدها و رفتارها را به برخی کلاس‌هایی که اصلاً نیازی به آن‌ها ندارند تحمیل کنیم اما اگر ما از چندین اینترفیس تخصصی استفاده کنیم، به سادگی می‌توانیم هر کلاسی که نیاز به هر کدام اینترفیس داشت را از آن implements کنیم و در صورتی هم کلاسی وجود داشت که نیاز به استفاده از چندین اینترفیس مختلف داشت، دست ما باز خواهد بود تا آن کلاس را از چندین اینترفیس implements کنیم.

Dependency Inversion
درک این اصل از اصول پنج‌گانه ی SOLID کمی دشوار تر به نظر می رسد. به طور خلاصه، ما می بایست به عنوان یک برنامه نویس حرفه‌ای تمام تلاش خود را به کار بندیم تا Dependency یا «وابستگی» را مابین آبجکت های مختلف به حداقل برسانیم که با این کار، اعمال تغییرات در آینده به مراتب راحت تر صورت خواهد پذیرفت.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *