SOLID و الگوهای طراحی GoF در جاواSOLID & GoF Design Patterns in Java

بیا از یک حقیقت ساده شروع کنیم: کدی که امروز می‌نویسی، فردا عوض می‌شود. نیازمندی جدید می‌آید، یک باگ کشف می‌شود، یک روش پرداخت تازه اضافه می‌شود. سؤال واقعیِ مهندسی نرم‌افزار این نیست که «چطور این را کار بیندازم؟» — بلکه این است که «وقتی این را عوض کنم، چقدر آسان می‌شکند؟». اصول SOLID و الگوهای GoF دقیقاً برای همین ساخته شده‌اند: تا تغییر را ارزان و بی‌خطر کنند. این‌ها تزئین نیستند، ابزار بقا هستند.

در این درس هیچ اصطلاحی را بدون توضیح رها نمی‌کنیم. هر مفهوم را اول با یک تشبیه روزمره حس می‌کنی، بعد اسم فنی‌اش را می‌گذاریم، بعد به کد جاوا وصلش می‌کنیم، و آخر می‌بینیم چرا در مصاحبه و کد تولیدی به دردت می‌خورد.

بخش ۰ — چند کلمه که باید بلد باشی

قبل از هر چیز، چند واژه را که مدام تکرار می‌شوند از پایه بسازیم، تا بعداً هیچ‌جا گیر نکنی.

• رابط (interface): قراردادی که فقط می‌گوید چه متدهایی هست، نه اینکه بدنه‌شان چطور کار می‌کند. در جاوا با کلمه‌ی interface.
• پیاده‌سازی (implementation): کلاس واقعی‌ای که آن قرارداد را با کد پُر می‌کند (implements).
• جفت‌شدگی (coupling): میزان وابستگیِ دو تکه کد به هم. جفت‌شدگیِ زیاد یعنی با دست‌زدن به یکی، دیگری می‌شکند — بد است.
• هم‌بستگی (cohesion): میزان به‌هم‌مربوط‌بودنِ چیزهای داخل یک کلاس. هم‌بستگیِ بالا یعنی همه‌چیزِ داخل کلاس به یک هدف مشترک خدمت می‌کند — خوب است.
• چندریختی (polymorphism): توانایی صدازدنِ یک متد روی یک رابط، بدون اینکه بدانی کدام کلاسِ مشخص پشتش نشسته و پاسخ می‌دهد. مثل زدن دکمه‌ی «پخش» روی هر پخش‌کننده‌ای؛ خودت را با نوعِ دستگاه درگیر نمی‌کنی.
• وراثت (inheritance) در برابر ترکیب (composition): وراثت یعنی «کلاس B یک نوع از A است» (B extends A). ترکیب یعنی «کلاس B دارای یک A است» (فیلدی از جنس A نگه می‌دارد و کارش را به آن واگذار می‌کند).

مدل ذهنی: الگوها ابزار فشرده‌سازیِ تغییرند

اصول و الگوهای طراحی را با یک نگاه بفهم: آن‌ها ابزار فشرده‌سازی تغییر (compression tools for change) هستند — یعنی دامنه‌ی اثر یک تغییر آینده را محدود (localize) می‌کنند. هنگام ارزیابی هر اصل یا الگو، دقیقاً یک سؤال بپرس:

وقتی نیازمندی X تغییر کند، چند فایل را باید دست بزنم و چقدر احتمال دارد چیزِ نامرتبطی را بشکنم؟

اصول SOLID پنج راهنمای عملی (heuristic) برای ساختاردهیِ وابستگی‌ها می‌دهند. الگوهای GoF بیست‌وسه شکلِ تکرارشونده و نام‌گذاری‌شده هستند که همین راهنماها معمولاً تولیدشان می‌کنند. حواست باشد: یک مهندس ارشد «الگو اعمال نمی‌کند»؛ او تشخیص می‌دهد که مسئله از پیش دارد به چه شکلی درمی‌آید، و نامِ مرسومش را رویش می‌گذارد تا تیم بتواند درباره‌اش راحت حرف بزند.

بخش ۱ — SOLID، با یک بازآراییِ مشخص برای هر اصل

S — اصل مسئولیت واحد (Single Responsibility Principle)

