SOLID 원칙

객체지향 프로그래밍을 하면서(With NestJs...) SOLID 원칙이라는 단어를 많이 접해왔지만, 정작 이것이 무엇인지에 답변을 하지 못하였다.
그래서 이에 대한 개념을 잡고 보다 더 객체지향적인 개발을 하기위한 초석을 다져보고자 한다.

좋은 객체 지향 설계를 하면, 개발 기간을 단축하고 비용을 줄여 효율적인 개발이 가능해진다.
이유는 좋은 설계에 따른 객체 지향 프로그래밍은 코드의 재사용, 유지보수의 용이성 등의 장점을 가지기 때문이다.

코드는 항상 유연하고, 확장할 수 있고, 유지보수가 용이해야하며, 재사용되어야 한다.
이러한 코드의 구현을 위해 OOP라는 방법론이 제안되었고, OOP라는 방법론을 잘 준수하기 위한 원칙으로 SOLID 라는 원칙이 제안되었다.

SOLID

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

• Class(객체)는 하나의 책임만 지녀야 한다.
• User Controller는 User에 관련된(유저의 생성, 삭제 등) 요청만 받는다.(만약, 인증까지 수행한다면? SRP에 반하는 것이다.)

2. 개방-폐쇄 원칙(Open/Closed Principle)

• Class(객체)는 확장에는 개방되어야 하나, 수정에는 폐쇄되어야 한다.
• 자식 Class에서 부모 Class의 기능을 extend(기능을 추가하거나 overriding?을 하거나)할 수는 있지만, 부모 Class에서 이를 위한 수정을 할 필요는 없다.

**3. 리스코프 치환 원칙(Liskov's Substitution Principle, LSP)

• 자식 Class는 언제나 부모 Class로 교체할 수 있다.
• 포유류(부모), 코끼리(자식), 사람(자식)
  <포유류>는 네발로 걸으며, 새끼를 낳는다.
  <코끼리>는 네발로 걸으며, 새끼를 낳는다.
  <사람>은 네발로 걸으며, 새끼를 낳는다.
  사람은 네발로 걷지 않는다. 포유류 Class는 LSP에 반하는 설계이다.

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

• 클라이언트가 자신과 관련 없는 인터페이스는 구현하지 않아야 한다.
• 게시판을 예로 들어보자, '게시판' 인터페이스에는 글을 읽고, 쓰고, 수정하고, 삭제하는 메서드가 있다.
  이 '게시판'은 '일반 사용자'와 '관리자'가 이용한다. 하지만, '일반 사용자'는 게시판의 글을 삭제할 수 없다.
  '일반 사용자'는 '게시판' 인터페이스의 '삭제' 메서드는 사용하지 않는 것이다. 이는 ISP를 만족하지 못한다.(단, '게시판' 관련 기능만을 수행하므로 SRP는 만족한다.)

5. 의존성 역전 법칙(Dependency Inversion Principle, DIP)

• 고차원 module/class는 저차원 module/class에 의존하면 안된다.
• 저수준 module/class는 고수준 module/class에서 정의한 추상 타입에 의존해야 한다.(이러한 추상화는 추상 클래스나 인터페이스로 구현한다.)(변하기 쉬운것의 영향을 받지 않아야 한다.)
• 아이라는 상위 Class가 있다. 이 '아이'는 매번 가지고 노는 장난감이 다르다(로봇, 자동차, 레고 등) 상위 Class인 아이가 로봇, 자동차, 레고 등에 의존한다.(변하기 쉬운 것의 영향을 받음)
  이는 DIP를 위반하는 것이며, 이를 개선하기 위해서는 장난감이라는 인터페이스(or 추상클래스)를 만들어 로봇, 자동차, 레고 등이 이에 의존하게 한다.(의존성 역전. 변하기 쉬운 것의 영향을 받지 않음.)
  가지고 노는 것이 바뀌게 되면, '장난감'만 변경하면 된다.