Skip to main content

김시용

1. 📌 핵심 개념 정리

✅ 요약하기

각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리하고 개선 전, 후에 대한 예시 코드를 비교하며 개념을 설명합니다.

  1. 캡슐화
    클래스 내 선언된 변수, 함수 등은 외부에서 접근 못하게 private 선언으로 숨기는 것을 의미.
    테스트 코드 등을 이유로 같은 패키지에서 접근이 가능하도록 protected로 선언하여 접근 가능하게 하기도 함.
    단, 비공개 상태를 유지할 온갖 방법을 강구한 후에 캡슐화를 풀어주는 결정을 최후의 수단으로 사용
  1. SRP
    단일 책임 원칙을 의미하며, 클래스는 작아야하는데 그 '작다'의 척도를 클래스가 맡은 책임을 세는 것으로 한다.
    즉, 메서드 갯수가 적다고 클래스가 작은 것이 아니라 책임이 1개여야 작은 클래스라 할 수 있다.
    책임이란 클래스가 변경할 이유가 하나여야 한다를 의미한다. 변경할 의미를 파악하려 애쓰다 보면 코드를 추상화하기도 쉬워진다.
    -> 작은 클래스 많이 두기 = 큰 서랍 몇 개에 모두 던져 넣기보다는 작은 서랍 많이 두고 쓸모에 맞게 정리하여 넣기
  1. 응집도
    클래스 내의 인스턴스 변수를 클래스 메서드가 많이 사용할수록 메서드와 클래스의 응집도가 높다.
    즉, 응집도란 클래스와 클래스 메서드간의 연관도를 의마한다.
    응집도를 유지하면 작은 클래스 여럿이 나온다.
    -> 큰 함수의 일부를 작은 함수로 빼내기
    -> 작은 함수가 필요한 인수를 클래스의 인스턴스 변수로 승격시켜 작은 함수는 인수가 필요없다
    -> 클래스가 응집력을 잃는다
    -> 종종 작은 클래스 여럿으로 쪼갤 기회 생김
  1. 결합도 클래스에서 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소여야 바람직하다.
    변경으로부터 격리 - 인터페이스와 추상 클래스 활용 (API 직접 호출 대신)
    시스템의 결합도를 낮추면 유연성과 재사용성 증가

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

  1. 결합도

    • 어려웠던 부분
      결합도란 무엇을 의미하고 결합도를 낮추는 예시 살펴보기

    • 궁금한 점
      결합도(Coupling)는 한 모듈(클래스, 함수)이 다른 모듈과 얼마나 강하게 연결되어 있는지를 나타내는 개념입니다.

      • 높은 결합도 (High Coupling): 한 모듈이 다른 모듈의 내부 구현에 직접 의존하는 경우, 변경이 어렵고 유지보수 비용이 증가합니다.
      • 결합도가 높은 코드 예시
        (OrderService는 PayPalPaymentProcessor의 구체적인 구현에 직접 의존) 
        class PayPalPaymentProcessor {
  void processPayment(double amount) {
      System.out.println("Processing payment of $" + amount + " via PayPal");
  }
}

class OrderService {
  private PayPalPaymentProcessor paymentProcessor;

  public OrderService() {
      this.paymentProcessor = new PayPalPaymentProcessor(); // 직접 의존
  }

  public void checkout(double amount) {
      paymentProcessor.processPayment(amount);
  }

      }

      • 낮은 결합도 (Low Coupling): 한 모듈이 다른 모듈과 독립적으로 동작할 수 있도록 인터페이스 또는 추상화 계층을 두는 방식으로 결합을 줄입니다.

      • 결합도가 낮은 코드 예시
        (PaymentProcessor 인터페이스를 도입하여 OrderService가 특정 구현이 아니라 추상화에 의존)

        // 추상화 계층 추가
interface PaymentProcessor {
    void processPayment(double amount);
}

// PayPal 구현
class PayPalPaymentProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing payment of $" + amount + " via PayPal");
    }
}

// Stripe 구현
class StripePaymentProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        System.out.println("Processing payment of $" + amount + " via Stripe");
    }
}

// OrderService는 구체적 클래스가 아니라 인터페이스에 의존
class OrderService {
    private final PaymentProcessor paymentProcessor;

    public OrderService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor; // 인터페이스에 의존
    }

    public void checkout(double amount) {
        paymentProcessor.processPayment(amount);
    }
}

3. 📚 참고 사항

📢 논의하기

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

  1. 관련 자료 공유
  1. 논의하고 싶은 주제
    • 주제
      어떤 클래스를 보고 SRP를 위반했는지 파악하는 법은?
    • 설명
      각자 개인의 기준이 있는지 궁금하다.
No Comments
Back to top