قاعده این است: یک کلاس باید فقط یک دلیل برای تغییر داشته باشد. اما «دلیل تغییر» یعنی چه؟ یعنی یک بازیگر / یک محورِ تغییر (one actor / one axis of change) — نه «فقط یک کار انجام می‌دهد». بازیگر یعنی یک منبعِ نیازمندی: تیم مالی، تیم گزارش‌گیری، تیم زیرساخت. اگر دو بازیگرِ مختلف بتوانند مستقلاً از یک کلاس تغییر بخواهند، آن کلاس SRP را نقض کرده.

بیا مشکل را در کد ببینیم. این کلاس هم‌زمان مالیات را حساب می‌کند، هم HTML می‌سازد، هم در دیتابیس ذخیره می‌کند — سه بازیگر در یک بسته:

// بد: سه دلیل تغییر در یک کلاس بسته‌بندی شده‌اند
class InvoiceService {
    BigDecimal calculateTotal(Invoice inv) { /* قواعد مالیات */ return null; }
    String toHtml(Invoice inv) { /* ارائه/نمایش */ return null; }
    void save(Invoice inv) { /* JDBC */ }
}

راه‌حل، تقسیمِ کلاس بر اساس بازیگر است — هر همکار (collaborator) فقط برای یک بازیگر تغییر می‌کند:

// خوب: هر همکار برای یک بازیگر تغییر می‌کند
class InvoiceCalculator { BigDecimal total(Invoice inv) { /* قواعد مالیات */ return null; } }
class InvoiceHtmlRenderer { String render(Invoice inv) { /* نمایش */ return null; } }
interface InvoiceRepository { void save(Invoice inv); }

O — اصل باز/بسته (Open/Closed Principle)

قاعده: باز برای توسعه، بسته برای تغییر. باید بتوانی رفتار تازه بیفزایی بدون ویرایشِ کدِ موجود و تست‌شده. مکانیزمش همان چندریختی (polymorphism) است: یک switch روبه‌رشد را با مجموعه‌ای از پیاده‌سازی‌ها جایگزین می‌کنی.

این کدِ بد، هر بار که روشِ ارسالِ تازه‌ای اضافه شود باید دستکاری شود — یعنی هر بار خطرِ شکستنِ چیزی که کار می‌کرد:

// بد: هر روش ارسال جدید این متد را ویرایش می‌کند
double cost(Order o) {
    switch (o.method()) {
        case STANDARD: return 5;
        case EXPRESS:  return 15;
        default: throw new IllegalArgumentException();
    }
}

نسخه‌ی خوب: برای روشِ جدید فقط یک کلاس اضافه می‌کنی و به هیچ کدِ موجودی دست نمی‌زنی. (خبرِ خوب: این دقیقاً همان الگوی Strategy است که بعداً می‌بینی.)

// خوب: یک کلاس اضافه کن، به کد موجود دست نزن (این همان Strategy است)
interface ShippingCost { BigDecimal cost(Order o); }
class StandardShipping implements ShippingCost { public BigDecimal cost(Order o){ return new BigDecimal("5"); } }
class ExpressShipping implements ShippingCost { public BigDecimal cost(Order o){ return new BigDecimal("15"); } }

L — اصل جایگزینیِ لیسکوف (Liskov Substitution Principle)

قاعده: زیرنوع‌ها باید بدون شگفتی از طریق نوعِ پایه‌شان قابل‌استفاده باشند. مشخص‌تر: یک زیرنوع می‌تواند پیش‌شرط‌ها را ضعیف‌تر و پس‌شرط‌ها را قوی‌تر کند (weaken preconditions, strengthen postconditions)، هرگز برعکس، و نباید استثنای بررسی‌شده‌ی (checked exception) جدید پرتاب کند یا رفتار را تنگ‌تر کند.

بگذار این دو اصطلاح را باز کنم: پیش‌شرط (precondition) چیزی است که کد قبل از فراخوانیِ یک متد باید فراهم کند (مثلاً «ورودی نباید null باشد»). پس‌شرط (postcondition) چیزی است که متد بعد از اجرا تضمین می‌کند (مثلاً «خروجی همیشه مرتب است»). زیرنوع مجاز است سخت‌گیریِ ورودی را کم کند و تضمینِ خروجی را بیشتر کند — نه برعکس؛ چون کلاینت روی رفتارِ نوعِ پایه حساب باز کرده.

