هستهٔ Spring: IoC، DI، Bean و AOPSpring Core: IoC, DI, Beans & AOP

بیا با یک تصویر ساده شروع کنیم. فرض کن یک رستوران راه انداخته‌ای. در روش قدیمی، هر آشپز باید خودش برود بازار، گوشت بخرد، سبزی بشوید، چاقو تیز کند و اجاق روشن کند تا بتواند یک غذا بپزد. آشوب می‌شود. در یک رستوران حرفه‌ای اما یک نفر (یا یک سیستم) مسئول تهیهٔ همه‌چیز است؛ آشپز فقط اعلام می‌کند «من گوشت و سبزی و اجاق می‌خواهم» و همه‌چیز آماده جلویش می‌آید. آشپز روی کاری تمرکز می‌کند که فقط از او برمی‌آید: پختن.

هستهٔ Spring دقیقاً همان «سیستم تدارکات» است. این درس همه‌چیز را از پایه می‌سازد.

بخش صفر — واژه‌هایی که باید بلد باشی

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

• کانتینر (container): موتوری که ساخت، سیم‌کشی، پیکربندی و نابودی اشیایت را در دست می‌گیرد.
• bean: هر شیئی که چرخهٔ حیاتش را کانتینر مدیریت می‌کند.
• BeanDefinition: فراداده (metadata) دربارهٔ یک bean — کلاسش، scope، وابستگی‌هایش، متدهای init/destroy و پرچم lazy. کانتینر این نقشه را می‌خواند تا bean را بسازد.
• پراکسی (proxy): یک شیء «بدل» که جلوی شیء اصلی می‌ایستد و پیش/پس از فراخوانی متدها کاری اضافه انجام می‌دهد. کمی جلوتر مفصل بازش می‌کنیم؛ فعلاً بدان که «نگهبانِ دمِ در» است.

کانتینر واقعاً چه کار می‌کند؟ (IoC و DI)

بیا به همان رستوران برگردیم. وقتی آشپز خودش می‌رفت بازار خرید می‌کرد، کنترل در دست آشپز بود. وقتی سیستم تدارکات همه‌چیز را جلویش می‌گذارد، کنترلِ «تهیهٔ ملزومات» از آشپز گرفته و به سیستم داده شده. به این وارونه‌شدنِ مسئولیت می‌گویند وارونگی کنترل.

«وارونگی کنترل» (Inversion of Control – IoC) یعنی دیگر خودت روی همکارها (collaborators — یعنی اشیائی که کلاست به آن‌ها نیاز دارد) new نمی‌زنی و چرخهٔ حیاتشان را مدیریت نمی‌کنی؛ فقط اعلام می‌کنی به چه چیزی نیاز داری و کانتینر آن را به تو تحویل می‌دهد.

تزریق وابستگی (Dependency Injection – DI) مکانیزم مشخصی است که IoC را پیاده می‌کند: وابستگی‌ها به داخل شیء هل داده می‌شوند (push)، نه اینکه شیء خودش برود آن‌ها را بکشد (pull).

فایدهٔ اصلی این کار جادو نیست، کاهش وابستگی (decoupling) است. کلاست به یک اینترفیس وابسته است، کانتینر تصمیم می‌گیرد کدام پیاده‌سازی را بدهد، و تو می‌توانی بدون دست‌زدن به مصرف‌کننده، پیاده‌سازی را عوض، mock (نمونهٔ ساختگی برای تست) یا بازپیکربندی کنی.

دو نوع کانتینر: BeanFactory و ApplicationContext

Spring دو اینترفیس کانتینر دارد و دانستن فرقشان مهم است.

• BeanFactory — قرارداد کمینه و تنبل (lazy) برای IoC. تنبل یعنی beanها را تا لحظه‌ای که برای اولین‌بار getBean() صدا نزنی نمی‌سازد. به‌ندرت مستقیم استفاده می‌شود.
• ApplicationContext — یک اَبَرمجموعه از BeanFactory با امکانات بیشتر:
  • ساخت زودهنگام (eager) singletonها هنگام بالاآمدن برنامه (نه لحظهٔ درخواست).
  • انتشار رویداد با ApplicationEventPublisher.
  • بین‌المللی‌سازی (i18n) با MessageSource.
  • بارگذاری منابع (resource loading).
  • کشف خودکار BeanPostProcessor و BeanFactoryPostProcessor (این‌ها را جلوتر باز می‌کنیم).

