Design Patterns, Spring Framework, and Related Interview Questions

This article provides concise explanations of common design patterns, compares simple and abstract factory patterns, and offers an extensive overview of Spring framework concepts including IoC, AOP, bean scopes, dependency injection methods, transaction management, MVC workflow, and key annotations such as @RequestMapping and @Autowired.

Java Captain
Java Captain
Java Captain
Design Patterns, Spring Framework, and Related Interview Questions

Design Patterns

Common interview question: "Which design patterns are you familiar with?" A reference link to a detailed design‑pattern summary is provided.

Simple Factory vs. Abstract Factory

The simple factory pattern is suitable for small projects with limited product variations. It consists of three roles: the factory class (core logic), an abstract product (interface or abstract class), and concrete products (e.g., Benz, Bmw classes).

A class diagram illustrates the relationships among these roles.

Abstract Factory

An abstract factory creates families of related products (product families). Examples: BmwCar and BenzCar belong to different product hierarchies, while BmwSportsCar and BenzSportsCar form a sports‑car family. The pattern differs from the Factory Method by handling more complex object creation across multiple product families.

Key conditions for using an abstract factory:

The system contains multiple product families, but only one family is used at a time.

Products within the same family are used together.

The roles are analogous to the Factory Method: abstract factory (interface/abstract class), concrete factory (implements creation logic), abstract product (interface/abstract class), and concrete product (actual class).

Spring / Spring MVC

Why use Spring?

Purpose: simplify enterprise application development.

Features: lightweight IoC container, AOP support, and extensive enterprise utilities.

Scope: applicable to any Java application.

Spring is a lightweight IoC (Inversion of Control) and AOP container framework.

Lightweight nature

The core framework fits in a ~1 MB JAR and imposes minimal runtime overhead. It is non‑intrusive; application objects do not depend on Spring‑specific classes.

Control Inversion (IoC)

IoC injects dependencies into objects rather than having objects create or locate them, promoting loose coupling.

Aspect‑Oriented Programming (AOP)

Spring provides rich AOP support, allowing cross‑cutting concerns (e.g., logging, transactions) to be modularized into aspects.

Container role

Spring manages bean configuration and lifecycle, supporting prototype and singleton scopes, among others.

Core concepts

Spring enables clean, manageable, and testable code by handling component composition, transaction management, persistence integration, and more.

AOP Explanation

AOP complements OOP by modularizing cross‑cutting concerns into reusable aspects, reducing code duplication and coupling.

IoC Explanation

IoC (Inversion of Control) decouples objects by delegating dependency creation to a container, acting as a “glue” that assembles the system.

Spring Modules

Spring consists of over 20 modules grouped into core container, data access/integration, web, AOP, tools, messaging, and testing.

Dependency Injection (DI) Methods

Constructor injection

Setter injection

Annotation‑based injection

Bean Thread Safety

Spring does not enforce thread safety for beans; safety depends on the bean’s scope and implementation.

Bean Scopes

singleton – one instance per container

prototype – a new instance each request

request – new instance per HTTP request (web only)

session – new instance per HTTP session (web only)

globalsession – per global session (portlet only)

Singleton and prototype are the most commonly used scopes.

Bean Autowiring

Spring supports implicit bean discovery/autowiring and explicit configuration via Java or XML.

Transaction Management

Programmatic transaction management (direct API calls)

Declarative transaction management with TransactionProxyFactoryBean Declarative transaction management with @Transactional AspectJ‑based transaction configuration

Transaction Isolation Levels

Dirty read

Non‑repeatable read

Phantom read

Spring MVC Workflow

1. Client request is captured by DispatcherServlet. 2. DispatcherServlet resolves the handler via HandlerMapping. 3. Appropriate HandlerAdapter is selected. 4. Request data is bound to controller method parameters (including type conversion, formatting, validation). 5. Controller returns a ModelAndView. 6. ViewResolver resolves the view. 7. View renders the response. 8. Response is sent back to the client.

Spring MVC Core Components

DispatcherServlet – front controller

Controller – request handling

HandlerMapping – maps requests to handlers

ModelAndView – data and view holder

ViewResolver – resolves view names

Interceptors – pre/post‑processing of requests

@RequestMapping

Maps URLs to controller classes or methods; supports attributes such as value, method, consumes, produces, params, and headers.

@Autowired

Injects bean dependencies automatically, simplifying wiring of components.

(End of article)

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Java Captain
Written by

Java Captain

Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.