نقضِ کلاسیک، Square extends Rectangle است. مربع ادعا می‌کند یک مستطیل است، اما اضلاعش مستقل نیستند:

// نقض LSP: جایگزینی Square قرارداد Rectangle را می‌شکند
class Rectangle { int w, h; void setW(int w){this.w=w;} void setH(int h){this.h=h;} int area(){return w*h;} }
class Square extends Rectangle {
    void setW(int w){ this.w=w; this.h=w; }   // ارتفاع را بی‌صدا تغییر می‌دهد
    void setH(int h){ this.w=h; this.h=h; }
}
// تستی که برای Rectangle پاس می‌شود برای Square شکست می‌خورد:
// r.setW(5); r.setH(4); assert r.area()==20;  // برای Square می‌شود ۱۶

هر کلاینتی که فرض می‌کند اضلاع مستطیل مستقل‌اند، با یک مربع بی‌سروصدا می‌شکند. راه‌حل، وراثتِ زیرکانه نیست — بلکه دست‌برداشتن از این تظاهر است که مربع یک مستطیلِ تغییرپذیر است. آن‌ها را دو شکلِ تغییرناپذیرِ جدا مدل کن.

I — اصل تفکیک رابط (Interface Segregation Principle)

قاعده: هیچ کلاینتی نباید مجبور به وابستگی به متدهایی شود که استفاده نمی‌کند. رابط‌های چاق، کلاینت‌های نامرتبط را به هم جفت (couple) می‌کنند و پیاده‌سازی‌های بی‌معنا تحمیل می‌کنند — همان بویِ بدِ throw new UnsupportedOperationException().

// بد: یک کلاینت فقط‌خواندنی مجبور است متدهای تغییردهنده را ببیند
interface Repository<T> { T find(long id); void save(T t); void delete(long id); }

// خوب: بر اساس نیاز کلاینت تفکیک کن
interface Reader<T> { T find(long id); }
interface Writer<T> { void save(T t); void delete(long id); }

جالب اینجاست که خودِ JDK این ضدالگو را به نمایش گذاشته: java.util.List متدهای add/remove را به لیست‌های تغییرناپذیر هم تحمیل می‌کند، که آن‌ها سپس در زمان اجرا UnsupportedOperationException پرتاب می‌کنند. این یک مصالحه‌ی مستند و عمدی است، اما دقیقاً همان چیزی است که ISP می‌گوید در کدِ خودت از آن پرهیز کن.

D — اصل وارونگیِ وابستگی (Dependency Inversion Principle)

قاعده: سیاستِ سطح‌بالا نباید به جزئیاتِ سطح‌پایین وابسته باشد؛ هر دو به انتزاع‌ها وابسته‌اند. و نکته‌ی حیاتی: انتزاع را ماژولِ سطح‌بالا مالک است (owns)، نه جزئیات. یعنی رابط را کنارِ منطقِ کسب‌وکار تعریف می‌کنی، و لایه‌ی دیتابیس مجبور است خودش را با آن وفق دهد — نه برعکس.

// خوب: سیاست به رابطی که مالکش است وابسته است؛ جزئیات پایگاه‌داده آن را پیاده می‌کند
class OrderService {                       // سیاست سطح‌بالا
    private final OrderRepository repo;     // انتزاع (مالکش این‌جاست)
    OrderService(OrderRepository repo) { this.repo = repo; }
}
interface OrderRepository { void save(Order o); }              // انتزاع
class JpaOrderRepository implements OrderRepository { /* جزئیات */ } // سطح‌پایین

این دقیقاً همان کاری است که یک ظرفِ تزریق وابستگی (DI container) مثل Spring خودکار می‌کند: جزئیاتِ مشخص را می‌سازد و «تزریق (inject)» می‌کند، تا سیاست هرگز نامِ یک کلاسِ مشخص را نبرد. به‌همین‌دلیل منطقِ کسب‌وکارِ تو با یک مخزنِ ساختگی (mock — یعنی یک پیاده‌سازیِ قلابی مخصوصِ تست) قابلِ تستِ واحد است و هرگز به دیتابیسِ واقعی دست نمی‌زند.

بخش ۲ — الگوهای پرتکرار GoF

«GoF» یعنی Gang of Four، لقبِ چهار نویسنده‌ی کتابِ مرجعِ الگوهای طراحی. آن‌ها بیست‌وسه الگو را در سه خانواده دسته‌بندی کردند:

