सॉफ्टवेयर विकास में, किसी परियोजना की दीर्घकालिक सफलता के लिए कोड रखरखाव, विस्तार और लचीलापन महत्वपूर्ण हैं। SOLID सिद्धांतों को डेवलपर्स को ऐसे कोड बनाने में मार्गदर्शन करने के लिए तैयार किया गया था जो समझने, संशोधित करने और विस्तार करने में आसान हो। इस लेख में, हम पांच SOLID सिद्धांतों में से प्रत्येक के बारे में बात करेंगे और जावा में व्यावहारिक उदाहरणों के साथ उनका उपयोग कैसे करें।

1. एकल उत्तरदायित्व सिद्धांत

एकल उत्तरदायित्व सिद्धांत (एसआरपी) स्थापित करता है कि एक वर्ग के पास परिवर्तन का केवल एक ही कारण होना चाहिए, अर्थात, सिस्टम के भीतर उसकी एक ही जिम्मेदारी होनी चाहिए।

// Antes de aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }

    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

// Após aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }
}

class EmailService {
    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

उदाहरण में, हम डेटाबेस में किसी उत्पाद को सहेजने की ज़िम्मेदारी को उत्पाद के बारे में ईमेल भेजने की ज़िम्मेदारी से अलग करते हैं। यह भविष्य में परिवर्तनों को सुविधाजनक बनाता है, क्योंकि ईमेल भेजने में परिवर्तन अब उत्पाद बचत तर्क को प्रभावित नहीं करते हैं।

2. खुला/बंद सिद्धांत

ओपन/क्लोज्ड सिद्धांत (ओसीपी) सुझाव देता है कि सॉफ्टवेयर इकाइयां (कक्षाएं, मॉड्यूल, फ़ंक्शन इत्यादि) विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद होनी चाहिए। यह अमूर्तन और वंशानुक्रम के उपयोग के माध्यम से प्राप्त किया जाता है।

// Exemplo inicial violando o OCP
class AreaCalculator {
    public double calculateArea(Rectangle[] rectangles) {
        double area = 0;
        for (Rectangle rectangle : rectangles) {
            area  = rectangle.width * rectangle.height;
        }
        return area;
    }
}

// Exemplo após aplicar o OCP
interface Forma {
    double calculateArea();
}
class Rectangle implements Forma {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    @Override
    public double calculateArea() {
        return width * height;
    }
}

class AreaCalculator {
    public double calculateArea(Forma [] formas) {
        double area = 0;
        for (Forma formas: formas) {
            area  = forma.calculateArea();
        }
        return area;
    }
}

इस दूसरे उदाहरण में, प्रारंभ में एरियाकैलकुलेटर वर्ग सीधे आयत वर्ग पर निर्भर था। इसका मतलब यह है कि यदि आप किसी अन्य प्रकार की आकृति, जैसे वृत्त या त्रिकोण, जोड़ना चाहते हैं, तो आपको एरियाकैलकुलेटर वर्ग को संशोधित करना होगा, इस प्रकार ओसीपी का उल्लंघन होगा। शेप इंटरफ़ेस के निर्माण के साथ, एरियाकैलकुलेटर वर्ग मौजूदा कोड को संशोधित किए बिना नए ज्यामितीय आकार प्राप्त करने में सक्षम है।

3. लिस्कोव प्रतिस्थापन सिद्धांत

लिस्कोव प्रतिस्थापन सिद्धांत (एलएसपी) में कहा गया है कि सिस्टम की अखंडता को प्रभावित किए बिना एक सुपरक्लास की वस्तुओं को उसके उपवर्गों की वस्तुओं द्वारा प्रतिस्थापित किया जाना चाहिए। दूसरे शब्दों में, उपवर्गों का व्यवहार सुपरवर्गों के व्यवहार के अनुरूप होना चाहिए।

// Classe base
class Bird {
    public void fly() {
        // Método padrão que imprime "Flying"
        System.out.println("Flying");
    }
}

// Classe derivada que viola o LSP
class Duck extends Bird {
    @Override
    public void fly() {
        // Sobrescrita que imprime "Ducks cannot fly"
        System.out.println("Ducks cannot fly");
    }
}

समस्या: डक क्लास "बत्तखें उड़ नहीं सकती" प्रिंट करने के लिए फ्लाई() विधि को ओवरराइड कर रही है, इस प्रकार बर्ड बेस क्लास में परिभाषित डिफ़ॉल्ट व्यवहार बदल रहा है, जो कि सभी पक्षी उड़ते हैं ("फ्लाइंग")। यह एलएसपी का उल्लंघन करता है क्योंकि कोई भी कोड जो बर्ड ऑब्जेक्ट या उसके उपवर्गों के उड़ने की उम्मीद करता है वह डक के साथ सही ढंग से काम नहीं करेगा, जिसके बारे में हम पहले से ही जानते हैं कि वह उड़ता नहीं है।

// Classe derivada que respeita o LSP
interface Bird {
    void fly();
}
class Eagle implements Bird {
    @Override
    public void fly() {
        System.out.println("Flying like an Eagle");
    }
}
class Duck implements Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ducks cannot fly");
    }
}

