design principle comes from Object oriented programming guidelines. It is designed to develop software that can be easily maintained and extended; prevents code smells; easy to refractor; promotes agility and finally incorporates rapid + frequent changes quickly without bugs. S.O.L.I.D Generally, technical debt is the result of prioritising speedy delivery over perfect code. To keep it under control - use SOLID principles, during development. , is credited with writing the SOLID principles and stated 4 major software issues if S.O.L.I.D is not followed diligently. They are : Robert Martin : Rigidity Implementing even a small change is difficult since it's likely to translate into a cascade of changes. : Fragility Any change tends to break the software in many places, even in areas not conceptually related to the change. : Immobility We're unable to reuse modules from other projects or within the same project because those modules have lots of dependencies. : Viscosity Difficult to implement new features the right way. SOLID is a guideline and not a rule. It is important to understand the crux of it and incorporate it with a crisp judgement. There can be a case when only few principles out of all is required. S.O.L.I.D stands for: ; Single Responsibility Principle (SRP) ; Open Closed Principle (OCP) ; Liskov Substitution Principle (LSP) ; Interface Segregation Principle (ISP) ; Dependency Inversion Principle (DIP) Single Responsibility Principle (SRP) : Every function, class or module should have one, and only one reason to change, implies should have only one job and encapsulate within the class (stronger cohesion within the class). It supports "Separation of concerns" — do one thing, and do it well!" For example, consider this class: Menu { ( ) {}
  getDishName() {}
  saveDish(a: Dish) {}
} class constructor dish: string This class violates SRP. Here is why. It is managing the properties of menu and also handling the database. If there is any update in database management functions then it will affect the properties management functions as well, hence resulting in coupling. More cohesive and Less Coupled class Instance. Menu { ( ) {}
  getDishName() {}
} MenuDB {
  getDishes(a: Dish) {}
  saveDishes(a: Dish) {}
} // Responsible for menu management class constructor dish: string // Responsible for Menu management class Open Closed Principle (OCP): Classes, functions, or modules should be opened for extensibility, but closed for modification. If you created and published a class - changes in this class, it can break the implementation of those, who are started using this class. Abstraction is the key to getting OCP right. For example, consider this class: Menu { ( ) {}
  getDishName() {}
} class constructor dish: string We want to iterate through a list of dishes and return their cuisine. Menu { ( ){ }
getDishName() { getCuisines(dishName) { ( index = ; index <= dishName.length; index++) { (dishName[index].name === ) { .log( );
         } (dishName[index].name === ) { .log( );
         }
      }
    }

} class constructor dish: string // ... } for let 0 if "Burrito" console "Mexican" else if "Pizza" console "Italian" The function getCuisines() does not meet the open-closed principle because it cannot be closed against new kind of dishes. If we add a new dish say Croissant, we need to change the function and add the new code like this. Menu { ( ){ }
getDishName() { getCuisines(dishName) { ( index = ; index <= dishName.length; index++) { (dishName[index].name === ) { .log( );
         } (dishName[index].name === ) { .log( );
         } (dishName[index].name === ) { .log( );
         }
      }
    }

} class constructor dish: string // ... } for let 0 if "Burrito" console "Mexican" if "Pizza" console "Italian" if "Croissant" console "French" If you observe, for every new dish, a new logic is added to the getCuisines() function. As per the open-closed principle, the function should be open for extension, not modification. Here is how we can make the codebase meets the standard to OCP. Menu { ( ) {}
  getCuisines() {}
} Burrito Menu {
  getCuisine() { ;
  }
} Pizza Menu {
  getCuisine() { ;
  }
} Croissant Menu {
  getCuisine() { ;
  }
} { ( index = ; index <= a.length; index++) { .log(a[index].getCuisine());
  }
}

getCuisines(dishes); class constructor dish: string class extends return "Mexican" class extends return "Italian" class extends return "French" ( ) function getCuisines a: <dishes> Array for let 0 console This way we do not need to modify the code whenever a new dish is required to add. We can just create a class and extends it with the base class. Liskov Substitution Principle (LSP) A sub-class must be substitutable for their base type, states that we can substitute a subclass for its base class without affecting behaviour and hence helps us conform to the "is-a" relationship. In other words, subclasses must fulfil a contract defined by the base class. In this sense, it's related to Design by Contract that was first described by . Bertrand Meyer For example, Menu has a function getCuisines which is used by Burrito, Pizza, Croissant and didn't created individual functions. Menu { ( ) {}
  getCuisines(cuisineName: ) { cuisineName;
  }
} Burrito Menu { ( ) { (); .cuisine = cuisineName;
  }
} Pizza Menu { ( ) { (); .cuisine = cuisineName;
  }
} Croissant Menu { ( ) { (); .cuisine = cuisineName;
  }
} burrito = Burrito(); pizza = Pizza();
burrito.getCuisines(burrito.cuisine);
pizza.getCuisines(pizza.cuisine); class constructor dish: string string return class extends constructor cuisineName: string super this class extends constructor cuisineName: string super this class extends constructor cuisineName: string super this const new const new Interface Segregation Principle (ISP) A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use. The "interface" word in the principle name does not strictly mean an interface, it could be an abstract class . For example ICuisines {
  mexican();
  italian();
  french();
} Burrito ICuisines {
  mexican() {}
  italian() {}
  french() {}
} interface class implements If we add a new method in the interface, all the other classes must declare that method or error will be thrown. To solve it BurritoCuisine {
  mexican();
} PizzaCuisine {
  italian();
} Burrito BurritoCuisine {
  mexican();
} interface interface class implements Many client-specific interfaces are better than one general-purpose interface. Dependency Inversion Principle (DIP) Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, decouple them and make use of abstractions. High-level modules are part of an application that solve real problems and use cases. They are more abstract and map to the business domain (business logic); They tell us what the software should do (not how, but what); Low-level modules contain implementation details that are required to execute the business policies; About how the software should do various tasks; For Example pool = mysql.createPool({}); MenuDB { ( ) {}
  saveDishes() { .db.save();
  }
} const class constructor db: pool private this Here, class MenuDB is a high-level component whereas a pool variable is a low-level component. To solve it, we can separate Connection instance. Connection {
  mysql.createPool({})
} MenuDB { ( ) {}
   saveDishes() { .db.save();
   }
} interface class constructor db: Connection private this Ending Note Code that follows S.O.L.I.D. principles can be easily shared, extended, modified, tested, and refactored without any problems. With each real-world application of these principles benefits of the guidelines will become more apparent. Anti-patterns and improper understanding can lead to code: Singleton, Tight Coupling, Un-testability, Premature Optimization, In-descriptive Naming, and Duplication. SOLID can help developers stay clear of these. STUPID PS: I, Box Piper born on Sept 2020 with the sole aim to provide high-quality content. Do check my profile. Previously published at https://www.boxpiper.com/posts/solid-software-design-principles/

S.O.L.I.D. Software Design Principles To Help You Become A Better Developer

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Improving Focus and Productivity Using the Pomodoro Technique

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

Improving Focus and Productivity Using the Pomodoro Technique

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps