Best Practices in Java: Clean Code, Design Patterns, SOLID Principles, and Security

What Are Java Best Practices?

Java best practices are proven development habits that help make applications more readable, maintainable, reliable, and secure.

They cover much more than formatting. Good practices include meaningful naming, proper exception handling, avoiding unnecessary duplication, following object-oriented design principles, using appropriate collections, validating input, and protecting sensitive data.

The goal is not to follow rules blindly. The goal is to make code easier for another developer—or your future self—to understand and safely modify.

Why Clean Code Matters in Java

Clean code is code that communicates its purpose clearly and avoids unnecessary complexity.

A program may produce the correct result but still be difficult to maintain if methods are too long, classes have too many responsibilities, or variable names are unclear.

For example, this code is difficult to understand:

int x = 500;
int y = 10;
int z = x * y;

A clearer version explains what the values represent:

int productPrice = 500;
int quantity = 10;
int totalPrice = productPrice * quantity;

Both versions work, but the second communicates intent much better.

1. Use Meaningful Names

Names should describe what a variable, method, or class represents.

Avoid names such as:

int a;
String x;
void process();

Prefer descriptive names:

int customerAge;
String customerEmail;
void calculateOrderTotal();

A good name can reduce the amount of commenting required to understand the code.

Good naming examples

class PaymentService {
    void processPayment() {
        // payment logic
    }
}

Instead of:

class PS {
    void doIt() {
        // payment logic
    }
}

2. Keep Methods Small and Focused

A method should ideally perform one clear task.

Avoid creating methods that validate input, calculate prices, save data, send emails, and generate reports all at once.

For example:

void processOrder() {
    validateOrder();
    calculateTotal();
    saveOrder();
    sendConfirmationEmail();
}

The main method now communicates the overall workflow while individual methods handle specific responsibilities.

This makes the application easier to test and modify.

3. Follow the Single Responsibility Principle

The Single Responsibility Principle, commonly called SRP, says that a class should have one primary responsibility and one reason to change.

Consider this example:

class UserService {
    void createUser() {
        // create user
    } void sendEmail() {
        // send email
    } void generatePdfReport() {
        // generate PDF
    }
}

The class is handling several unrelated responsibilities.

A better structure could be:

class UserService {
    void createUser() {
        // create user
    }
}class EmailService {
    void sendEmail() {
        // send email
    }
}class ReportService {
    void generatePdfReport() {
        // generate PDF
    }
}

Each class now has a more focused responsibility.

4. Avoid Duplicate Code

Repeated code makes maintenance harder because a change may need to be applied in several places.

Instead of:

double total1 = price1 * 0.90;
double total2 = price2 * 0.90;
double total3 = price3 * 0.90;

Create reusable behavior:

double applyDiscount(double price) {
    return price * 0.90;
}

Then:

double total1 = applyDiscount(price1);
double total2 = applyDiscount(price2);
double total3 = applyDiscount(price3);

This idea is often summarized as DRY — Don't Repeat Yourself.

5. Avoid Overly Long Classes

A class containing thousands of lines can become difficult to understand and maintain.

Large classes often indicate that several responsibilities should be separated.

For example, an e-commerce application might separate:

OrderServicePaymentServiceInventoryServiceEmailServiceInvoiceServiceShippingService

Instead of placing every operation inside:

OrderManager

The goal is not to create hundreds of tiny classes. The goal is to keep responsibilities understandable.

6. Avoid Overly Long Methods

Long methods are difficult to test and understand.

Instead of:

void registerUser() {
    // 100 lines of validation
    // 50 lines of database logic
    // 30 lines of email logic
}

Break the workflow into meaningful operations:

void registerUser(User user) {
    validateUser(user);
    saveUser(user);
    sendWelcomeEmail(user);
}

The implementation becomes easier to navigate.

7. Prefer Constants Over Magic Numbers

Avoid unexplained values scattered throughout the code.

Instead of:

if (age >= 18) {
    // allowed
}

You could use:

private static final int MINIMUM_ADULT_AGE = 18;
if (age >= MINIMUM_ADULT_AGE) {
    // allowed
}

Similarly:

private static final double TAX_RATE = 0.18;

is clearer than repeatedly writing:

price * 0.18

8. Use Comments Carefully

Comments are useful when they explain why something is done.

Avoid comments that simply repeat the code:

// Add two numbers
int result = a + b;

The code already explains itself.

A useful comment might explain an unusual business rule:

// The legacy payment gateway requires amounts in paise.
long amountInPaise = amountInRupees * 100;

Good code should communicate what it does; comments can explain why an unusual decision exists.

9. Prefer Immutability When Practical

Immutable objects cannot have their state changed after creation.

Java provides several useful immutable types, including:

StringIntegerLocalDateLocalDateTime

For example:

LocalDate date = LocalDate.of(2026, 10, 3);
LocalDate nextDate = date.plusDays(1);

The original date is not changed.

Immutability can make code easier to reason about and can reduce problems caused by unexpected state changes.

10. Program to Interfaces

Instead of tightly coupling code to a specific implementation:

ArrayList<String> names = new ArrayList<>();

Prefer the interface when the implementation does not matter:

List<String> names = new ArrayList<>();

This makes it easier to change the implementation later:

List<String> names = new LinkedList<>();

The rest of the code can continue working with the List interface.

SOLID Principles in Java

SOLID is a group of five object-oriented design principles.

The five principles are:

S → Single Responsibility PrincipleO → Open/Closed PrincipleL → Liskov Substitution PrincipleI → Interface Segregation PrincipleD → Dependency Inversion Principle

They help developers design classes and components that are easier to maintain and extend.

11. Single Responsibility Principle — SRP

SRP says a class should have one primary responsibility.

Poor design:

class Invoice {
    void calculateTotal() {
    } void saveToDatabase() {
    } void sendEmail() {
    }
}

The class contains business calculation, persistence, and communication responsibilities.

A more focused design could be:

class Invoice {
    void calculateTotal() {
    }
}class InvoiceRepository {
    void save(Invoice invoice) {
    }
}class EmailService {
    void sendInvoice(Invoice invoice) {
    }
}

This separation makes each component easier to test and change.

12. Open/Closed Principle — OCP

The Open/Closed Principle says software entities should generally be open for extension but closed for modification.

Suppose a payment system supports multiple payment methods.

Instead of continuously changing one large method:

void pay(String type) {
    if (type.equals("CARD")) {
        // card payment
    } else if (type.equals("UPI")) {
        // UPI payment
    } else if (type.equals("BANK")) {
        // bank payment
    }
}

You can define an abstraction:

interface PaymentMethod {
    void pay(double amount);
}

Then create implementations:

class CardPayment implements PaymentMethod {
    public void pay(double amount) {
        System.out.println("Card payment: " + amount);
    }
}

class UpiPayment implements PaymentMethod {
    public void pay(double amount) {
        System.out.println("UPI payment: " + amount);
    }
}

New payment methods can be added without turning the original code into a growing collection of conditions.

13. Liskov Substitution Principle — LSP

The Liskov Substitution Principle means that a subtype should be usable wherever its base type is expected without breaking the expected behavior.

For example:

interface Bird {
    void fly();
}

If you create:

class Sparrow implements Bird {
    public void fly() {
        System.out.println("Flying");
    }
}

it fits the abstraction.

But a penguin cannot naturally satisfy an abstraction requiring every bird to fly.

A better design might separate capabilities:

interface Bird {
}interface FlyingBird extends Bird {
    void fly();
}

Now:

class Sparrow implements FlyingBird {
    public void fly() {
        System.out.println("Flying");
    }
}

while:

class Penguin implements Bird {
}

The abstraction better matches the actual behavior.

14. Interface Segregation Principle — ISP

The Interface Segregation Principle says clients should not be forced to depend on methods they do not need.

Avoid a large interface such as:

interface Machine {
    void print();
    void scan();
    void fax();
}

A simple printer may not support scanning or faxing.

Instead, separate capabilities:

interface Printer {
    void print();
}interface Scanner {
    void scan();
}interface Fax {
    void fax();
}

A device can implement only the capabilities it actually supports.

15. Dependency Inversion Principle — DIP

The Dependency Inversion Principle encourages high-level code to depend on abstractions rather than concrete implementations.

Instead of:

class OrderService {
    private MySqlOrderRepository repository = new MySqlOrderRepository();
}

Use an interface:

interface OrderRepository {
    void save(Order order);
}

Then:

