Skip to main content

이정우

8. 📌 경계

✅ 요약하기

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

  1. 외부 코드 사용하기
  • 인터페이스 제공자
    • 더 많은 고객을 얻기 위해 가용성과 적용성을 높인다.
  • 인터페이스 사용자
    • 자신의 요구에 집중하는 인터페이스를 바란다.
  • 이러한 긴장으로 시스템 경계에서 문제 발생 소지가 많다.
  1. 경계 살피고 익히기
  • 외부 코드 사용시 적은 시간에 더 많은 기능 출시가 쉬워진다. 테스트가 필수와 책임은 아니지만 하는 편이 바람직하다.
    • 타사 라이브러리 사용시 사용법이 분명치 않다고 가정.
    • 하루이틀 문서 읽으며 사용법 결정
    • 이후 자사 코드를 작성해 정상 동작 여부를 확인
    • 버그 위치와 원인 확인에 오랜 디버깅으로 어려움을 겪는다.
  • 학습테스트
    • 자사 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트케이스를 작성하고 외부 코드를 익히는 방법
  1. 학습 테스트는 공짜 이상이다.
  • 비용 소비 없이 이해도를 높여주는 정확한 실험이다.
  • 패키지의 새 버전 출시에 패키지가 예상대로 돌아가는지 검증한다.
  • 새 버전이 우리의 코드와 호환되지 않으면 곧바로 밝혀낸다.
  • 학습 테스트 여부와 무관하게 실제 코드와 같은 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다.
    • 학습 테스트가 있다면 새 버전의 패키지로의 이전이 쉬워진다.
  1. 아직 존재하지 않는 코드를 사용하기.
  • 아는 코드와 모르는 코드를 분리하는 경계
  • 경계를 기준으로 능력, 존재의 여부 등으로 알 수 없는 경우가 있다.
  • 원하는 인터페이스의 사전 구현은 인터페이스의 전적인 통제를 가능케 한다.
  1. 깨끗한 경계
  • 경계에 위치하는 코드는 깔끔히 분리해야 한다.
  • 기대치를 정의하는 테스트케이스 작성
  • 외부 패키지 호출 코드를 줄여 경계 관리
    • 새로운 클래스로 경계를 감싼다.
    • ADAPTER 패턴을 사용해 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환
    • 어떠한 방식이든 코드 가독성, 경계 인터페이스 사용하는 일관성이 높아지고 외부 패키지의 변화시 변경할 코드가 줄어든다.

2. 🤔 이해가 어려운 부분

🔍 질문하기

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

  1. 개념 또는 원칙의 이름

    • 어려웠던 부분
      ADAPTER 패턴

      • 어댑터 패턴(Adapter pattern)은 처음클래스의 봤습니인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해준다.
      • 이름 그대로 클래스를 어댑터로서 사용되는 구조 패턴이다. 이를 객체 지향 프로그래밍에 접목해보면, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들을 함께 작동해주도록 변환 역할을 해주는 행동 패턴이라고 보면 된다.
      • 객체 어댑터 (Object Adaptor)
        • 합성(Composition)된 맴버에게 위임을 이용한 어댑터 패턴 (추천 🌟)
        • 자기가 해야 할 일을 클래스 맴버 객체의 메소드에게 다시 시킴으로써 목적을 달성하는 것을 위임이라고 한다.
        • 합성을 활용했기 때문에 런타임 중에 Adaptee(Service)가 결정되어 유연하다.
        • 그러나 Adaptee(Service) 객체를 필드 변수로 저장해야 되기 때문에 공간 차지 비용이 든다.
  1. 개념 또는

    클래스 원칙의어댑터 이름(Class Adaptor)

    • 클래스 상속을 이용한 어려웠던댑터 부분
      패턴
    • Adaptee(Service)를 상속했기 때문에 따로 객체 구현없이 바로 코드 재사용이 가능하다.
    • 궁금한상속은 점
      대표적으로 기존에 구현된 코드를 재사용하는 방식이지만, 자바에서는 다중 상속 불가 문제 때문에 전반적으로 권장하지는 않는 방법이다.

  • 턴

      사용 시기

      • 레거시 코드를 사용하고 싶지만 새로운 인터페이스가 레거시 코드와 호환되지 않을 때
      • 이미 만든 것을 재사용하고자 하나 이 재사용 가능한 라이브러리를 수정할 수 없을 때
      • 이미 만들어진 클래스를 새로운 인터페이스(API)에 맞게 개념조할때
      • 소프트웨어의 구 버전과 신 버전을 공존시키고 싶을때

    1. 패턴 장점

      • 프로그램의 기본 비즈니스 로직에서 인터페이스 또는 데이터 변환 코드를 분리할 수 있기 때문에 단일 책임 원칙(SRP)Visit Website을 만족한다.
      • 기존 클래스 코드를 건들지 않고 클라이언트 인터페이스를 통해 어댑터와 작동하기 때문에 개방 폐쇄 원칙(OCP)Visit Website을 만족한다.
      • 만일 추가로 필요한 메소드가 있다면 어댑터에 빠르게 만들 수 있다. 만약 버그가 발생해도 기존의 이름클래스에는 버그가 없으므로 Adapter 역할의 클래스를 중점적으로 조사하면 되고, 프로그램 검사도 쉬워진다.

    2. 패턴 단점

      • 새로운 인터페이스와 어려웠던댑터 부분
        클래스 세트를 도입해야 하기 때문에 코드의 복잡성이 증가한다.
      • 궁금때로는 직접 서비스(Adaptee) 클래스를 변경하는것이 간단할수 있는 경우가 있기 때문에 신중히 선택하여야 한다.
        • 점
      .

    3. 📚 참고 사항

    📢 논의하기

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

    1. 관련 자료 공유
    1. 논의하고 싶은 주제
      • 주제
        논의하고 싶은 내용을 간략히 정리합니다.
      • 설명
        논의하고 싶은 이유를 작성합니다.
    • Back to top