اصول پنج‌گانه SOLID در طراحی شیءگرا - اصل مسئولیت‌پذیری تک‌وظیفه‌ای (The Single Responsibility Principle - SRP)

(اصل مسئولیت‌پذیری تک‌وظیفه‌ای) - The Single Responsibility Principle (SRP)

 
در دنیای توسعه نرم‌افزار، ایجاد کدی که قابل فهم، قابل نگهداری و توسعه‌پذیر باشد اهمیت زیادی دارد.
یکی از اصول مهم در این زمینه که جزو اصول اصلی طراحی نرم‌افزار است که در مبحث SOLID مطرح شده است، اصل مسئولیت‌پذیری تک‌وظیفه‌ای است. این اصل می‌گوید که یک کلاس یا ماژول باید تنها یک دلیل برای تغییر داشته باشد، یعنی فقط یک مسئولیت یا وظیفه داشته باشد.

تعریف SRP
اصل مسئولیت‌پذیری تک‌وظیفه‌ای بیان می‌کند که:
هر کلاس باید تنها یک دلیل برای تغییر داشته باشد. به زبانی دیگر، هر کلاس باید تنها یک "وظیفه" داشته باشد و تمام متدها و داده‌های آن باید مستقیماً به همان وظیفه مرتبط باشند.
به بیان ساده، این یعنی کلاس‌ها یا ماژول‌ها نباید همزمان چندین مسئولیت مختلف را بر عهده بگیرند. اگر کلاسی چندین مسئولیت مختلف داشته باشد، تغییرات در یکی از این مسئولیت‌ها می‌تواند به تغییرات در سایر بخش‌ها منجر شود که این موضوع باعث پیچیدگی و کاهش قابلیت نگهداری و تست نرم‌افزار می‌شود.


برای مثال:
- اگر یک کلاس هم وظیفه پردازش داده‌ها و هم وظیفه نمایش داده‌ها را داشته باشد، وقتی نیاز به تغییر نحوه نمایش داده‌ها باشد، ممکن است تغییراتی در بخش پردازش داده‌ها ایجاد کنید که باعث ایجاد باگ‌های غیرمنتظره شود.
-  بنابراین، طبق  Single Responsibility Principle، باید این دو مسئولیت را در دو کلاس جداگانه پیاده‌سازی کنید.

به طور کلی، هدف این اصل کاهش پیچیدگی و افزایش قابلیت نگهداری کد است.

پس تا الان، همانطور که گفتیم، SOLID یک مجموعه از پنج اصل طراحی شی‌گرا است.
و SRP اولین اصل از این پنج اصل است.
و هدف این اصول کمک به ساختار کدهای مقیاس‌پذیر، قابل نگهداری و تست‌شده است.
و مسئولیت‌ها باید به طور جداگانه و مستقل از یکدیگر مدیریت شوند.

در این راستا دو مفهوم دیگر نیز مطرح می شوند، که از آنها با عنوان "اتصال و انسجام (Coupling & Cohesion) در طراحی نرم افزار" صحبت می شود.

انسجام یا همان Cohesion:
مسئولیت‌های مختلف یک ماژول چقدر مرتبط و متمرکز هستند.

  اتصال یا همان Coupling:
میزانی که هر ماژول برنامه به هر یک از ماژول های دیگر متکی است.

و ما باید برای اتصال کم و انسجام بالا تلاش کنیم.

چرا SRP اهمیت دارد؟
•    سادگی و خوانایی: کلاسی که تنها یک کار انجام می‌دهد، بسیار ساده‌تر برای درک و استفاده است.
•    نگهداری آسان‌تر: وقتی تغییرات تنها به یک حوزه خاص محدود می‌شوند، خطر بروز خطاهای ناخواسته کاهش می‌یابد.
•    تسهیل تست واحد (Unit Testing): کلاس‌های کوچک با یک مسئولیت خاص، راحت‌تر تست می‌شوند.
•    افزایش قابلیت توسعه: با اعمال SRP، افزودن ویژگی‌های جدید بدون تأثیرگذاری روی سایر قسمت‌های سیستم ساده‌تر می‌شود.

-  مثال ساده
- یک مثال از نقض SRP:
  - کلاسی که هم مسئول پردازش داده‌ها و هم مسئول نمایش داده‌ها است.

public class Report
{
    public string Content { get; set; }

    public Report(string content)
    {
        Content = content;
    }

    public void FormatReport()
    {
        // گزارش را فرمت می‌کند
        Console.WriteLine("Formatting report...");
    }

    public void PrintReport()
    {
        // گزارش را چاپ می‌کند
        Console.WriteLine("Printing report...");
    }

    public void SaveToFile(string filePath)
    {
        // گزارش را در فایل ذخیره می‌کند
        File.WriteAllText(filePath, Content);
        Console.WriteLine("Report saved to file.");
    }
}

