SOLID Principles

 in Programming  tagged interface / principles / dependency / open / closed / Martin / solid / liskov / inversion by

American software engineer and instructor Robert C. Martin promotes the SOLID principles in his books and talks. What are they? In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. The theory of SOLID principles was introduced by Robert C. Martin in his 2000 paper Design Principles and Design Patterns.

If our code is understandable by other programmers when they read it, is easily changeable, and maintainable, we have written better code. Better code is important.

  • S – Single-responsibility Principle
  • O – Open-closed Principle
  • L – Liskov Substitution Principle
  • I – Interface Segregation Principle
  • D – Dependency Inversion Principle

SOLID design principles will help you to:

  • write code that’s easy to read and understand
  • write code that’s easy to maintain
  • make it easier to extend the system with new functionality

In order to realyy understand each of these five principles, you need to look at examples and write code. Here are the five concepts with brief descriptions only.

Single responsibility means that your class (any entity for that matter, including a method in a class, or a function in structured programming) should only do one thing.

The Open/Closed Principle states that a module should be open for extension, but closed for modification. You should be able to extend a module with new features (without breaking existing features) not by changing its source code, but by adding new code instead.

The Liskov Substitution Principle was first introduced by Barbara Liskov (an American computer scientist) in the late 80s. you should be able to substitute a parent class with any of its child classes, without breaking the system. Putting it more simply, implementations of the same interface should never give a different result.

The Interface Segregation Principle states that you should never force the client to depend on methods it doesn’t use.

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules – both should depend on abstractions.