Lecture 34: Spring Boot Annotations & Build Systems

BMC201 - Web Technology

Mr. Prashant Kumar Nag

2026-03-20

Lecture 34

Spring Boot Annotations & Build Systems

Week 9 | Unit V: Spring Boot & REST Services
BMC201 - Web Technology
Mr. Prashant Kumar Nag, Assistant Professor

Learning Objectives


  • Define what a design pattern is and why patterns matter
  • Explain the Factory pattern and implement it in Java
  • Explain the Strategy pattern and implement it in Java
  • Relate Factory pattern to Spring’s BeanFactory and ApplicationContext
  • Relate Strategy pattern to Spring’s DI and polymorphism
  • Choose the right pattern for a given design problem

Prerequisites


Before this lecture, quickly revise:

  • previous lecture concepts and key terminology
  • related unit outcomes and expected practical skills
  • baseline Java/web flow needed for in-class examples

Syllabus Mapping


  • Unit alignment for this lecture topic
  • Exam alignment for short and long questions
  • Lab/practical alignment for implementation tasks

Agenda


  • quick revision of context
  • concept explanation with examples
  • implementation/demo walk-through
  • debugging and exam-focused recap

Introduction


This lecture builds conceptual clarity first, then connects it to practical coding and exam application.

Think About It


What one real classroom/lab scenario best demonstrates where this topic is useful?

What Are Design Patterns?


Design patterns are reusable solutions to commonly occurring problems in software design.

They are not code — they are templates describing how to solve a problem in a given context.

Category Purpose Examples
Creational Object creation Factory, Singleton, Builder
Structural Object composition Adapter, Decorator, Proxy
Behavioral Object communication Strategy, Observer, Template

Why Patterns Matter in Spring


  • Spring itself is built on patterns
  • BeanFactory → Factory pattern
  • ApplicationContext → Context object pattern
  • AOP proxies → Proxy pattern
  • JdbcTemplate → Template Method pattern
  • @Component scanning → Factory + Strategy

Understanding patterns helps you understand why Spring is designed the way it is.

Factory Pattern: Intent


Problem: The calling code should not need to know which concrete class to instantiate.

Solution: Delegate object creation to a Factory — a dedicated class or method responsible for creating objects.

When to use: - When object creation logic is complex - When the concrete type may change or vary - When you want to centralize creation logic

Factory Pattern in Java


// Step 1: Define the interface
public interface Notification {
  void send(String message);
}
class EmailNotification  implements Notification { ... }
class SMSNotification    implements Notification { ... }
class PushNotification   implements Notification { ... }

// Step 2: Create the factory
public class NotificationFactory {
  public static Notification create(String type) { // #<1>
    return switch (type) {
      case "email" -> new EmailNotification();
      case "sms"   -> new SMSNotification();
      default      -> new PushNotification();
    };
  }
}

// Step 3: Use the factory
Notification n = NotificationFactory.create("email"); // #<2>
n.send("Your order is confirmed!");
  1. Factory method centralises creation; callers use only the interface
  2. Caller does not need to know which concrete class is used

Factory Pattern in Spring


Spring’s ApplicationContext is a factory for beans.

// Spring creates and returns the correct implementation
ApplicationContext ctx =
  new AnnotationConfigApplicationContext(AppConfig.class);

Notification n = ctx.getBean(Notification.class); // #<1>
n.send("Hello from Spring Factory!");
  1. Spring resolves the correct implementation based on configuration — exactly Factory pattern

flowchart LR
  A[ctx.getBean] --> B[ApplicationContext / BeanFactory]
  B --> C{Configuration}
  C --> D[EmailNotification bean]
  C --> E[SMSNotification bean]

Strategy Pattern: Intent


Problem: An algorithm or behavior needs to change at runtime without changing the class that uses it.

Solution: Define a family of algorithms, encapsulate each one, and make them interchangeable via a common interface.

When to use: - When you have multiple algorithms for the same task - When you want to switch behavior without conditionals - When you want to isolate algorithm changes from client code

Strategy Pattern in Java


// Step 1: Strategy interface
public interface SortStrategy {
  void sort(int[] data);
}

// Step 2: Concrete strategies
class BubbleSort implements SortStrategy { ... }
class QuickSort  implements SortStrategy { ... }
class MergeSort  implements SortStrategy { ... }

