SOLID Principles Explained in a Solid Way

Hello friend,

If you have read hundreds of articles and even watched a lot of videos but still confused about SOLID. Help me help you. You are in safe hands.

What are SOLID principles

SOLID principles help write maintainable, testable code. These principles were initially pointed out by Robert C. Martin a.k.a. "Uncle Bob". If you have not watched his lectures, I would highly suggest to go on YouTube and watch, those are pure fun and knowledge.

Now let's go over each of these principles. I will try to write examples that are more real in terms of software usage (no more Bike extending Vehicle class, no offense to anyone 😊).

---

Single Responsibility Principle

"A class should have one, and only one, reason to change."

❌ Bad Example: The "Do-It-All" Controller

This Spring controller handles HTTP routing, manual SQL execution, external API payments, and email alerts. If your database schema or your email provider changes, this class breaks.

@RestController
public class OrderController {
    @PostMapping("/orders")
    public ResponseEntity<String> createOrder(@RequestBody OrderRequest request) {
        // 1. Validation
        if (request.getItems().isEmpty()) return ResponseEntity.badRequest().body("No items");

        // 2. Direct Database Connection & SQL
        Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/db");

        // 3. Third-party Payment API HTTP call
        HttpClient.newHttpClient().send(paymentRequest, HttpResponse.BodyHandlers.ofString());

        // 4. Email Notification
        Transport.send(emailMessage);

        return ResponseEntity.ok("Order Processed");
    }
}

✅ Good Example: Layered Architecture

@RestController
public class OrderController {
    @Autowired private OrderService orderService;

    @PostMapping("/orders")
    public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
        return ResponseEntity.ok(orderService.processOrder(request));
    }
}

@Service
public class OrderService {
    @Autowired private PaymentProcessor paymentProcessor;
    @Autowired private OrderRepository orderRepository;
    @Autowired private NotificationService notificationService;

    @Transactional
    public Order processOrder(OrderRequest request) {
        paymentProcessor.charge(request.getAmount());
        Order order = orderRepository.save(Order.from(request));
        notificationService.sendConfirmation(order);
        return order;
    }
}

Now the controller handles response handling, business logic is offloaded to service class. Even in service class the database configuration is delegated to repository classes.

---

Open/Closed Principle

"Software entities should be open for extension, but closed for modification."

❌ Bad Example: The Infinite If-Else
Every time your security team introduces a new auth method (like OAuth or WebAuthn), you have to modify this core security filter, risking breaking changes to existing auth flows.

@Component
public class AuthenticationFilter extends OncePerRequestFilter {
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response) {
        String authType = request.getHeader("X-Auth-Type");

        if ("JWT".equals(authType)) {
            // Complex JWT Validation logic...
        } else if ("API_KEY".equals(authType)) {
            // Complex Database API Key validation...
        } else if ("BASIC".equals(authType)) {
            // Basic Auth logic...
        }
    }
}

✅ Good Example: The Strategy Pattern
By abstracting authentication into a strategy interface, Spring automatically injects all implementations. Adding a new auth method means writing a new class, completely leaving the filter untouched.

public interface AuthStrategy {
    boolean supports(HttpServletRequest request);
    Authentication authenticate(HttpServletRequest request);
}

@Component
public class AuthenticationFilter extends OncePerRequestFilter {
    @Autowired private List<AuthStrategy> strategies; // Automatically injected by Spring

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response) {
        strategies.stream()
            .filter(s -> s.supports(request))
            .findFirst()
            .ifPresent(s -> SecurityContextHolder.getContext().setAuthentication(s.authenticate(request)));
    }
}

// To add OAuth, just create this class. The Filter remains untouched!
@Component
public class OAuthStrategy implements AuthStrategy { ... }

Spring automatically injects all AuthStrategy beans into the filter. Add a new auth method? Just create a new @Component that implements the interface. The filter never changes!

---

Liskov Substitution Principle

"Subclasses must be substitutable for their superclasses without breaking the application."

❌ Bad Example: Shoving Incompatible Behavior into a Subclass

ReadOnlyStorage inherits from FileStorage but throws unexpected runtime crashes when a consumer tries to use a perfectly valid parent method (write).

public class FileStorage {
    public byte[] read(String path) { return Files.readAllBytes(Paths.get(path)); }
    public void write(String path, byte[] data) { Files.write(Paths.get(path), data); }
}

public class ReadOnlyStorage extends FileStorage {
    @Override
    public void write(String path, byte[] data) {
        // ⚠️ CRASH! Violates LSP because it breaks the expected behavior of the base class
        throw new UnsupportedOperationException("Cannot write to a read-only bucket!"); 
    }
}

✅ Good Example: Splitting Contracts

Segregate capabilities into a clear hierarchy so that the type system prevents consumers from attempting invalid actions.

