SOLID Tutorials

Reason behind most of the unsuccessful application

Developers start building applications with good and tidy designs using their knowledge and experience. But over time, applications might develop bugs. The application design must be altered for every change request or new feature request. After some time we might need to put in a lot of effort, even for simple tasks and it might require a full working knowledge of the entire system. But we can't blame change or new feature requests. They are part of the software development. We can't stop them and refuse them either. So who is the culprit here? Obviously it is the design of the application.
The following are the design flaws that cause the damage in software, mostly.
  • Putting more stress on classes by assigning more responsibilities to them. (A lot of functionality not related to a class.)
  • Forcing the classes to depend on each other. If classes are dependent on each other (in other words tightly coupled), then a change in one will affect the other.
  • Spreading duplicate code in the system/application.

Solution

  • Choosing the correct architecture (in other words MVC, 3-tier, Layered, MVP, MVVP and so on).
  • Following Design Principles.
  • Choosing correct Design Patterns to build the software based on it's specifications.

Now we go through the Design Principles first and will cover the rest soon.

What is SOLID principles?

SOLID principles are the design principles that enable us to manage with most of the software design problems. Robert C. Martin compiled these principles in the 1990s. These principles provide us ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real needs of a business properly. SOLID is an acronym of the following.
  • S: Single Responsibility Principle (SRP)
  • O: Open closed Principle (OSP)
  • L: Liskov substitution Principle (LSP)
  • I: Interface Segregation Principle (ISP)
  • D: Dependency Inversion Principle (DIP)
;