[OOAD] SOLID

SOLID Principles

Table of Contents

• 1. What is SOLID?
• 2. SOLID Principles
  • 2.1. SRP, Single Responsibility Principle (단일 책임 원칙)
  • 2.2. OCP, Open-Closed Principle (개방 폐쇄 원칙)
  • 2.3. LSP, Liskov Substitution Principle (리스코프 치환 원칙)
  • 2.4. ISP, Interface Segregation Principle (인터페이스 분리 원칙)
  • 2.5. DIP, Dependeny Inversion Principle (의존성 역전 원칙)

 

1. What is SOLID?

소프트웨어 공학에서 솔리드 원칙(솔리드)는 OOD(Object-Oriented Design)을 보다 이해하기 쉽고, 유연하며, 유지보수가 가능하도록 하기 위해 고안된 5가지 설계 원리이다. 이 원칙들은 Robert C Martin의 Design Principles and Design Patterns에서 처음 소개되었다.

 

2. SOLID Principles

2.1. SRP, Single Responsibility Principle (단일 책임 원칙)

A class should have one, and only one, reason to change.
하나의 클래스는 단 하나의 변경할 이유만 있어야 한다.

• 하나의 클래스에 하나의 책임만 갖게 한다는 것은 클래스가 관련 없는 여러 일을 처리하게 두지 말라는 뜻이다.
• 연관된 작업 외의 것들은 다른 클래스로 분리하여 관리하여야 한다.
• SRP를 사용해야하는 이유
  • 하나의 클래스에서 여러 기능을 갖고 있으면, 해당 클래스로 접근하는 relation이 증가하게 된다. 이는 커플링이 증가로 이어진다. 이것을 해결 하기 위해서 기능을 분리하여 하나의 클래스는 하나의 책임만 갖게 하는 것이다.

 

2.2. OCP, Open-Closed Principle (개방 폐쇄 원칙)

Software Entity(classes, modules, functions, etc.) should be open for extension but closed for modification.
소프트웨어 개체는 확장에는 열려있고 수정에는 닫혀있어야 한다.

• 확장하기 쉽다는 것은 변경사항에 유연하여 유지보수에 용이하다 해석할 수 있다.
• 수정에 닫혀있다는 것은 변경사항에 따라 수정이 되어도 클래스를 사용하는 개체들의 코드는 변경이 없도록 하는 것이다.
• 추상화(abstraction)을 이용하는 것이 핵심이다.
• OCP를 사용해야하는 이유
  • 만약 새로운 요구사항이 추가되어 수정해야 할 때, 기존 코드를 수정할 필요 없게 설계하기 위함이다.

 

2.3. LSP, Liskov Substitution Principle (리스코프 치환 원칙)

Subtypes must be substituable for their base types.
하위 클래스는 반드시 기본(혹은 상위) 클래스의 기능을 대신 수행할 수 있어야 한다.

• inheritance or implementation 할 때는 상위 클래스의 대체하지않고 수행할 수 있어야 한다.
• subtype은 is a 관계가 성립되어야 한다. (subtype class is a base type class.)
• 만약 상위기능을 가져와서 수정을 하게 된다면, subtype 가 아니라 object composition 이다.
• LSP를 사용해야하는 이유
  • LSP 위반(violation)은 desgin smell이다. 그리고 위반하기 쉽다.
  • LSP는 규약을 준수하는 상속 구조를 제공한다.
    LSP를 바탕으로 OCP는 확장하는 부분에 다형성을 제공해 변화에 열러 있는 프로그램을 만들 수 있도록 해준다.

 

2.4. ISP, Interface Segregation Principle (인터페이스 분리 원칙)

Client should not be forced to depend on methods they do not use.
클라이언트가 사용하지 않는 방법에 의존하지 않도록 해야한다.

• 만약 하나의 interface가 큰 관련이 없는 여러 개의 Implementation을 가진다면 불필요한 커플링을 갖게 된다.
• 이를 해결하기 위해 관련 없는 interface를 분리하여야 한다.

 

• Bad Example
  
  • 잘못된 예시와 같이 구현되면, 필요없는 커플링이 생긴다.
  • 응집력이 없는 fat interface 의 예라 할 수 있다.

 

• Good Example
  
  • 위의 문제를 아래와 같이 분리하면, interface는 필요한 기능만 갖게 되므로 응집력이 증가하고, interface는 커플링이 낮아지는 것을 알 수 있다.
• ISP 를 사용해야하는 이유
  • 관련이 없는 기능이 엮여있다면 인터페이스를 분리하여 커플링을 낮출 수 있다.

 

2.5. DIP, Dependeny Inversion Principle (의존성 역전 원칙)

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstraction should not depend on details. Details should depend on abstractions.
고수준 모듈은 저수준 모듈에 의존해서는 안된다. 둘 다 추상화와 연결되어야한다.
추상화는 세부 사항에 의존해서는 안된다. 세부 사항은 추상화에 의존해야한다.

• 고수준 모듈이 저수준 모듈을 직접 호출하지 않게 하기 위한 방법이다.
• Example
• DIP를 사용해야하는 이유
  • DIP를 통해 상위클래스는 하위클래스를 직접 호출하지 않으므로 코드 재사용성을 올릴 수 있고, 커플링을 낮출 수 있다.

 

ref)
https://en.wikipedia.org/wiki/SOLID

images)
https://dev.to/huzaifa99/why-the-dependency-inversion-principle-is-worth-using-opj