design pattern আর clean code — পরীক্ষিত নকশা, পড়ার মতো কোড

১ · Pattern মানে নাম দেওয়া সমাধান, clean code মানে পরের পাঠকের প্রতি সম্মান

ক্রিকেট মাঠে অধিনায়ক বোলারের সাথে কথা বলে শুধু বলেন, “একটা slip আর একটা gully দাও।” দুই শব্দে পুরো একটি পরিকল্পনা বোঝানো হয়ে গেল — কোথায় দাঁড়াতে হবে, কেন, কোন ধরনের বলের জন্য। এই নামগুলো কেউ একদিনে আবিষ্কার করেনি; বহু বছরের খেলায় যে অবস্থানগুলো বারবার কাজে লেগেছে, সেগুলোর নাম হয়ে গেছে। নতুন খেলোয়াড় নামগুলো শিখলেই অভিজ্ঞদের ভাষায় কথা বলতে পারেন।

সফটওয়্যারের design pattern ঠিক এমন। এটা কোনো library নয়, কপি করে বসানোর কোডও নয়। এটা একটি বারবার আসা নকশা-সমস্যার পরীক্ষিত সমাধান-ধাঁচ, যার একটি নাম আছে। “ডেলিভারি চার্জের নিয়ম শহরভেদে বদলায়, আর নতুন নিয়ম প্রায়ই আসে” — এই সমস্যার ধাঁচটির নাম Strategy. সহকর্মীকে “এখানে Strategy বসাও” বললে তিনি সাথে সাথে বোঝেন: একটি interface, কয়েকটি বদলযোগ্য implementation, আর মূল কোড শুধু interface-কে চেনে। প্রতিটি pattern-এর তিনটি অংশ থাকে — কোন পরিস্থিতিতে, কোন সমস্যা (প্রায়ই দুটি টানাপোড়েনের মধ্যে), আর সমাধানের আকার ও তার দাম।

এবার clean code. কোড একবার লেখা হয়, কিন্তু পড়া হয় শতবার — bug খুঁজতে, নতুন feature যোগ করতে, রিভিউ করতে। Clean code-এর মাপকাঠি একটাই: পরের পাঠক কত তাড়াতাড়ি বুঝে কত নিরাপদে বদলাতে পারবেন। সেই পাঠক প্রায়ই ছয় মাস পরের আপনি নিজে, নতুন যোগ দেওয়া সহকর্মী, অথবা একটি AI সহকারী, যে আপনার কোড পড়ে পরামর্শ দেবে। অস্পষ্ট নাম আর জট পাকানো method মানুষকে যেমন বিভ্রান্ত করে, AI-কেও ভুল পথে নেয়।

২ · আগে নীতি — SOLID, DRY, KISS আর YAGNI এক টেবিলে

এই কোর্সে আপনি এর মধ্যে বেশিরভাগ নীতির সাথে আলাদা আলাদা পর্বে দেখা করেছেন। এখানে সবগুলো এক জায়গায়, কারণ প্রতিটি pattern আসলে এদের কোনো একটিকে রক্ষা করার কৌশল। SOLID নামের পাঁচটি নীতি জনপ্রিয় করেন Robert C. Martin, আর আদ্যক্ষর দিয়ে নামটি দেন Michael Feathers.

খেয়াল করুন শেষ দুটি সারি। প্রথম পাঁচটি নীতি বলে “বদলের জন্য জায়গা রাখুন”, শেষ দুটি বলে “যে বদল আসেনি, তার জন্য জায়গা বানাবেন না”। এই দুইয়ের টানাপোড়েনেই নকশার আসল বিচার। একটা কাজের নিয়ম: একই ধরনের বদল দ্বিতীয়বার এলে pattern ভাবুন, প্রথমবারেই নয়। অনেকে আরও সতর্ক নিয়ম মানেন, যার নাম “rule of three”: দ্বিতীয়বার শুধু খেয়াল রাখুন, তৃতীয়বার একই জিনিস লিখতে গেলে তখন abstraction বানান।

আরেকটি শব্দ পুরো পর্বে বারবার আসবে: coupling আর cohesion. Coupling মানে দুটি অংশ একে অপরের কতটা গভীরে জানে; cohesion মানে একটি class-এর ভেতরের জিনিসগুলো কতটা একই কাজের। ভালো নকশা = কম coupling, বেশি cohesion. প্রায় প্রতিটি pattern এই দুটির কোনো একটিকে ঠিক করে।

৩ · তিন পরিবার, আর প্রথমটি — object বানানোর pattern

১৯৯৪ সালে Erich Gamma, Richard Helm, Ralph Johnson আর John Vlissides — যাঁদের ডাকনাম Gang of Four (GoF) — Design Patterns বইয়ে ২৩টি pattern তিনটি পরিবারে সাজান। আজও এই ভাগই সবচেয়ে প্রচলিত:

