Spring Core & DI

• Immutability — constructor injection lets the field be final, guaranteeing it's set once and never null after construction; field injection can't be final.
• Fails fast, at the right time — a missing/misconfigured dependency breaks object construction immediately (in tests too, with plain new), instead of surfacing later as a runtime NullPointerException the first time the field is used.
• Testability — with constructor injection you can instantiate the class directly in a unit test and pass mocks, with zero Spring involved. Field injection forces you to use reflection or a Spring test context just to set a private field.
• Surfaces design smells — a constructor with eight parameters is an obvious signal the class does too much; field injection hides that same problem.

BeanFactory is the root, most basic container interface — lazy bean instantiation only, minimal features. ApplicationContext extends it and adds what real applications need: eager singleton instantiation at startup (fail fast on misconfiguration), event publishing, internationalization (message source), AOP integration, and easy access to environment properties. In practice, every Spring Boot application uses ApplicationContext (specifically AnnotationConfigApplicationContext or its web variant) — BeanFactory is rarely used directly today.

@Autowired tells Spring to inject a matching bean by type. If more than one bean implements that type, Spring needs a tiebreaker: @Primary marks one bean as the default choice whenever there's ambiguity; @Qualifier("beanName") lets the injection point explicitly pick a specific bean by name, overriding @Primary if both are present.

interface NotificationSender { }

@Primary @Component
class EmailSender implements NotificationSender { }

@Component("smsSender")
class SmsSender implements NotificationSender { }

@Service
class AlertService {
    AlertService(@Qualifier("smsSender") NotificationSender sender) { /* explicitly picks SMS */ }
}

@Configuration marks a class as a source of bean definitions written in plain Java instead of XML. Each method inside it annotated @Bean returns an object that Spring registers as a managed bean — useful for wiring up third-party classes you don't own (so you can't add @Component to them) or beans that need custom construction logic.

@Configuration
class AppConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate(); // third-party class -- can't annotate it directly
    }
}

Spring AOP (Aspect-Oriented Programming) lets you factor out cross-cutting concerns — logging, transaction management, security checks — that would otherwise be duplicated across many unrelated methods, and apply them declaratively instead.

• Join point — a point during execution where an aspect could apply (in Spring AOP, always a method call).
• Pointcut — an expression that selects which join points to match (e.g. "every public method in any @Service").
• Advice — the actual code that runs at a matched join point, and when: @Before, @After, @Around (wraps the call, can short-circuit or modify the result), @AfterThrowing.
• Aspect — a class (@Aspect) that bundles a pointcut with its advice.

@Aspect @Component
class LoggingAspect {
    @Around("execution(* com.app.service.*.*(..))") // pointcut: any method in service package
    Object logTiming(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.nanoTime();
        Object result = pjp.proceed(); // actually calls the real method
        log.info("{} took {}ms", pjp.getSignature(), (System.nanoTime() - start) / 1_000_000);
        return result;
    }
}

Spring's default AOP implementation works via proxies (a wrapper object intercepts calls), which is why AOP doesn't apply to private methods or self-invocation (a method calling another method on this bypasses the proxy).

Spring's event mechanism lets beans communicate without holding a direct reference to each other — a publisher fires an event; any number of listeners react to it, fully decoupled from the code that raised it. It's Spring's built-in observer pattern.

record OrderPlacedEvent(Long orderId) { }

@Service
class OrderService {
    private final ApplicationEventPublisher publisher;
    void placeOrder(Order order) {
        // ... save the order ...
        publisher.publishEvent(new OrderPlacedEvent(order.getId()));
    }
}

@Component
class EmailNotifier {
    @EventListener
    void onOrderPlaced(OrderPlacedEvent event) {
        // send confirmation email -- runs decoupled from OrderService
    }
}

By default, listeners run synchronously, on the same thread and within the same transaction as the publisher — add @Async to a listener to run it on a separate thread, or @TransactionalEventListener to defer it until after the publishing transaction commits (useful so a listener never reacts to an event whose triggering transaction later rolled back).