빌더 메소드와 서비스 메소드 결합 - 나쁜 습관?

Question

이것은 일반적인 패턴/모범 사례 질문입니다. 저는 C#을 사용하고 있지만 자바와 다른 환경에도 똑같이 적용될 수 있다고 생각합니다. 라이브러리가 좀더 서비스 지향적 인 클래스와 손 잡고 사용되는 빌더 클래스를 노출하는 것은 매우 일반적입니다.

var users = db.Select("*").From("Users").ExecQuery<User>(); 

: 관심을 가질 그것은 단지 하나의 객체로 더 유창, 검색 가능한 API로 다음을 결합하는 유혹 라이브러리 개발자

var sql = SQLBuilder.Select("*").From("Users"); 
var users = db.ExecQuery<User>(sql); 

:이 작업을 수행 할 수있는 가상 ORM을 가지고 차이점은 API 표면에 있습니다. 후드 아래에서 우리는 여전히 적절한 관심을 가지고 여러 클래스를 가질 수 있습니다.

두 번째 접근법의 잠재적 단점 중 하나는 테스트 가능성입니다. 첫 번째 방법에서는 서비스 객체를 스텁링하는 것이 훨씬 쉽습니다. 하지만 라이브러리 개발자가 앱 시작 또는 테스트 설정에서 구성 할 수있는 정적 인 TestMode 속성을 노출하여 서비스를 호출하고 서비스 호출을 기록/변조해야한다고 알리는 경우 어떻게해야할까요?

테스트 가능성 이외의 순수한 관점에서 보면 두 번째 접근 방식에는 "잘못된"것이 있습니까? 저는 실제로 작업하고있는 몇 개의 라이브러리에서 이것을 수행 할 것인지에 대해 논쟁 중입니다. 그리고 주요한 붉은 깃발은 첫 번째 접근법이 훨씬 더 보편적 인 것처럼 보입니다.

Answer 1

공개 API 클래스가 유창한 인터페이스를 제공하고 작업을 올바르게 위임하는 한 두 번째 접근 방식은 괜찮다고 생각합니다.

Answer 2

나는 실제로 내 마이크로 OM의 다음 버전에 대한 두 번째 접근 방식을 취하려고합니다. 테스트 가능성이 어려워 질 것이라는 생각이 들지 않았습니다. 지금은 그렇지 않을 것 같습니다. 그 유창한 건축업자는 단순히 외관 일 뿐이며 적어도 마지막 부분은 쉽게 테스트 할 수있는 확장 방법으로 구현할 것입니다.