Factory Method আর static factory — সংক্ষেপে ফিরে দেখা

পর্ব ১৬-এ static factory method দেখেছেন: List.of(...), Integer.valueOf(42), Optional.empty(). Constructor-এর বদলে নামওয়ালা একটি method object দেয় — নাম দিয়ে উদ্দেশ্য বোঝায়, cache থেকে পুরোনো object ফেরত দিতে পারে, এমনকি subclass-এর object-ও দিতে পারে। GoF-এর আসল Factory Method একটু আলাদা: parent class একটি overridable method রাখে, কোন concrete object বানানো হবে সেটা subclass ঠিক করে। আধুনিক Java-তে দুটোর কাজই প্রায়ই একটি Supplier<T> বা static method দিয়ে সেরে ফেলা যায়।

Builder — telescoping constructor-এর ওষুধ

পর্ব ১৬-এর telescoping constructor মনে আছে? new Order("Rahim", "017...", "Rajshahi", null, false, true) — কোন true কিসের, কেউ বলতে পারে না। Builder বাধ্যতামূলক মান নেয় শুরুতে, ঐচ্ছিক মানগুলো নামওয়ালা method-এ, আর শেষে build() একবারে যাচাই করে অপরিবর্তনীয় object দেয়:

record Order(String customer, String phone, String city, List<String> items,
             String coupon, boolean giftWrap) {

    static Builder builder(String customer, String phone) {
        return new Builder(customer, phone);
    }

    static final class Builder {
        private final String customer, phone;          // বাধ্যতামূলক
        private String city = "Dhaka";                 // ঐচ্ছিক, ডিফল্টসহ
        private final List<String> items = new ArrayList<>();
        private String coupon;
        private boolean giftWrap;

        private Builder(String customer, String phone) {
            this.customer = customer;
            this.phone = phone;
        }
        Builder city(String c)   { city = c; return this; }
        Builder item(String i)   { items.add(i); return this; }
        Builder coupon(String c) { coupon = c; return this; }
        Builder giftWrap()       { giftWrap = true; return this; }

        Order build() {                                // যাচাই এক জায়গায়
            if (items.isEmpty()) throw new IllegalStateException("order has no items");
            return new Order(customer, phone, city, List.copyOf(items), coupon, giftWrap);
        }
    }
}

// ব্যবহার — পড়লেই বোঝা যায়
Order o = Order.builder("Rahim", "01711000000")
        .city("Rajshahi")
        .item("Panjabi").item("Attar")
        .giftWrap()
        .build();

প্রতিটি setter-ধাঁচের method this ফেরত দেয় বলে ডাকগুলো শিকলের মতো জোড়া যায় — এটাই fluent interface. List.copyOf দিয়ে তালিকার অপরিবর্তনীয় কপি নেওয়া হয়েছে, যাতে build()-এর পর builder-এ নতুন item যোগ করলেও তৈরি হওয়া Order না বদলায়। JDK-তেও Builder আছে: StringBuilder, Java 11-এর HttpRequest.newBuilder(), Java 21-এর Thread.ofVirtual().name("worker").start(task) (পর্ব ৪২)। চার-পাঁচটির বেশি parameter, যার অনেকগুলো ঐচ্ছিক — তখনই Builder; দুই-তিনটি হলে record-এর সাধারণ constructor যথেষ্ট।

Singleton — সবচেয়ে বিখ্যাত, সবচেয়ে বেশি অপব্যবহৃত

Singleton নিশ্চিত করে পুরো প্রোগ্রামে একটি class-এর একটিমাত্র object, আর সবাই তাকে একটি global পথে পায়। Java-তে লেখার সবচেয়ে নিরাপদ উপায় হলো একটি উপাদানের enum — Joshua Bloch-এর Effective Java বইও এটাই সুপারিশ করে:

enum AppConfig {
    INSTANCE;
    private final Map<String, String> values = new HashMap<>();
    String get(String key) { return values.getOrDefault(key, ""); }
}

String sender = AppConfig.INSTANCE.get("sms.sender");

JVM নিজেই নিশ্চিত করে enum constant একবারই তৈরি হয় — thread-safe, আর serialization বা reflection দিয়ে দ্বিতীয় কপি বানানো যায় না। new AppConfig() লিখলে compiler আটকায়: error: enum classes may not be instantiated.

৪ · জোড়া লাগানোর pattern — Adapter, Decorator, Facade, Proxy

এবার একটি অনলাইন দোকানের checkout ধরুন — এই পর্বের বাকি উদাহরণ এর ওপরেই। এখানে চারটি structural pattern স্বাভাবিকভাবে এসে পড়ে।