इस दृष्टिकोण के साथ, ईगल और डक को विनिमेय किया जा सकता है जहां एक पक्षी की अपेक्षा की जाती है, बर्ड इंटरफ़ेस द्वारा निर्धारित अपेक्षाओं को तोड़े बिना। डक द्वारा दिया गया अपवाद स्पष्ट रूप से बताता है कि बत्तखें उड़ती नहीं हैं, सुपरक्लास के व्यवहार को इस तरह से संशोधित किए बिना कि कोड में अप्रत्याशित समस्याएं पैदा हो सकती हैं।

4. इंटरफ़ेस पृथक्करण सिद्धांत

इंटरफ़ेस पृथक्करण सिद्धांत (आईएसपी) सुझाव देता है कि एक वर्ग के इंटरफेस उन ग्राहकों के लिए विशिष्ट होने चाहिए जो उनका उपयोग करते हैं। यह "वसा" इंटरफेस से बचता है जिसके लिए ग्राहकों द्वारा उपयोग नहीं किए जाने वाले तरीकों के कार्यान्वयन की आवश्यकता होती है।

// Exemplo antes de aplicar o ISP
interface Worker {
    void work();
    void eat();
    void sleep();
}

class Programmer implements Worker {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

// Exemplo após aplicar o ISP
interface Worker {
    void work();
}
interface Eater {
    void eat();
}
interface Sleeper {
    void sleep();
}
class Programmer implements Worker, Eater, Sleeper {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

उदाहरण में, हमने वर्कर इंटरफ़ेस को छोटे इंटरफ़ेस (कार्य, खाओ, नींद) में विभाजित किया है ताकि यह सुनिश्चित किया जा सके कि जो कक्षाएं उन्हें लागू करती हैं उनके पास केवल वही विधियां हैं जिनकी उन्हें आवश्यकता है। यह कक्षाओं को उन तरीकों को लागू करने से रोकता है जो उनके लिए प्रासंगिक नहीं हैं, कोड स्पष्टता और सामंजस्य में सुधार करते हैं।

5. निर्भरता व्युत्क्रम सिद्धांत

निर्भरता व्युत्क्रम सिद्धांत (डीआईपी) सुझाव देता है कि उच्च-स्तरीय मॉड्यूल (जैसे व्यवसाय या एप्लिकेशन वर्ग, जो मुख्य व्यवसाय नियमों को लागू करते हैं) को निम्न-स्तरीय मॉड्यूल (बुनियादी ढांचे वर्ग, जैसे बाहरी डेटा तक पहुंच और) पर निर्भर नहीं होना चाहिए सेवाएँ जो उच्च-स्तरीय संचालन का समर्थन करती हैं)। दोनों को अमूर्तता पर निर्भर होना चाहिए।

// Exemplo antes de aplicar o DIP
class BackendDeveloper {
    public void writeJava() {
        // Lógica para escrever em Java
    }
}
class Project {
    private BackendDeveloper developer;

    public Project() {
        this.developer = new BackendDeveloper();
    }
    public void implement() {
        developer.writeJava();
    }
}

// Exemplo após aplicar o DIP
interface Developer {
    void develop();
}
class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        // Lógica para escrever em Java
    }
}
class Project {
    private Developer developer;

    public Project(Developer developer) {
        this.developer = developer;
    }
    public void implement() {
        developer.develop();
    }
}

परियोजना वर्ग अब एक ठोस कार्यान्वयन (बैकएंडडेवलपर) के बजाय एक अमूर्त (डेवलपर) पर निर्भर करता है। यह विभिन्न प्रकार के डेवलपर्स (जैसे फ्रंटएंडडेवलपर, मोबाइलडेवलपर) को उसके कोड को संशोधित किए बिना आसानी से प्रोजेक्ट क्लास में इंजेक्ट करने की अनुमति देता है।

निष्कर्ष

SOLID सिद्धांतों को अपनाने से न केवल आपके कोड की गुणवत्ता बढ़ती है, बल्कि यह आपके तकनीकी कौशल को भी मजबूत करता है, आपकी कार्य कुशलता बढ़ाता है, और एक सॉफ्टवेयर डेवलपर के रूप में आपके करियर पथ को बढ़ावा देता है।