클래스에 매개 변수로 전달 된 연결에 대한 테스트 가능성에 미치는 영향은 무엇입니까?

Question

저는 OO 설계 문제로 작업하고 있습니다. 나는 혼란스러워하는 부분에 초점을 맞추고 코드를 제공하기보다는 텍스트로 설명하려고 노력할 것이다.

TaxPolicy 목록이 포함 된 SalesPolicy 클래스가 있습니다. TaxPolicy는 이름과 세율을 속성으로 갖는 세금 정책을 나타내는 추상 클래스입니다. TaxPolicy에는 accept라는 추상 메서드가 포함되어 있습니다. TaxPolicy의 구체적인 구현은 accept 메소드를 구현하고 TaxPolicy가 적용 가능한시기를 결정하는 논리를 제공해야합니다.

SalesEngine이라는 또 다른 클래스가 있습니다. SalesEngine에는 SalesPolicy가 있으며 SalesPolicy는 SalesEngine 생성자에 대한 매개 변수 중 하나입니다. SalesEngine은 SalesPolicy의 TaxPolicy 목록에있는 TaxPolicy가 accept 메소드를 호출하여 항목에 적용 가능한지 여부를 결정한 다음 그에 따라 세금을 계산합니다. 이전에 설명했듯이 SalesPolicy에는 TaxPolicy의 목록 인 단일 속성과 목록에 추가 할 메소드가 들어 있습니다.

내가 알아야 할 것은 SalesEngine 클래스의 SalesPolicy와 같은 매개 변수가 있는지 여부입니다. 이것이 테스트 가능한 코드의 관점에서 어떤 영향을 미칩니 까? SalesEngine가 사용자 또는 누구든지 이미 그들이 사용하고자하는 그 무엇 SalesPolicy 알고를 작성되는

public SalesEngine(SalesPolicy policy) { ... } 

:

Answer 1

는 나는 이런 시나리오를 가지고 완벽하게 정상적으로라고 생각합니다.

이 포함 도움이 될 수있는 또 다른 시나리오는 사용자가 들은 기본 생성자를 추가하여 당신이 할 수있는의 SalesEngine이 작성 될 때 사용하고 싶은 SalesPolicy 모르는 않는 경우와 setter 메소드입니다 :

나는 헌터의 당신의 설명을 합리적인 소리 대답에 동의

// default construtor 
public SalesEngine() { ... } 

// sets the sales policy 
public void setSalesPolicy(SalesPolicy policy){ ... } 

Answer 2

(그리고, 그것이 사용되는 방법에 따라,에서는 SalesPolicy 나중에 추가 할 수 있도록 유용 할 수 있습니다). 여기서는 테스트에 관한 귀하의 질문에 답변 해 드리겠습니다. 짧은 대답은 실제로 많이 바뀌지 않는다는 것입니다.

SalesEngine에 SalesPolicy 객체가 필요하다고 가정 할 때, SalesEnine은 일방적으로 또는 다른 방식으로 가져와야 할 것입니다. 아마도 테스트의 어려움은 SalesPolicy 객체의 대표적인 범위를 테스트하는 데있을 것입니다. 그러나 그것을 생성자의 일부로 제공하든 나중에 추가하든 실제로 더 쉽거나 어렵지는 않습니다.

반면 SalesEngine이 항상 SalesPolicy를 작동시킬 필요는없는 경우 헌터의 제안을 반드시 받아야합니다. 이는 더 적절한 인터페이스 일 것이며 SalesPolicy가 필요없는 경우 테스트 부담을 덜어줍니다.