class OrderService {
    private final OrderRepository repository;
    OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

Now the service does not need to know whether the repository uses MySQL, PostgreSQL, a mock object, or another storage mechanism.

This approach also makes unit testing easier.

Java Design Patterns

A design pattern is a reusable solution structure for a common software design problem.

A pattern is not copy-and-paste code. It is a design idea that can be adapted to the application's requirements.

Common Java patterns include:

SingletonFactoryBuilderStrategyObserverAdapterDecoratorFacadeRepository

16. Factory Pattern

The Factory Pattern centralizes object creation.

Suppose an application supports different notification types:

interface Notification {
    void send(String message);
}

Implementations:

class EmailNotification implements Notification {
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

class SmsNotification implements Notification {
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

A factory can create the appropriate implementation:

class NotificationFactory {
    static Notification create(String type) {
        if (type.equalsIgnoreCase("email")) {
            return new EmailNotification();
        } if (type.equalsIgnoreCase("sms")) {
            return new SmsNotification();
        } throw new IllegalArgumentException("Unknown notification type");
    }
}

Usage:

Notification notification = NotificationFactory.create("email");
notification.send("Welcome!");

Factories are useful when object creation involves decisions or configuration.

17. Builder Pattern

The Builder Pattern is useful when an object has many optional parameters.

Without a builder:

User user = new User( "Tanmoy", "tanmoy@example.com", 35, "India", true);

It may become difficult to remember the constructor parameter order.

A builder can make object creation clearer:

User user = new User.Builder() .name("Tanmoy") .email("tanmoy@example.com") .age(35) .country("India") .active(true) .build();

The Builder Pattern is especially useful for complex configuration objects.

18. Strategy Pattern

The Strategy Pattern allows an application to select an algorithm or behavior dynamically.

For example:

interface DiscountStrategy {
    double calculate(double price);
}

One implementation:

class RegularDiscount implements DiscountStrategy {
    public double calculate(double price) {
        return price * 0.95;
    }
}

Another:

class PremiumDiscount implements DiscountStrategy {
    public double calculate(double price) {
        return price * 0.80;
    }
}

The service can receive the strategy:

class CheckoutService {
    private final DiscountStrategy strategy;
    CheckoutService(DiscountStrategy strategy) {
        this.strategy = strategy;
    } double calculatePrice(double price) {
        return strategy.calculate(price);
    }
}

This avoids large conditional blocks when behavior varies.

19. Observer Pattern

The Observer Pattern is useful when one object needs to notify multiple interested components about an event.

For example:

Order Created
↓
┌───┼─────────┐
↓

↓

↓
Email SMS    Analytics

In modern Java applications, similar ideas appear in event-driven systems and application event mechanisms.

The pattern helps reduce direct coupling between the event producer and event consumers.

20. Adapter Pattern

The Adapter Pattern allows incompatible interfaces to work together.

Imagine your application expects:

interface PaymentProcessor {
    void processPayment(double amount);
}

But an external library provides:

class LegacyPaymentApi {
    void makePayment(double amount) {
        System.out.println("Legacy payment");
    }
}

An adapter can bridge the two:

class PaymentAdapter implements PaymentProcessor {
    private final LegacyPaymentApi api;
    PaymentAdapter(LegacyPaymentApi api) {
        this.api = api;
    } public void processPayment(double amount) {
        api.makePayment(amount);
    }
}

The application can now depend on its own interface rather than spreading third-party API details throughout the code.

21. Facade Pattern

A Facade provides a simple interface over a more complicated subsystem.

Suppose placing an order requires:

InventoryPaymentShippingNotificationInvoice

Instead of exposing all these services to the caller:

class OrderFacade {
    void placeOrder(Order order) {
        // inventory
        // payment
        // shipping
        // notification
        // invoice
    }
}

The caller can simply use:

orderFacade.placeOrder(order);

Facade patterns are useful for keeping application-level workflows simple.

Java Security Best Practices

Security should be considered during development rather than added only after an application is complete.

Common security areas include input validation, authentication, authorization, password handling, secrets management, database queries, logging, dependency management, and secure communication.

22. Never Hard-Code Passwords or API Keys

Avoid:

String password = "MySecretPassword";
String apiKey = "123456789";

Secrets should normally be supplied through secure configuration mechanisms such as environment variables or a dedicated secrets-management system.

For example:

String apiKey = System.getenv("API_KEY");

The exact secret-management approach depends on the deployment environment.

23. Never Store Plaintext Passwords

Applications should not store user passwords as readable strings.

Instead, use a password-hashing algorithm designed for password storage, such as:

Argon2bcryptscryptPBKDF2

Do not use a simple hash such as:

SHA-256(password)

as a password-storage strategy by itself.

Password hashing should include an appropriate work factor and salt.

24. Validate User Input

Never assume external input is trustworthy.

Input may come from:

HTTP requestsJSONFormsFilesHeadersCookiesCommand-line argumentsThird-party APIs

Validate values before processing them.

For example:

if (username == null || username.isBlank()) {
    throw new IllegalArgumentException("Username is required");
}

Validation should also enforce expected length, format, range, and business rules where appropriate.

25. Prevent SQL Injection

Do not construct SQL queries by directly concatenating user input.

Unsafe:

String sql = "SELECT * FROM users WHERE email = '" + email + "'";

Use parameterized queries instead:

String sql = "SELECT * FROM users WHERE email = ?";
PreparedStatement statement = connection.prepareStatement(sql);
statement.setString(1, email);

Parameterized queries separate SQL structure from user-provided values.

26. Protect Sensitive Data in Logs

Avoid logging passwords, authentication tokens, API keys, session identifiers, or other secrets.

Bad:

System.out.println("Password: " + password);

Better:

System.out.println("User authentication attempted");

Production logs should contain enough information for troubleshooting without unnecessarily exposing sensitive data.

27. Use HTTPS for Sensitive Communication

Sensitive information should be transmitted over secure connections.

For web applications, HTTPS protects data while it travels between the client and server.

Java applications communicating with external services should also use properly configured TLS connections rather than sending credentials over unencrypted channels.

28. Keep Dependencies Updated

Java applications often depend on libraries for:

Database accessJSON processingLoggingHTTP clientsAuthenticationWeb frameworksFile processing

Third-party libraries can contain security vulnerabilities.

Keep dependencies updated and regularly review security advisories affecting your application's dependency versions.

Dependency management tools such as Maven and Gradle make version management easier.

29. Use Least Privilege

An application should receive only the permissions it actually needs.

For example, a database account used by an application should not automatically have unrestricted administrative privileges.

Instead:

Application↓Application DB User↓Required tables/operations

This limits the potential impact if application credentials are compromised.

30. Handle Exceptions Without Leaking Sensitive Information

Avoid exposing internal implementation details to users.

For example, do not return a full database exception directly to a web client:

SQL connection failed:jdbc:mysql://internal-server:3306/company
username=admin...

Instead, return a safe message:

Unable to complete the request. Please try again later.

Detailed diagnostic information can be logged securely on the server.

31. Use try-with-resources

Resources such as files, streams, and JDBC objects should be closed reliably.

Prefer:

try(BufferedReader reader = Files.newBufferedReader(path)) {
    String line = reader.readLine();
}

The resource is automatically closed when the block finishes.

This reduces resource leaks and makes cleanup easier to reason about.

32. Avoid Unnecessary Mutable State

Mutable shared state can make applications harder to reason about, especially in concurrent programs.

Instead of exposing mutable collections:

public List<String> getUsers() {
    return users;
}

consider returning an unmodifiable view or a suitable immutable result when the API contract allows it:

public List<String> getUsers() {
    return List.copyOf(users);
}

The right choice depends on whether callers need to modify the returned collection.

33. Use Dependency Injection

Dependency injection means providing dependencies to an object rather than having the object create them internally.

Avoid:

class UserService {
    private final EmailService emailService = new EmailService();
}

Prefer:

class UserService {
    private final EmailService emailService;
    UserService(EmailService emailService) {
        this.emailService = emailService;
    }
}

Now the dependency can be replaced easily during testing.

For example:

EmailService fakeEmailService = new FakeEmailService();
UserService service = new UserService(fakeEmailService);

Frameworks such as Spring provide dependency injection containers, but the underlying design principle does not require a framework.

34. Write Testable Code

Good design makes testing easier.

Instead of combining many responsibilities:

class OrderService {
    // database
    // payment
    // email
    // calculations
}

separate dependencies:

class OrderService {
    private final OrderRepository repository;
    private final PaymentService paymentService;
    OrderService( OrderRepository repository, PaymentService paymentService) {
        this.repository = repository;
        this.paymentService = paymentService;
    }
}

Dependencies can then be replaced with test doubles during unit tests.

35. Prefer Composition Over Inheritance When Appropriate

Inheritance creates a strong relationship between parent and child classes.

Sometimes composition is more flexible.

Inheritance:

class Car extends Vehicle {
}

Composition:

class Car {
    private final Engine engine;
    Car(Engine engine) {
        this.engine = engine;
    }
}

Composition allows behavior to be assembled from components without creating deep inheritance hierarchies.

Inheritance is still useful when the subtype genuinely satisfies the abstraction and substitution relationship.

36. Avoid Premature Optimization

Do not make code complicated simply because you expect it might be faster.

Start with:

Correctness↓Clarity↓Maintainability↓Measure performance↓Optimize the real bottleneck

Use profiling and measurements when performance actually matters.

An unnecessarily complicated optimization can make future maintenance harder.

37. Use Appropriate Collections

Choose collections according to the problem.

Do not choose a collection simply because it is familiar. Consider ordering, lookup behavior, concurrency, memory usage, and API requirements.

38. Prefer Modern Java APIs

Modern Java provides APIs that can make code clearer.

For example, instead of manually concatenating complex strings:

String message = "Hello " + name + ", your order is " + orderId;

Java text blocks can be useful for multiline text:

String json = """
        {
          "name": "Tanmoy",
          "active": true
        }
        """;

Likewise, java.time should generally be preferred over the older date/time APIs for new development.

39. Use Streams When They Improve Clarity

Streams are useful for clear data-processing pipelines.

For example:

List<String> activeUsers = users.stream() .filter(User::isActive) .map(User::getName) .toList();

This expresses:

Users↓Keep active users↓Get their names↓Create a list

However, streams are not automatically better than loops. A traditional loop may be clearer when the logic contains complex state changes or control flow.

40. Do Not Use Design Patterns Everywhere

Design patterns solve recurring design problems.

They should not be added simply to make code look sophisticated.

For example, creating five classes and three interfaces just to implement a simple operation can make the application harder to understand.

A useful rule is:

Use a pattern when it makes the design clearer or solves a real recurring problem.

Not:

Use a pattern because the pattern exists.

Clean Code Review Checklist

Before considering a Java class complete, ask:

✓ Are class and method names meaningful?✓ Does each class have a focused responsibility?✓ Are methods reasonably small?✓ Is duplicated logic minimized?✓ Are magic numbers replaced with meaningful constants?✓ Are exceptions handled appropriately?✓ Are mutable objects protected where necessary?✓ Are dependencies easy to replace during testing?✓ Are interfaces used where they provide flexibility?✓ Is the chosen collection appropriate?✓ Are resources closed correctly?✓ Are secrets kept out of source code?✓ Is user input validated?✓ Are database queries parameterized?✓ Are sensitive values excluded from logs?✓ Are dependencies regularly updated?

SOLID Quick Reference

Design Patterns Quick Reference

Security Quick Reference

A secure Java application should generally:

Validate external input↓Use parameterized database queries↓Hash passwords securely↓Protect API keys and secrets↓Use HTTPS/TLS↓Avoid sensitive logging↓Apply least privilege↓Keep dependencies updated↓Handle errors safely↓Test security-sensitive functionality

Security is not one feature. It is a collection of practices applied throughout the application lifecycle.

Practical Example: Combining Good Practices

Consider a payment service.

Instead of putting everything inside one large class:

class PaymentService {
    void process(String type, double amount) {
        if (type.equals("CARD")) {
            // payment
        } // database
        // email
        // logging
        // validation
        // error handling
    }
}

A cleaner design can separate responsibilities:

interface PaymentProcessor {
    void process(double amount);
}

Implementation:

class CardPaymentProcessor implements PaymentProcessor {
    @Override public void process(double amount) {
        System.out.println("Processing card payment: " + amount);
    }
}

Service:

class PaymentService {
    private final PaymentProcessor processor;
    PaymentService(PaymentProcessor processor) {
        this.processor = processor;
    } void processPayment(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException( "Amount must be positive");
        } processor.process(amount);
    }
}

Usage:

PaymentProcessor processor = new CardPaymentProcessor();
PaymentService service = new PaymentService(processor);
service.processPayment(1000);

This small example demonstrates several good practices:

Interface↓Dependency Injection↓Focused Responsibility↓Input Validation↓Testable Design

It also creates a foundation for adding other payment implementations without making the service responsible for every payment detail.

Common Java Best-Practice Mistakes

Mistake 1: One Giant Class

Putting database access, business logic, HTTP handling, email, and reporting into one class creates strong coupling.

Separate responsibilities according to the application's actual boundaries.

Mistake 2: Excessive Inheritance

Deep inheritance hierarchies can make behavior difficult to follow.

Use inheritance when the relationship is genuinely appropriate; otherwise consider composition.

Mistake 3: Catching Every Exception

Avoid:

try {
    // code
} catch (Exception e) {
    // ignore
}

Ignoring failures can hide serious problems.

Catch exceptions when you can actually handle them, or propagate them appropriately.

Mistake 4: Logging Secrets

Never use logs as a dumping ground for passwords, tokens, or private credentials.

Mistake 5: Hard-Coded Configuration

Database passwords, API keys, environment-specific URLs, and other secrets should not normally be embedded directly in source code.

Mistake 6: Overengineering

Not every small problem requires a factory, strategy, abstract factory, event bus, and five interfaces.

Start with a simple design and introduce abstractions when they provide a real benefit.

Best Practices for Java Interviews

Common interview questions include:

What is SOLID in Java?

SOLID is a set of five object-oriented design principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

What is a design pattern?

A design pattern is a reusable design approach for a recurring software design problem.

What is dependency injection?

Dependency injection means providing an object's dependencies from outside rather than having the object create those dependencies itself.

Why use interfaces?

Interfaces define contracts and allow implementations to vary without forcing callers to depend on concrete classes.

What is the difference between composition and inheritance?

Inheritance creates an "is-a" relationship, while composition generally creates a "has-a" relationship by assembling objects from other components.

How can Java applications prevent SQL injection?

Use parameterized queries or prepared statements instead of concatenating untrusted input into SQL statements.

Should passwords be encrypted?

Passwords should generally be stored using a password-hashing algorithm designed for password storage rather than reversible encryption.

Frequently Asked Questions

What are the most important Java best practices?

Start with readable naming, focused classes and methods, appropriate exception handling, low duplication, proper collection choices, testable design, secure input handling, and safe dependency management.

Is SOLID mandatory in every Java application?

No. SOLID provides design guidance rather than a checklist that must be applied mechanically. The appropriate level of abstraction depends on the application's complexity.

Are design patterns always better than simple code?

No. A design pattern is useful when it solves a real design problem. Unnecessary patterns can increase complexity.

Which design pattern should Java developers learn first?

Factory, Builder, Strategy, Adapter, Observer, and Facade are useful patterns to understand because they appear in many different application designs.

Is dependency injection only available in Spring?

No. Dependency injection is a design technique. You can perform it manually through constructors, methods, or other mechanisms. Frameworks such as Spring automate dependency management.

How can Java code be made more secure?

Validate external input, use parameterized queries, protect credentials, hash passwords securely, use TLS, restrict permissions, avoid sensitive logging, and keep dependencies updated.

Should every method have comments?

No. Clear code often needs fewer comments. Comments are most valuable when they explain intent, constraints, or non-obvious decisions.

Is clean code the same as short code?

No. Clean code is not necessarily the shortest code. It is code whose structure and behavior are understandable and maintainable.

Suggested Page Graphics and Design Ideas

Graphic 1 — Java Best Practices Overview

Create a clean infographic:

              JAVA BEST PRACTICES
                       │
       ┌───────────────┼───────────────┐
↓

↓

↓
CLEAN CODE        SOLID          SECURITY
       │               │               │
 Naming           SRP/OCP/LSP      Input Validation
 Small Methods    ISP/DIP          Password Hashing
 DRY              Interfaces       SQL Protection
 Testing          Abstraction      Secret Management

Graphic 2 — SOLID Principles

Use five connected cards:

S → Single ResponsibilityO → Open / ClosedL → Liskov SubstitutionI → Interface SegregationD → Dependency Inversion

Graphic 3 — Design Pattern Map

Show:

Object Creation
 ├── Factory
 └── Builder

Behavior
 ├── Strategy
 └── Observer

Structure
 ├── Adapter
 └── Facade

Graphic 4 — Secure Java Application

Illustrate:

User Input↓Validation↓Business Logic↓Parameterized Query↓Database

With a security layer around the complete application.