بينما نمضي قدمًا في مشروع ما، ضائعين في كتل if-else، ونكافح مع الشروط المعقدة والتعليمات البرمجية المتكررة، فإننا نبحث عن حل. ولكن لماذا يجب أن نكون عالقين في كتل إذا كان الأمر كذلك؟ في هذه المقالة، دعونا نكتشف طريقة التخلص من الارتباك إذا كان آخر مع أنماط الإستراتيجية والمصنع.

المشكلة: إذا كان هناك ارتباك آخر

لنفترض أنك تقوم بتطوير تطبيق للتجارة الإلكترونية وتحتاج إلى دعم طرق دفع مختلفة مثل بطاقة الائتمان وبطاقة الخصم والعملات المشفرة. تبدأ باستخدام كتل if-else لمعالجة الدفعات:

public class PaymentService {

    public void processPayment(String paymentType) {
        if (paymentType.equals("CREDIT_CARD")) {
            System.out.println("Processing credit card payment...");
        } else if (paymentType.equals("DEBIT_CARD")) {
            System.out.println("Processing debit card payment...");
        } else if (paymentType.equals("CRYPTO")) {
            System.out.println("Processing crypto payment...");
        } else {
            throw new IllegalArgumentException("Invalid payment type");
        }
    }
}

على الرغم من أن الأمر قد يبدو بسيطًا في البداية، إلا أنه مع زيادة طرق الدفع، يزداد التعقيد أيضًا. طريقة الدفع الجديدة تعني إضافة شرط جديد. والنتيجة هي كومة من التعليمات البرمجية التي يصعب إدارتها. وهذه الطريقة تتعارض مع مبدأ المفتوح المغلق.

ولكن يمكننا استخدام كلا من نمطي الإستراتيجية والمصنع لحل هذه المشكلة.

أولاً، لنقم بإنشاء تعداد:

public enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    CRYPTO
}

الحل: التنظيف باستخدام نمط الإستراتيجية

public interface PaymentStrategy {
    void pay(PaymentRequest request);
}

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class DebitCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class CryptoPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

في هذه المرحلة، يتم تنفيذ استراتيجية منفصلة لكل طريقة دفع من واجهة مشتركة. الآن، مع نمط المصنع، سنقرر الإستراتيجية التي سنختارها.

الخطوة 2: اختيار الإستراتيجية باستخدام نمط المصنع

في هذه الخطوة، يمكننا جعل نمط المصنع أكثر نظافة وتحسينًا باستخدام EnumMap.

public class PaymentFactory {
    private static final Map strategies = new EnumMap(PaymentType.class);

    static {
        strategies.put(PaymentType.CREDIT_CARD, new CreditCardPayment());
        strategies.put(PaymentType.DEBIT_CARD, new DebitCardPayment());
        strategies.put(PaymentType.CRYPTO, new CryptoPayment());
    }

    public static PaymentStrategy getPaymentStrategy(PaymentType paymentType) {
        PaymentStrategy strategy = strategies.get(paymentType);

        if (Objects.isNull(strategy))
            throw new IllegalArgumentException("Strategy not found");

        return strategy;
    }
}

الخطوة الأخيرة: إعادة تنظيم فئة الخدمة

الآن، دعونا نستخدم ما قمنا به.

public class PaymentService {

    public void processPayment(PaymentRequest request) {
        // Don't forget to check objects if null!
        if (Objects.isNull(request) || Objects.isNull(request.getPaymentType())
            throw new IllegalArgumentException("Request can not be null!");
        PaymentStrategy strategy = PaymentFactory.getPaymentStrategy(request.getPaymentType());

        strategy.pay(request);
    }
}

في الوضع الحالي، لا نحتاج إلى أي عمليات حظر إذا كانت غير ذلك لمعالجة الدفع. بفضل الإستراتيجية وأنماط المصنع، أصبح الكود الخاص بنا أكثر وضوحًا وقابلية للتوسيع.

لماذا يجب علينا استخدام هذه الأنماط؟

1. القابلية للتوسعة: لا تتطلب إضافة طريقة دفع جديدة سوى فئة جديدة وبضعة أسطر من التعليمات البرمجية.
2. سهولة القراءة: باستخدام الاستراتيجيات والمصنع بدلاً من كتل if-else، فإنك تجعل التعليمات البرمجية الخاصة بك أكثر قابلية للفهم والإدارة.
3. قابلية الصيانة: باستخدام الإستراتيجية ونمط المصنع، يمكن إجراء تغييرات على الكود دون التأثير على أجزاء أخرى من الكود.

الخاتمة: من الارتباك إلى الوضوح

إذا كنت تعمل في مشروع متنامٍ، فلا يجب عليك استخدام كتل if-else. تعد أنماط الإستراتيجية والمصنع حلولاً مثالية لجعل التعليمات البرمجية الخاصة بك أكثر وضوحًا ونمطية وقابلة للصيانة.

كما ترون في هذه المقالة، فإن استخدام أنماط التصميم بدلاً من كتل if-else لإدارة معاملات الدفع يجعل المشروع أكثر قابلية للتطوير ويحسن إمكانية قراءة التعليمات البرمجية. جرب هذه الأنماط في مشروعك القادم بدلاً من استخدام كتل if-else.

...

شكرًا لك على قراءة مقالتي! إذا كان لديك أي أسئلة أو تعليقات أو أفكار ترغب في مشاركتها، فأنا أحب أن أسمعها في التعليقات.

يمكنك متابعتي على dev.to لمزيد من المعلومات حول هذا الموضوع ومشاركاتي الأخرى.

شكرًا لك؟؟

لمتابعتي على LinkedIn: https://www.linkedin.com/in/tamerardal/
متوسط: لا تستخدم كتل if-else بعد الآن! استخدم الإستراتيجية ونمط المصنع معًا