public interface ReadableStorage {
    byte[] read(String path);
}

public interface WritableStorage extends ReadableStorage {
    void write(String path, byte[] data);
}

// Implements both read and write
public class S3Storage implements WritableStorage { ... }

// Only implements read, perfectly honoring its type contract
public class ReadOnlyBackupStorage implements ReadableStorage { ... }

Now ReadOnlyStorage doesn't pretend to be something it's not. The type system prevents misuse.

---

Interface Segregation Principle

"Clients should not be forced to depend on interfaces they don't use."

❌ Bad Example: Fat interface:

A read-only public document viewer widget is forced to provide empty implementations or throw boilerplate exceptions for admin features it shouldn't even know exist.

public interface DocumentService {
    Document getDoc(String id);
    void deleteDoc(String id);
    byte[] exportToPdf(String id);
    List<AuditLog> getAuditTrail(String id);
}

public class PublicDocumentViewer implements DocumentService {
    @Override
    public Document getDoc(String id) { return database.find(id); }

    // Forced to implement methods it doesn't need just to compile
    @Override public void deleteDoc(String id) { throw new UnsupportedOperationException(); }
    @Override public byte[] exportToPdf(String id) { throw new UnsupportedOperationException(); }
    @Override public List<AuditLog> getAuditTrail(String id) { return Collections.emptyList(); }
}

✅ Good Example: Role-Based Micro-Interfaces

Break the large interface into focused capabilities. Clients can pick and choose only what they actually require.

public interface DocumentReader { Document getDoc(String id); }
public interface DocumentExporter { byte[] exportToPdf(String id); }
public interface DocumentAuditor  { List<AuditLog> getAuditTrail(String id); }

// The viewer widget remains simple, clean, and safe
public class PublicDocumentViewer implements DocumentReader {
    @Override
    public Document getDoc(String id) { return database.find(id); }
}

// The admin panel implements multiple interfaces as needed
public class AdminDocumentManager implements DocumentReader, DocumentExporter, DocumentAuditor {
    // Implements all required methods cleanly
}

Each class now depends only on the interfaces it actually uses!

---

Dependency Inversion Principle

"Depend on abstractions, not concretions."

❌ Bad Example: Hardcoded Concrete Implementations

The high-level NotificationService is tightly coupled to a concrete TwilioSmsClient. If you want to switch to AWS SNS or mock the SMS client for local unit testing, you are forced to rewrite this core service class.

import com.yourcompany.clients.TwilioSmsClient; // Concrete import

public class NotificationService {
    private TwilioSmsClient smsClient = new TwilioSmsClient(); // Hardcoded dependency

    public void sendAlert(String userId, String message) {
        smsClient.send(userId, message);
    }
}

✅ Good Example: Injecting Abstractions

NotificationService depends entirely on an interface. It does not know or care who is sending the message under the hood, making it decoupled and testable.

public interface MessageSender {
    void send(String target, String body);
}

@Service
public class NotificationService {
    private final MessageSender messageSender;

    // Spring injects the interface bean automatically via the constructor
    public NotificationService(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

    public void sendAlert(String userId, String message) {
        messageSender.send(userId, message);
    }
}

// The concrete implementation Spring will inject
@Component
public class TwilioSender implements MessageSender {
    @Override
    public void send(String target, String body) {
        twilioClient.messages.create(target, body);
    }
}

// Swapping to SNS later? Just create this — NotificationService is untouched
@Component
public class AwsSnsSender implements MessageSender {
    @Override
    public void send(String target, String body) {
        snsClient.publish(target, body);
    }
}

Now NotificationService doesn't know or care about concrete implementations. You can:

• Add new channels without modifying NotificationService
• Mock channels easily for testing
• Swap implementations at runtime
• Configure channels via dependency injection

Key Takeaways

Principle	In one line
Single Responsibility	One class, one job
Open/Closed	Add new features without disrupting old ones
Liskov Substitution	Subclasses should work anywhere the parent class works. Don't break contracts
Interface Segregation	Many small, focused interfaces beat one large interface
Dependency Inversion	Depend on interfaces, not concrete classes. Use dependency injection

Why SOLID Matters

Following SOLID principles leads to:

• Testable code: Easy to mock dependencies
• Maintainable code: Changes are localized
• Flexible code: Easy to extend without breaking existing functionality
• Readable code: Clear responsibilities and dependencies

SideNote

All these rules are like trade offs. In software engineering rules are not strict but more dependent on specific trade offs for the task at hand.

E.g. Adding interfaces that have only single implementations, just for flexibility in future, I can skip it if I'm sure I won't be adding new implementations in near future. Premature optimization is evil.

Remember: SOLID isn't about being dogmatic. It's about writing code that's easier to change when requirements inevitably evolve. Start applying these principles gradually, and you'll see the benefits compound over time.

Happy coding! 🚀