Adapter — তৃতীয় পক্ষের SMS API-কে নিজের চুক্তিতে আনা

দোকানের কোড পর্ব ২১-এর মতো একটি ছোট চুক্তি চেনে: SmsSender.send(phone, text). কিন্তু যে SMS কোম্পানির সাথে চুক্তি হলো, তাদের Java library-র method দেখতে সম্পূর্ণ আলাদা — API key লাগে, নম্বর লাগে দেশের কোডসহ, আর সফল হলে 202 ফেরত দেয়। ওদের কোড আপনি বদলাতে পারবেন না, নিজের সারা কোডে ওদের ভাষাও ছড়াতে চান না। সমাধান Adapter — বিদেশি প্লাগের জন্য একটি কনভার্টার:

// তৃতীয় পক্ষের library — এটা আপনি বদলাতে পারবেন না
class QuickSmsClient {
    int dispatch(String apiKey, String msisdn, String body, String mask) { ... }
}

interface SmsSender { boolean send(String phone, String text); }   // আপনার চুক্তি

class QuickSmsAdapter implements SmsSender {
    private final QuickSmsClient client;
    private final String apiKey;
    QuickSmsAdapter(QuickSmsClient client, String apiKey) {
        this.client = client;
        this.apiKey = apiKey;
    }
    public boolean send(String phone, String text) {
        String msisdn = "88" + phone;                    // 017... → 88017...
        int status = client.dispatch(apiKey, msisdn, text, "ABCL");
        return status == 202;                            // ওদের "সফল" কোড
    }
}

এখন বাইরের কোম্পানির সব অদ্ভুততা এক class-এ বন্দি। কাল কোম্পানি বদলালে শুধু নতুন একটি adapter লিখবেন; OrderService একটি অক্ষরও জানবে না। JDK-তে চেনা উদাহরণ: InputStreamReader byte-এর stream-কে character-এর Reader-এ রূপ দেয়, আর Arrays.asList একটি array-কে List-এর চেহারা দেয়।

Decorator — মূল জিনিস না বদলে চারপাশে ক্ষমতা যোগ করা

পেমেন্ট gateway মাঝে মাঝে timeout দেয়। আপনি চান: (১) প্রতিটি চার্জ log হবে, (২) timeout হলে আরেকবার চেষ্টা হবে। Gateway class-এর ভেতরে এসব লিখলে তার দায়িত্ব বাড়ে, আর অন্য gateway-তে আবার লিখতে হয়। Decorator বলে: একই interface implement করা একটি মোড়ক বানান, যে ভেতরের object-কে ডাকে আর আগে-পরে নিজের কাজটুকু করে। মোড়কের ওপর মোড়ক বসানো যায়। পর্ব ৯ আর ৩৭-এ এর সবচেয়ে বিখ্যাত রূপ দেখেছেন: new BufferedReader(new InputStreamReader(in)) — প্রতিটি স্তর একটি করে ক্ষমতা যোগ করে।

interface PaymentGateway { String charge(int amount); }

class FlakyBank implements PaymentGateway {        // প্রথম ডাকে timeout
    private int calls = 0;
    public String charge(int amount) {
        if (++calls == 1) throw new IllegalStateException("timeout");
        return "OK-" + amount;
    }
}
record Logging(PaymentGateway inner) implements PaymentGateway {
    public String charge(int amount) {
        System.out.println("  log: charge " + amount);
        return inner.charge(amount);
    }
}
record Retry(PaymentGateway inner) implements PaymentGateway {
    public String charge(int amount) {
        try { return inner.charge(amount); }
        catch (IllegalStateException e) {
            System.out.println("retry: " + e.getMessage() + ", once more");
            return inner.charge(amount);
        }
    }
}
class Main {
    public static void main(String[] args) {
        PaymentGateway gw = new Retry(new Logging(new FlakyBank()));
        System.out.println("final: " + gw.charge(1560));
    }
}

ডাকটি কোন পথে ভেতরে ঢোকে আর কোন পথে বেরোয়, ধাপে ধাপে দেখুন:

(কিছু ছাপা হয়নি)
main → Retry.charge(1560)

  log: charge 1560

  log: charge 1560
FlakyBank ✗ IllegalStateException("timeout")
→ Logging ধরে না, পার হয়ে যায় → Retry

  log: charge 1560
retry: timeout, once more
  log: charge 1560

FlakyBank → "OK-1560"
Logging → "OK-1560" (অপরিবর্তিত)
Retry → "OK-1560"

  log: charge 1560
retry: timeout, once more
  log: charge 1560
final: OK-1560

Facade — জটিল ব্যবস্থার সামনে একটি সরল দরজা