// Step 3: Context that uses the strategy
public class Sorter {
  private SortStrategy strategy; // #<1>
  public Sorter(SortStrategy s) { this.strategy = s; }
  public void sort(int[] data)  { strategy.sort(data); }
}

// Step 4: Select strategy at runtime
Sorter s = new Sorter(new QuickSort()); // #<2>
s.sort(data);
  1. Holds a reference to a strategy — can be swapped
  2. Concrete strategy chosen by the caller — no conditionals in Sorter

Strategy Pattern in Spring DI


Spring DI naturally supports the Strategy pattern. Inject the correct strategy via configuration:

@Service
public class PaymentService {
  private final PaymentStrategy strategy; // #<1>
  @Autowired
  public PaymentService(PaymentStrategy strategy) {
    this.strategy = strategy;
  }
  public void pay(double amount) { strategy.execute(amount); }
}

@Component("creditCard")
public class CreditCardStrategy implements PaymentStrategy { ... }

@Component("upi")
public class UPIStrategy implements PaymentStrategy { ... }
  1. Inject the right strategy using @Qualifier("upi") or conditional config

Factory vs Strategy — Quick Comparison


Aspect Factory Pattern Strategy Pattern
Category Creational Behavioral
Goal Manage object creation Swap algorithms/behavior
Key element Factory class/method Strategy interface
When to switch At creation time At runtime
Spring example BeanFactory / getBean() @Autowired strategy bean

Classroom Exercise


Task: Implement a simple discount system.

  1. Create DiscountStrategy interface with apply(double price) method
  2. Implement FestiveDiscount (10%) and ClearanceDiscount (30%)
  3. Create a PriceCalculator that uses the strategy
  4. Use a factory method to choose the strategy based on a string input

Combine both patterns in one mini project.

Common Mistakes to Avoid


  • Confusing Factory (creational) with Strategy (behavioral)
  • Using long if-else chains instead of a factory method
  • Hardcoding strategy selection instead of injecting via DI
  • Making the factory too complex — keep creation logic minimal
  • Not using an interface — pattern requires programming to an abstraction

AKTU Exam-Oriented Checklist


Prepare these high-probability questions:

  1. Define design patterns and list the three categories with examples
  2. Explain Factory pattern with a Java example
  3. Explain Strategy pattern with a Java example
  4. How does Spring use the Factory pattern internally?
  5. Compare Factory and Strategy patterns with a table

Summary


You now understand:

  • Design patterns as reusable templated solutions
  • Factory pattern to centralise object creation
  • Strategy pattern to swap algorithms via a shared interface
  • How Spring implements both patterns in its core
  • How DI and Factory/Strategy work together naturally

Memory Booster


Quick memory anchor for this lecture:

  • define the core concept in one line
  • map where it is used in architecture
  • recall one implementation or exam-style example

Live Demo


Demo focus for this lecture:

  • walk through one practical code flow
  • identify key configuration/code lines
  • verify output and common failure points

Resources & References


  • Official Spring/JSP/Servlet documentation relevant to this lecture
  • Classroom notes and examples discussed in slides
  • Course repository examples and demo references

Structured Debug Checklist


  1. verify imports, annotations/tags, and object names are correct
  2. check request flow, mappings, and lifecycle/state assumptions
  3. inspect runtime logs and stack trace for first failing point
  4. validate expected output against actual response/view

Exam Preparation Questions: Short


  • Define the core concept covered in this lecture.
  • Differentiate related terms/approaches with one example.
  • List important components, annotations, or lifecycle steps.
  • Mention common mistakes and how to avoid them.

Exam Preparation Questions: Long


  • Explain the lecture topic with architecture/flow diagram and examples.
  • Compare alternatives and justify best-practice usage.
  • Discuss practical implementation steps and debugging strategy.

Practice Task


  • implement one minimal, working example based on this lecture
  • test with valid and invalid inputs
  • document two errors encountered and how you fixed them

Checklist


Can you:

  • explain the concept clearly without notes?
  • implement the basic example end-to-end?
  • debug common classroom/exam mistakes?

Next Lecture


  • Topic: Lecture 35 continuation
  • Preparation required: revise this lecture summary and practice task

Spring Boot Annotations & Build Systems

Next: Lecture 35 - Spring IoC, Bean Scopes & Life Cycle Callbacks