• ایجادی (Creational): درباره‌ی ساختِ شیء — چطور اشیاء را می‌سازیم بدون اینکه کد به کلاس‌های مشخص گره بخورد.
• ساختاری (Structural): درباره‌ی ترکیبِ اشیاء — چطور اشیاء را کنارِ هم می‌چینیم تا ساختارهای بزرگ‌تر بسازیم.
• رفتاری (Behavioral): درباره‌ی تعاملِ اشیاء — چطور مسئولیت و ارتباط را بینشان تقسیم می‌کنیم.

در ادامه فقط آن‌هایی را می‌آموزیم که واقعاً در مصاحبه و کدِ تولیدی ظاهر می‌شوند، هر کدام با هدف، جاوای اصطلاحی، و جای زندگی‌شان در JDK/Spring.

الگوی راهبرد (Strategy) — رفتاری

هدف: خانواده‌ای از الگوریتم‌های قابل‌تعویض تعریف کن و یکی را در زمانِ اجرا انتخاب کن. این عملاً همان OCP در قالبِ شیء است.

@FunctionalInterface interface DiscountPolicy { BigDecimal apply(BigDecimal price); }

class Checkout {
    BigDecimal total(BigDecimal price, DiscountPolicy policy) { return policy.apply(price); }
}
// با لامبدا، Strategy تقریباً رایگان است:
new Checkout().total(new BigDecimal("100"), p -> p.multiply(new BigDecimal("0.9")));

در دنیای واقعی: java.util.Comparator نمونه‌ی درسیِ Strategy است — list.sort(comparator) بخشِ مقایسه‌ی الگوریتمِ مرتب‌سازی را مستقل تغییر می‌دهد. PlatformTransactionManager اسپرینگ، مبدل‌های پیامِ RestTemplate و هر @FunctionalInterfaceای که پاس می‌دهی، Strategy هستند. از جاوا ۸ به بعد، یک Strategy با یک متد صرفاً یک لامبدا است — به‌همین‌سادگی.

الگوی متد کارخانه و کارخانه‌ی انتزاعی (Factory Method & Abstract Factory) — ایجادی

Factory Method: نمونه‌سازی را از طریقِ متدی قابل‌بازنویسی به زیرکلاس واگذار کن. Abstract Factory: یک کارخانه از کارخانه‌های مرتبط، که خانواده‌هایی از محصولات را تولید می‌کند که باید با هم استفاده شوند (مثلاً همه‌ی ویجت‌ها به سبکِ مک، یا همه به سبکِ ویندوز).

// Factory Method
abstract class Dialog {
    abstract Button createButton();        // متد کارخانه
    void render() { createButton().render(); }
}
class WindowsDialog extends Dialog { Button createButton(){ return new WindowsButton(); } }

// Abstract Factory: خانواده‌ای از ویجت‌های رابط کاربری که باید هماهنگ باشند
interface GuiFactory { Button button(); Checkbox checkbox(); }
class MacFactory implements GuiFactory { public Button button(){return new MacButton();} public Checkbox checkbox(){return new MacCheckbox();} }

در دنیای واقعی: Calendar.getInstance()، DateFormat.getInstance()، ThreadFactory در ThreadPoolExecutor، و کلِ BeanFactory/ApplicationContext اسپرینگ کارخانه‌اند. Collection.iterator() یک Factory Method است که Iterator تولید می‌کند.

الگوی سازنده (Builder) — ایجادی

هدف: ساختِ گام‌به‌گامِ یک شیءِ پیچیده، به‌ویژه وقتی پارامترهای اختیاریِ زیادی هست. این مسئله‌ی «سازنده‌ی تلسکوپی (telescoping constructor)» را حل می‌کند — یعنی آن حالتی که مجبوری چند سازنده‌ی تودرتو با تعدادِ آرگومانِ متفاوت بنویسی و کدت شبیه تلسکوپِ بازشونده می‌شود. Builder همچنین تغییرناپذیری (immutability) را ممکن می‌کند.

public final class HttpRequest {
    private final String url;            // اجباری
    private final String method;         // اختیاری
    private final Duration timeout;      // اختیاری
    private HttpRequest(Builder b){ this.url=b.url; this.method=b.method; this.timeout=b.timeout; }

