험블객체는 아키텍처 경계 정의 및 테스트 용이성을 가지게 해준다는 점에서 중요한듯..
험블 객체 패턴
- 험블 객체 패턴은 디자인 패턴으로 테스트하기 쉬운 행위와 테스트하기 어려운 행위를 분류한다.
- 험블 객체 패턴은 행위를 두개의 모듈 혹은 클래스로 나눈다.
- 테스트하기 어려운 모듈을 험블 객체로 옮긴다.
- 나머지 모듈에는 테스트하기 쉬운 행위를 모두 옮긴다.
- GUI의 경우 화면을 보며 요소들이 필요한 위치에 표시되었는지 단위 테스트가 어려움. 하지만 GUI에서 수행되는 행위는 쉽게 테스트가능.
- 이렇게 두 부류의 행위를 분리하여 프레젠터와 뷰라는 서로 다른 클래스로 만들 수 있다.
프레젠터와 뷰
뷰
- 뷰는 험블 객체이고 테스트가 어렵다.
- 이 객체에 포함된 코드는 가능한 간단하게 유지한다.
- 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지 않는다.
프레젠터
- 프레젠터는 테스트하기 쉬운 객체이다.
- 프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만든다.
- 뷰는 데이터를 화면으로 전달하는 간단한 일만 처리할 수 있게 된다.
테스트와 아키텍처
- 좋은 아키텍처는 테스트 용이성을 지녀야 한다.
- 험블 객체 패턴이 좋은 예인데, 행위를 테스트하기 쉬운 부분과 테스트 하기 어려운 부분으로 분리하면 아키텍처 경계가 정의되기 때문이다.
데이터베이스 게이트웨이
- 데이터베이스 게이트웨이는 유스케이스 인터랙터와 데이터베이스 사이에 위치하는 계층으로, 다형적 인터페이스이다.
- 애플리케이션이 데이터베이스에 수행하는 CRUD와 관련된 모든 메서드를 포함한다.
- 유스케이스 게층은 SQL을 허용하지 않기 때문에 필요한 메서드를 제공하는 게이트웨이 인터페이스를 호출해야 한다.
- 그리고 인터페이스의 구현체는 데이터베이스 계층에 위치하며,험블 객체가 된다.
- 어떤 면에서 테스트가 어려워지는 것이지?
- 반면 유스케이스 인터랙터는 업무 규칙을 캡슐화하기 때문에 험블 객체가 아니며, 테스트하기가 쉽다.
데이터 매퍼
- 하이버네이트 같은 ORM은 어느 계층에 속하는가?
- 데이터베이스 계층에 속한다. 실제로 ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 일종의 또 다른 험블 객체 경계를 형성한다.
ORM이란
Object Relational Mapping, 객체-관계 매핑
객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것을 말한다.
객체 지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용한다.
https://gmlwjd9405.github.io/2019/02/01/orm.html
서비스 리스너
- 서비스 경계를 생성하는 험블 객체 패턴을 발견할 수 있다.
- 외부로 데이터를 송신하는 서비스의 경우, 애플리케이션은 데이터를 간단한 데이터 구조 형태로 로드한 후, 이 데이터 구조를 경계를 가로질러서 특정 모듈로 전달한다. 그러면 해당 모듈은 데이터를 적절한 포맷으로 만들어서 외부 서비스로 전송한다.
- 외부로부터 데이터를 수신하는 서비스의 경우, 데이터를 애플리케이션에서 사용할 수 있게 간단한 데이터 구조로 포맷을 변경한다.
- 그러면 어디가 험블 객체가 되는거지??
하루하루 꾸준히