SOLID Principles

In my first writing I want to talk about SOLID principles of object-oriented programming that every software developer must know.

What are these SOLID principles?

SOLID, first introduced in Robert Martin’s 2000 paper Design Principles and Design Patterns. After that, introduced by Michael Feathers around 2004. SOLID is the principle that brings together the rules that must be followed while object-oriented programming. There are five principles that you can apply to any object-oriented design.

1. Single Responsibility Principle
2. Open/Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

The purpose of these principles;

• The software easily adapts to future requirements.
• Easily add new features without the need for a change in the code.
• Provides the least change on the code despite new requirements.
• Minimize the time loss caused by problems such as constant editing or even rewriting on the code.

Let’s briefly review each principle with code examples.

Single Responsibility Principle

“There should never be more than one reason for a class to change.”

In other words, the Single Responsibility Principle states that a class should have only one responsibility.

class Membership {
  func deleteMembership() {}
  func register() {}
  func updateMember() {}
}

class Login {
  func login() {}
  func logout() {}
}

class Mail {
  func sendMail() {}
}

Open/Closed Principle

“Software entities … should be open for extension, but closed for modification.”

It means, a class/method should be open to development and closed to change and change should only be made by adding new codes.

protocol Shape {
  func draw()
}

class Circle: Shape {
  func draw() {}
}

class Triangle: Shape {
  func draw() {}
}

class DrawShapes: Shape {
  func drawShape(shape: Shape) {
    shape.draw()
  }
}

let draw = DrawShapes()
draw.drawShape(shape: Circle())
draw.drawShape(shape: Triangle())

Liskov Substitution Principle

Introduced by Barbara Liskov in a 1988 conference Data abstraction and hierarchy.

“Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

The properties of the main class should also be available to its subclasses.

Interface Segregation Principle

“Many client-specific interfaces are better than one general-purpose interface.”

In short, objects should be parsed from interfaces of methods they don’t need.

protocol FirstProtocol {
    func breath()
}

protocol SecondProtocol {
    func eatPlant()
}

protocol ThirdProtocol {
    func eatMeat()
}

class Omnivore: FirstProtocol, SecondProtocol, ThirdProtocol {
    func breath() {}
    func eatMeat() {}
    func eatPlant() {}
}
      
class Herbivore: FirstProtocol, SecondProtocol {
    func breath() {}
    func eatPlant() {}
}
      
class Carnivore: FirstProtocol, ThirdProtocol {
    func breath() {}
    func eatMeat() {}
}

Dependency Inversion Principle

“Depend upon abstractions, [not] concretions.”

High level modules should not depend upon low level modules. Instead of a direct dependency, a protocol should be written.

Benefits of SOLID

• Accessibility
• Extensibility
• Ease of refactoring
• Readability
• Debugging

I hope you enjoyed the article.