    public static Builder builder(String url){ return new Builder(url); }
    public static final class Builder {
        private final String url;
        private String method = "GET";
        private Duration timeout = Duration.ofSeconds(30);
        Builder(String url){ this.url = url; }
        public Builder method(String m){ this.method = m; return this; }   // روان (fluent)
        public Builder timeout(Duration t){ this.timeout = t; return this; }
        public HttpRequest build(){ return new HttpRequest(this); }
    }
}

توجه کن هر متدِ Builder خودِ Builder را برمی‌گرداند (return this) — به این می‌گویند سبکِ روان (fluent)، که اجازه می‌دهد فراخوانی‌ها را زنجیره کنی: builder(url).method("POST").timeout(...).build().

در دنیای واقعی: StringBuilder، Stream.Builder، java.net.http.HttpRequest.newBuilder() (از JDK 11)، Locale.Builder و @Builder لومبوک.

الگوی تک‌نمونه (Singleton) — و تک‌نمونه‌ی enum — ایجادی

هدف: دقیقاً یک نمونه که سراسری در دسترس است. پیاده‌سازیِ درست و امن‌در‌برابرِ‌نخ (thread-safe) در جاوا، تک‌نمونه‌ی enum است، که از دو باگِ کلاسیک آزاد است: قفل‌گذاریِ دوباره‌بررسی‌شده‌ی (double-checked locking) خرابِ تنبل، و حملاتِ بازتاب/سریال‌سازی (reflection/serialization).

public enum ConfigCache {
    INSTANCE;
    private final Map<String,String> cache = new ConcurrentHashMap<>();
    public String get(String k){ return cache.get(k); }
}
// استفاده: ConfigCache.INSTANCE.get("region");

اگر به مقداردهیِ تنبل (lazy — یعنی «فقط وقتی واقعاً لازم شد بساز») بدونِ enum نیاز داری، از اصطلاحِ نگه‌دارنده‌ی مقداردهی‌درصورت‌نیاز (initialization-on-demand holder) استفاده کن. این ترفند برای امنیتِ نخ به تضمین‌های بارگذاریِ کلاسِ JVM متکی است — یعنی JVM خودش تضمین می‌کند یک کلاس فقط یک‌بار و به‌صورتِ اتمیک بارگذاری می‌شود — و صفر همگام‌سازیِ (synchronization) دستی لازم دارد:

class Lazy {
    private Lazy(){}
    private static class Holder { static final Lazy INSTANCE = new Lazy(); }
    public static Lazy get(){ return Holder.INSTANCE; }   // Holder در اولین فراخوانی، اتمیک بارگذاری می‌شود
}

کلاسِ داخلیِ Holder تا وقتی get() صدا زده نشود اصلاً بارگذاری نمی‌شود؛ و لحظه‌ای که بارگذاری شد، JVM تضمین می‌کند فقط یک‌بار و امن اتفاق می‌افتد. تنبلی رایگان، بدونِ یک خط قفل.

در دنیای واقعی: Runtime.getRuntime()، Collections.emptyList(). بین‌های اسپرینگ بر اساسِ دامنه (scope) تک‌نمونه‌اند (یکی به‌ازای هر ظرف)، که گونه‌ای مدیریت‌شده توسطِ ظرف است — نه تک‌نمونه‌ی ایستایِ GoF، و بسیار قابل‌تست‌تر.

الگوی مبدل (Adapter) — ساختاری

هدف: تبدیلِ یک رابط به رابطِ دیگری که کلاینت انتظارش را دارد. یک نوعِ ناسازگار را می‌پیچد (wrap می‌کند) تا با کدِ تو جور شود.

interface PaymentGateway { void charge(long cents); }           // چیزی که کد ما می‌خواهد
class StripeApi { void makePayment(BigDecimal dollars){ /* شخص ثالث */ } } // چیزی که داریم

class StripeAdapter implements PaymentGateway {
    private final StripeApi stripe;
    StripeAdapter(StripeApi s){ this.stripe = s; }
    public void charge(long cents){ stripe.makePayment(BigDecimal.valueOf(cents, 2)); } // تطبیق
}

در دنیای واقعی: Arrays.asList()، java.io.InputStreamReader (یک InputStream بایتی را به Reader کاراکتری تطبیق می‌دهد)، و HandlerAdapter در Spring MVC که به DispatcherServlet اجازه می‌دهد انواعِ کاملاً متفاوتِ کنترلر را یکنواخت فراخوانی کند.