অর্ডার নিশ্চিত করতে চারটি subsystem লাগে: স্টক সংরক্ষণ, পেমেন্ট, কুরিয়ার বুকিং, আর খবর পাঠানো। Controller বা অ্যাপের বোতাম যদি নিজেই এই চারটিকে ঠিক ক্রমে ডাকে, তাহলে সেই ক্রম দশ জায়গায় ছড়িয়ে পড়বে। Facade একটি সরল class, যার একটি method পুরো কাজ ঠিক ক্রমে করে দেয়:

class CheckoutService {
    private final Inventory inventory;
    private final PaymentGateway payment;      // ভেতরে Retry(Logging(...)) থাকতে পারে
    private final Shipping shipping;
    private final OrderEvents events;

    CheckoutService(Inventory i, PaymentGateway p, Shipping s, OrderEvents e) {
        inventory = i; payment = p; shipping = s; events = e;
    }
    Receipt checkout(Cart cart, String address) {
        inventory.reserve(cart.items());
        String txn = payment.charge(cart.total());
        String tracking = shipping.book(cart.items(), address);
        events.publish(cart.id(), OrderStatus.PLACED);
        return new Receipt(txn, tracking);
    }
}

বাইরের জগৎ জানে শুধু checkout(cart, address). সব নির্ভরতা constructor দিয়ে আসছে — এটাই dependency injection, তাই টেস্টে প্রতিটির নকল বসানো যায় (পর্ব ৪৭)। Facade-এর ঝুঁকি একটাই: ধীরে ধীরে সব কাজ এতে ঢুকে পড়লে সে নিজেই একটি God class হয়ে ওঠে। Facade শুধু সমন্বয় করবে; আসল যুক্তি থাকবে subsystem-গুলোতে।

Proxy — একই চেহারার প্রতিনিধি

Proxy দেখতে Decorator-এর মতো — একই interface, ভেতরে আসল object. পার্থক্য উদ্দেশ্যে: Decorator নতুন ক্ষমতা যোগ করে, Proxy আসল object-এ পৌঁছানো নিয়ন্ত্রণ করে — দেরিতে তৈরি করা (lazy), অনুমতি যাচাই, দূরের সার্ভারের প্রতিনিধিত্ব। পর্ব ৪৫-এ দেখেছেন, java.lang.reflect.Proxy দিয়ে চলার সময় এমন dynamic proxy বানানো যায়, আর Spring-এর @Transactional এভাবেই আপনার method-এর চারপাশে transaction শুরু ও শেষ করে।

৫ · আচরণের pattern (১) — Strategy আর Observer

Strategy — বদলযোগ্য নিয়ম আলাদা object-এ

ডেলিভারি চার্জ: ঢাকার ভেতরে ৬০ টাকা (২০০০ টাকা বা বেশি কেনাকাটায় ফ্রি), ঢাকার বাইরে ১২০ টাকা, ঈদে সবার জন্য ফ্রি। if-else-এর শিকল লিখলে প্রতিটি নতুন অফারে checkout-এর কোড খুলতে হবে — Open/Closed ভাঙা। Strategy বলে: নিয়মটিকে একটি interface বানান, প্রতিটি নিয়ম একটি implementation, আর checkout শুধু interface-কে ডাকুক। JDK-র সবচেয়ে চেনা Strategy হলো Comparator — list.sort(...) একই থাকে, সাজানোর নিয়ম বাইরে থেকে আসে (পর্ব ৩৩)।

import java.util.List;

interface DeliveryFee { int feeFor(int subtotal); }

class InsideDhaka implements DeliveryFee {
    public int feeFor(int subtotal) { return subtotal >= 2000 ? 0 : 60; }
}
class OutsideDhaka implements DeliveryFee {
    public int feeFor(int subtotal) { return 120; }
}
record Checkout(String label, DeliveryFee fee) {
    int total(int subtotal) { return subtotal + fee.feeFor(subtotal); }
}
class Main {
    public static void main(String[] args) {
        var options = List.of(
            new Checkout("Dhaka", new InsideDhaka()),
            new Checkout("Outside", new OutsideDhaka()),
            new Checkout("Eid", subtotal -> 0));       // lambda = নতুন strategy
        for (var c : options)
            System.out.println(c.label() + ": " + c.total(1500) + ", " + c.total(2500));
    }
}

একই total(), ভিন্ন strategy — কোন কোড কখন চলে, দেখুন:

1interface DeliveryFee { int feeFor(int s); }2class InsideDhaka implements DeliveryFee {3  public int feeFor(int s) { return s >= 2000 ? 0 : 60; } }4class OutsideDhaka implements DeliveryFee {5  public int feeFor(int s) { return 120; } }6int total(int subtotal, DeliveryFee fee) {7  return subtotal + fee.feeFor(subtotal); }8total(1500, new InsideDhaka());9total(1500, new OutsideDhaka());10total(2500, new InsideDhaka());11total(1500, s -> 0);   // lambda

