اصل تک مسئولیته بودن

اصل تک مسئولیته بودن - Single responsibility یا (SRP)

مقایسه با دنیای واقعی

من (نویسنده) به عنوان رهبر تیم توسعه در یکی از شرکتهای نرم افزاری هند کار می کنم. در وقت های مازادم، مشغول به نوشتن هستم یا به ویرایش روزنامه می پردازم و چندین پروژه ی مختلف نیز انجام می دهم. در واقع من مسئولیت های متعددی در زندگی ام دارم.

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

تشخیص دادن مشکل در برنامه نویسی

قبل از اینکه به اصل تک مسئولیته بودن بپردازیم، از شما می خواهم که به کلاس زیر نگاهی بیندازید. 

• هر گاه منطق درج، تغییر پیدا کند، این کلاس نیز تغییر پیدا می کند.
• هر گاه منطق گزارش گیری، تغییر پیدا کند، این کلاس نیز تغییر پیدا می کند.

مسئله چیست؟

هر بار که یکی از اجزای کلاس تغییر پیدا می کند، این شانس وجود دارد که بقیه ی اجزا نیز دستخوش تغییر قرار گیرد، زیرا هر دو در یک خانه هستند و والدین هر دو یکی است. نمی توانیم همه چیز را کنترل کنیم. بنابراین تنها یک تغییر ما را وادار می کند که تست را دو بار یا بیشتر انجام دهیم.

تک مسئولیته (SRP) بودن چیست؟

تک مسئولیته بودن می گوید: "هر ماژول نرم افزار باید یک دلیل برای تغییر داشته باشد."

•  ماژول مانند نرم افزار، کلاس، تابع و ...
• دلیل تغییر مسئولیت

بنابراین باید دنبال راه حل هایی باشیم که تک مسئولیته بودن را نقض نکند.

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

1. Employee – شامل ویژگی ها و داده ها
2. EmployeeDB – عملیات مربوط به پایگاه داده را انجام می دهد
3. EmplyeeReport – وظایف مربوط به گزارش گیری را انجام می دهد

public class Employee
{
    public string EmployeeName { get; set; }
    public int EmployeeNo { get; set; }
}
public class EmployeeDB
{
    public void Insert(Employee e) 
    {
       //Database Logic written here
    }
    public Employee Select() 
    {
       //Database Logic written here
    }
}
public class EmployeeReport
{
    public void GenerateReport(Employee e)
    {
       //Set report formatting
    }
}

نکته: این اصل برای متدها نیز برقرار است. هر متد تنها باید یک مسئولیت داشته باشد.

آیا یک کلاس می تواند چندین متد داشته باشد؟

پاسخ مثبت است. حال شما ممکن است بپرسید چگونه ممکن است.

1. یک کلاس تنها یک مسئولیت داشته باشد.
2. یک متد فقط یک مسئولیت داشته باشد.
3. یک کلاس بیش از یک متد داشته باشد.

جواب این سوال بسیار ساده است: بستر

در این جا، مسئولیت مربوط به بستری است که در مورد آن صحبت می کنیم. وقتی می گوییم مسئولیت یک کلاس، در واقع به چیزی در سطح بالاتر اشاره دارد. برای نمونه کلاس EmployeeDB مسئول عملیات مرتبط با پایگاه داده است در حالی که کلاس EmployeeReport مسئولیت عملیات مربوط به گزارشات کارمند را بر عهده دارد.

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

صبر کنید تا برای درک بهتر، مثال زیر را با همدیگر مشاهده کنیم.

//متدی با چند مسئولیت که تک مسئولیته بودن را نقض می کند
public void Insert(Employee e)
{     
    string StrConnectionString = "";       
    SqlConnection objCon = new SqlConnection(StrConnectionString); 
    SqlParameter[] SomeParameters=null;//Create Parameter array from values
    SqlCommand objCommand = new SqlCommand("InertQuery", objCon);
    objCommand.Parameters.AddRange(SomeParameters);
    ObjCommand.ExecuteNonQuery();
}

//متدی تنها با یک مسئولیت که از تک مسئولیته بودن پیروی می کند
public void Insert(Employee e)
{            
    SqlConnection objCon = GetConnection();
    SqlParameter[] SomeParameters=GetParameters();
    SqlCommand ObjCommand = GetCommand(objCon,"InertQuery",SomeParameters);
    ObjCommand.ExecuteNonQuery();
}

private SqlCommand GetCommand(SqlConnection objCon,
 string InsertQuery, SqlParameter[] SomeParameters)
{
    SqlCommand objCommand = new SqlCommand(InsertQuery, objCon);
    objCommand.Parameters.AddRange(SomeParameters);
    return objCommand;
}

private SqlParameter[] GetParaeters()
{
   //Create Paramter array from values
}

private SqlConnection GetConnection()
{
    string StrConnectionString = "";
    return new SqlConnection(StrConnectionString);
}

 استفاده از تست، به خودی خود یک مزیت محسوب می شود، اما چون با استفاده از تست، کد خواناتر می شود، بنابرای یک مزیت دیگر تست ها، افزایش خوانایی کد است. هر چه کد خوانا تر باشد، ساده تر به نظر می رسد.