الگوی تزئین‌گر (Decorator) — ساختاری

هدف: افزودنِ پویا (dynamic — یعنی در زمانِ اجرا، نه زمانِ کامپایل) مسئولیت به یک شیء، با پیچیدنش، ضمنِ حفظِ همان رابط. این پاسخِ «ترکیب بر وراثت» به مسئله‌ی «۸ افزونه‌ی اختیاری می‌خواهم» است — به‌جای ساختنِ ۲⁸ (یعنی ۲۵۶) زیرکلاس برای هر ترکیبِ ممکن، افزونه‌ها را روی هم می‌پیچی.

interface DataSource { void write(String s); }
class FileSource implements DataSource { public void write(String s){ /* خام */ } }

abstract class SourceDecorator implements DataSource {
    protected final DataSource wrapped;
    SourceDecorator(DataSource d){ this.wrapped = d; }
}
class Encrypting extends SourceDecorator {
    Encrypting(DataSource d){ super(d); }
    public void write(String s){ wrapped.write(encrypt(s)); }   // رفتار افزوده، سپس واگذاری
    private String encrypt(String s){ return s; }
}
// new Encrypting(new Compressing(new FileSource()));

نکته‌ی کلیدی در آن خطِ آخر است: هر تزئین‌گر یکی دیگر را در بر می‌گیرد و رفتارش را اضافه می‌کند، بعد به لایه‌ی درونی واگذار (delegate) می‌کند.

در دنیای واقعی: کلِ پشته‌ی java.io — عبارتِ new BufferedReader(new InputStreamReader(new FileInputStream(f))) سه تزئین‌گر است که روی هم پیچیده‌اند. همچنین Collections.unmodifiableList()/synchronizedList() و HttpServletRequestWrapper اسپرینگ.

الگوی نماینده (Proxy) — ساختاری

هدف: جانشینی با همان رابط که دسترسی را کنترل می‌کند — برای تنبلی (نماینده‌ی مجازی)، امنیت، دسترسی از راه دور، یا دغدغه‌های عرضی (cross-cutting — یعنی دغدغه‌هایی مثل لاگ و تراکنش که در کلِ برنامه پخش‌اند و به منطقِ اصلی ربطی ندارند).

interface Image { void display(); }
class RealImage implements Image {
    RealImage(String f){ load(f); }                 // پرهزینه
    public void display(){ /* ... */ }
    private void load(String f){ /* ورودی/خروجی دیسک */ }
}
class LazyImage implements Image {                  // نماینده‌ی مجازی
    private final String file; private RealImage real;
    LazyImage(String f){ this.file = f; }
    public void display(){ if (real==null) real = new RealImage(file); real.display(); }
}

در دنیای واقعی: نماینده‌های بارگذاریِ تنبلِ JPA/Hibernate، java.lang.reflect.Proxy (نماینده‌های پویا)، و Spring AOP — @Transactional، @Cacheable و @Async همگی با پیچیدنِ بینِ تو در یک نماینده پیاده می‌شوند.

الگوی ناظر (Observer) — رفتاری

هدف: اطلاع‌رسانیِ یک‌به‌چند — سوژه‌ها (subjects) تغییرِ حالت را به هر تعداد مشترک (subscriber) منتشر می‌کنند بدونِ آنکه آن‌ها را بشناسند.

interface Listener { void onEvent(String e); }
class EventBus {
    private final List<Listener> listeners = new CopyOnWriteArrayList<>(); // پیمایش امن
    void subscribe(Listener l){ listeners.add(l); }
    void publish(String e){ listeners.forEach(l -> l.onEvent(e)); }
}

چرا CopyOnWriteArrayList و نه یک ArrayList ساده؟ چون ممکن است در حینِ انتشار (publish)، یک لیسنر بخواهد مشترک یا لغوِ اشتراک شود و لیست را وسطِ پیمایش تغییر دهد. این ساختارِ داده هر بار که تغییر می‌کند یک کپیِ تازه می‌سازد، پس پیمایش همیشه امن است. (به این تله در سؤالِ مصاحبه‌ی ۱۱ برمی‌گردیم.)

