Just gone through few articles on SOLID principles and i got a little understanding of them. But in all of the cases i have never seen the proper examples to demonstrate. Everyone is taking an example of a random class. For better understanding, i am trying to understand from Java in-built API perspective. e.g. Open close principle states that the classes/components are open for extensions but closed for modifications, now the good example for this is - Functional interfaces. Similarly i am looking for more examples on all SOLID principles from within java in-built API.
Hope you understood my concern. Suppose you want to explain this SOLID principles to batch of 10-12 people in your office or what if you are preparing for an interview, you should have some good examples to convey the material in right direction. If for explaining each principle, i need to take a new random class in to picture , then the audience may not get convinced and may lead to confusion. It would be better if I explain each SOLID principle by taking an example from java in-build API then it would be easier for them to understand and they can think of random class examples on their own. Hope you got the concern..!!
First, let me point out that I could very well be wrong with my reply/this post or some parts of it at least.
Let's all get on the same page, shall we:
S ingle Responsibility Principle
a class should have only a single responsibility (i.e. changes to only one part of the software's specification should be able to affect the specification of the class).
"software entities … should be open for extension, but closed for modification."
L iskov substitution
"objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program."
I nterface segregation
"many client-specific interfaces are better than one general-purpose interface."
D ependency inversion
one should "depend upon abstractions, [not] concretions."
A.K.A. SOLID, you can read more about this here https://www.composablesystems.com/solid-principles-make-code-flexible/ and Wikipedia.
For Open/closed, perhaps the use of the Map interface is a good example
https://docs.oracle.com/javase/9/docs/api/java/util/Map.html All the classes that use that interface could be swapped out for a different class that use that interface.
You cannot change base interface, but you can add to it the classes that use it if you choose to
The way I think about dependency inversion is that it's more about whether your code is hardcoded against a concrete dependency (like a specific model of printer or a specific file system), or if it instead inverts this relationship and becomes itself dependent on an abstraction of the concrete dependency. That sounds kind of confusing so think of it this way: you send a daily email with the day's total sales. So you write code that does a lot of stuff against "EmailSystem" and the code is completely dependent on email. Next, the boss decides she wants to get the day's sales total text message summary each day instead. What do you do? Copy/paste the code and find/replace "EmailSystem" with "SmsSystem"?
You instead make the code depend on an abstraction like "MessageSystem" and you supply a concrete implementation for each instance. The code is more resilient to change now, and when the boss decides now she wants to get it via a REST API call to her Internet-of-Things appliance in her house, you've got it covered.
So I'd look at things like InputStream or Writer as Java library interfaces that facilitate dependency inversion.