این کلاس چندین مسئولیت دارد:
مدیریت محتوا
فرمت‌بندی
چاپ
ذخیره‌سازی
که یعنی اصل SRP رعایت نشده.

بنابراین، بر خلاف SRP عمل کرده است. اگر هر کدام از این کارها تغییر کند (مثلاً نحوه چاپ یا نحوه ذخیره)، این کلاس باید تغییر کند.

- یک مثال از رعایت SRP:
  - تقسیم کد به چند کلاس: یکی برای مدیریت محتوا و یکی برای فرمت‌بندی و یکی برای چاپ و دیگری برای ذخیره‌سازی.

کد اصلاح‌ شده براساس SRP:

public class Report
{
    public string Content { get; private set; }

    public Report(string content)
    {
        Content = content;
    }
}

کلاس برای فرمت‌بندی:

public class ReportFormatter
{
    public string Format(Report report)
    {
        // منطق فرمت‌بندی فرضی
        return $"*** FORMATTED REPORT ***\n{report.Content}\n**************************";
    }
}

کلاس برای چاپ:

public class ReportPrinter
{
    public void Print(string formattedReport)
    {
        // فرضاً چاپ روی کنسول
        Console.WriteLine("Printing Report:");
        Console.WriteLine(formattedReport);
    }
}

کلاس برای ذخیره‌سازی:

public class ReportSaver
{
    public void Save(string content, string filePath)
    {
        File.WriteAllText(filePath, content);
        Console.WriteLine($"Report saved at: {filePath}");
    }
}

استفاده از کلاس ها:

class Program
{
    static void Main()
    {
        var report = new Report("This is the content of the report.");

        var formatter = new ReportFormatter();
        var printer = new ReportPrinter();
        var saver = new ReportSaver();

        string formattedReport = formatter.Format(report);
        printer.Print(formattedReport);
        saver.Save(formattedReport, "report.txt");
    }
}

اکنون هر کلاس فقط یک دلیل برای تغییر دارد و مسئولیت خودش را مدیریت می‌کند.

در این ساختار جدید:

کلاس Report فقط داده را نگهداری می‌کند.
کلاس ReportFormatter فقط مسئول فرمت است.
کلاس ReportPrinter فقط چاپ می‌کند.
کلاس ReportSaver فقط ذخیره می‌کند.
بنابراین هر کدام تنها یک مسئولیت دارند و اصل SRP رعایت شده.

نشانه‌های نقض SRP
•    کلاس‌هایی با متدهای زیاد و نامرتبط
•    کلاس‌هایی که به تغییرات در چند بخش مختلف پروژه واکنش نشان می‌دهند
•    تغییر در یک نیازمندی باعث تغییرات متعدد در یک کلاس می‌شود

نکته‌های عملی برای رعایت SRP
•    تحلیل دقیق مسئولیت‌ها: قبل از طراحی کلاس‌ها، مسئولیت‌ها را شفاف کنید.
•    نام‌گذاری دقیق: اگر برای نام‌گذاری کلاس دچار مشکل شدید یا مجبور به استفاده از "و" در نام شدید، احتمالاً کلاس بیش از یک مسئولیت دارد.
•    طراحی مبتنی بر تغییرات آتی: به این فکر کنید که چه تغییراتی ممکن است رخ دهد و کلاس باید چقدر مقاوم باشد.

 مشکلات نقض SRP
- اگر کلاس‌ها بیش از یک مسئولیت داشته باشند:
-    تغییرات در یک بخش می‌تواند بر سایر بخش‌ها تأثیر بگذارد.
-    تست و نگهداری مشکل‌تر می‌شود.
-    کد به راحتی پیچیده و قابل فهم نیست.

مثال‌های واقعی از SRP در پروژه‌ها
- مثال 1: مدیریت پایگاه داده و مدیریت لاگ‌ها در دو کلاس جداگانه.
- مثال 2: تفکیک مدیریت ورودی کاربر و پردازش داده‌های ورودی.

-  مزایای SRP
-    کاهش پیچیدگی
-    قابلیت تست بهتر
-    انعطاف‌پذیری در تغییرات
-    کاهش خطر باگ‌ها

-  نتیجه‌گیری
اصل مسئولیت‌پذیری تک‌وظیفه‌ای یکی از بنیادی‌ترین اصول برای نوشتن کد تمیز و مقیاس‌پذیر است. رعایت SRP باعث می‌شود نرم‌افزار شما منعطف‌تر، قابل تست‌تر و قابل نگهداری‌تر باشد. گرچه گاهی اوقات تقسیم مسئولیت‌ها در ابتدا به نظر وقت‌گیر می‌آید، اما در بلندمدت ارزش بسیار بالایی خواهد داشت.