اصول SOLID و GRASP نرم افزار

هر کلاس یا entity باید تنها یک مسئولیت داشته باشد و از انجام کار های مختلف و نا مرتبط در یک کلاس باید پرهیز کرد.

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

کلاس ها باید برای توسعه دادن باز ( open for extension ) و برای تغییر دادن بسته باشند (‌close for modification).

یعنی اگر بخواهیم نوع یا feature جدیدی اضافه کنیم، باید بتوانیم این کار را به راحتی انجام دهیم ولی کلاس های موجود دچار کم ترین تغییر شوند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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