I'll never forget the day I accidentally exposed user passwords in my API responses. I returned the entire User entity from a GET endpoint, thinking "Spring Boot will handle it!" Spoiler alert: It returned EVERYTHING—including hashed passwords, internal IDs, and timestamps. My code reviewer nearly had a heart attack. 😱 That's when I learned about DTOs. Let me save you from this nightmare.
"Why make something private? Just make everything public. If the coder knows which method to call, they call it. Problem solved, right?" That was me a week ago. I was so wrong. Here's my journey from "public/private is just fancy nonsense" to "holy crap, this actually makes sense!" 🤯
"Why create InvalidCredentialsException extending RuntimeException? Isn't it just to get a descriptive name instead of generic RuntimeException?" No! The name is only a small part. The real power is type-safe error handling - allowing Spring to distinguish between different errors and handle them differently without string parsing. Let's see why custom exceptions are essential, not just fancy naming.
"But don't we still have if-else statements with interfaces?" Yes! But here's the critical difference: scattered if-else in 10 files vs centralized if-else in 1 factory vs zero if-else with registry pattern. Let's see the evolution.
"Interfaces are for frameworks, right?" Wrong! While frameworks love interfaces, they're solving a much broader problem. Here are 7 real-world scenarios where YOU will use interfaces—no framework required.
"Why do we need both generateToken() (public) and createToken() (private) instead of just one method?" Because separation of concerns makes your code extensible. The public method handles what claims to add (business logic), while the private method handles how to build the JWT (technical details). This lets you add new token types without repeating code. Let's understand why this design pattern is essential.
In Parts 1 and 2, we learned what interfaces are and when to use them. Now let's dive deep into the OOP principles that make interfaces essential for large-scale applications. This isn't about avoiding code duplication—it's about fundamental software design.
"Can't we just create a utility class with static methods instead of using interfaces? Isn't the interface approach just fancy?" Great question! Yes, you could use utility classes - but you'd be solving only 50% of the problem. Let's see what happens in practice and why interfaces aren't fancy, they're necessary.