برنامه نویسی

SOLID: اصل مسئولیت واحد با مثال

در این مقاله با موارد زیر آشنا خواهید شد:

  1. SRP چیست؟
  2. اهمیت SRP در توسعه نرم افزار
  3. نقاط قوت
  4. نقاط ضعف
  5. ثبت نام توییتر

SRP چیست؟

اصل مسئولیت واحد (SRP) یکی از پنج اصل طراحی جامد است که توسعه نرم افزار را هدایت می کند.

تعریف: یک کلاس یا ماژول باید تنها یک دلیل برای تغییر داشته باشد.

این اصل می گوید که یک کلاس باید تنها یک دلیل برای تغییر و یک مسئولیت داشته باشد. این اصل برای ارتقای ماژولار بودن و کمک به توسعه‌دهندگان برای ایجاد کد آسان‌تر برای درک، اصلاح و نگهداری است.

در اصل، SRP بیان می کند که هر کلاس باید یک مسئولیت واحد و کاملاً تعریف شده داشته باشد و مسئولیت باید در آن کلاس محصور شود.

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

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

اهمیت SRP در توسعه نرم افزار

چندین دلیل وجود دارد که چرا SRP در توسعه نرم افزار مهم است:

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

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

مزایای

مزایای پیروی از اصل مسئولیت واحد (SRP) شامل موارد زیر است:

  • سازماندهی کد و قابلیت نگهداری بهتر.
  • بهبود خوانایی و درک کد.
  • اشکال زدایی و تست کد آسان تر.
  • درجه بالاتری از قابلیت استفاده مجدد کد.
  • تسهیل توسعه موازی و اجرای ویژگی های جدید.
  • امکان ایجاد تغییرات در کد با خطر کمتر معرفی باگ.

معایب

برخی از معایب اصل مسئولیت واحد (SRP) شامل موارد زیر است:

  • افزایش پیچیدگی، زیرا یک سیستم ممکن است به کلاس های بیشتری برای پیاده سازی عملکرد مشابه نیاز داشته باشد.
  • پتانسیل برای مهندسی بیش از حد، که منجر به انتزاع بیش از حد و کد غیر ضروری می شود.
  • مشکلات در تعیین ریزه کاری مناسب مسئولیت ها.
  • چالش‌ها در ایجاد تعادل بین تفکیک مسئولیت‌ها و حفظ عملکرد.

هنگامی که برنامه نویسان سعی می کنند ویژگی ها یا رفتار جدیدی را به یک محصول نرم افزاری اضافه کنند، اغلب همه چیز را در کلاس فعلی ادغام می کنند. زمانی که چیزی بعداً نیاز به تغییر داشته باشد، به دلیل پیچیدگی کد، فرآیند Refactor کد بسیار وقت گیر و خسته کننده است.

اصل مسئولیت واحد به ما کمک می کند کلاس های ساده ای ایجاد کنیم که فقط یک کار را انجام می دهند. این کمک می کند تا تغییرات یا افزودن برنامه های افزودنی به کد موجود بسیار ساده تر شود.

ثبت نام توییتر با استفاده از اصل مسئولیت واحد

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

بیایید اولین اصل طراحی را در جریان ثبت نام توییتر پیاده سازی کنیم.

🔐 فرآیند ثبت نام در توییتر

یک مورد استفاده را در نظر بگیرید که در آن کاربر می خواهد در توییتر ثبت نام کند. مراحلی که توییتر برای ثبت نام انجام می دهد عبارتند از:

  1. توییتر از کاربران می خواهد که با فرم های ثبت نام ثبت نام کنند.
  2. توییتر شی کاربر را در پایگاه داده خود ذخیره می کند که شامل User جزئیات – email، name، passwordو سایر ابرداده ها و غیره
  3. توییتر یک پیام خوشامدگویی برای کاربر ارسال می کند.

اجازه دهید کلاسی را اعلام کنیم که مراحل بالا را انجام می دهد.

public class TwitterRegistration {
    public void register() {
        // step 1
        System.out.println("Fill signup form");

        // step 2
        System.out.println("Store account details in database");

        // step 3
        System.out.println("Send a welcome message");
    }
}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

ما در حال ایجاد یک حساب کاربری در توییتر هستیم و این سه مرحله باید جداگانه انجام شود. اما طبقه فوق همه آنها را در یک واحد اعلام کرد TwitterRegistration کلاس آیا این نقض SRP نیست؟

همچنین، مرحله 2 ذخیره یک شی در پایگاه داده نیاز به کار اضافی برای باز کردن یک ارتباط با پایگاه داده، تأیید اعتبار دست دادن و ذخیره شی کاربر دارد. این منطق درج است و باید به طور جداگانه مدیریت شود.

مرحله سوم ارسال پیام خوشامدگویی به کاربر است که باید توسط آن اداره شود NotificationService، بصورت جداگانه.

با استفاده از اصل SRP موارد فوق را تقسیم می کنیم TwitterRegistration کلاس به سه کلاس مختلف، که هر یک دارای یک مسئولیت و تنها یک.

Refactoring برای SRP

Refactoring TwitterRegistration کلاس می دهد:

// Notification Service
class NotificationService {
    public void sendNotification() {
        // step 3
        System.out.println("Send out welcome message");
    }
}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

// Database handshakes
class AccountRepository {
    public void createUser() {
        // step 2
        System.out.println("🔐 Auth Success!");
        System.out.println("Store user data into database");
    }
}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

// Account Registration
class TwitterAccountRegister {
    public void registerUser() {
        // step 1
        System.out.println("fill account internal details");
    }
}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در نهایت پس از بازسازی کلاس های فوق. ما ابتدا اجازه می دهیم TwitterAccountService برای ایجاد چند شیء برای AccountRepository و NotificationService برای ثبت نام کاربران در توییتر.

// Execution Class or Main class
public class TwitterAccountRegister {
    public static void main(String[] args) {
        TwitterAccountService service = new TwitterAccountService();
        service.registerUser();
    }
}

// Account Registration Service
class TwitterAccountService {
    AccountRepository repository = new AccountRepository();
    NotificationService notificationService = new NotificationService();

    public void registerUser() {
        // step 1
        System.out.println("fill account internal details");

        repository.createUser();
        notificationService.sendNotification();
    }
}

// Notification Service
class NotificationService {
    public void sendNotification() {
        // step 3
        System.out.println("Send out welcome message");
    }
}

// Database handshakes
class AccountRepository {
    public void createUser() {
        // step 2
        System.out.println("🔐Signup Success!! Registered");
        System.out.println("Store user data into database");
    }
}

/*
Outputs:
fill account internal details
🔐Signup Success!! Registered
Store user data into database
Send out welcome message
*/
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در بالا TwitterAccountService هر سه کار را انجام می دهد مسئولیت اصلی پر کردن جزئیات حساب در جزئیات حساب و واگذاری سایر مسئولیت ها به کلاس های دیگر است.

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

نتیجه

در نتیجه، اصل مسئولیت واحد (SRP) یک اصل طراحی نرم افزار است که بیان می کند که هر کلاس باید تنها یک دلیل برای تغییر داشته باشد.

پیروی از SRP درک، نگهداری و گسترش کد را آسان‌تر می‌کند. خطر ایجاد اشکالات را کاهش می دهد و آزمایش اجزای جداگانه را آسان تر می کند.

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

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا