می خواهیم در مورد اصول پنجگانه طراحی شی گرا صحبت کنیم. این اصول را شخصی به نام رابرت مارتین مشهور به عمو باب (ایشان یکی از امضا کنندگان مانیفست چابک (Agile) هم می باشند) در کنار هم گرد آورده است و اختصارا به اصول SOLID مشهور است.
S: Single Responsibility Principle
اصل تک مسئولیتی، ایجاب می کند که هر شی تنها و تنها به یک دلیل مشخص وجود داشته باشد و نه بیش از آن. در واقع یعنی هر شی تنها یک مسئولیت باید داشته باشد. این امر مانع از آن نمی شود که یک شی چند رفتار داشته باشد، بلکه می گوید که این رفتار ها باید در یک زمینه و یک شرح مسئولیت باشند.
O: Open / Close Principle
این اصل یکی از مهمترین اصول طراحی شی گرا می باشد و ایجاب می کند که موجودیت ها (این موجودیت ها می توانند یک کلاس باشند یا یک ماژول یا حتی یک تابع) را طوری طراحی کنیم، که برای توسعه باز و برای تغییر بسته باشند. این یعنی آنکه اگر یک کلاس داشته باشیم که به خوبی مشغول به کار است و بخواهیم تغییری در آن ایجاد کنیم، مجبور نباشیم کد هایی را که درست کار می کند را تغییر دهیم بلکه تنها چند خط کد به کلاس اضافه کنیم.
یکی از بهترین مثال ها برای این اصل، وراثت است. فرض کنید یک کلاس رفتاری را ارائه می دهد و چند کلاس دیگر از آن به ارث رفته اند، حال می خواهیم کلاس جدیدی به سیستم اضافه کنیم که آن رفتار را تغییر دهد، این امر به سادگی با ارث بری از کلاس پدر و بازنویسی (Overriding) آن رفتار در کلاس فرزند جدید، محقق می شود، بدون آنکه سایر کلاس ها دچار تغییر شوند.
بهترین قاعده ای که در پیاده سازی این اصل به کار می آید، قاعده چند ریختی پویا یا Dynamic Polymorphism می باشد.یک مثال خوب در این مورد را می توانید در این آدرس ببینید.
L: Liskov Substitution Principle
اصل جایگزینی لیسکوف، می گوید یک کلاس که از کلاس دیگری به ارث رفته است، باید بتواند، جایگزین کلاس والد شود. یک مثال کاربردی در این باب به شفاف تر شدن مطلب کمک می کند:
تابعی که پارامتری از جنس یک base class می گیرد، باید بتواند با هر نوع کلاس دیگری هم که از این base class مشتق شده است هم کار کند بدون آنکه نیاز باشد نوع آن را بداند. این یعنی کلاس های فرزند، رفتار ها و خصوصیات کلاس پدر را به درستی استفاده کنند تا در موقع لزوم بتوانند جایگزین هم باشند.
I: Interface Segregation Principle
چند interface خاص که هر کدام یک رفتار مشخصی را بیان می کنند، بهتر از یک interface عمومی است که رفتار های مختلفی دارد. چرا که کلاس هایی که از این interface استفاده می کنند، باید چندین رفتار را پیاده سازی کنند که شاید نیازی بدان ها نداشته باشند.
D: Dependency Inversion Principle
رعایت این اصل بخصوص از در هم تنیدگی (Coupling) سیستم جلوگیری می کند. اصل وابستگی معکوس، بر این مهم تاکید دارد که ماژول های سطح بالا نباید به ماژول های سطح پایین وابستگی داشته باشند، بلکه هر دو این ها باید به یک مفهوم مجازی مانند یک interface وابسته باشند. با بزرگ تر شدن سیستم ها، این اصل امروزه آنچنان مهم شده است که ابزار های زیادی مانند Ninject برای جلوگیری از وابستگی ها و مدیریت و تزریق وابستگی های ضروری از بیرون کلاس ها، ایجاد شده اند
