프레젠터와 험블 객체
23. 프레젠터와 험블 객체
험블 객체 패턴
행위들을 두 개의 모듈 또는 클래스로 나눈다. 이들 모듈 중 하나가 험블
가장 기본적인 본질을 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다.
험블 객체 패턴을 사용하여 행위를 분리 가능
프레젠터와 뷰
뷰는 험블 객체이고 테스트하기 어렵다.
프레젠터는 테스트하기 쉬운 객체다.
프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것
이를 통해 뷰는 데이터를 화면으로 전달하는 간단한 일만 처리하도록 만든다.
뷰는 뷰 모델의 데이터를 화면으로 로드할 뿐이며, 이 외에 뷰가 맡은 역할은 전혀 없다 -> humble
테스트와 아키텍처
테스트 용이성은 좋은 아키텍처가 지녀야 할 속성
데이터베이스 게이트웨이
유스케이스 인터랙터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 위치한다.
애플리케이션이 데이터베이스에 수행하는 작업과 관련된 모든 메서드를 포함한다.
유스케이스 계층은 SQL을 허용하지 않는다.
유스케이스 계층은 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출
인터페이스의 구현체는 데이터베이스 계층에 위치
구현체는 험블 객체
인터랙터는 험블 객체가 아님
그래서 테스트하기 쉽다. (ex. stub 또는 mock)
데이터 매퍼
사용자는 객체에서 public 메서드만 볼 수 있다.
사용자 관점에서 볼 때 객체는 단순히 오퍼레이션의 집합
객체와 달리 데이터 구조는 함축된 행위를 가지지 않는 public 변수의 집합
그래서 ORM보다는 ‘데이터 매퍼’라고 부르는 것이 맞다.
ORM은 데이터베이스 계층에 위치
ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 일종의 또 다른 험블 객체 경계를 형성
서비스 리스너
서비스도 험블 객체 발견 가능 -> 서비스 리스너
결론
각 아키텍처 경계마다 경계 가까이 숨어 있는 험블 객체 패턴을 발견할 수 있다.
이러한 아키텍처 경계에서 험블 객체 패턴을 사용하면 전체 시스템의 테스트 용이성을 높일 수 있다.
참조
- 클린 아키텍처(Clean Architecture)