به عنوان يک برنامه‌نويس، حتماً با اين مشکل روبرو شده‌ايد: پروژه‌اي که ابتدا هيجان‌انگيز بود، به مرور زمان تبديل به باتلاقي از کد‌هاي به‌هم‌تنيده و غيرقابل نگهداري شد. اضافه کردن يک قابليت ساده، سيستم را به هم مي‌ريزد و پيدا کردن باگ‌ها تبديل به کابوس مي‌شود. نام اين مشکل در دنياي برنامه‌نويسي کد‌هاي "بد بو" (Code Smells) است.

براي فرار از اين چرخه معيوب، بايد به اصول طراحي شيءگرا (OOP) متکي شويد. و در ميان تمام دستورالعمل‌ها، هيچ‌کدام مهم‌تر از اصول SOLID نيستند. اين مجموعه، 5 اصل بنيادين است که توسط رابرت سي. مارتين (معروف به Uncle Bob) براي کمک به توسعه‌دهندگان جهت ساخت سيستم‌هاي انعطاف‌پذير، قابل درک و با قابليت توسعه درازمدت ارائه شده‌اند.

در اين مقاله جامع از Learndun، ما نه تنها توضيح مي‌دهيم که اصول SOLID چيست، بلکه هر اصل را با مثال‌هاي عملي، بررسي مثال‌هاي نقض (Anti-Patterns) و فوايد مستقيم آن در پروژه‌هاي بزرگ به شما آموزش مي‌دهيم. در پايان اين مقاله، ديدگاه شما نسبت به ساختار کد کاملاً تغيير خواهد کرد.

1. اصل SRP: Single Responsibility Principle (اصل مسئوليت يگانه)

تعريف SRP: يک کلاس، يک دليل براي تغيير

بر اساس اصل SRP، هر کلاس يا ماژول در برنامه شما بايد تنها يک مسئوليت (Job) داشته باشد و فقط يک دليل براي تغيير وجود داشته باشد. اين دليل بايد مربوط به آن مسئوليت يگانه باشد.

هدف اصلي SRP افزايش هم‌بستگي (Cohesion) در کلاس‌ها و کاهش اتصال (Coupling) بين ماژول‌ها است. کلاسي که بيش از يک مسئوليت دارد، به دليل‌هاي مختلفي براي تغيير وابسته است که اين امر توسعه، تست و نگهداري آن را به شدت سخت مي‌کند.

مثال نقض (Code Smell): کلاس UserGod

يک کلاس که هم مديريت داده کاربر (ذخيره در ديتابيس) و هم منطق گزارش‌گيري و هم اعتبارسنجي را انجام مي‌دهد، يک نقض آشکار SRP است:

class User {
    public void saveUserToDB() { /* ... منطق اتصال به ديتابيس ... */ }
    public boolean isValid() { /* ... منطق اعتبارسنجي ورودي‌ها ... */ return true; }
    public void generateReport() { /* ... منطق ساخت گزارشات مالي ... */ }
}
            

پياده‌سازي صحيح SRP (تفکيک مسئوليت‌ها)

ما مسئوليت‌ها را به سه کلاس جداگانه تفکيک مي‌کنيم:

class User { // فقط مسئول نگهداري داده (POJO)
    private String name;
    private String email;
    // ... getter و setter
}

class UserValidator { // فقط مسئول اعتبارسنجي
    public boolean isValid(User user) { /* ... */ return true; }
}

class UserRepository { // فقط مسئول ذخيره‌سازي داده
    public void save(User user) { /* ... */ }
}
            

حالا اگر قوانين اعتبارسنجي تغيير کند، فقط UserValidator دستکاري مي‌شود، بدون اينکه نيازي به باز کردن کلاس‌هاي User يا UserRepository باشد.

2. اصل OCP: Open-Closed Principle (اصل باز/بسته)

تعريف OCP: توسعه‌پذير باشيد، اما دستکاري نکنيد!

اين اصل مي‌گويد: يک ماژول بايد براي توسعه‌پذيري (Extension) باز باشد، اما براي تغيير (Modification) بسته باشد. به زبان ساده، وقتي نياز به افزودن قابليت جديد داريد، بايد يک کد جديد بنويسيد، نه اينکه کد موجود و امتحان شده را ويرايش کنيد.

مثال نقض: استفاده از عبارت Switch/If-Else

تصور کنيد يک تابع محاسبه هزينه حمل و نقل داريد که بر اساس نوع کالا (کتاب، الکترونيک، لباس) با استفاده از if-else يا switch کار مي‌کند:

class ShippingCalculator {
    public double calculate(String itemType, double weight) {
        if (itemType.equals("BOOK")) { /* ... منطق کتاب ... */ }
        else if (itemType.equals("ELECTRONIC")) { /* ... منطق الکترونيک ... */ }
        // اگر نوع جديدي مثل "FOOD" اضافه شود، بايد اين کلاس را دستکاري کنيد! (نقض OCP)
        return 0; 
    }
}
            

پياده‌سازي صحيح OCP (با اينترفيس و پلي‌مورفيسم)

به جاي عبارت‌هاي شرطي، يک اينترفيس تعريف مي‌کنيم:

interface ShippingStrategy {
    double calculate(double weight);
}

class BookShipping implements ShippingStrategy {
    public double calculate(double weight) { /* ... */ return weight * 5; }
}

class ElectronicShipping implements ShippingStrategy {
    public double calculate(double weight) { /* ... */ return weight * 10; }
}
// براي اضافه کردن نوع جديد (FOOD)، کافي است يک کلاس جديد بسازيد و اينترفيس را پياده‌سازي کنيد. بدون تغيير کد قديمي! (رعايت OCP)
            

3. اصل LSP: Liskov Substitution Principle (اصل جايگزيني ليسکوف)

تعريف LSP: هر زيرکلاسي، مي‌تواند جايگزين والد خود شود

به بيان کوتاه از باربارا ليسکوف: اشياي يک زيرکلاس بايد بتوانند جايگزين اشياي کلاس اصلي (Base Class) خود شوند، بدون اينکه عملکرد صحيح برنامه را به خطر بيندازند.

اين اصل بر اهميت رفتار صحيح (Behavioral Subtyping) تمرکز دارد. وراثت زماني امن است که کلاس فرزند قرارداد (Contract) کلاس والد را کاملاً رعايت کند.

مثال نقض: کلاس مربع که از مستطيل ارث مي‌برد

اين رايج‌ترين مثال نقض LSP است. مستطيل (Rectangle) دو سمت مستقل دارد، اما مربع (Square) هر دو سمت را برابر نگه مي‌دارد. اگر کلاس مربع از مستطيل ارث ببرد و سعي کند متد setHeight() را Override کند و عرض را هم تغيير دهد، اين نقض LSP است.

به جاي وراثت، مي‌توان از يک انتزاع مشترک (مثل شکل سه‌بعدي) استفاده کرد يا ساختار را به کلي تغيير داد.

4. اصل ISP: Interface Segregation Principle (اصل تفکيک اينترفيس)

تعريف ISP: اينترفيس‌هاي کوچک و مشخص بسازيد

اصل ISP مستقيماً با SRP در سطح اينترفيس‌ها ارتباط دارد. برنامه‌نويسان نبايد مجبور باشند متدهايي را پياده‌سازي کنند که به کارشان نمي‌آيد.

به جاي داشتن يک اينترفيس بزرگ (Fat Interface) با متدهاي زياد، آن را به چندين اينترفيس کوچک و مخصوص وظيفه (Role Interfaces) تقسيم کنيد.

مثال نقض: اينترفيس MegaWorker

فرض کنيد اينترفيس MegaWorker شامل متدهاي work()، eat() و sleep() است. شما يک کلاس Robot داريد که بايد اين اينترفيس را پياده‌سازي کند:

interface MegaWorker {
    void work();
    void eat();
    void sleep();
}

class Robot implements MegaWorker {
    public void work() { /* کار مي‌کند */ }
    public void eat() { throw new UnsupportedOperationException(); } // مجبور به پياده‌سازي متد بي‌معني! (نقض ISP)
    public void sleep() { /* ... */ }
}
            

پياده‌سازي صحيح ISP (تفکيک اينترفيس‌ها)

بهترين راهکار، تفکيک اينترفيس به نقش‌هاي کوچک است:

interface Workable { void work(); }
interface Eatable { void eat(); }
interface Sleepable { void sleep(); }

class Robot implements Workable, Sleepable { // فقط موارد مورد نياز را پياده‌سازي مي‌کند (رعايت ISP)
    public void work() { /* ... */ }
    public void sleep() { /* ... */ }
}
            

5. اصل DIP: Dependency Inversion Principle (اصل وارونگي وابستگي)

تعريف DIP: وابستگي به انتزاع، نه پياده‌سازي

مهم‌ترين اصل براي ساخت معماري‌هاي ماژولار و تست‌پذير. DIP مي‌گويد:

1. ماژول‌هاي سطح بالا (مثل منطق کسب‌وکار) نبايد به ماژول‌هاي سطح پايين (مثل ديتابيس) وابسته باشند. هر دو بايد به انتزاعيات (Abstraction) وابسته باشند.
2. انتزاعيات نبايد به جزئيات وابسته باشند. جزئيات بايد به انتزاعيات وابسته باشند.

مثال نقض: وابستگي مستقيم و سخت

وقتي يک کلاس سرويس ايميل (ماژول سطح بالا) مستقيماً از يک کلاس پياده‌سازي SMTP (ماژول سطح پايين) استفاده مي‌کند، وابستگي سخت ايجاد شده است:

class EmailService {
    private SmtpServer smtpServer = new SmtpServer(); // وابستگي سخت به يک کلاس خاص (نقض DIP)
    public void sendEmail(String to, String msg) {
        smtpServer.connect();
        smtpServer.send(to, msg);
    }
}
            

پياده‌سازي صحيح DIP (استفاده از Injection)

با تعريف يک اينترفيس و استفاده از آن در کلاس سطح بالا، وابستگي را وارونه مي‌کنيم:

interface IMessageSender { // انتزاع
    void send(String to, String msg);
}

class SmtpServer implements IMessageSender { /* پياده‌سازي جزئيات */ } 

class EmailService { // ماژول سطح بالا
    private final IMessageSender sender;
    
    // تزريق وابستگي (Dependency Injection) در سازنده
    public EmailService(IMessageSender sender) {
        this.sender = sender;
    } 
    
    public void sendEmail(String to, String msg) {
        sender.send(to, msg); // وابستگي به انتزاع، نه جزئيات (رعايت DIP)
    }
}
            

با رعايت DIP، مي‌توانيم هر زمان که خواستيم، بدون تغيير کلاس EmailService، شيوه ارسال پيام را از SMTP به SMS يا WebSocket تغيير دهيم.