در عمل تقریباً همیشه ApplicationContext را استفاده می‌کنی — مثل AnnotationConfigApplicationContext یا GenericWebApplicationContext.

// ساخت یک کانتینر از روی کلاس پیکربندی جاوایی
try (var ctx = new AnnotationConfigApplicationContext(AppConfig.class)) {
    OrderService svc = ctx.getBean(OrderService.class);
    svc.place(new Order());
} // close() فراخوانی‌های نابودی singletonها را trigger می‌کند

یک نکتهٔ ظریف: post-processorها می‌توانند BeanDefinitionها را پیش از ساخته‌شدن هر beanی تغییر دهند — بخش بزرگی از آن چیزی که «جادوی Spring» می‌نامیم دقیقاً همین‌گونه پیاده شده است.

سه سبک تزریق وابستگی

سه نقطه برای تزریق وجود دارد: constructor (سازنده)، setter (متد ست‌کننده) و field (مستقیم روی فیلد). این‌ها معادل هم نیستند و انتخاب بینشان مهم است.

@Service
class ConstructorInjected {
    private final PaymentGateway gateway;      // می‌تواند final باشد
    private final InventoryClient inventory;

    // از Spring 4.3 به بعد، اگر یک constructor واحد باشد @Autowired اختیاری است
    ConstructorInjected(PaymentGateway gateway, InventoryClient inventory) {
        this.gateway = gateway;
        this.inventory = inventory;
    }
}

@Service
class FieldInjected {
    @Autowired private PaymentGateway gateway;  // نمی‌تواند final باشد؛ با reflection ست می‌شود
}

@Service
class SetterInjected {
    private PaymentGateway gateway;
    @Autowired void setGateway(PaymentGateway g) { this.gateway = g; }
}

چرا constructor injection پاسخ پیش‌فرض است؟

۱. تغییرناپذیری (immutability) و امنیت در نخ (thread-safety). فیلدها می‌توانند final باشند؛ شیء وقتی از constructor برمی‌گردد کاملاً مقداردهی شده است. هیچ بازه‌ای نیست که bean موجود باشد اما نیمی از وابستگی‌هایش null. («تغییرناپذیر» یعنی بعد از ساخت دیگر تغییر نمی‌کند؛ همین باعث می‌شود چند نخ بتوانند بی‌خطر همزمان استفاده‌اش کنند.)

۲. شکست سریع (fail-fast) در نبود یا ابهام وابستگی. آرگومان اجباریِ constructor که قابل resolve نباشد، همان لحظهٔ بالاآمدن context شکست می‌خورد، نه بعداً وسط کار با یک NPE (NullPointerException) مرموز.

۳. قابلیت تست بدون Spring. می‌توانی در یک تست ساده JUnit بنویسی new ConstructorInjected(mock1, mock2). اما field injection مجبورت می‌کند یا reflection بزنی یا کل context را بالا بیاوری.

۴. آشکارکردن بوی بد طراحی (design smell). constructor با ۸ پارامتر فریاد می‌زند که این کلاس کار زیادی می‌کند. field injection این درد را پنهان می‌کند و کلاس بی‌سروصدا به یک god object (شیئی که همه‌کاره و بیش‌ازحد بزرگ است) تبدیل می‌شود.

۵. جلوگیری از فرارِ bean نیمه‌ساخته. setter/field injection اجازه می‌دهند شیء پیش از تکمیل سیم‌کشی استفاده شود (مثلاً درون یک callback چرخهٔ حیات).

یک مزیت ظریف دیگر: constructor injection مخفی‌کردن وابستگی چرخه‌ای را ناممکن می‌کند. Spring نمی‌تواند A را که به B نیاز دارد بسازد در حالی که هنوز مشغول ساخت B است که به A نیاز دارد؛ پس به‌جای کارکردن مرموز، سرِ استارتاپ فریاد می‌زند (در بخش وابستگی چرخه‌ای مفصل می‌بینی).

