Standard Design Principles


  1. DRY (Don’t Repeat Yourself)

DRY stands for “don’t repeat yourself” meaning don’t write duplicate code but instead abstract common blocks of code that is used by different functions or classes into one place.

This can be variables, methods, or classes. If you hard code a variable in more than one place, abstract it to a public final constant variable. If you are using a same logic in more than one place, abstract it to a method. The same thing can be done for classes.

DRY Advantages

  • Maintainability – easy to maintain.When you need to update your code later, you will only need to make changes to your code in one place.
  • Readability – less code often translates to less noise and confusion. You can follow the code more easily.
  • Flexibility – with one place to make changes, you can make changes and be confident that
  • Easy to test – only one place to test
  • Cost efficiency – It saves time and spaces. Time to debug and test. spaces on server’s RAM.

DRY Disadvantages

  • It might take time in the beginning to plan where things are supposed to go.

What not to do
* Don’t combine anything which uses similar code but not related. In other words don’t create a common variable or method for two different functionalities or things. For example a method that validates a bank account is also used to validate social security numbers. Down the road you might change this method because a bank account is different but that might cause social security number validation to crash.

2. Encapsulation

Encapsulate code that is expected to change in the future.

To encapsulate your code make your variables private and provide getters and setters to access and change them.

3. Open Closed Design Principle

Methods and classes should be open for extension when adding a new functionality and closed for modification.

This prevents developers from modifying already tested and working code which lessens the chance of breaking the existing code.

Changes are required when new functionality is added or existing functionality is updated. Often in both situations you will need to modify the existing code. You should avoid changing the existing code when requirements change. Instead you should extend the existing functionality by adding new code to meet the new requirements.

Use polymorphism and inheritance to extend the existing behavior. Use interface and abstract classes/methods to accomplish this.

Let’s say we a accounting system where we need to validate payment methods before adding or updating them.

public interface PaymentMethodValidator{
   public boolean validate();

public class CardValidator implements PaymentMethodValidator{
   public boolean validate(){
      // validate card payment method

public class BankAccountValidator implements PaymentMethodValidator{
   public boolean validate(){
      // validate bank payment method

// if you need to add more payment method validator like one for Apple pay then just implement PaymentMethodValidator

4. Single Responsibility Principle

A method or class should only have a single functionality which reduces coupling of different components. One reason for a class to change. Methods related to the same concern should be in one class.

A robust system is one that can handle these unwanted situations elegantly. There are various ways for a software engineer to achieve robustness, such as testing the code for different kinds of inputs, but generally, in order to achieve robustness (and high cohesion), programmers follow a certain set of rules and principles for better organization of object-oriented programs. One such principle is the single responsibility principle

If you put more than one functionality in a class. There is a chance you will break the existing functionality if you make changes to one of the functionality.

A typical violation of the single responsibility principle I often see in legacy Spring applications is an abundance of code in controller actions. I’ve seen Spring controllers getting JDBC connections to make calls to the database. This is a clear violation of the single responsibility principle. Controller objects have no business interacting with the database. Nor do controllers have any business implementing other business logic. In practice your controller methods should be very simple and light. Database calls and other business logic belong in a service layer

5. Dependency Inversion Principle

The beauty of this design principle is that any class which is injected by DI framework is easy to test with the mock object and easier to maintain because object creation code is centralized in the framework and client code is not littered with that.

Creating an object with the new operator makes it tightly coupled to another class.

  • A high level module should not dependent on low level modules. Both should dependent on abstractions.
  • Abstraction should not dependent on details. Details should dependent on abstraction.

6. Composition over Inheritance

Composition is more flexible in terms of what you want to do. With inheritance you might have to implement all methods from the super class. But with Composition you can have a type and then decide at run time whether you want to use it or not.

Another advantage of Composition is that you can have multiple types in one class but with inheritance you can only inherit one class.

Composition is easier to test because you can mock types.

7. Liskov Substitution Principle

Sub-types must be able to substitute in for super-types. If a super sub-type has more methods or functionality then there is a problem there.

8. Interface Segregation Principle

Interfaces with one method.

9. Programming for interface not implementation

You should use interface types for variables, method return types, or method parameters instead of subclass.

So instead of using ArrayList, use List.

10. Delegation Principle

Don’t do everything yourself. Use a dedicated class.

Subscribe To Our Newsletter
You will receive our latest post and tutorial.
Thank you for subscribing!


Leave a Reply

Your email address will not be published. Required fields are marked *