DRY vs WET Principles — PHP Implementation

DRY (Don’t Repeat Yourself)

Every developer should know that repeating codes is not a preferable approach. Think that you have admin panel and you will have lots of forms in your code base. You will repeat all the inputs and other elements again and again. This will take much more effort and time. Why a person do this to himself/herself.? Such as think that you are using Laravel. You can create view components and you can reuse instead of repeating your codes again and again. This will be a really timesaver. And you can use your efforts to other things.

Advantages:

1. Maintainability

We can say the best advantage of DRY is maintainability. When creating reuseable codes and when changes needed we can change all things in just one file. You don’t have to search other files to do changes. You can change at one place and you can finish your work. This makes you app maintainable and sustainable.

2. Readability

Codes written with DRY principles are more readable. When you don’t repeat your codes you will also write your variable names in a proper way. The codebase is more readable and maintainable, with repetitive writing and each related reference written in a related object.

3. Reuse

DRY inherently promotes reuse of code because we are merging 2 or more instances of repeating code into a single block of code. Reusable code pays off in the long run as it speeds up development time.

4. Cost

Think that you have non DRY approached code base and you should refactor this. This will cost extra effort and time. On the contrary, thanks to this principle, such costs are minimized.

Let’s see some non-dry approach

<?php
  class ProductService
{
  public function checkProduct(Product $product)    
  {
    if (!isset($product->color)) 
    {
      throw new \Exception('Error: the product attribute color is missing');        
    }
    
    if (!isset($product->size)) 
    {
      throw new \Exception('Error: the product attribute size is missing');        
    }
    
    if (!isset($product->type)) 
    {
      throw new \Exception('Error: the product attribute type is missing');        
    }    
  }
}

As you can see there is 3 if condition which checks attributes are isset or not , does it look perfect?

Let’s refactor this into this

<?php
class ProductService
{
    private $productAttributes = [
            'color',
            'size',
            'type',    
    ];
    
    public function checkProduct(Product $product)    
    {
         if($this -> checkAttributes())
         {
               return true;        
         }    
    }
    public function checkAttributes()  
    {
         foreach ($this->productAttributesas$attribute) 
         {
              if (!isset($product->{$attribute})) 
              {
                   throw new \Exception(sprintf('Error: the product attribute %s is missing', $attribute));            
               }        
          }
      return true;  
   }
}

So we can reuse checkAttributes method in different place of code base. And we don’t repeat checking process again and again.

WET (Write Everything Twice)

This principle opposite of DRY principle. One developer comes and add a function that getRecord which get some data from database. And one another adds getDbRecord which is completely same with the other. And goes on this way. Is it maintainable? Or sustainable? Short answer is a big NO!.

You may say this is my approach and i can find everything in my code base when it is needed. But this will take much more time and effort of you with a nonsense way.

Summary

DRY is a very good approach but you can be careful. It is not recommended to proceed too strictly just because I will apply this principle. There are some pitfalls of DRY principle. You should be very very careful about this.

1. All code should not merge in one. Two function may looks similar but it can be use very different way.

2. When your code is over-dried , it will ne neither readable nor sustainable.

3. DRY not only applies on code but also applies on approach, database tables, relations etc.

Resource: Backend Developer

The Tech Platform

www.thetechplatform.com