چرخهٔ حیات bean

درک ترتیب دقیقِ تولد تا مرگ یک bean، اغلب همان چیزی است که یک برنامه‌نویس ارشد را از میانی جدا می‌کند.

ساخت نمونه (constructor)
   ↓
مقداردهی property‌ها (field/setter DI)
   ↓
callbackهای Aware (BeanNameAware، BeanFactoryAware، ApplicationContextAware)
   ↓
BeanPostProcessor.postProcessBeforeInitialization
   ↓
@PostConstruct
   ↓
InitializingBean.afterPropertiesSet()
   ↓
init-method سفارشی (@Bean(initMethod=...))
   ↓
BeanPostProcessor.postProcessAfterInitialization   ← پراکسی‌های AOP اینجا ساخته می‌شوند
   ↓
[ bean در حال سرویس‌دهی ]
   ↓ (هنگام خاموشی context، فقط singletonها)
@PreDestroy
   ↓
DisposableBean.destroy()
   ↓
destroy-method سفارشی

@Component
class LifecycleDemo implements InitializingBean, DisposableBean, BeanNameAware {
    @Override public void setBeanName(String name) { /* سوم */ }
    @PostConstruct void warmUp() { /* پنجم — hook ترجیحی برای init */ }
    @Override public void afterPropertiesSet() { /* ششم */ }
    @PreDestroy void flush() { /* هنگام خاموشی */ }
    @Override public void destroy() { /* بعد از @PreDestroy */ }
}

BeanPostProcessor در برابر BeanFactoryPostProcessor

این دو اسم شبیه‌اند اما دو کار کاملاً متفاوت می‌کنند.

• BeanFactoryPostProcessor یک‌بار اجرا می‌شود، پس از بارگذاری تعریف‌های bean اما پیش از ساخت هر beanی. فرادادهٔ پیکربندی را تغییر می‌دهد. مثال: PropertySourcesPlaceholderConfigurer که مقادیر ${...} را resolve می‌کند.
• BeanPostProcessor به‌ازای هر bean اجرا می‌شود و دورِ مقداردهی اولیه را می‌پیچد. این همان نقطهٔ توسعه‌ای است که Spring در آن پراکسی می‌سازد. مثال‌ها: AutowiredAnnotationBeanPostProcessor (که @Autowired را پردازش می‌کند) و AnnotationAwareAspectJAutoProxyCreator (که پراکسی‌های AOP را می‌سازد).

Scopeهای bean

Scope یعنی «دامنهٔ زندگی» یک bean: کانتینر چند نمونه از آن می‌سازد و هر نمونه چقدر عمر می‌کند.

تلهٔ کلاسیک: تزریق prototype در singleton

@Component @Scope("prototype")
class Task { /* هربار یک نمونهٔ جدید می‌خواهیم */ }

@Component
class Worker {
    @Autowired private Task task;   // باگ: یک‌بار resolve می‌شود، برای همیشه همان Task
}

راه‌حل‌ها، از بهترین به پایین:

۱. ObjectProvider<T> / Provider<T> (JSR-330) — تمیزترین راه. به‌جای خودِ prototype، یک «کارخانهٔ تنبل» تزریق می‌کنی و هر بار که واقعاً لازم داری یک نمونهٔ تازه می‌سازی. صریح، قابل‌تست و بدون جادوی پراکسی.

@Component
class Worker {
    private final ObjectProvider<Task> taskProvider;   // کارخانهٔ تنبل (lazy factory)
    Worker(ObjectProvider<Task> taskProvider) { this.taskProvider = taskProvider; }

    void run() {
        Task fresh = taskProvider.getObject();  // هر فراخوانی یک prototype جدید
        fresh.execute();
    }
}

۲. پراکسی scope‌دار (scoped proxy) — به‌جای prototype یک پراکسی می‌گذاری تا هر فراخوانی متد یک نمونهٔ تازه resolve کند:

@Component
@Scope(value = "prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
class Task { }

۳. تزریق متدی با @Lookup — Spring یک متد abstract/lookup را با CGLIB (کتابخانه‌ای که در زمان اجرا subclass می‌سازد) override می‌کند تا هر بار bean تازه برگرداند:

@Component
abstract class Worker {
    void run() { createTask().execute(); }
    @Lookup protected abstract Task createTask();  // توسط کانتینر override می‌شود
}

‎@Configuration، ‎@Bean و پراکسی CGLIB

این یکی از محبوب‌ترین دام‌های مصاحبه است. با دقت بخوانش.

@Configuration
class AppConfig {
    @Bean ClientA clientA() { return new ClientA(shared()); }
    @Bean ClientB clientB() { return new ClientB(shared()); }
    @Bean Shared shared()   { return new Shared(); }
}

سؤال: چند نمونهٔ Shared ساخته می‌شود؟ در نگاه اول انگار دو بار shared() صدا زده شده، پس دو نمونه. اما جواب یکی است.

حالا خودِ دام — حالت «lite»:

@Component   // نه @Configuration
class LiteConfig {
    @Bean ClientA clientA() { return new ClientA(shared()); }
    @Bean Shared  shared()  { return new Shared(); }   // مثل یک متد ساده فراخوانی می‌شود
}

متدهای @Bean که روی کلاسی اعلام شوند که @Configuration نیست (مثلاً روی @Component، یا با @Configuration(proxyBeanMethods = false)) توسط CGLIB رهگیری نمی‌شوند. یعنی منشی هوشمندی در کار نیست. هر فراخوانی مستقیم shared() متد واقعی را دوباره اجرا می‌کند → چند نمونهٔ Shared. توجه: beanهایی که خودِ کانتینر ثبت می‌کند همچنان singleton هستند، اما فراخوانی مستقیم متد به متد، کانتینر را دور می‌زند.

@Configuration(proxyBeanMethods = false)   // سریع‌تر، اما بدون رهگیری بین‌بینی
class FastConfig { /* متدهای @Bean نباید یکدیگر را صدا بزنند */ }

اسکن کامپوننت‌ها و stereotypeها

@ComponentScan (که به‌طور ضمنی داخل @SpringBootApplication هست) پکیج‌ها را می‌پیماید، کلاس‌های دارای annotationِ stereotype را پیدا می‌کند و آن‌ها را به‌عنوان bean ثبت می‌کند. «stereotype» یعنی برچسبی که نقش کلاس را اعلام می‌کند.

• @Component — برچسب عمومی.
• @Service، @Repository، @Controller، @RestController — تخصصی‌های @Component. از نظر معنایی برچسب نقش‌اند، اما دو تای‌شان کار اضافه هم می‌کنند:
  • @Repository علاوه بر برچسب، ترجمهٔ استثنای persistence را فعال می‌کند: استثناهای وابسته به vendor در JDBC/JPA به سلسله‌مراتب یکدست DataAccessException در Spring تبدیل می‌شوند.
  • @Controller/@RestController توسط Spring MVC مدیریت و به مسیرهای HTTP وصل می‌شوند.

وقتی چند کاندیدا با یک نوع match می‌شوند، Spring باید تصمیم بگیرد کدام را تزریق کند:

@Autowired
public Notifier(@Qualifier("sms") Notifier n) { ... }   // انتخاب با qualifier

@Component @Primary   // برندهٔ پیش‌فرض در حالت ابهام
class EmailNotifier implements Notifier {}

وابستگی‌های چرخه‌ای (circular dependencies)

فرض کن A به B نیاز دارد و B هم به A. این یک معمای مرغ‌و‌تخم‌مرغ است: کدام اول ساخته شود؟

setter/field injection: Spring گاهی می‌تواند این را با کش سه‌سطحی (three-level cache) و «مرجع‌های زودهنگام bean» حل کند. A را می‌سازد، یک مرجع زودهنگامِ خام از A را در کش singleton قرار می‌دهد، همان A زودهنگام را در B تزریق می‌کند، B را کامل می‌کند و سپس A را. این کار می‌کند چون ساخت و مقداردهی دو فاز جدا هستند.

constructor injection: Spring نمی‌تواند آن را حل کند — constructor مربوط به A به یک B کاملاً ساخته‌شده نیاز دارد و بالعکس؛ مرغ‌وتخم‌مرغ بدون هیچ مرجع زودهنگامی برای تحویل. نتیجه: BeanCurrentlyInCreationException هنگام بالاآمدن.

چرخهٔ constructor → BeanCurrentlyInCreationException (شکست استارتاپ — خوب، fail fast)
چرخهٔ setter/field → با کش مرجع زودهنگام حل می‌شود (کار می‌کند — اما بوی بد طراحی است)

@Service
class A {
    private final B b;
    A(@Lazy B b) { this.b = b; }   // @Lazy یک پراکسی تزریق می‌کند → چرخهٔ ساخت را می‌شکند
}

AOP: دغدغه‌های عرضی (cross-cutting concerns)

بعضی دغدغه‌ها در ده‌ها کلاس مختلف تکرار می‌شوند: لاگ‌گرفتن، شروع/پایان تراکنش، بررسی دسترسی، اندازه‌گیری زمان، caching. اگر این‌ها را داخل هر متد بنویسی، کدت پر از تکرار می‌شود.

AOP این دغدغه‌های مشترک را به aspectها استخراج می‌کند که به‌صورت اعلانی (declarative) — یعنی با یک annotation، نه با کد دستی داخل هر متد — اعمال می‌شوند. اصطلاحات کلیدی:

• Join point — نقطه‌ای در اجرا که advice می‌تواند اعمال شود (در Spring AOP همیشه یک اجرای متد).
• Pointcut — یک گزاره (predicate) که join pointها را انتخاب می‌کند؛ مثلاً execution(* com.acme.service..*(..)) یعنی «هر متدی در پکیج service».
• Advice — خودِ عملی که انجام می‌شود: @Before (قبل)، @AfterReturning (بعد از بازگشت موفق)، @AfterThrowing (بعد از استثنا)، @After (در هر حال)، @Around (دورتادور، قدرتمندترین).
• Aspect — کلاسی که pointcutها و adviceها را بسته‌بندی می‌کند (خودِ «نگهبان»).
• Weaving — عملِ چسباندن aspectها به کد. Spring از weaving مبتنی بر پراکسی در زمان اجرا استفاده می‌کند، نه weaving در زمان کامپایل/بارگذاریِ AspectJ (مگر خودت انتخابش کنی).

@Aspect @Component
class TimingAspect {
    @Around("execution(* com.acme..*Service.*(..))")
    public Object time(ProceedingJoinPoint pjp) throws Throwable {
        long t0 = System.nanoTime();
        try {
            return pjp.proceed();                 // متد واقعی را فراخوانی کن
        } finally {
            long us = (System.nanoTime() - t0) / 1000;
            System.out.println(pjp.getSignature() + " took " + us + "us");
        }
    }
}

پراکسی داینامیک JDK در برابر CGLIB

حالا وقتش است بفهمیم آن «نگهبان» چطور ساخته می‌شود. Spring پراکسی را در زمان post-processing مربوط به bean می‌سازد و دو راه دارد:

از نظر تاریخی Spring اگر bean دست‌کم یک اینترفیس پیاده می‌کرد از پراکسی JDK استفاده می‌کرد، وگرنه CGLIB. اما Spring Boot پیش‌فرض را به proxyTargetClass = true تغییر داد (یعنی همیشه CGLIB)، چون پراکسی مبتنی بر اینترفیس وقتی کد انتظار نوع concrete را داشت ClassCastException غیرمنتظره می‌ساخت. هر دو را بدان، چون تعیین می‌کند bean تزریق‌شده را به چه نوعی می‌توانی cast کنی.

دام self-invocation (محبوب سطح ارشد)

@Service
class OrderService {
    @Transactional
    public void outer() {
        inner();   // باگ: 'this.inner()' — پراکسی نیست → @Transactional نادیده گرفته می‌شود
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void inner() { /* انتظار تراکنش جدید؛ چیزی نمی‌گیرد/تراکنش outer را می‌گیرد */ }
}

outer() روی پراکسی صدا زده می‌شود (پس advise می‌شود)، اما inner() به‌صورت this.inner() فراخوانی می‌شود — یک فراخوانی مستقیم روی نمونهٔ خامِ target — پس advice تراکنش برای inner هرگز فعال نمی‌شود. همین باگ عیناً روی @Cacheable، @Async، @Retryable و هر annotationِ AOP دیگری هم رخ می‌دهد.

راه‌حل‌ها:

۱. inner() را به یک bean جدا منتقل کن و تزریقش کن؛ حالا فراخوانی از پراکسیِ آن bean عبور می‌کند. تمیزترین راه.

۲. پراکسی را به خودت تزریق کن (self-inject) و self.inner() را صدا بزن (از @Lazy یا ObjectProvider استفاده کن تا چرخهٔ ساخت پیش نیاید).

۳. از AopContext.currentProxy() با @EnableAspectJAutoProxy(exposeProxy = true) استفاده کن — کار می‌کند اما کد را به Spring AOP گره می‌زند؛ تا جای ممکن اجتنابش کن.

دام‌ها و نکات ظریف رایج

• @Autowired روی Optional<T> / @Nullable / ObjectProvider<T> یک وابستگی اختیاری را نشان می‌دهد؛ اما یک نوع اجباریِ ساده در نبودِ bean، NoSuchBeanDefinitionException پرتاب می‌کند.
• field injection + final ناممکن است؛ field injection همچنین تضمین‌های تغییرناپذیریِ مبتنی بر constructor را می‌شکند.
• @Value("${prop}") به PropertySourcesPlaceholderConfigurer نیاز دارد (Boot خودکار فراهمش می‌کند). اگر property موجود نباشد → شکست استارتاپ، مگر اینکه از ${prop:default} (مقدار پیش‌فرض) استفاده کنی.
• @PreDestroy روی prototype هرگز اجرا نمی‌شود. پاکسازی prototype را دستی، یا با DisposableBean‌ای که خودت صدا می‌زنی، مدیریت کن.
• دو کلاس @Configuration که هرکدام @Bean‌ای با نام یکسان اعلام کنند → ثبتِ دیرتر جایگزین می‌شود؛ اما Boot به‌طور پیش‌فرض override را ممنوع می‌کند (spring.main.allow-bean-definition-overriding=false).
• @Async/@Transactional روی همان کلاسِ فراخواننده → self-invocation، بی‌سروصدا بی‌اثر.
• ترتیب @PostConstruct بین beanهای مختلف به‌طور سراسری تضمین نمی‌شود، مگر با @DependsOn صریح یا لبه‌های واقعیِ وابستگی.

بهترین شیوه‌ها

۱. از constructor injection با فیلدهای final استفاده کن؛ بگذار Lombok @RequiredArgsConstructor یا یک constructor دست‌نویس سیم‌کشی کند. ۲. پیکربندی را در کلاس‌های @Configuration نگه دار؛ به proxyBeanMethods = false فقط زمانی دست بزن که متدها مستقل‌اند و سرعت استارتاپ اهمیت دارد. ۳. هرگز به مراجع چرخه‌ای متکی نباش؛ آن‌ها را ساختاری بشکن. ۴. برای تزریق beanهای با scope باریک‌تر، ObjectProvider را به پراکسی scope‌دار ترجیح بده — صریح و دوست‌دار تست است. ۵. متدهای دارای annotationِ AOP را public نگه دار و آن‌ها را از طریق bean صدا بزن، هرگز با this.. ۶. @Transactional را در لایهٔ service بگذار، نه روی controllerها یا repositoryها، و همیشه به‌یاد داشته باش که این یک پراکسی است — برای آن طراحی کن.

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

@Configuration
class C {
  @Bean A a() { return new A(shared()); }
  @Bean B b() { return new B(shared()); }
  @Bean Shared shared() { return new Shared(); }
}

@Transactional public void outer() { inner(); }
@Transactional(propagation = REQUIRES_NEW) public void inner() {}