99클럽 20일차 TIL: SOLID

#1. 오늘의 학습 키워드

개발원칙 SOLID 에 대해서

• 자바 스프링 부트로 개발을 하기 시작하면서, 여러 기술을 접하면서, 객체 지향 프로그래밍은 이런 것이구나, 를 간접적으로 느꼈다.
  • 그러면 객체지향 프로그래밍의 5가지 설계원칙, SOLID 에 대해서도 알아보자

---

#2. 공부한 내용

• SOLID
  • 객체지향 프로그래밍을 하면서 지켜야하는 5대 원칙
  • 5개의 원칙은 아래와 같다
    • SRP (단일 책임 원칙)
    • OCP (개방 - 폐쇄 원칙)
    • LSP (리스코프 원칙)
    • ISP (인터페이스 원칙)
    • DIP (의존 역전 원칙)

1. SRP (Single Responsibility Principle)

• 단일 책임 원칙
  • 단일의 모듈은 단일의 책임을 갖는다는 원칙
  • 특정 모듈을 수정할 때, 해당 모듈을 수정하는 이유는 하나여야된다는 의미로 해석할 수 있다.
  • 예시)
    • 인사 관리 서비스에서 휴가 신청 기능이 있을 때,
      • 기획 팀에서는 잔여 휴가를 조회할 수 있는 기능을 추가하고자 하고,
      • 보안 팀에서는 자신 이외에는 자신의 휴가를 신청하지 못하게 끔 하고자 한다.
    • 이때 해당 모듈에 위 기능들을 추가하고자 할 때, 휴가 신청에 관한 로직의 책임과 접근 권한의 책임을 동시에 지게 된다.
    • 따라서 접근 권한 관련 로직을 권한 모듈로 분리를 해야한다.

2. OCP (Open-Closed Principle)

• 개방 폐쇄 원칙
  • 확장에 대해서는 개방을 하고, 수정에 대해서는 폐쇄를 해야한다는 원칙
  • 즉 새로운 요건에 대해서 기존의 코드를 수정하지 않고, 기능을 추가하는 식으로 대응하는 것을 지향해야 한다는 의미
  • 예시)
    • 인사 관리 서비스의 휴가 관리 기능에서,
      • 관리자는 모든 인원의 잔여 휴가를 보고 싶은데, 임직원의 이름과 전화번호, 및 직위 직책도 같이 보고 싶어한다.
      • 이때 만약 임직원 서비스에서 다른 모듈로의 정보 제공이 원활히 이뤄지고 있었다면, 단순히 휴가 조회 코드에서, DTO 의 속성만 추가해주면 해결된다.
        • 그게 아니라면, 기존의 임직원 관리 모듈의 코드를 수정해야할 염려가 있다.

3. LSP (Liskov Substitution Principle)

• 리스코프 치환 원칙
  • 상속한(하위) 타입은 상속된(상위) 타입을 대체할 수 있어야한다.
    • 올바른 상속 관계의 특징을 정의하기 위해, 수립된 원칙
  • 객체를 사용할 때, 해당 객체의 타입을 기존 클래스를 상속한 클래스 타입으로 바꿔도 차이점이 있으면 안 된다는 의미
  • 예시)
    • 휴가 클래스가 있고, 잔여 휴가를 담는 속성이 있고, 휴가를 사용할 시 잔여 휴가가 차감되는 메서드 있다고 하자.
      • 만약 공가라는 하위 클래스를 만들어서 휴가 클래스를 상속하면,
      • 공가는 잔여 휴가를 차감하지 않으므로, 하위 클래스는 상위 클래스를 대체하지 못한다.
    • 이를 미루어보아, 해당 원칙은 상위 클래스가 구현된 전제 조건을 하위 클래스도 다 만족 시켜야한다는 것을 강조한다.

4. ISP (Interface Segregation Principle)

• 인터페이스 분리 원칙
  • 목적이 다른 클라이언트가 객체 내에 있으면, 인터페이스를 통해 분리를 해줘야한다.
  • 즉 모든 클라이언트가 자신의 요건에만 부합하는 퍼블릭 인터페이스만을 접근하여, 불필요한 간섭을 최소화할 수 있다는 의미.
  • 예시)
    • 휴가 모듈에서 임직원 모듈의 임직원 정보 조회 관련 로직들이 필요할 때, 임직원 클래스에서 조회 로직 뿐만이 아닌, 등록 및 수정 로직을 담는 메서드들까지 같은 클래스 내에서 구현이 되어있을 수 있다.
    • 이때 휴가 모듈은 단지 조회만 필요하다.
    • 그러면 조회 관련된 로직 만을 담는 인터페이스를 만들고, 휴가 모듈에서는 해당 인터페이스를 주입 받는 것이 적절하다.
  • 인터페이스 분리 원칙에서의 인터페이스는 API 도 포함이다.

5. DIP (Dependency Inversion Principle)

• 의존 역전 원칙
  • 저수준 모듈이 고수준 모듈에 의존해야한다.
  • 반대로 고수준 모듈이 저수준 모듈에 의존하면 안 된다.
  • 저수준 모듈
    • 입력, 출력(네트워크, DB 등) 과 가까운 구현 모듈
      • 서비스가 잘 제공되기 위한 도구들
    • low - level
  • 고수준 모듈
    • 입력, 출력과 먼 구현 모듈 (로직 중심)
      • 서버에서 제공하는 실질적인 서비스
    • high - level
  • 즉 비즈니스 로직과 관련된 부분은 세부 사항에는 의존하면 안 된다는 의미.
  • 원래대로면 고수준 모듈이 개별 되면서 저수준 모듈을 의존하는 것은 당연하지만, 저수준 모듈이 빈번하게 변경되면, 그에 따라 고수준 모듈도 변경해야하기에, 저수준 모듈이 제공하는 구체화에 의존하지 말고 추상화의 의존하라는 의미
  • 예시)
    • 휴가 모듈에서 휴가를 사용 시 관리자에게 메일을 보내는 기능이 있다.
    • 만약 휴가 모듈이 메일 모듈에 의존하면, 메일 모듈에서 기능이 변경 될 때마다 휴가 모듈이 변경 될 여지가 있다.
      • 이는 번거로우므로, 휴가 모듈의 메일 모듈에 대한 의존성을 최소화해야한다.
    • 이를 미루어보아 DIP는 사실 OCP 랑 상당히 흡사하다.

---

• 참조:
  • https://mangkyu.tistory.com/194
  • https://velog.io/@harinnnnn/OOP-객체지향-5대-원칙SOLID-의존성-역전-원칙-DIP

---

#3. 오늘의 회고

• SOLID의 원칙을 정리하면서, 해당 원칙들이 주는 느낌은 외부와의 소통 창구를 딱 필요한 정도만 남기려고 하는 것 같다.
  • 그래서 어딘가에서 수정이 이뤄졌을 때, 다른 코드에서 일어날 잠재적인 사이드 이팩트를 미리 대비하고자 하는 것이다.
• 백엔드 개발을 하면서, 기능이 추가될 수록 모듈이 많아지고, 모듈 간의 논리적 상하 계층 구조가 형성 되면서, 어딘가에서 수정이 이뤄졌을 때 다른 곳도 수정을 했던 경험이 여러 번 있다.
  • 따라서 해당 원칙들을 준수하는 것이 얼마나 중요한 지를 다시 한 번 스스로 상기시킬 수 있었다.