Built-in Technologies

1. JDBC (Java Database Connectivity)

a. Source: Java SE (part of the JDK)
b. Description: The standard Java API for connecting and
executing queries with relational databases.
2. Spring Data JPA
a. Source: Spring Boot
b. Description: Part of the Spring Data project, which simplifies
the implementation of JPA-based repositories.
3. Spring Data JDBC
a. Source: Spring Boot
b. Description: A simpler alternative to Spring Data JPA for direct
JDBC access that avoids the complexity of JPA but still provides a
repository abstraction.
4. Spring JDBC
a. Source: Spring Framework
b. Description: Simplifies the use of JDBC and helps to avoid
common issues like resource management and error handling.

Third-Party Technologies

1. Hibernate
a. Source: Hibernate ORM
b. Description: A powerful ORM framework that simplifies
database interactions by mapping Java objects to database
tables.
2. MyBatis
a. Source: MyBatis
b. Description: A persistence framework that allows mapping SQL
statements to Java objects.
3. JOOQ (Java Object Oriented Querying)
a. Source: JOOQ
b. Description: A library that generates Java code from your
database schema and provides a fluent API to build SQL queries.
4. MongoDB
a. Source: MongoDB Inc.
b. Description: A popular NoSQL document database that stores
data in flexible, JSON-like documents.
Conclusion

Thank you for your patience and for pointing out the need for clarification.
Hibernate is indeed a third-party library and should not be considered built-
in. If you have further questions or need additional information about specific
technologies, please let me know!

1. JDBC Example

Overview: This example demonstrates how to connect to a database using

plain JDBC.

Code Snippet:

java
Copy code
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

