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. 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 😊). "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 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 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. "Software entities should be open for extension, but closed for modification." ❌ Bad Example: The Infinite If-Else @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 public interface AuthStrategy { boolean supports(HttpServletRequest request); Authentication authenticate(HttpServletRequest request); } @Component public class AuthenticationFilter extends OncePerRequestFilter { @Autowired private List 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! "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. "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 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 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 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! "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 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 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 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! 🚀