강의: Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈

Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의 | 박우빈 - 인프런

• 미션 1

  • 아래 코드와 설명을 보고, [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.

  public boolean validateOrder(Order order) {
      if (order.getItems().size() == 0) {
          log.info("주문 항목이 없습니다.");
          return false;
      } else {
          if (order.getTotalPrice() > 0) {
              if (!order.hasCustomerInfo()) {
                  log.info("사용자 정보가 없습니다.");
                  return false;
              } else {
                  return true;
              }
          } else if (!(order.getTotalPrice() > 0)) {
              log.info("올바르지 않은 총 가격입니다.");
              return false;
          }
      }
      return true;
  }
  

  • 과정

    • 파악한 문제점

      1. if-else 문이 여러 번 사용되면서 depth가 증가하였다. 이는 사고 과정의 depth를 증가시킬 수 있다.
      2. ‘!’ 부정어를 사용하여 기존에 조건을 한번 더 생각하게끔 만들었다.
      3. Order객체에 getter를 통하여 강제로 값을 가져오는 모습은 바람직하지 않다.

    • 생각한 개선점

      • if-else문을 early return을 통하여 최대한 depth를 줄일 수 있어 보인다.
      • 부정어 대신 부정을 의미하는 메서드 네이밍을 통하여 사고 과정을 줄일 수 있어 보인다.
      • getter를 통하여 직접 가져오는 것이 아닌 최대한 명시적인 메서드를 사용하고 진짜 불가피한 상황에만 getter를 사용할 수 있어 보인다.

  • 개선한 코드

  public boolean validateOrder(Order order) {
      if (order.isEmpty()) { // getter 대신 명시적으로 조건을 요구하는 메서드를 사용
          log.info("주문 항목이 없습니다.");
          return false;
      }
      
      // early return을 통하여 else문을 제거 -> depth 낮아짐
      if (order.checkInvalidTotalPrice()) {
  				log.info("올바르지 않은 총 가격입니다.");
          return false;
      }
  		
  		// 부정어를 메서드 네임에 표현
  	  if (order.doesNotHaveCustomerInfo()) {
  		    log.info("사용자 정보가 없습니다.");
  		    return false;
      }
      
      return true;
  }
  

• 미션 2

  • SOLID에 대하여 자기만의 언어로 정리해 봅시다.

  • SOLID는 SRP, OCP, LSP, ISP, DIP의 앞 글자를 따서 만든 말로, 객체 지향 설계를 우리가 더 이해하기 쉽고 유연하고, 유지보수 하기 쉽게 만드는 데 도움을 주는 원칙들이다.

  • 하나씩 정리해보면

  • SRP

    • Single Responsibility Principle
    • 단일 책임 원칙
    • 하나의 클래스는 하나의 책임만을 가져야 함
    • 변경이 있을 시 파급 효과가 적어야 함
    • 높은 응집도와 낮은 결합도를 가져야 함

  • OCP

    • Open-Closed Principle
    • 개방 - 폐쇄 원칙
    • 확장에는 열려 있으며, 수정에는 닫혀있어야 함
    • 추상화와 다형성을 활용해서 OCP를 지킴 (역할과 구현을 분리)

  • LSP

    • Liskov Substitution Principle
    • 리스코프 치환 원칙
    • 상속 구조에서 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있어야 함
    • 자식 클래스는 부모 클래스의 책임을 준수하며, 부모 클래스의 행동을 변경하지 않아야 함
    • LSP 위반 시 상속 클래스를 사용할 때 오동작, 예외가 발생하거나 이를 방지하기 위한 불필요한 타입 체크가 동반될 수 있음

• ISP

  • Interface Segregation Principle
  • 인터페이스 분리 원칙
  • 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안 됨
  • 인터페이스를 기능별로 잘게 쪼개기
  • ISP 위반 시 불필요한 의존성으로 인하여 결합도 증가, 특정 기능의 변경이 여러 클래스에 영향을 미칠 수 있음

• DIP

  • Dependency Inversion Principle

  • 의존성 역전 원칙

  • 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 됨

    • 구현 클래스에 의존하지 말고, 인터페이스에 의존
    • 역할(Role)에 의존하자!

  • 의존성의 순방향

    • 고수준 모듈이 저수준 모듈을 참조하는 것

  • 의존성의 역방향

    • 고수준, 저수준 모듈이 모두 추상화에 의존하는 것

  → 저수준 모듈이 변경되어도, 고수준 모듈에는 영향이 가지 않음