Observer — একটি ঘটনা, অনেক শ্রোতা

অর্ডারের অবস্থা বদলালে (রওনা হলো, পৌঁছাল) গ্রাহককে SMS, অফিসে Email, আর হিসাবের জন্য analytics — তিন জায়গায় খবর যাবে। Order-এর কোড যদি এই তিনটিকে নিজে ডাকে, তাহলে চতুর্থ চ্যানেল (WhatsApp) যোগ করতে order-এর কোড খুলতে হবে, আর order জানবে SMS-এর খুঁটিনাটি। Observer উল্টো দিক থেকে ভাবে: যারা খবর চায়, তারা নিজেরাই নাম লেখায় (subscribe); ঘটনা ঘটলে প্রকাশক শুধু তালিকা ধরে সবাইকে জানায়। পর্ব ২৭-এর event listener ঠিক এই pattern.

interface OrderListener { void onStatusChange(String orderId, OrderStatus status); }

class OrderEvents {
    private final List<OrderListener> listeners = new ArrayList<>();
    void subscribe(OrderListener l) { listeners.add(l); }
    void publish(String orderId, OrderStatus status) {
        for (OrderListener l : listeners) l.onStatusChange(orderId, status);
    }
}

events.subscribe((id, st) -> sms.send(phone, "Order " + id + ": " + st));
events.subscribe((id, st) -> System.out.println("email: order " + id + " is " + st));
events.subscribe((id, st) -> { if (st == OrderStatus.DELIVERED) analytics.count(id); });

subscribe(SMS) → subscribe(Email) → subscribe(Analytics)
তালিকা: [SMS, Email, Analytics]

SMS → 017...: Order A-17: SHIPPED
email: order A-17 is SHIPPED
Analytics: SHIPPED, তাই কিছু করল না

SMS → 017...: Order A-17: DELIVERED
email: order A-17 is DELIVERED
analytics: delivered +1

events.subscribe(whatsApp);
OrderEvents-এর কোড: ০ লাইন বদল

JDK-তে পুরোনো java.util.Observer/Observable আছে, কিন্তু Java 9 থেকে deprecated — কারণ Observable একটি class (interface নয়) হওয়ায় অন্য parent-ওয়ালা class সেটা নিতে পারত না, আর ঘটনার ধরন বোঝানোর ভালো উপায় ছিল না। এখন GUI-ধাঁচের কাজে java.beans.PropertyChangeListener, আর অনেক ঘটনার প্রবাহ ও চাপ সামলানোর (backpressure) জন্য Java 9-এর java.util.concurrent.Flow interface-গুলো আছে — reactive library-গুলো সেই চুক্তিই মানে।

৬ · আচরণের pattern (২) — State, Chain of Responsibility আর পুরোনো বন্ধুরা

State — object-এর অবস্থা অনুযায়ী আচরণ

অর্ডার “Placed” অবস্থায় বাতিল করা যায়, “Shipped” হলে আর যায় না, “Delivered” হলে কিছুই বদলায় না। প্রতিটি method-এ if (status == ...) লিখলে নিয়মগুলো সারা class-এ ছড়িয়ে পড়ে। State pattern প্রতিটি অবস্থাকে একটি object বানায়, যে নিজেই জানে সে কী অনুমতি দেয় আর পরের অবস্থা কী:

sealed interface OrderState permits Placed, Shipped, Delivered, Cancelled {
    OrderState next();
    OrderState cancel();
}
record Placed() implements OrderState {
    public OrderState next()   { return new Shipped(); }
    public OrderState cancel() { return new Cancelled(); }
}
record Shipped() implements OrderState {
    public OrderState next()   { return new Delivered(); }
    public OrderState cancel() { throw new IllegalStateException("already shipped"); }
}
// Delivered আর Cancelled একইভাবে ...

পর্ব ২৪-এ একই কাজ enum দিয়ে করেছিলেন — state machine, যেখানে প্রতিটি constant-এর নিজস্ব শরীর থাকে। কখন কোনটা? অবস্থাগুলোর কোনো নিজস্ব ডেটা না থাকলে enum সবচেয়ে সরল ও যথেষ্ট। কোনো অবস্থার নিজস্ব ডেটা লাগলে — যেমন Shipped-এর tracking নম্বর, Cancelled-এর কারণ — তখন sealed interface + record, কারণ enum constant-এর ডেটা সব object-এর জন্য একই। দুটোই State pattern-এর Java-রূপ; GoF-এর মূল সংস্করণের মতো আলাদা context class প্রায়ই লাগে না।

Chain of Responsibility — অনুরোধ এক হাত থেকে আরেক হাতে