در دنیای واقعی: ApplicationEventPublisher / @EventListener اسپرینگ، java.util.Observer منسوخ‌شده (به‌عنوانِ یک درسِ طراحی حذف شد — بی‌نوع و بدقواره بود)، لیسنرهای Swing/JavaFX، و Flow.Publisher/Subscriber واکنشی (JDK 9، جریان‌های واکنشی). توجه: ناظرِ همگامِ خام می‌تواند باعث شود استثنای یک لیسنر، ناشر را بشکند — باس‌های تولیدی هندلرها را ایزوله می‌کنند.

الگوی متدِ قالبی (Template Method) — رفتاری

هدف: اسکلتِ یک الگوریتم را در یک متدِ پایه تعریف کن و به زیرکلاس‌ها اجازه بده گام‌های مشخص را پُر کنند بدونِ تغییرِ ساختارِ کلی. این مبتنی بر وراثت است؛ Strategy پسرعمویِ مبتنی بر ترکیبِ آن است.

abstract class DataImporter {
    public final void run() {          // متد قالبی — final تا اسکلت تغییر نکند
        open(); parse(); close();
    }
    protected abstract void parse();   // گام متغیر («قلاب» / hook)
    protected void open(){}            // قلاب‌های اختیاری با پیش‌فرض
    protected void close(){}
}

دقت کن run() با کلمه‌ی final علامت خورده — یعنی هیچ زیرکلاسی نمی‌تواند ترتیبِ اسکلت را عوض کند؛ فقط قلاب‌ها (hooks) را پُر می‌کند. قلاب (hook) همان جای خالیِ قابل‌بازنویسی است.

در دنیای واقعی: AbstractList، AbstractMap، و HttpServlet.service() که به doGet/doPost توزیع می‌کند، متدهای قالبی‌اند. JdbcTemplate، JmsTemplate و RestTemplate اسپرینگ نمونه‌های سازمانیِ کلاسیک‌اند: قالب مالکِ مدیریتِ اتصال/استثنا/منبع است و تو کال‌بکِ متغیر را می‌دهی.

الگوی فرمان (Command) — رفتاری

هدف: یک درخواست را به‌عنوانِ یک شیء کپسوله کن، تا بتوانی صف کنی، لاگ بگیری، بازگردانی (undo) یا پارامتری‌اش کنی.

interface Command { void execute(); }
class LightOn implements Command {
    private final Light light; LightOn(Light l){ this.light = l; }
    public void execute(){ light.on(); }
}
class Remote { private Command slot; void set(Command c){slot=c;} void press(){slot.execute();} }

در دنیای واقعی: Runnable یک Command است (یک Runnable که به ExecutorService سپرده می‌شود، فرمانی صف‌شده است)، Callable، Action در Swing، و هر صفِ کار/تسک. پشته‌های undo و outboxهای تراکنشی، Command با یک undo() افزوده‌اند.

الگوی زنجیره‌ی مسئولیت (Chain of Responsibility) — رفتاری

هدف: درخواست را در طولِ زنجیره‌ای از هندلرها عبور بده تا یکی آن را مدیریت کند — این فرستنده را از گیرنده جدا (decouple) می‌کند.

abstract class Handler {
    protected Handler next;
    Handler linkTo(Handler n){ this.next = n; return n; }
    abstract void handle(Request r);
    protected void forward(Request r){ if (next != null) next.handle(r); }
}

در دنیای واقعی: زنجیره‌ی javax.servlet.Filter و زنجیره‌ی فیلترِ Spring Security نمونه‌ی درسیِ CoR هستند، و همین‌طور HandlerInterceptor و هر خط‌لوله‌ی میان‌افزار (middleware). سطوحِ اپندرِ Log4j/SLF4J و هندلرهای استثنا هم زنجیره‌اند.

الگوی وضعیت (State) — رفتاری

هدف: به یک شیء اجازه بده هنگامِ تغییرِ حالتِ داخلی، رفتارش را تغییر دهد — انگار کلاسش عوض می‌شود. این if/switchهای پراکنده‌ی وضعیت را با اشیای وضعیتِ چندریخت جایگزین می‌کند.

