아키텍쳐 패턴 사용시 interface 사용

Question

클린 아키텍쳐 사용한 예시들을 보면

MVP를 사용할 경우 Presenter, MVVM일 경우 ViewModel 로

*UseCase나 *Mapper등을 인터페이스를 형태로 넘겨받아 실행하도록 구현하고

구현체를 넘겨주는 방식을 대부분 사용하는데

 

의존성을 제거하고 결합도를 낮출 수 있다는것은

이해하겠고 의존성 주입을 통하여 내부 구현을 변경하지 않고 주입되는 모듈만 

수정하는게 가능하다는것도 알겠으나

모든 UseCase나 Repository 사용시 일일히 인터페이스를 만들어 구현하는것은

귀찮은 작업이 되고 클래스 수 증가로 복잡해지지 않을까하여.. 이것을 통해

얻어지는 다른 이익이 있는지 알고 싶습니다..

1.

public class TestViewModel {
	TestUsecase useCase;

	public TestViewModel(TestUsecase uc) {
		useCase = uc;
	}

	public void load() {
		useCase.load().subscribe(val -> {});
	}

	interface TestUsecase {
		Observable<String> load();
	}
}

 

2.

public class TestViewModel {
	TestUsecase useCase = new TestUsecase();

	public TestViewModel() {
	}

	public void load() {
		useCase.load().subscribe(val -> {});
	}
}

 

Usecase 변경시 1번의 경우 TestUsecaseImpl 클래스의 변경이 필요하고

2번의 경우 TestUsecase 클래스를 변경하면 됩니다.. 이 경우 

1번의 장점은 무엇인가요.. 혹시 test case 작성을 위해서 그런건가요..

test case를 작성하지 않을때는 필요가 없는건가요..

 

물론 모든경우에 필수가 아니라는 글도 보이지만

다른 소스들을 보면 작은 부분도 다들 그렇게 구현하는걸로 보여 드리는 질문입니다

다들 현업에서 개발시 어떻게 하는지 알고 싶습니다

Answer 1

이러한 의문이 시작되었으니 Dependency Inject 를 봐보세요

https://google.github.io/dagger/

Comments

DI 써도 인터페이스 만드는것은 매한가지 아닌가요..

---

네 만드는건 동일 합니다. +_+ 하지만 사용성이 확 올라가지요

귀찮은 작업이 되고 클래스 수 증가로 복잡해지지 않을까하여..
==> 그렇죠

이것을 통해 얻어지는 다른 이익이 있는지 알고 싶습니다..
==> 초기에는 그냥 코딩하는게 나은데 그 코드가 10년 정도 지났을때 기능 추가로 인해 답 안나오는 상황보다는, 일정한 인터페이스를 유지하면서 사용하는게 낫더군요

문제는 그 인터페이스가 수정되면서 그 에 따르는 문제점인데 이건 답이 안나와요 그래서 초기에 설계가 잘되어야 합니다.