The best way for learning any design principle or pattern is regarded as a real-world example and the knowledge of knowing the violation consequences of design principle which is mentioned in the article Introducing Object-oriented design principles for Java developers.
DRY (Do not repeat yourself) :
DRY is regarded as our first object-oriented design principle as the name offers DRY (don’t repeat yourself) implies don’t write duplicate code rather than usage of Abstraction for abstracting common things at a single place. If you are not aware of a block of code in something greater than two places make it an isolated method or using a hard-coded value more than a single time public final constant.
The advantage of this Object Oriented design principle is in maintenance and it is not that significant not with any duplication which is not in code but for functionality. It implies that if it is used for a common code for validating order ID and SSN and it does not imply that they are the same or will be the same in the future.
Read More : What Is So Special Object Oriented Programming?
Encapsulate the Changes :
The only thing that is the same is constant in software field and Change is evident and therefore you need to encapsulate the code you suspect or expect for changes in the future. OOP Design principle has an advantage which makes it simple for testing and handling proper covered code.
Open Closed Design Principle :
Functions, methods, or classes must be Open for extension and Close for modification and it is another wonderful SOLID design principle, which avoids few people from changing the pre-tried and tested code. If new functionalities are included by you than your code must be tested and that is the end point of Open Closed Design principle.
Read More : Explain The OOPs Concept In Java
Single Responsibility Principle (SRP) :
There is another SOLID Design principle called as Single Responsibility Principle and exhibits S on the SOLID acronym. Similar to SRP there will not be more than a single reason for a class to change or a class must always look after single functionality.
If more than one function is put by you in Java then it unveils coupling among two functionality and even if you get rid of one functionality then there is a risk you broke coupled functionality which needs another round of testing for ignoring any surprise on the environment production.
Dependency Injection or Inversion Principle :
Enquiry about dependency will be offered to you by the framework and this has been excellently implemented in Spring framework and the beauty of this design principle of any class is injected with the help of DI framework and it simple to test with the mock object and simpler to maintain as the object creation code is centralized in the framework and client code is not littered inside that.
There are lots of ways for implementing the Dependency injection similar to bytecode usage instrumentation which few some AOP framework similar to AspectJ does with the help of proxies like Spring.
Favor Composition over Inheritance :
If things are feasible and favorable then over inheritance, compositions can be favored and few of them may argue this which is more flexible when compared to Inheritance.
Changing behavior of a class is permitted by composition at run-time by establishing property during run-time and by simple interfaces for composing a class we use polymorphism which offers flexibility for replacing with good implementation any time.
Read More : Java Vs C++ : An In Detailed Comparison
Liskov Substitution Principle (LSP) :
As per Liskov Substitution Principle, there must be a good amount of substitutable for supertype that is methods or functions which utilizes superclass type for an ability to work with the object of a subclass and there is no issue about it.
LSP is very much closely associated with Single responsibility principle and Interface Segregation Principle. If a class has lots of functionality than subclass will not be able to assist few of the functionality and it does not violate LSP.
Reference site: Javarevisited