프레젠터와 험블 객체

험블 객체 패턴

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

https://martinfowler.com/bliki/HumbleObject.html - 마틴 파울러

프레젠터와 뷰

• 뷰는 험블 객체이고 테스트하기 어렵다.

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

• 프리젠터는 테스트하기 쉬운 객체.
• 프리젠터의 역활은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것

• 뷰는 데이터를 건들지 않고 화면으로 전달하는 간단한 일만 한다.

• 화면에 표시되고 애플리케이션에서 어느 정도 제어할 수 있는 요소라면 뷰 모델 내부에 문자열, 불 또는 열거형 형태로 표현 한다.
• 뷰는 뷰 모델의 데이터를 화면으로 로드할 뿐이며, 이 외에 뷰가 맡은 역활은 전혀 없다.

테스트와 아키텍처

• 테스트 용이성은 좋은 아키텍처가 지녀야 할 속성
• 험블 객체 패턴이 좋은 예프레젠터와 뷰 사이의 경계는 이러한 경계중 하나이며, 이 밖에도 수많은 경계가 존재한다.

데이터베이스 게이트웨이

• 유스케이스 인터랙터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 위치한다.

• 이 게이트웨이는 다형적 인터페이스로, 애플리케이션이 데이터베이스에 수행하는 CRUD 작업과 관련된 모든 메서드를 포함한다. (django orm ??, spring jpa ??)

• 유스케이스 계층은 SQL을 허용하지 않는다.
• 그래서 유스케이스 계층은 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호츌한다.
• 인터페이스의 구현체는 데이터베이스 계층에 위치한다.

• 구현체에서 직접 SQL을 사용하거나 데이터베이스에 대한 임의의 인터페이스를 통해 게이트웨이의 메서드에 필요한 데이터에 접근한다.

• 인터렉터는 애플리케이션에 특화된 업무 규칙을 캡슐화하기 때문에 험블 객체가 아니다.
• 따라서 테스트하기 쉬운데, 게이트웨이는 스텁이나 테스트 더블로 적당히 교체할 수 있기 때문이다.

테스트 더블은 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행할 수 있도록 만들어주는 객체를 말한다. (링크)

데이터 매퍼

• 하이버네이트 같은 ORM은 어느 계층에 속한다고 봐야 하는가?

• 객체 관계 메퍼(Object Relational Mapper, ORM) 같은 건 존재하지 않는다고 한다.
• 객체는 데이터 구조가 아니기 때문이다.
• 데이터는 모두 private으로 선언되므로 객체의 사용자는 데이터를 볼 수 없다.
• 사용자는 객체에서 public 메서드만 볼 수 있다.

• 사용자관점에서 볼 때 객체는 단순히 오퍼레이션의 집합이다.

• 객체와 달리 데이터 구조는 함축된 행위를 가지지 않은 public 데이터 변수의 집합이다.

• ORM보다는 차라리 데이터 매퍼라고 하는게 좋아 보인다, 관계형 데이터베이스 테이블로부터 가져온 데이터를 데이터구조에 맞게 담아주기 때문이다.

• ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 일종의 다른 험블 객체 경계를 형성한다.

서비스 리스너

• 애플리케이션이 다른 서비스와 반드시 통신하거나, 서비스를 제공해야 한다면?
• 이 경우에도 서비스 경계를 생성하는 험블 객체 패턴을 발견할 수 있다.