Java में SOLID सिद्धांत: डेवलपर्स के लिए सिद्धांत और व्यवहार

SOLID सिद्धांत Java में: सिद्धांत से स्वच्छ कोड तक

प्रत्येक Java डेवलपर को देर-सबेर "गंदे" कोड की समस्या का सामना करना पड़ता है: ऐसी क्लासेस जो सब कुछ एक साथ करती हैं, कठोर निर्भरताएँ, और मौजूदा लॉजिक को तोड़े बिना विस्तार करने में असमर्थता। यहीं पर SOLID सिद्धांत मदद करते हैं — रॉबर्ट मार्टिन (अंकल बॉब) द्वारा प्रतिपादित ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के पाँच मौलिक नियम। इस लेख में, हम Java में उदाहरणों के साथ प्रत्येक सिद्धांत को व्यवहार में समझेंगे, ताकि आपका कोड लचीला, परीक्षण योग्य और रखरखाव में आसान बन सके।

1. Single Responsibility Principle (SRP) — एकल उत्तरदायित्व का सिद्धांत

सार: "एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए।" दूसरे शब्दों में, क्लास को एक स्पष्ट रूप से परिभाषित कार्य के लिए जिम्मेदार होना चाहिए।

SRP का उल्लंघन

क्लास OrderService पर विचार करें, जो एक साथ मूल्य गणना, डेटाबेस में सहेजना और ईमेल भेजने का काम करती है:

public class OrderService {    public void processOrder(Order order) {        // 1. लागत की गणना        double total = order.getItems().stream()                .mapToDouble(Item::getPrice)                .sum();

        // 2. DB में सहेजना        Database.save(order);

        // 3. सूचना भेजना        EmailService.send("ऑर्डर राशि के साथ तैयार: " + total);    }}

समस्या: ईमेल भेजने के तर्क या सहेजने के तरीके में बदलाव से OrderService को बदलना होगा। यह SRP का उल्लंघन है।

SRP के अनुसार रिफैक्टरिंग

जिम्मेदारियों को तीन अलग-अलग क्लासेस में विभाजित करते हैं:

public class PriceCalculator {    public double calculateTotal(Order order) {        return order.getItems().stream()                .mapToDouble(Item::getPrice)                .sum();    }}

public class OrderRepository {    public void save(Order order) {        Database.save(order);    }}

public class NotificationService {    public void sendConfirmation(Order order) {        EmailService.send("ऑर्डर राशि के साथ तैयार: " + order.getTotal());    }}

// क्लाइंट कोडpublic class OrderProcessor {    private PriceCalculator calculator;    private OrderRepository repository;    private NotificationService notifier;

    public void processOrder(Order order) {        double total = calculator.calculateTotal(order);        order.setTotal(total);        repository.save(order);        notifier.sendConfirmation(order);    }}

परिणाम: प्रत्येक क्लास में बदलाव का एक ही कारण है। कोड मॉड्यूलर और परीक्षण योग्य हो जाता है।

2. Open-Closed Principle (OCP) — खुले/बंद का सिद्धांत

सार: "सॉफ्टवेयर संस्थाएँ विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद।" नई कार्यक्षमता मौजूदा कोड को बदलने के बजाय विस्तार के माध्यम से जोड़ी जाती है।

OCP का उल्लंघन

एक डिस्काउंट सिस्टम पर विचार करें, जहाँ प्रत्येक नए डिस्काउंट प्रकार के लिए applyDiscount विधि में बदलाव की आवश्यकता होती है:

public class DiscountService {    public double applyDiscount(String type, double price) {        if (type.equals("SUMMER")) {            return price * 0.9;        } else if (type.equals("VIP")) {            return price * 0.8;        }        // नया प्रकार जोड़ना → क्लास में बदलाव        return price;    }}

पॉलीमॉर्फिज्म के माध्यम से समाधान

इंटरफ़ेस और विभिन्न इम्प्लीमेंटेशन का उपयोग करें:

public interface Discount {    double apply(double price);}

public class SummerDiscount implements Discount {    @Override    public double apply(double price) {        return price * 0.9;    }}

public class VipDiscount implements Discount {    @Override    public double apply(double price) {        return price * 0.8;    }}

// नया प्रकार — बस एक नई क्लास
```