اصول SOLID:

.

Single responsibility

هر کلاس یا entity باید تنها یک مسئولیت داشته باشد و از انجام کار های مختلف و نا مرتبط در یک کلاس باید پرهیز کرد.
مثلا اگر کلاسی تحت عنوان User داریم ، نباید همزمان کارهای عادی مربوط به کاربر و کارهای مربوط به دیتابیس و کارهای مربوط به شبکه را انجام دهیم.

Open / Closed Principle (OCP)

کلاس ها باید برای توسعه دادن باز ( open for extension ) و برای تغییر دادن بسته باشند (‌close for modification).
یعنی اگر بخواهیم نوع یا feature جدیدی اضافه کنیم، باید بتوانیم این کار را به راحتی انجام دهیم ولی کلاس های موجود دچار کم ترین تغییر شوند.

Liskov Substitution Principle (LSP)

کلاس فرزند باید به طور کامل تمام ویژگی ها و متد های کلاس پدر را داشته باشد و پیاده سازی کند.

Interface Segregation Principle (ISP)

هر کلاسی که یک interface را پیاده سازی می کند،‌باید همه متد های آن را پیاده کند و همه متد ها برای آن کلاس با معنی باشند.

در غیر این صورت برای کلاس مذکور نیاز به interface جدیدی خواهیم داشت ( که احتمالا parent برای interfaceقبلی است.)

Dependency Inversion Principle

پیاده سازی باید به گونه ای باشد که تا جای ممکن وابسه به کلاس های abstractباشیم تا این که به کلاس های low-level و مشخص.

با این کار امکان گسترش و تعمیم پیاده سازی بالا می رود.

اصول GRASP:

Creator

ساخت بعضی از اشیا از کلاس ها فرایند نسبتا پیچیده ای است، به همین دلیل نیاز به کلاس های مجزا برای برعهده گرفتن وظبفه ساخت این گونه کلاس ها را داریم. (builder classes).

Information Expert

نیازی نیست که همه کلاس ها همه نوع کار را انجام بدهند! نیاز به کلاس هایی داریم که وظایف تخصصی را برعهده بگیرند و بقیه entity ها این کار را به آن ها بسپارند.

مثلا داشتن کلاس DatabaseUtils و …

Low Coupling

باید تا جای امکان وابستگی بین کلاس ها را از بین ببریم. این کار فرایند گسترش و تغییر در پیاده سازی را آسان می کند.

Controller

استفاده از کلاس هایی که وظیفه مدیریت و برقراری ارتباط بین بقیه کلاس ها را دارند. مثل (mvc).

Cohesion

کلاس های مختلف باید منسجم باشند و با هم یک واحد را تشکیل دهند. ( انسجام در کلاس ها!)

 

Polymorphism

استفاده از چندریختی!

Indirection

برای کاهش وابستگی یا coupling بین کلاس ها نیاز به کلاس ها واسطه ای خواهیم داشت که ارتباط این دو کلاس را تامین کنند.

Pure Fabrication

استفاده از کلاس هایی که به طور مشخص و فیزیکی یک entity را در طراحی ما تعریف نمی کنند، اما در طراحی ما یک سری serviceارايه می دهند یا باعث برقراری بعضی از principle ها می شوند. (‌مثلا کلاس های controller ).

Protected Variation

ارتباط بین کلاس ها باید با یک api ثابتی همواره برقرار باشد و مخاطب های یک کلاس صرفا این api را بشناسند.

این کار باعث می شود که تغییر در logic و داخل یک کلاس باعث تغییر در بقیه کلاس ها و entity های سیستم نشود.

منابع:

https://medium.com/@mari_azevedo/s-o-l-i-d-principles-what-are-they-and-why-projects-should-use-them-50b85e4aa8b6

https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o

About Nilva

No. 5
Orang Dead End
Abbas Sharghi Alley
Akbari Blv
Tehran, IRAN

T: +98 (0)915 077 3830
E: admin[@]nilva.ir