অর্ডার গ্রহণের আগে কয়েকটি যাচাই: কার্ট খালি কি না, ফোন নম্বর ঠিক কি না, অঙ্কটা হাতে-যাচাইয়ের মতো বড় কি না। প্রতিটি যাচাই একটি আলাদা handler; অনুরোধ শিকল ধরে এগোয়, যেকোনো handler থামিয়ে দিতে পারে। এটাই Chain of Responsibility. আধুনিক Java-তে একটি তালিকা আর stream দিয়েই লেখা যায়:

interface Check { Optional<String> validate(Req r); }   // খালি = পাস

List<Check> chain = List.of(
    r -> r.items().isEmpty() ? Optional.of("cart empty") : Optional.empty(),
    r -> r.phone().matches("01\\d{9}") ? Optional.empty() : Optional.of("bad phone"),
    r -> r.total() > 50_000 ? Optional.of("needs manual review") : Optional.empty());

Optional<String> problem = chain.stream()
        .map(c -> c.validate(req))
        .flatMap(Optional::stream)      // প্রথম সমস্যা পেলেই থামে
        .findFirst();

Stream lazy (পর্ব ৩৫), তাই প্রথম যে check সমস্যা পায়, তারপরের check আর চলেই না। নতুন নিয়ম মানে তালিকায় নতুন একটি lambda. Java-র ওয়েব জগতে এর সবচেয়ে বড় উদাহরণ Servlet Filter: প্রতিটি filter কাজ করে chain.doFilter(request, response) ডেকে অনুরোধ পরেরজনকে দেয়, বা না ডেকে থামিয়ে দেয়। Spring Security-র login, CSRF আর অনুমতি যাচাইও এমন একটি filter-শিকল।

যাদের আগেই চেনেন

এখন পুরো checkout এক নজরে: বোতাম ডাকে Facade CheckoutService-কে; চার্জ হিসাব করে Strategy DeliveryFee; টাকা কাটে Decorator-মোড়া Retry(Logging(gateway)); ঘটনা ছড়ায় Observer OrderEvents; আর SMS যায় Adapter QuickSmsAdapter দিয়ে। পাঁচটি pattern, কিন্তু প্রতিটির পেছনে একটি বাস্তব বদলের কারণ আছে — সেটাই তাদের থাকার অধিকার দেয়।

৭ · আধুনিক Java pattern বদলে দিয়েছে — আর যখন pattern নিজেই সমস্যা

GoF বইটি লেখা হয়েছিল ১৯৯৪ সালের C++ আর Smalltalk মাথায় রেখে। অনেক pattern আসলে ভাষার কোনো অভাব পূরণের কৌশল ছিল। ভাষা বদলালে সেই অভাব কমে, pattern-ও ছোট হয়:

Anti-pattern — যে সমাধান সমস্যা তৈরি করে

Anti-pattern হলো এমন একটি ধাঁচ, যা শুরুতে যুক্তিসংগত মনে হয় কিন্তু বারবার একই ক্ষতি করে। এই পর্বের প্রসঙ্গে চারটি:

• God class: OrderManager নামের একটি class স্টক, পেমেন্ট, SMS, রিপোর্ট, ডিসকাউন্ট — সব করে, তিন হাজার লাইন। কম cohesion, সবার সাথে coupling. সমাধান: দায়িত্ব ধরে ভাঙা (পর্ব ০২)।
• Singleton-এর অপব্যবহার: “সুবিধার জন্য” সবকিছু XxxManager.getInstance(). আসলে এটা ছদ্মবেশী global ভ্যারিয়েবল — অংশ ৩-এর সতর্কতা দেখুন।
• Over-engineering: দুটি ডিসকাউন্ট নিয়মের জন্য DiscountStrategyFactoryProvider. Spring Framework-এ সত্যিই AbstractSingletonProxyFactoryBean নামে একটি class আছে — প্রোগ্রামারদের আড্ডায় দীর্ঘ নামের উদাহরণ হিসেবে এটা প্রায়ই হাসির বিষয় হয়। ন্যায্যভাবে বললে, framework-এর ভেতরে সেই class-এর একটি নির্দিষ্ট কাজ আছে; কিন্তু একটি ছোট দোকানের অ্যাপে এমন স্তর বানানো over-engineering.
• Pattern-itis: নতুন pattern শিখে প্রতিটি সমস্যায় সেটা বসানোর রোগ। লক্ষণ: class-এর নামে pattern-এর নাম (OrderVisitorFactory), কিন্তু কেউ বলতে পারে না কোন বদল থেকে এটা রক্ষা করছে।

৮ · Clean code — নাম, ছোট method, code smell আর ধাপে ধাপে refactoring

