23장 프레젠터와 험블 객체

험블 객체 패턴

험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위, 테스트하기 쉬운 행위를 분리하는 방법임.

두개의 모듈 또는 클래스로 분리 하되 테스트하기 어려운 행위를 한곳으로 옮기는데 이는 험블 객체가 됨.

험블 객체에 속하지 않은 테스트하기 쉬운 나머지 행위는 다른 하나의 객체로 옮김.

GUI의 경우 화면을 보며 요소들이 필요한 위치에 표시되었는지 단위 테스트가 어려움.

하지만 GUI에서 수행되는 행위는 쉽게 테스트가능.

이 부류의 행위를 험블 객체 패턴을 사용하면 프레젠터와 뷰로 나눌 수 있음.

뷰는 험블 객체이며 테스트하기 어려움.

뷰는 데이터를 GUI로 이동시키지만 데이터를 직접 처리하지 않음.

프레젠터는 테스트하기 쉬운 객체임.

프레젠터는 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만듦.

이를 뷰로 전달함.

좋은 아키텍처는 테스트 용이성을 지녀야함.

험블 객체 패턴이 좋은 예이며, 테스트하는 행위를 어렵거나 쉬운것으로 분리하면 아키텍처 경계가 정의 되기 때문.

유스케이스 인터랙터와 데이터베이스 사이에는

데이터베이스 게이트웨이(다형적 인터페이스이며 CRUD 메서드를 포함)가 위치함.

유스케이스 계층은 SQL을 허용하지 않기 때문에 게이트웨이 인터페이스를 호출하며 이 인터페이스의 구현체는 데이터베이스 계층에 존재함.

이 구현체는 험블 객체임. → 직접 SQL사용함.

이와 달리 인터랙터는 험블 객체가 아님. → 애플리케이션에 특화된 업무 규칙을 캡슐화 함.

하이버네이트 같은 ORM(Object Relational Mapping)은 어느 계층인가?

객체는 데이터 구조(DB?)가 아님 → 객체 사용자 관점에서 객체의 데이터가 private이므로 사용자는 데이터를 볼 수 없음.

객체와 달리 데이터 구조(DB?)는 public 데이터 변수 집합임.

하이버네이트 같은 ORM은 데이터 베이스 계층임.

실제로 ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 또 다른 험블 객체 경계를 형성함.

서비스 경계를 생성하는 험블 객체 패턴도 발견할 수 있음.

외부로 부터 데이터를 수신하는 서비스의 경우, 서비스 리스너가 서비스 인터페이스로 부터 데이터를 수신하고, 데이터를 애플리케이션에서 사용할 수 있는 간단한 데이터 구조로 포맷을 변경 후 서비스 경계를 가로질러 내부로 전달됨. (프레젠터랑 뷰와 비슷함.)

아키텍처 경계마다 험블 객체 패턴을 발견할 수 있음. 그 경계를 테스트하기 어려운 것과 쉬운 것으로 분리하는 험블 객체 패턴을 적용하면 테스트 용이성도 크게 높아질 수 있음.