interface OrderState { OrderState pay(); OrderState ship(); }
class New implements OrderState { public OrderState pay(){ return new Paid(); } public OrderState ship(){ throw new IllegalStateException("اول پرداخت کن"); } }
class Paid implements OrderState { public OrderState pay(){ throw new IllegalStateException("قبلاً پرداخت شده"); } public OrderState ship(){ return new Shipped(); } }
class Shipped implements OrderState { public OrderState pay(){ throw new IllegalStateException(); } public OrderState ship(){ throw new IllegalStateException(); } }

در دنیای واقعی: Thread.State، ماشین‌های حالتِ اتصالِ TCP، موتورهای گردش‌کار/سفارش، و Spring StateMachine. State و Strategy از نظرِ ساختاری یکسان‌اند (هر دو به یک رابط واگذار می‌کنند)؛ هدف فرق دارد — Strategy از بیرون انتخاب می‌شود و بی‌حالت است، State خودش را از درون منتقل می‌کند.

ضدالگوها و هشدارهای استفاده‌ی افراطی

الگوها ابزارند، نه هدف. استفاده‌ی نابه‌جا از آن‌ها بدتر از نداشتنشان است. این‌ها رایج‌ترین دام‌هایند:

• فضانوردِ الگو / مهندسیِ افراطی (over-engineering). یک SingletonFactoryStrategyProxy برای مسئله‌ای که یک متدِ ساده حلش می‌کند، ضررِ خالص است. الگوها لایه‌ی غیرمستقیم (indirection) اضافه می‌کنند، و غیرمستقیمی هزینه دارد. الگو را وقتی معرفی کن که واقعاً دومین تنوع برسد («قاعده‌ی سه» / Rule of Three)، نه گمانه‌زنانه.
• تک‌نمونه به‌عنوانِ حالتِ سراسریِ تغییرپذیر. Singleton پرسوءاستفاده‌ترین الگوست — وابستگی‌ها را پنهان می‌کند، تست‌پذیری را نابود و جفت‌شدگیِ پنهان ایجاد می‌کند. یک نمونه‌ی دامنه‌دار (scoped) مدیریت‌شده توسطِ DI را بر getInstance() ایستا ترجیح بده.
• دامنه‌ی کم‌خون + انفجارِ سرویس‌ها از بدفهمیِ SRP: ده‌ها «سرویسِ» تک‌متدی بدونِ هم‌بستگی. SRP درباره‌ی دلایلِ تغییر است، نه تعدادِ متد.
• OCP گمانه‌زنانه. ساختنِ نقاطِ توسعه برای محورهایی که هرگز تغییر نمی‌کنند، فریم‌ورکی با یک پیاده‌سازی تولید می‌کند. آنچه امروز تغییر می‌کند را ببند.
• نشتِ Decorator/Proxy. پشته‌های پیچیدنِ عمیق، دیباگ و استک‌تریس را دردناک می‌کنند و می‌توانند equals/instanceof را بشکنند. تله‌ی خودفراخوانیِ نماینده‌ی اسپرینگ رایج‌ترین باگِ تولیدی از این دست است.
• سفتیِ Template Method. وراثت تو را در یک سلسله‌مراتب قفل می‌کند؛ وقتی گام‌ها باید مستقل تغییر کنند، Strategy/ترکیب را ترجیح بده (اسپرینگ ترکیب را انتخاب کرد — JdbcTemplate کال‌بک می‌گیرد نه اینکه زیرکلاس‌سازی را تحمیل کند).
• اشتباه‌گرفتنِ وراثت با بازاستفاده. بیشترِ الگوهای ساختاریِ GoF دقیقاً وجود دارند چون وراثت مکانیزمِ بازاستفاده‌ی ضعیفی است. اول به‌سراغِ ترکیب برو.

سؤالات مصاحبه

هر سؤال را با پاسخِ کامل بخوان؛ این‌ها همان جاهایی هستند که مصاحبه‌گر عمقِ فهمت را می‌سنجد.

@Service
class OrderService {
    @Transactional public void outer(){ inner(); }        // خودفراخوانی
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void inner(){ throw new RuntimeException("boom"); }
}

class Bus {
    private final List<Listener> ls = new ArrayList<>();
    void subscribe(Listener l){ ls.add(l); }
    void publish(String e){ for (Listener l : ls) l.onEvent(e); }
}

منابع

• الگوی Template Method — Spring Framework Guru
• الگوهای طراحی در فریم‌ورک اسپرینگ
• کدام الگو را چه زمانی استفاده کنیم — JavaTechOnline