Pattern বড় কাঠামোর ব্যাপার; প্রতিদিনের পরিচ্ছন্নতা আসে ছোট অভ্যাস থেকে।

• অর্থপূর্ণ নাম: d, tmp, data2 নয় — deliveryFee, daysSinceOrder. Method-এর নাম ক্রিয়া (calculateTotal), boolean-এর নাম প্রশ্ন (isPaid). নাম ঠিকমতো দিতে না পারলে প্রায়ই দায়িত্বটাই অস্পষ্ট।
• ছোট, এক কাজের method: একটি method এক বাক্যে বর্ণনা করা গেলে ভালো। “এবং” লাগলে ভাঙার কথা ভাবুন। তবে সংখ্যা ধরে নিয়ম নয় — ভাবনার প্রশ্ন ৪ দেখুন।
• Comment বলবে কেন, কী নয়: // i এক বাড়াও অর্থহীন। // কুরিয়ার কোম্পানি ১১ অঙ্কের নম্বর ছাড়া নেয় না — এটাই দরকারি, কারণ কোড দেখে এটা বোঝা যায় না।
• Magic number নয়: if (sub >= 2000)-এর বদলে FREE_DELIVERY_FROM নামের constant (পর্ব ১৮)।
• একই ধাঁচের formatting: দলের সবাই একই নিয়ম — IDE-র formatter বা build-এ চালানো tool দিয়ে, তর্ক দিয়ে নয়।
• Guard clause/early return: অবৈধ অবস্থা শুরুতেই return বা throw, যাতে মূল যুক্তি বাসা-বাঁধা if-এর গভীরে না ডোবে (পর্ব ১০)।

Code smell আর তার ওষুধ

Code smell নিজে bug নয়, একটি লক্ষণ — যেমন রান্নাঘরে পোড়া গন্ধ মানেই আগুন নয়, কিন্তু একবার দেখে আসা উচিত। শব্দটি জনপ্রিয় হয় Martin Fowler-এর Refactoring বই থেকে, আর প্রতিটি smell-এর একটি নামওয়ালা refactoring আছে — বাইরের আচরণ না বদলে ভেতরের গঠন উন্নত করা।

এবার একটি বাস্তব জট। প্রথম সংস্করণে লেখা অর্ডার প্রসেস করার method — চলে, কিন্তু ছুঁতে ভয় লাগে:

int process(String name, String phone, String city, String type,
            int price, int qty, String coupon) {
    if (name != null && !name.isBlank()) {
        if (phone != null && phone.length() == 11) {
            int sub = price * qty;
            if (coupon != null && coupon.equals("EID10")) {
                sub = sub - sub / 10;
            }
            int fee;
            if (type.equals("STANDARD")) {
                if (city.equals("Dhaka")) fee = 60; else fee = 120;
            } else if (type.equals("EXPRESS")) {
                if (city.equals("Dhaka")) fee = 100; else fee = 200;
            } else if (type.equals("PICKUP")) {
                fee = 0;
            } else {
                throw new IllegalArgumentException("bad type");
            }
            if (sub >= 2000) fee = 0;
            int total = sub + fee;
            // send sms
            String msg = "Dear " + name + ", your order total is " + total;
            smsApi.dispatch("KEY-123", "88" + phone, msg, "ABCL");
            return total;
        } else {
            throw new IllegalArgumentException("bad phone");
        }
    } else {
        throw new IllegalArgumentException("bad name");
    }
}

গুনে দেখুন: সাতটি parameter, তিন স্তরের বাসা-বাঁধা if, 2000, 60, "EID10"-এর মতো magic value, type একটি String (বানান ভুল করলে চলার সময় ধরা পড়ে), কোডে বসানো API key, আর যাচাই, হিসাব, SMS — তিনটি দায়িত্ব এক method-এ। শুরুর আগে একটি শর্ত: এই method-এর বর্তমান আচরণ ধরে রাখে এমন টেস্ট (পর্ব ৪৭)। টেস্ট ছাড়া refactoring হলো চোখ বেঁধে দেয়াল সরানো। এবার চার ধাপ:

long method · long parameter list (7)
magic number: 2000, 60, 120, "EID10"
primitive obsession: String type
nested if (৩ স্তর) · ৩টি দায়িত্ব

int process(...7 params...) {
    validate(name, phone);
    int sub = discounted(price * qty, coupon);
    int total = sub + deliveryFee(type, city, sub);
    notifyCustomer(name, phone, total);
    return total;
}

record Customer(String name, String phone) {}
record OrderRequest(Customer customer, String city,
    String type, int unitPrice, int qty, String coupon) {}

int process(OrderRequest req) { ... }