public class JdbcExample {

public static void main(String[] args) {
String url = "jdbc:mysql://localhost:3306/yourDatabase";
String user = "yourUsername";
String password = "yourPassword";

try (Connection conn = DriverManager.getConnection(url, user,

password)) {
// Create a new user
String insertQuery = "INSERT INTO users (name, email) VALUES
(?, ?)";
try (PreparedStatement pstmt =
conn.prepareStatement(insertQuery)) {
pstmt.setString(1, "Alice");
 pstmt.setString(2, "alice@example.com");
pstmt.executeUpdate();
}

// Retrieve users
String selectQuery = "SELECT * FROM users";
try (PreparedStatement pstmt =
conn.prepareStatement(selectQuery);
ResultSet rs = pstmt.executeQuery()) {
while (rs.next()) {
System.out.println("User: " + rs.getString("name") + ", Email: "
+ rs.getString("email"));
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}

2. Spring Data JPA Example

Overview: This example demonstrates how to use Spring Data JPA to handle
database operations with an entity.

Code Snippet:

Entity Class:

java
Copy code
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
 private Long id;
private String name;
private String email;

// Getters and Setters

}

Repository Interface:

java
Copy code
import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {

User findByEmail(String email);
}

Service Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class UserService {
@Autowired
private UserRepository userRepository;

public List<User> getAllUsers() {

return userRepository.findAll();
}

public void createUser(User user) {

userRepository.save(user);
}
}
Controller Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/users")
public class UserController {
@Autowired
private UserService userService;

@GetMapping
public List<User> getAllUsers() {
return userService.getAllUsers();
}

@PostMapping
public void createUser(@RequestBody User user) {
userService.createUser(user);
}
}

3. Spring Data JDBC Example

Overview: This example demonstrates how to use Spring Data JDBC for
direct JDBC access with a simplified repository interface.

Code Snippet:

Entity Class:

java
Copy code
import org.springframework.data.annotation.Id;
import org.springframework.data.relational.core.mapping.Table;
@Table("users")
public class User {
@Id
private Long id;
private String name;
private String email;

// Getters and Setters

}

Repository Interface:

java
Copy code
import org.springframework.data.repository.CrudRepository;

public interface UserRepository extends CrudRepository<User, Long> {

User findByEmail(String email);
}

Service Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class UserService {
@Autowired
private UserRepository userRepository;

public List<User> getAllUsers() {

return (List<User>) userRepository.findAll();
}

public void createUser(User user) {

userRepository.save(user);
 }
}

Controller Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/users")
public class UserController {
@Autowired
private UserService userService;

@GetMapping
public List<User> getAllUsers() {
return userService.getAllUsers();
}

@PostMapping
public void createUser(@RequestBody User user) {
userService.createUser(user);
}
}

4. Spring JDBC Example

Overview: This example demonstrates how to use Spring JDBC to simplify

database access without the overhead of an ORM like JPA.

Code Snippet:

Configuration Class:

java
Copy code
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import javax.sql.DataSource;

@Configuration
public class DatabaseConfig {
@Bean
public DataSource dataSource() {
DriverManagerDataSource dataSource = new
DriverManagerDataSource();
dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
dataSource.setUrl("jdbc:mysql://localhost:3306/yourDatabase");
dataSource.setUsername("yourUsername");
dataSource.setPassword("yourPassword");
return dataSource;
}
}

DAO Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
public class UserDao {
@Autowired
private JdbcTemplate jdbcTemplate;

public void createUser(String name, String email) {

String sql = "INSERT INTO users (name, email) VALUES (?, ?)";
jdbcTemplate.update(sql, name, email);
}
 public List<User> getAllUsers() {
String sql = "SELECT * FROM users";
return jdbcTemplate.query(sql, (rs, rowNum) -> {
User user = new User();
user.setId(rs.getLong("id"));
user.setName(rs.getString("name"));
user.setEmail(rs.getString("email"));
return user;
});
}
}

Service Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class UserService {
@Autowired
private UserDao userDao;

public void createUser(String name, String email) {

userDao.createUser(name, email);
}

public List<User> getAllUsers() {

return userDao.getAllUsers();
}
}

Controller Class:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/users")
public class UserController {
@Autowired
private UserService userService;

@GetMapping
public List<User> getAllUsers() {
return userService.getAllUsers();
}

@PostMapping
public void createUser(@RequestParam String name, @RequestParam
String email) {
userService.createUser(name, email);
}
}

Conclusion

These examples illustrate how to work with different technologies for

database interaction in a Java/Spring Boot application. Each approach has
its own advantages:

 JDBC: Offers low-level control and flexibility for database operations.

 Spring Data JPA: Simplifies ORM-based data access and reduces
boilerplate code.
 Spring Data JDBC: Provides a simpler alternative to JPA with a focus
on direct JDBC access.
 Spring JDBC: Simplifies JDBC operations and resource management
without the complexity of ORM.

Each of these technologies can be chosen based on the specific needs of

your project, performance requirements, and developer preferences. If you
have further questions or need more examples, feel free to ask!
1. Design Patterns

 Definition: Design patterns are reusable solutions to common

problems that occur within a specific context in software design. They
provide guidelines or templates for how to solve particular design
challenges.
 Categories: Design patterns can be categorized into three main
types:
o Creational Patterns: Concerned with object creation
mechanisms (e.g., Singleton, Factory, Builder).
o Structural Patterns: Focus on how classes and objects are
composed to form larger structures (e.g., Adapter, Decorator,
Composite).
o Behavioral Patterns: Deal with object interaction and
responsibility (e.g., Observer, Strategy, Command).

2. Structural Patterns

 Definition: Structural patterns are a subset of design patterns that

deal with the composition of classes or objects. They focus on how to
 combine objects and classes to form larger structures while keeping
them flexible and efficient.
 Examples:
o Adapter Pattern: Allows incompatible interfaces to work
together.
o Decorator Pattern: Adds behavior to individual objects without
modifying their classes.
o Composite Pattern: Composes objects into tree structures to
represent part-whole hierarchies.

3. Architectural Patterns

 Definition: Architectural patterns provide a high-level solution for

organizing the overall structure of a software system. They define how
various components of the system interact and communicate.
 Examples:
o Microservices Architecture: Structures an application as a
collection of loosely coupled services.
o Model-View-Controller (MVC): Separates an application into
three main components: Model, View, and Controller.
o Layered Architecture: Organizes an application into layers,
such as presentation, business logic, and data access.

Key Differences

Design Structural Architectural

Aspect Patterns Patterns Patterns
Level of Often low-level, Specific type of High-level, focusing
Abstractio focusing on design pattern on overall system
n classes and focused on structure.
objects. composition.
Purpose Provide reusable Describe how to Define the overall
solutions to compose objects architecture of an
design problems. and classes. application.
Examples Singleton, Adapter, Decorator, Microservices,
Factory, Composite. MVC, Layered
Observer, Architecture.
Strategy.
Conclusion

 Design patterns encompass a wide range of patterns, including

structural patterns as one of their categories.
 Architectural patterns represent a higher-level view of how systems
are organized and how components interact, distinct from the more
granular focus of design patterns.

In summary, while all structural patterns are design patterns, not all design
patterns are structural patterns. Additionally, architectural patterns operate
at an even higher level, dealing with the overall organization of systems
rather than individual components or classes. If you have further questions
or need additional clarification, feel free to ask!

1. Architectural Patterns

a. Microservices Architecture
 Description: Structures an application as a collection of loosely
coupled, independently deployable services that communicate over a
network.
 Use Cases:
o E-commerce Platform: Different services for user
management, product catalog, and payment processing can
scale independently based on demand.
o Content Management System: Services handle content
publishing, user comments, and notifications, which operate
independently, allowing for easier updates and maintenance.
 Exclusivity: Not exclusive; applicable across various tech stacks.
b. Model-View-Controller (MVC)
 Description: Separates an application into three interconnected
components: Model (data), View (UI), and Controller (business logic).
 Use Cases:
o Admin Dashboard: The controller handles requests for user
management, the model interacts with the database, and the
view renders the user interface.
o Blog Application: The controller processes requests to create,
update, and delete blog posts, while the model represents the
post data, and the view displays the posts.
 Exclusivity: Not exclusive; widely used in many frameworks, including
ASP.NET MVC in C#.

c. Layered Architecture
 Description: Organizes the application into layers, each with a
specific responsibility (e.g., presentation, business logic, data access).
 Use Cases:
o Online Banking Application: The presentation layer handles
user interactions, the service layer contains business logic, and
the data access layer communicates with SQL Server.
o Inventory Management System: Different layers manage user
interfaces, business rules, and interactions with SQL Server.
 Exclusivity: Not exclusive; applicable in many programming
environments.

2. Design Patterns

a. Repository Pattern
 Description: Abstracts data access logic, allowing for separation
between the data layer and business logic.
 Use Cases:
o User Management: A UserRepository interface allows for
CRUD operations on user entities without exposing SQL queries
directly.
o Product Catalog: A ProductRepository manages all database
interactions related to products stored in SQL Server.
 Code Snippet:
java
Copy code
import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {

User findByEmail(String email); // Automatically generates the query
}

b. Singleton Pattern
 Description: Ensures a class has only one instance and provides a
global point of access to it.
 Use Cases:
o Configuration Management: A singleton can manage
application configuration settings throughout the application
lifecycle.
o Logging Service: A logging service can be implemented as a
singleton to provide a single point for logging across different
components.
 Code Snippet:
java
Copy code
public class Singleton {
private static Singleton instance;

private Singleton() {} // Private constructor

public static synchronized Singleton getInstance() {

if (instance == null) {
instance = new Singleton();
}
return instance;
}
}

c. Factory Pattern
 Description: Provides an interface for creating objects but allows
subclasses to alter the type of objects that will be created.
 Use Cases:
 o Service Creation: A factory can create instances of service
classes based on the provided parameters.
o Shape Creation: A shape factory can create different types of
shapes (e.g., Circle, Rectangle) based on input parameters.
 Code Snippet:
java
Copy code
public interface Shape {
void draw();
}

public class Circle implements Shape {

public void draw() {
System.out.println("Drawing a Circle");
}
}

public class ShapeFactory {

public static Shape getShape(String shapeType) {
if (shapeType.equalsIgnoreCase("CIRCLE")) {
return new Circle();
}
return null;
}
}

d. Observer Pattern
 Description: Defines a one-to-many dependency between objects so
that when one object changes state, all its dependents are notified and
updated automatically.
 Use Cases:
o Event Handling: In an event-driven application, observers can
listen for changes in data and react accordingly (e.g., updating UI
elements).
o Notification System: An observer can notify users of changes
or events, such as new messages or updates.
 Code Snippet:
java
Copy code
import java.util.ArrayList;
import java.util.List;

public class Subject {

private List<Observer> observers = new ArrayList<>();

public void attach(Observer observer) {

observers.add(observer);
}

public void notifyObservers() {

for (Observer observer : observers) {
observer.update();
}
}
}

public interface Observer {

void update();
}

public class ConcreteObserver implements Observer {

@Override
public void update() {
System.out.println("Observer notified!");
}
}

e. Decorator Pattern
 Description: Allows behavior to be added to individual objects, either
statically or dynamically, without affecting the behavior of other
objects from the same class.
 Use Cases:
o Logging: Adding logging functionality to service methods
without modifying their code.
o Data Synchronization: Intercepting CRUD operations to
synchronize data with another system (e.g., OpenSearch).
 Code Snippet:
java
Copy code
public interface DealRepository {
Deal create(Deal deal);
Deal update(Deal deal);
void delete(int dealId);
Deal getById(int dealId);
}

public class DealRepositoryDecorator implements DealRepository {

private final DealRepository innerRepository;

public DealRepositoryDecorator(DealRepository innerRepository) {

this.innerRepository = innerRepository;
}

public Deal create(Deal deal) {

// Decorator logic (e.g., logging, synchronization)
return innerRepository.create(deal);
}

// Implement other methods...

}

3. General Patterns

a. Dependency Injection
 Description: A design pattern that implements inversion of control,
allowing dependencies to be injected rather than being created
internally.
 Use Cases:
o Service Management: Injecting repositories into services to
decouple logic.
o Testing: Facilitating easier testing by allowing mock
implementations of dependencies.
 Code Snippet:
java
Copy code
@Service
public class UserService {
 private final UserRepository userRepository;

@Autowired
public UserService(UserRepository userRepository) {
this.userRepository = userRepository; // Dependency injection
}

public User getUserByEmail(String email) {

return userRepository.findByEmail(email);
}
}

b. Command Pattern
 Description: Encapsulates a request as an object, allowing for
parameterization of clients with queues, requests, and operations.
 Use Cases:
o Menu Actions: In an admin application, command objects can
represent actions for menu items.
o Undo Functionality: Command objects can be queued and
executed based on user actions, allowing for easy undo/redo
functionality.
 Code Snippet:
java
Copy code
interface Command {
void execute();
}

class Light {
public void turnOn() {
System.out.println("Light is ON");
}
public void turnOff() {
System.out.println("Light is OFF");
}
}

class LightOnCommand implements Command {

private Light light;
 public LightOnCommand(Light light) {
this.light = light;
}

public void execute() {

light.turnOn();
}
}

Conclusion

This comprehensive list covers a variety of architectural patterns, design

patterns, and general patterns relevant to the Java/Spring Boot
ecosystem, particularly when integrated with a tech stack that includes
React.js and Microsoft SQL Server. Each pattern is accompanied by detailed
descriptions, use cases, and code snippets, demonstrating how they can be
effectively applied in real-world scenarios.

If you have specific patterns you would like to explore further or additional
questions, feel free to ask!

1. DRY (Don't Repeat Yourself)

 Description: A principle that emphasizes the reduction of duplication

in code. Each piece of knowledge should have a single, unambiguous
representation in a system.
 Use Case: Helps in maintaining code consistency and reducing the
risk of errors when changes are made.
 Example: Instead of duplicating the same logic in multiple places,
encapsulate it in a method or class.
java
Copy code
public class UserService {
public User getUserById(Long id) {
// Logic to retrieve user
}

public User getUserByEmail(String email) {

// Logic to retrieve user by email
}
}

2. KISS (Keep It Simple, Stupid)

 Description: A principle that advocates for simplicity in design.

Systems work best if they are kept simple rather than made complex.
 Use Case: Encourages developers to avoid unnecessary complexity in
both code and architecture.
 Example: When designing a class, ensure it has a clear purpose
without excessive methods or properties.

java
Copy code
public class SimpleCalculator {
public int add(int a, int b) {
return a + b;
}
}

3. YAGNI (You Aren't Gonna Need It)

 Description: A principle that states that a programmer should not add

functionality until it is necessary. Avoid building features that are not
currently needed.
 Use Case: Helps prevent over-engineering and keeps the codebase
clean and manageable.
 Example: Avoid adding extra parameters or methods to a class that
are not required for the current use case.
java
Copy code
public class User {
private String name;
// No need to add future methods for features that aren't needed yet
}

4. Separation of Concerns

 Description: A design principle for separating a computer program

into distinct sections, such that each section addresses a separate
concern or functionality.
 Use Case: Enhances maintainability, as changes in one area of the
application do not affect others.
 Example: Dividing an application into layers (presentation, business
logic, data access) or using design patterns like MVC.

java
Copy code
// Example of a Controller, Service, and Repository setup
@RestController
public class UserController {
// Handles HTTP requests
}

@Service
public class UserService {
// Contains business logic
}

public interface UserRepository {

// Data access methods
}

5. Law of Demeter (Principle of Least Knowledge)

 Description: A design guideline for developing software, which states

that a unit should only talk to its immediate friends and not to
strangers.
  Use Case: Reduces coupling and increases modularity by limiting the
number of classes that any one class can interact with.
 Example: Instead of chaining method calls across multiple objects,
keep interactions simple and direct.

java
Copy code
public class Order {
private ShippingService shippingService;

public void shipOrder() {

shippingService.ship(this);
}
}

6. Composition over Inheritance

 Description: A principle that favors composing classes with other

classes to achieve functionality rather than relying on inheritance.
 Use Case: Promotes flexibility and reusability. Changes in one class do
not affect subclasses.
 Example: Using interfaces and composition to build behavior.

java
Copy code
public interface PaymentProcessor {
void processPayment(double amount);
}

public class CreditCardProcessor implements PaymentProcessor {

public void processPayment(double amount) {
// Logic to process credit card payment
}
}

public class Order {

private PaymentProcessor paymentProcessor;

public Order(PaymentProcessor paymentProcessor) {

this.paymentProcessor = paymentProcessor;
 }

public void checkout(double amount) {

paymentProcessor.processPayment(amount);
}
}

7. Interface Segregation Principle (ISP)

 Description: A principle that states that no client should be forced to

depend on methods it does not use. Rather than having one large
interface, multiple smaller interfaces are preferred.
 Use Case: Reduces the impact of changes and increases flexibility.
 Example:
java
Copy code
interface Printer {
void printDocument(String document);
}

interface Scanner {
void scanDocument(String document);
}

class MultiFunctionPrinter implements Printer, Scanner {

public void printDocument(String document) {
// Print logic
}

public void scanDocument(String document) {

// Scan logic
}
}

Conclusion

These principles complement the SOLID principles and are essential for
creating maintainable, scalable, and robust applications in Java, especially
when working with frameworks like Spring Boot. They are not exclusive to
Java and can be applied in other programming languages, including C# and
JavaScript.

The application of these principles varies based on the specific requirements

of your projects and the technologies involved. If you have any further
questions or need more examples, feel free to ask!

SOLID Principles Explained in the Context of Java/Spring Boot

1. S - Single Responsibility Principle (SRP):

a. A class should have only one reason to change, meaning it
should have only one job or responsibility. This encourages a
clear separation of concerns.
2. O - Open/Closed Principle (OCP):
a. Software entities (classes, modules, functions, etc.) should be
open for extension but closed for modification. This can be
achieved through interfaces and abstract classes.
3. L - Liskov Substitution Principle (LSP):
a. Subtypes must be substitutable for their base types without
altering the correctness of the program. This ensures that
derived classes extend the behavior of the base class without
changing its expected behavior.
4. I - Interface Segregation Principle (ISP):
a. Clients should not be forced to depend on interfaces they do not
use. Instead of one large interface, multiple smaller interfaces
are preferred.
5. D - Dependency Inversion Principle (DIP):
a. High-level modules should not depend on low-level modules;
both should depend on abstractions. This promotes loose
coupling.
Comprehensive Code Snippet

Here’s a code snippet that demonstrates the application of all SOLID

principles using a simple order processing system in a Spring Boot
application:

java
Copy code
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import org.springframework.stereotype.Service;

// 1. Single Responsibility Principle (SRP)

@Entity
public class Order {
private Long id;
private String product;
private int quantity;

// Getters and Setters...

}

// 2. Open/Closed Principle (OCP)

interface PaymentMethod {
void pay(Order order);
}

@Component
class CreditCardPayment implements PaymentMethod {
public void pay(Order order) {
// Payment logic for credit card
System.out.println("Paid " + order.getQuantity() + " of " +
order.getProduct() + " using Credit Card.");
}
}

@Component
class PayPalPayment implements PaymentMethod {
public void pay(Order order) {
// Payment logic for PayPal
 System.out.println("Paid " + order.getQuantity() + " of " +
order.getProduct() + " using PayPal.");
}
}

// 3. Liskov Substitution Principle (LSP)

// Any PaymentMethod can substitute for another
@Service
class OrderService {
private final PaymentMethod paymentMethod;

// 4. Dependency Inversion Principle (DIP)

// Constructor-based Dependency Injection
@Autowired
public OrderService(PaymentMethod paymentMethod) {
this.paymentMethod = paymentMethod; // High-level module depends
on abstraction
}

public void processOrder(Order order) {

// Business logic
paymentMethod.pay(order); // Delegating payment to the injected
payment method
}
}

// 5. Interface Segregation Principle (ISP)

interface NotificationService {
void notifyUser(Order order);
}

@Component
class EmailNotificationService implements NotificationService {
public void notifyUser(Order order) {
// Sending email logic
System.out.println("Notification sent to user for order: " +
order.getId());
}
}
@Component
class SmsNotificationService implements NotificationService {
public void notifyUser(Order order) {
// Sending SMS logic
System.out.println("SMS notification sent for order: " + order.getId());
}
}

// Main Application
@SpringBootApplication
public class Application {
public static void main(String[] args) {
ApplicationContext context = SpringApplication.run(Application.class,
args);
OrderService orderService = context.getBean(OrderService.class);

// Create an order
Order order = new Order();
order.setId(1L);
order.setProduct("Laptop");
order.setQuantity(2);

// Process the order

orderService.processOrder(order);

// Example of notification
NotificationService notificationService =
context.getBean(EmailNotificationService.class);
notificationService.notifyUser(order);
}
}

Comments on the Code Snippet

 Single Responsibility Principle (SRP): The Order class has a single

responsibility of representing an order, while payment processing and
notifications are handled by separate classes.
  Open/Closed Principle (OCP): The PaymentMethod interface allows
for new payment methods to be added without modifying existing
code. Each payment method implements this interface.
 Liskov Substitution Principle (LSP): The OrderService class can
work with any implementation of PaymentMethod. This promotes
flexibility in substituting different payment methods.
 Interface Segregation Principle (ISP): The NotificationService
interface allows for different types of notifications (email, SMS), so
classes implementing this interface only need to implement methods
relevant to them.
 Dependency Inversion Principle (DIP): The OrderService depends
on the abstraction PaymentMethod, not on concrete implementations.
This promotes loose coupling and easier testing.

Conclusion

Applying the SOLID principles helps create a robust and maintainable

software design. The provided code snippet demonstrates how these
principles can be integrated into a Spring Boot application, enhancing
readability, flexibility, and testability. If you have further questions or require
more examples, feel free to ask!