We all learn programming by making mistakes and learning from all the erroneous code that we develop. There will be situations where you may have faced a particular problem multiple times. Now, we have a clear approach on how to address the issue. A design pattern is designed, implemented, and verified industry wide.

Design patterns not only bring standardization to your code, but also ensure that your code follows good programming principles, such as coupling and cohesion.

Coupling measures the dependency of software components on each other. So, in essence, this is how two components interact with each other and pass information. High coupling leads to complex code. Practically, components need to communicate with each other, so dependency cannot be entirely removed. It also indicates the robustness of the code, that is, the impact it has on a component if any related component is modified. Hence, low coupling indicates a good code structure. Just imagine that you have a controller that calls a service class, which further calls another controller. So, effectively, the first controller is indirectly dependent on the second controller. With high coupling: 

Cohesion measures the degree to which a code component has been well built and focused. As per object-oriented design principle, encapsulation, all the related data and functionalities should be encapsulated in the same program component (for example, a class). It ensures that all related functionalities are present in one place and controls their accessibility. This enhances the robustness of the code and imparts modularity to the final product. Lower code cohesion indicates lower dependency of modules/classes, that is, higher maintainability, less complexity, and lesser impact on the part of change.

In short, high cohesion is better for you and indicates that a class is doing a well-defined job. Low cohesion means that a class is doing many jobs with little in common between jobs.

The following code snippet is an example of high cohesion: 

class AccountService{ 
 
  public Account createAccount(){ 
  // business logic 
  } 
 
  public Opportunity createOpportunity(){ 
  // business logic 
  } 
 
  public Contact createContact(){ 
  // business logic 
  } 
} 

In the preceding code snippet, notice that the AccountService class tends to be a jack of all trades, that is, it tries to solve multiple objectives. This leads to further confusion between method calls and makes maintenance tedious.

The following code snippet is an example of low cohesion: 

class AccountService{ 
 
  public Account createAccount(){ 
  // business logic 
  } 
} 
 
class OpportunityService 
    
  public Opportunity createOpportunity(){ 
  // business logic 
  } 
} 
 
class ContactService 
    
  public Contact createContact(){ 
  // business logic 
  } 
} 

The following diagram shows how we converted low cohesion to high cohesion.

Another advantage of using design patterns is that if testers know that a specific design pattern is used in an implementation, they can quickly relate to it. According to their past experience with design patterns, they can easily identify possible failure scenarios.

Next in the list of advantages is communication and support. Design patterns are well-known in the developer community and forums. Also, they can be easily discussed with your technical lead, project manager, test lead, or architects. When someone new joins your development team, usage of design patterns can help describe the code base to the new team member and aid in a developer's ramp up and acclimation.