Developer Log
  • Wiki
  • Books
    • 리눅스 시스템 프로그래밍
      • 핵심 개념 소개
        • 시스템 프로그래밍
        • API와 ABI
        • 리눅스 프로그래밍의 개념
          • 파일과 파일시스템
          • 프로세스
          • 사용자와 그룹
          • 권한
          • 시그널
          • 프로세스간 통신
          • 에러 처리
    • 데이터 베이스 첫걸음
      • 데이터베이스란
        • 데이터베이스의 역할을 생각해 보자
          • 우리와 데이터베이스의 관계
          • 데이터베이스의 기본 기능
          • 데이터베이스 종류
      • 관계형 데이터베이스란
        • 대표적인 DBMS를 알아보자
          • 관계형 데이터베이스란
          • SQL 기초 지식
          • 관계형 데이터베이스를 다루기 위한 사전 지식
      • 데이터베이스에 얽힌 돈 이야기
        • 초기비용과 운영비용을 생각하자
      • 데이터베이스와 아키텍처 구성
        • 다중화에 대해 생각해보자
          • 아키텍처란
          • 데이터베이스의 아키텍처
            • 역사와 개요
              • Stand-alone
              • 클라이언트/서버
              • Web 3계층
            • 가용성과 확장성의 확보
          • DB 서버의 다중화
            • 클러스터링
            • 리플리케이션
          • 성능을 추구하기 위한 다중화 - Shared Nothing
          • 적합한 아키텍처를 설계하기 위해
      • DBMS를 조작할 때 필요한 기본 지식
        • MySQL 설치해보자
        • MySQL과 커넥션 만들기, 데이터베이스에 전화걸기
        • SQL과 관리 명령의 차이
        • 관계형 데이터베이스의 계층
      • SQL 문의 기본
        • SELECT 문으로 테이블 내용을 살펴보자
        • SELECT 문을 응용해보자
        • 데이터를 갱신, 삽입, 제거해보자
        • 뷰를 작성하고 복수 테이블에서 선택해보자
      • 트랜잭션과 동시성 제어
      • 테이블 설계의 기초
      • 백업과 복구
      • 성능을 생각하자
    • 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴
      • 객체 지향
        • 들어가기
        • 객체 지향
        • 다형성과 추상 타입
        • 재사용: 상속보단 조립
      • 설계 원칙 / DI와 서비스 로케이터
        • 설계 원칙: SOLID
          • 단일 책임 원칙(Single Responsibility Principle)
          • 개방 폐쇄 원칙(Open - Closed Principle)
          • 리스코프 치환 원칙(Liskov Substitution Principle)
          • 인터페이스 분리 원칙(Interface Segregation Principle)
          • 의존 역전 원칙(Dependency Inversion Principle)
          • SOLID 정리
        • DI(Dependency Injection)와 서비스 로케이터
      • 주요 디자인 패턴
        • 디지인 패턴이란?
        • 전략(Strategy) 패턴
        • 템플릿 메서드(Template Method) 패턴
        • 상태(State) 패턴
        • 데코레이터(Decorator) 패턴
        • 프록시(Proxy) 패턴
        • 어댑터(Adapter) 패턴
        • 옵저버(Observer) 패턴
        • 미디에이터(Mediator) 패턴
        • 파사드(Facade) 패턴
        • 컴포지트(Composite) 패턴
        • 널(Null) 객체 패턴
        • 팩토리 메서드 패턴
        • 커맨드 패턴
        • 추상 팩토리 패턴
    • 테스트 주도 개발
      • 1부
        • 다중 통화를 지원하는 Money 객체
        • 타락한 객체
        • 모두를 위한 평등
        • 프라이버시
        • 솔직히 말하자면
        • 돌아온 '모두를 위한 평등'
        • 사과와 오렌지
Powered by GitBook
On this page
  • 또 다른 오퍼레이션
  • 삼각 측량

Was this helpful?

  1. Books
  2. 테스트 주도 개발
  3. 1부

모두를 위한 평등

Previous타락한 객체Next프라이버시

Last updated 5 years ago

Was this helpful?

또 다른 오퍼레이션

Dollar 부작용을 값 객체를 사용하여 해결하였다. 여기서, 값 객체는 또 다른 오퍼레이션인 equals() 를 구현해야한다는 것을 암시한다. 따라서 equals() 오퍼레이션에 대한 테스트를 진행해보자.

  • $5 + 10CHF = $10(환율이 2:1 일 경우)

  • $5 * 2 = 10$

  • amount를 private으로 만들기

  • Dollar 부작용(side effect)?

  • Money 반올림?

  • equals()

  • hashCode()

값 객체의 동치성을 비교하기 위한 테스트 시나리는 아래와 같다.

@Test
void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
    
}

컴파일은 성공하지만, 테스트에 실패하는 것을 확인할 수 있다.

빠르게 초록 막대를 보기 위해 가짜 구현을 해보자.

public boolean equals(Object object) {
    return true;

}

다행히 초록막대까지 볼 수 있게 되었다. 이제 리팩토링을 해야한다.

사실 true 값은 다음과 같은 단계를 밟아 일반화할 수 있다.

  1. 5 == 5

  2. amount == 5

  3. amount == dollar.amount

이러한 명확한 케이스의 경우에는 위와 같이 쉽게 일반화할 수 있으나, 그렇지 않은 경우에는 켄트벡은 삼각 측량 전략을 제시해준다.

삼각 측량

삼각 측량 전략을 핵심은 유추이다. 두 개 이상의 예제를 통해서 코드를 일반화해 나가는 것이며, 새로 추가된 예제가 일반적인 해를 필요로 할때만 비로소 일반화한다.

책에서 "새로 추가된 예제가 일반적인 해를 필요할 때만 일반화한다." 라는 문장이 이해가 되질 않았다. 개인적인 해석으로 비추어보면, 현재 구체적으로 작성된 코드 상황에서 "필요한 만큼만 점진적으 일반화(확장) 하라"는 의미로 생각하였다. 현재 상황에 불필요한 정도로 일반화를 시키게 되면 예기치 못한 버그를 발생시킬 있기 때문이다.

또한, 켄트벡은 어떻게 리팩토링, 설해야 할지 전혀 감이 오질 않을 때 삼각측량 전략을 사용한다고 말한다. 굳이 삼각측량 방법만이 아닌, 코드와 테스트의 중복을 제거하고 일반적인 해법이 존재할 경우에는 그 방법을 구현하면 된다는 것이다.

@Test
void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
    assertFalse(new Dollar(5).equals(new Dollar(6)));

}

테스트는 당연히 실패할 것이다.

이제 동치성을 일반화해야 한다.

public boolean equals(Object object) {
    Dollar dollar = (Dollar) object;
    return amount == dollar.amount;

}

초록막대를 볼 수 있을 것이다.

지금까지 동일성 문제는 일시적으로 해결됐다. 하지만, 현재 프로그램이 어떤 변화 가능성을 지원해야 하는가? 몇몇 부분을 변경시켜보면 답이 명확해질 것이다.

  • Null or 다른 객체들과 비교한다면?

이런 상황은 지금 당장 필요하지 않으므로 할일 목록에 적어두기만 하자.

  • $5 + 10CHF = $10(환율이 2:1 일 경우)

  • $5 * 2 = 10$

  • amount를 private으로 만들기

  • Dollar 부작용(side effect)?

  • Money 반올림?

  • equals()

  • hashCode()

  • Equal null

  • Equal object