• 프레젠터는 험블 객체 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움

험블 객체 패턴

• 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안
• 행위들을 두 개의 모듈 또는 클래스로 나눈다. 이들 중 하나가 험블
• 가장 기본적인 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다
• 나머지 모듈에는 험블 객체에 속하지 않은, 테스트하기 쉬운 행위를 모두 옮긴다

프레젠터와 뷰

• 뷰는 험블 객체이고 테스트하기 어렵고, 코드는 가능한 한 간단하게 유지.

• 데이터를 GUI로 이동시키지만, 데이터를 직접 처리 X

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

• 프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것

• 화면에 표시되고 애플리케이션에서 어느 정도 제어할 수 있는 요소라면 무조건 뷰 모델 내부에 문자열, 불 또는 열거형 형태로 표현

• 뷰는 뷰 모델의 데이터를 화면으로 로드할 뿐이며, 이 외에 뷰가 맡은 역할은 전혀 없다

  → Humble

테스트와 아키텍처

• 테스트 용이성은 좋은 아키텍처가 지녀야 할 속성으로 오랫동안 알려져 왔다

• 험블 객체 패턴이 좋은 예이며, 행위를 테스트 하기 쉬운 부분과 어려운 부분으로 분리

  Ex) 프레젠터와 뷰 사이의 경계

데이터베이스 게이트웨이

• 유스케이스 인터랙터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 존재
• 이 게이트웨이는 다형적 인터페이스로, 데이터베이스에 수행하는 CRUD 작업과 관련된 모든 메서드를 포함
• 유스케이스 계층은 SQL을 허용 X, 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출