private void validate(Customer c) {
    if (c.name() == null || c.name().isBlank())
        throw new IllegalArgumentException("name required");
    if (c.phone() == null || c.phone().length() != 11)
        throw new IllegalArgumentException("phone must be 11 digits");
}   // else-এর পিরামিড আর নেই

enum DeliveryType {
    STANDARD { int fee(boolean dhaka) { return dhaka ? 60 : 120; } },
    EXPRESS  { int fee(boolean dhaka) { return dhaka ? 100 : 200; } },
    PICKUP   { int fee(boolean dhaka) { return 0; } };
    abstract int fee(boolean insideDhaka);
}

শেষ ফল — process() এখন পাঁচ লাইন, আর প্রতিটি সাহায্যকারী method এক কাজের:

class OrderService {
    private static final int FREE_DELIVERY_FROM = 2000;
    private static final String EID_COUPON = "EID10";
    private final SmsSender sms;                       // Adapter, constructor দিয়ে
    OrderService(SmsSender sms) { this.sms = sms; }

    int process(OrderRequest req) {
        validate(req.customer());
        int subtotal = discounted(req.unitPrice() * req.qty(), req.coupon());
        int total = subtotal + deliveryFee(req.type(), req.city(), subtotal);
        notifyCustomer(req.customer(), total);
        return total;
    }
    private int discounted(int amount, String coupon) {
        return EID_COUPON.equals(coupon) ? amount - amount / 10 : amount;   // ১০% ছাড়
    }
    private int deliveryFee(DeliveryType type, String city, int subtotal) {
        if (subtotal >= FREE_DELIVERY_FROM) return 0;
        return type.fee("Dhaka".equals(city));
    }
    // validate() আর notifyCustomer() ওপরের stepper-এর মতো
}

"Dhaka".equals(city) উল্টো করে লেখা — city null হলেও NullPointerException হবে না। API key কোড থেকে সরে adapter-এ, আর adapter বাইরের config থেকে key পায়। খেয়াল করুন, আমরা কোনো “pattern বসাতে” শুরু করিনি; smell ধরে ধরে এগোতে গিয়ে শেষে polymorphism আর adapter নিজে থেকেই এসেছে। ভালো নকশা প্রায়ই এভাবেই জন্মায়।

Code review — দলের পরিচ্ছন্নতার অভ্যাস

Code review-তে অন্য কেউ আপনার পরিবর্তন মূল শাখায় যাওয়ার আগে পড়েন। ভালো review-এর সংস্কৃতি: ছোট পরিবর্তন পাঠান (কয়েকশো লাইনের বেশি হলে মানুষ মন দিয়ে পড়ে না); formatting-এর মতো যন্ত্রে ধরা যায় এমন জিনিস tool-কে ছেড়ে দিন; মন্তব্য কোড নিয়ে, মানুষ নিয়ে নয় — “এই নামটা পড়ে বুঝিনি, feeFor হলে কেমন?” প্রশ্নের আকারে; আর review-কে শেখার জায়গা ভাবুন, পরীক্ষার নয়। AI review-ও এখন সাধারণ — সেটা পরের অংশে।

৯ · AI-এর যুগে — pattern-এর ভারে চাপা না পড়া

AI-কে “একটি ডিসকাউন্ট সিস্টেম লিখে দাও, best practice মেনে” বললে প্রায়ই ফেরত আসে: DiscountStrategy interface, তিনটি implementation, একটি DiscountStrategyFactory, একটি Singleton DiscountManager, আর প্রতিটির জন্য আলাদা ফাইল — অথচ আসল নিয়ম দুটি, যা একটি switch-এ চার লাইনে লেখা যেত। AI “best practice” শব্দটিকে “যত বেশি pattern তত ভালো” হিসেবে পড়ে, কারণ তার শেখার উপাত্তে enterprise কোডের প্রাচুর্য। উল্টো দিকেও ভুল হয়: পুরোনো টিউটোরিয়াল থেকে শেখা anonymous class দিয়ে Strategy, double-checked locking দিয়ে Singleton, বা accept/visit-এর Visitor — যেখানে আধুনিক Java-তে lambda, enum আর sealed switch আছে।

AI-এর নকশা বা refactoring হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি নতুন interface/pattern-এর জন্য একটি বাস্তব বদলের কারণ বলতে পারি
• কোনো getInstance() Singleton বা static global state ঢোকেনি
• এক লাইনের নিয়মে class নয়, lambda; বন্ধ টাইপ-পরিবারে Visitor নয়, sealed switch
• আগের টেস্টগুলো কোনো বদল ছাড়াই সবুজ — আচরণ একই
• নামগুলো ব্যবসার ভাষায় (DeliveryFee), pattern-এর ভাষায় নয় (FeeStrategyImplFactory)
• ফাইল আর class-এর সংখ্যা সমস্যার আকারের সাথে মানানসই