پیاده سازی کد هایی که هم نیاز های فعلی را مرتفع سازد و هم نیاز های آینده را به خوبی پوشش دهد٬ یکی از دغدغه های برنامه نویسان است. در پروژه های برنامه نویسی٬ معمولا از یکسری از قواعد پیروی می‌کنیم و این قواعد به کد ها و برنامه ما ساختار می‌دهند. در این بین می‌توانیم به مجموعه ای از قوانین که به آنها SOLID گفته می‌شود اشاره کنیم. این مجموعه از قوانین شامل ۵ قانون بسیار مشهور در بحث برنامه نویسی شی گرا است. کلمه SOLID به اختصار از حرف اول هریک از این ۵ قانون ایجاد شده است :

• Solid responsibility
• Open/Closed
• Liskov substitution
• Interface segregation
• Dependency inversion

در این مقاله قصد داریم تا پیرامون Solid responsibility principle و یا به اختصار SRP توضیحاتی را ارائه دهیم.

در واقع همانطور که از اسم این قانون مشخص است٬ به این موضوع اشاره می‌کند که هر کلاس باید یک و تنها یک وظیفه برعهده داشته باشد. به این معنا که یک کلاس٬ به عنوان کلاس همه کاره نداشته باشیم. بنابراین می‌توان نتیجه گرفت که تنها یک دلیل باید برای ایجاد تغییر در کلاس وجود داشته باشد. البته باید به این موضوع اشاره کنیم که SRP نه تنها برای کلاس ها٬ بلکه برای module ها و microservice ها نیز قابل استفاده است.

لزوم رعایت Single Responsibility Principle

ما می‌دانیم که نیاز های پروژه در طول زمان نیاز به بروزرسانی دارد. بنابراین این تغییرات در نیاز ها٬ کد های موجود را تحت تاثیر قرار می‌دهند و می‌توان نتیجه گرفت که باعث تغییر در کد ها می‌شود. حال اگر یک کلاس به چند دلیل نیاز به تغییر داشته باشد٬ ممکن است روی عملکرد آن تاثیر بگذارد. معمولا تغییرات با افزایش و یا کاهش dependency ها همراه است که در این صورت ممکن است بر روی دیگر عملکرد های یک کلاس نیز تاثیر بگذارد. بنابراین امکان تغییر کلاس را دشوار می‌کند.

نمونه عدم رعایت SRP

برای مثال فرض کنید یک کلاس به نام User داریم و در این کلاس اطلاعات کاربر را نگهداری می‌کنیم. اگر متد های مورد نیاز برای ارتباط با پایگاه داده نیز در این کلاس قرار گیرد٬ به این ترتیب ما از یک کلاس به چند دلیل استفاده کرده‌ایم. در اینجا نگهداری و تست کلاس User سخت تر می‌شود. این کلاس به پایگاه داده مرتبط است بنابراین هر تغییری در نحوه برقراری ارتباط و انجام تراکنش با پایگاه داده٬ ممکن است ساختاری که کلاس برای نگهداری اطلاعات از آن استفاده می‌کند را تحت تاثیر قرار دهد. همچنین تغییر در شیوه نگهداری اطلاعات ممکن است فرآیند های ارتباط با پایگاه داده را نیز با مشکل مواجه کند.

class User { 
private String username;
private String password;

public void eqaul(Object user){
// code }

public void insert(){
// code
}

public void update() {
// code 
}

public void delete() {
// code
}

}

یکی از روش هایی که به ما این امکان را می‌دهد تا بتوانیم رعایت این قانون را بررسی کنیم٬ استفاده از “و” است. وقتی در توصیف وظیفه کلاس٬ از “و” استفاده کنیم٬ نشان می‌دهد که این کلاس شامل وظایفی است و مسئولیت آن انجام یک وظیفه نیست. در کلاسی که برای مثال فوق استفاده کرده‌ایم٬ اگر بخواهیم وظایف را شرح دهیم٬ باید بگوییم: “وظیفه این کلاس نگهداری اطلاعات و ارتباط با پایگاه داده است”. بنابراین ما دو وظیفه را در یک کلاس قرار دادیم و با این کار SRP را نقض کرده‌ایم.

Log4J نمونه ای از رعایت SRP

نمونه ای از رعایت SRP می‌تواند Log4J Framework باشد. Log4J یک framework سبک و منعطف است که برای log از آن استفاده می‌شود. همانطور که در شرح وظیفه این framework مشاهده می‌کنید٬ این framework تنها یک وظیفه را انجام می‌دهد. حال اگر بخواهیم برای مثال٬ RESTful را نیز پیاده سازی کنیم٬ باید از ابزار دیگری استفاده کنیم.

انجام تنها یک وظیفه توسط microservice به معنای داشتن تنها یک framework نیست. انجام تنها یک وظیفه توسط framework به منظور داشتن تنها یک کلاس نیست و همچنین داشتن تنها یک وظیفه به منظور داشتن تنها یک متد در یک کلاس نیست. می‌توانیم کلاس User را به دو کلاس User و UserDao تقسیم کنیم که کلاس User وظیفه نگهداری اطلاعات را برعهده دارد و کلاس UserDao وظیفه انجام تراکنش را پایگاه داده را بر عهده دارد.

class User { 
private String username;
private String password;

public void eqaul(Object user){
// code }


}

و

class UserDao { 
public void insert(){
// code
}

public void update() {
// code 
}

public void delete() {
// code
}
 
}

در این مقاله سعی بر این شد تا با مفهوم Single Responsiblity Principle اشنا شویم.

با ما همراه باشید.