OOPS Design Principles In Java

The object-oriented design principles are a significant piece of the OOP programming. However, we have seen the vast majority of a Java developers pursuing plan designs like the singleton design, decorator example, or observer design, and not putting the consideration on learning object-arranged examination and structure. It's essential to learn basics of object-oriented programming like abstraction, encapsulation, polymorphism, and inheritance. But, at the same time, it's equally important to know object-oriented design principles in Java application development. They will help you to create a clean and modular design, which would be easy to test, debug, and maintain in the future. Here are important object-oriented design principles and putting them here for a quick reference. These will, at least, give you the idea about what they are and what benefits they offer.

1. DRY (Don't repeat yourself)

Our first object-oriented design principle is the DRY, as the name suggests the DRY (don't repeat yourself) that means don't write duplicate code, instead of that, use abstraction to abstract common things in the one place. If you have the square of code in multiple spots, consider making it the different strategy, or on the off chance that you utilize the hard-coded esteem more than one time, make that the public final constant. The result of this Object-oriented design principle is in support. It's significant not to manhandle it, duplication isn't for code, yet usefulness. It means if you used standard code to validate OrderID and SSN, it doesn’t mean they are the same, or they will remain the same in the future.

2. Encapsulate What Changes

If you have the block of code in more than two places, consider making it the separate method, or if you use the hard-coded value more than one time only one thing is steady in the product field, and that is "Change," So typify the code you expect or suspect to be changed later on. The advantage of this OOP Design rule is that It's anything but difficult to test and keep up legitimate embodied code. If you are coding in Java, then follow the principle of making variables and methods private by default and increasing access step by step, for example, from the private method to protected and not public. Several of the design patterns in Java uses the Encapsulation, the Factory design pattern is one example of Encapsulation which encapsulates the object creation code and provides flexibility to the introduce a new product later with no impact on existing code.

3. Open Closed Design Principle

The classes, methods, or functions should be the Open for extension (new functionality) and the Closed for modification. This is another delightful SOLID plan rule, which keeps somebody from changing previously attempted and tried the code. Ideally, if you are adding the new functionality only, then your code should be tested, and that's the goal of the Open Closed Design principle. Incidentally, the Open-Closed guideline is "O" from the SOLID abbreviation.

4. Single Responsibility Principle (SRP)

Single Responsibility Principle is another SOLID design principle and represents "S" on the SOLID acronym. As per the SRP, there should not be more than one reason for a class to change, or the class should always handle single functionality. On the off chance that you put more than the one usefulness in one Class in Java, it presents the coupling between two usefulness, and regardless of whether you change one element, there is the opportunity you broke coupled usefulness, which requires another round of the testing to avoid any surprise on the production environment.

5. Dependency Injection or Inversion principle

Don't ask for the dependency; it will be provided to you by a framework. This has been very well implemented in the Spring framework, beauty of this design principle is that any class which is injected by the DI framework is easy to test with a mock object and more comfortable to maintain because the object creation code is centralized in the framework and client code is not littered with that. There are multiple ways to implemented Dependency injection like using the bytecode instrumentation, which some AOP (Aspect Oriented Programming) framework like AspectJ does or by using the proxies just like used in the Spring. 

6. Favor Composition over Inheritance

Always favor the composition over the inheritance, if possible. Some of you may contend this, yet I found that the Composition is parcel more adaptable than the Inheritance. Composition allows changing the behavior of the class at run-time by setting property during run-time, and by using Interfaces to compose the class, we use polymorphism, which provides the flexibility to replace with the better implementation at any time.

7. Liskov Substitution Principle (LSP)

As per a Liskov Substitution Principle, Subtypes must be substitutable for supertype, that is methods or functions which use the superclass type must be able to work with the object of subclass without any issue". The LSP is closely related to a Single responsibility principle and the Interface Segregation Principle. If the class has greater usefulness, than a subclass probably won't bolster a portion of usefulness and violates LSP.

8. Interface Segregation Principle (ISP)

Interface Segregation Principle says that the client should not implement the interface if it doesn't use that. This happens generally when the one interface contains more than the one usefulness, and a customer just needs the one usefulness and no other. Interface design is the tricky job since once you discharge the interface, you can not transform it without breaking all implementation. Another advantage of this structure rule in Java is, the interface has a disadvantage of implementing all methods before any class can use it, so having single functionality means less method to the implement.

9. Delegation principles

Don't do all the stuff by yourself, delegate it to a respective class. A classical example of delegation design principle is the equals() and hashCode() method in Java. To analyze the objects for equality, we ask a class itself to make the correlation rather than a Client class doing that check. The key benefit of this design principle is the no duplication of the code and pretty easy to modify the behavior. Event delegation is another example of this principle, where an event is delegated to handlers for the handling.