[기술 면접 질문] SOLID 설계

[기술 면접 질문] SOLID 설계

📝요약

SOLID 설계란 단일 책임 원칙, 개방 폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존성 반전 원칙을 지키는 설계를 말합니다.
단일 책임 원칙이란, 하나의 모듈은 하나의 일만 처리해야 한다는 원칙입니다.
개방 폐쇄 원칙이란, 소프트웨어 아티팩트는 확장에 열려있되 수정에 닫혀있어야 한다는 원칙입니다.
리스코프 치환 원칙이란, 자식 클래스가 부모 클래스를 대체하는데 문제가 없어야 한다는 원칙입니다.
인터페이스 분리 원칙이란, 인터페이스를 사용하는 객체가 불필요한 함수를 구현하는 것을 강요하면 안된다는 원칙입니다.
마지막으로 의존성 반전 원칙이란, 상위 모듈은 하위 모듈에 의존해서는 안된다는 원칙입니다.

📌참고자료

• 안드로이드(Kotlin)를 SOLID로 설계하기 | 기계공학 주인장
• 코틀린으로 알아보는 SOLID 원칙 | Nanamare
• SOLID - DIP(Dependency Inversion Principle)란 : 의존성 역전 원칙 | huisam

• SOLID 설계란?
  • Single Responsibility Principle(SRP): 단일 책임 원칙
  • Open/Closed Principle(OCP): 개방 폐쇄 원칙
  • Liskov Substitution Proncople(LSP): 리스코프 치환 원칙
  • Interface Segregation Principle(ISP): 인터페이스 분리 원칙
  • Dependency Inversion Principle(DIP): 의존성 반전 원칙/의존성 역전 원칙

Single Responsibility Principle(SRP)

• 하나의 모듈은 하나의 일만 처리해야 -> Facade 패턴 적용
• 하지만, 모든 클래스에 단일 책임 부여 -> 클래스 수 기하급수적으로 늘어날 수 있음

Open/Closed Principle(OCP)

• Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
  = 소프트웨어 아티팩트의 동작은 아티팩트를 수정할 필요 없이 확장 가능해야

• 예) OCP를 위반하는 설계
  -> 새로운 Notification을 추가할 경우, sendNotification 함수 수정 필요!

  enum class Notification {
     PUSH_NOTIFICATION, EMAIL
  }
  class NotificationService {
     fun sendNotification(notification: Notification) {
         // notificagion의 값에 따라 다른 작업을 실행하게 한다
         when (notification) {
             Notification.PUSH_NOTIFICATION -> {
                 // send push notification
             }
             Notification.EMAIL -> {
                 // send email notification
             }
         }
     }
  }

• 예) OCP를 지킨 설계

  interface Notification {
     fun sendNotification()
  }
  // Notification interface를 상속 받으며 각 함수 재정의
  class PushNotification : Notification {
     override fun sendNotification() {
         // send push notification
     }
  }
  class EmailNotification : Notification {
     override fun sendNotification() {
         // send email notification
     }
  }
  class NotificationService {
     fun sendNotification(notification: Notification) {
         notification.sendNotification()
     }
  }

Liskov Substitution Principle(LSP)

• 자식 클래스가 부모 클래스를 대체하는데 아무 문제가 없어야

Interface Segregation Principle(ISP)

• 인터페이스를 상속하는 클래스에서 불필요한 메서드를 구현하도록 강요해선 안된다
  -> 작은 단위의 목적에 맞는 인터페이스 설계하기

• 예) ISP를 위반하는 설계
  -> 롱클릭을 사용하지 않는 경우에도 onLongClick 함수를 구현해야 함

  interface OnClickListener {
     fun onClick()
     fun onLongClick()
  }

• 예) ISP를 지킨 설계

  interface OnClickListener {
     fun onClick()
  }
  interface OnLongClickListener {
     fun onLongClick()
  }

Dependency Inversion Principle(DIP)

• 상위 모듈은 하위 모듈에 의존해서는 안된다
  = 추상화는 세부 사항에 의존해서는 안된다
  = 자식 클래스의 변경이 부모 클래스에게 영향을 주어서는 안된다